> If you are brave :) 😂
> On AArch64, it should be usable in a few months, assuming you can patch your kernel (fingers crossed; and help is welcome!). Will keep my eyes open for this! On Wed, Jan 31, 2018 at 4:38 PM, Konstantin Serebryany < [email protected]> wrote: > > > 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/HardwareAs >> sistedAddressSanitizerDesign.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. > -- 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.
