* 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). > 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 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.
