On Wed, Jan 31, 2018 at 1:33 PM, Francis Ricci <[email protected]> wrote:
> * Most system allocators have inline metadata (i.e. 8 or 16 bytes to > the left of the chunk returned to the user). Those will have to be > poisoned somehow. Also, if you don't fully know how your allocator > works, you don't know what else remains unpoisoned nearby. > * How to create redzones? If you create both left and right redzone, > you probably waste too much space. If you create just one (e.g. right) > how do you guarantee that there is one at the left. > > These seem like issues with replacing asan_allocator.cc, I was > planning to go one level deeper and replace the sanitizer_common > sanitizer_allocator.cc (which seems to be much more generic, and > therefore easier to replace). > If you are brave :) In our environments we never try anything like this -- we simply disable tcmalloc and annotate various specialized allocators (e.g. freelists). So, we won't be able to advise you on this effort. > > > With our new ASAN (HWASAN, clang.llvm.org/docs/ > HardwareAssistedAddressSanitizerDesign.html) most of these things will > become much simpler since there is no quarantine or redzones any more. > > Maybe I will just wait for the new toy... > On AArch64, it should be usable in a few months, assuming you can patch your kernel (fingers crossed; and help is welcome!). On x86_64 -- good luck :) / :( > > On Wed, Jan 31, 2018 at 4:27 PM, Konstantin Serebryany > <[email protected]> wrote: > > \ > > > > On Wed, Jan 31, 2018 at 10:17 AM, Kuba Mracek <[email protected]> wrote: > >> > >> If you're careful enough (and make sure the allocator itself is not > >> instrumented, nor does it call *any* intercepted functions, or have > some way > >> of disabling interceptors when we're in the middle of an allocator > call), > >> this should be theoretically possible. > > > > > > ... but your warranty is void after that. :) > > > >> > >> > >> Dan is right about the quarantine, but it should be possible to build > the > >> quarantine as another layer on top an existing allocator. The quarantine > >> would just not call the underlaying free() unless the memory is to be > >> released from the quarantine. Actually, I think the quarantine in ASan > is > >> already decoupled from the allocator and could probably be used against > >> other allocators. > >> > >> Needless to say, doing this would require quite a lot of changes to the > >> existing allocator(s). > >> > >> Kostya, are there some extra features in the sanitizer allocator(s) > that a > >> system/user allocator wouldn't have? > > > > > > Off the top of my head: > > * Most system allocators have inline metadata (i.e. 8 or 16 bytes to the > > left of the chunk returned to the user). Those will have to be poisoned > > somehow. Also, if you don't fully know how your allocator works, you > don't > > know what else remains unpoisoned nearby. > > * How to create redzones? If you create both left and right redzone, you > > probably waste too much space. If you create just one (e.g. right) how do > > you guarantee that there is one at the left. > > * Where do you store stack traces associated with allocation and other > > metadata (thread is, user requested size)? > > * Quarantine is a huge PITA > > * How do you recycle the shadow after deallocating large heap chunks (aka > > madvise don't need)? > > * How do you report bugs with detailed position inside the heap chunk? > > * probably a couple more.... > > > > <ad> > > With our new ASAN (HWASAN, > > clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html) > > most of these things will become much simpler since there is no > quarantine > > or redzones any more. > > </ad> > > > > > > > > > >> > >> > >> Kuba > >> > >> > >> On Jan 12, 2018, at 8:49 AM, Dan Liew <[email protected]> wrote: > >> > >> Hi, > >> > >> On 12 January 2018 at 08:37, Francis Ricci <[email protected]> > >> wrote: > >> > >> Hi all, > >> > >> I may be missing something conceptually with the way ASan works, but > >> is there any reason that ASan couldn't pass-through allocations to the > >> user's allocator? For example: > >> > >> 1) User calls malloc() > >> 2) ASan intercepts malloc(), does checks/adds metadata, etc > >> 3) Instead of using the sanitizer allocator, ASan calls back into the > >> user's malloc(). > >> > >> Barring technical challenges here with the way interception works, is > >> there any reason this couldn't work from an allocation perspective? > >> Would it just be very slow? Or does the sanitizer allocator actually > >> do a lot of extra work besides just allocating memory? > >> > >> > >> I believe one of the reasons that ASan has a custom allocator is to > >> detect use-after-free bugs. > >> When memory is freed, that memory is placed in a quarantine area. By > >> placing the freed memory > >> in the quarantine, future calls to `malloc()` can't return the freed > >> memory (unless the memory gets evicted from the quarantine) and ASan > >> can record in its shadow > >> memory that the region of memory that was freed should not be > >> accessed. Then if the user's code tries to read or write to this freed > >> memory > >> ASan can report a use-after-free error. > >> > >> If you used your own allocator in ASan it might (and probably would > >> given that its likely optimized for performance, not bug finding) > >> return regions of memory that have previously been freed and thus ASan > >> would miss use-after-free bugs. > >> > >> HTH, > >> Dan. > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "address-sanitizer" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an > >> email to [email protected]. > >> For more options, visit https://groups.google.com/d/optout. > >> > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "address-sanitizer" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an > >> email to [email protected]. > >> For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "address-sanitizer" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [email protected]. > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "address-sanitizer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
