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.
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? 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] > <mailto:[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] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <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.
