Bug 124744 – [ASAN] Use manual poisoning of mmap'ed regions in WTF and JavaScriptCore

• Status: NEW
• Component: JavaScriptCore

[David Farler]

The Address Sanitizer is likely ignoring JavaScriptCore's allocated regions since we are using mmap directly. In order to get the real benefits of ASan in JSC, we're probably going to need to manually poison/un-poison allocations in WTF. This will need the following:

- Conditional macro defines on __has_feature(address_sanitizer) || defined(__SANITIZE_ADDRESS__)
- Conditional include of compiler-rt's sanitizer/asan_interface.h in order to get __asan_poison_memory_region and __asan_unpoison_memory_region
- Simple macros for poisoning / unpoisoning regions that include the above conditional

An example usage would be something like this from the wiki:

#if __has_feature(address_sanitizer) || defined(__SANITIZE_ADDRESS__)
#define ASAN_POISON_MEMORY_REGION(addr, size) \
  __asan_poison_memory_region((addr), (size))
#define ASAN_UNPOISON_MEMORY_REGION(addr, size) \
  __asan_unpoison_memory_region((addr), (size))
#else
#define ASAN_POISON_MEMORY_REGION(addr, size) \
  ((void)(addr), (void)(size))
#define ASAN_UNPOISON_MEMORY_REGION(addr, size) \
  ((void)(addr), (void)(size))
#endif

[David Farler]

If ASan doesn't intercept mmap, I'll investigate poisoning there also if it makes sense.

[David Farler]

(In reply to comment #1)
> If ASan doesn't intercept mmap, I'll investigate poisoning there also if it makes sense.

Sorry, by "there" I mean in LLVM's compiler-rt ASan runtime itself, instead of writing custom poisoners in WebKit.

[David Kilzer (:ddkilzer)]

Alternate strategies:
1. Teach clang ASan how to poison mmap regions and then check them itself.  (Benefit is that it would cover all mmap regions used in any part of the codes.)  Should definitely have a bug on http://llvm.org/bugs/ regardless, and CC Google folks in case they want to implement it.
2. Make JavaScriptCore use system malloc when compiling with -DUSE_SYSTEM_MALLOC=1.

I think we should investigate Item 1 first since it would be the most benefit to the most people if implemented.

Item 2 is probably the last thing we should try since it would be better to instrument what customers use if we did our own poison checking in JSC for mmap regions.

[David Farler]

(In reply to comment #3)
> Alternate strategies:
> 1. Teach clang ASan how to poison mmap regions and then check them itself.  (Benefit is that it would cover all mmap regions used in any part of the codes.)  Should definitely have a bug on http://llvm.org/bugs/ regardless, and CC Google folks in case they want to implement it.


I just realized that you probably don't really need to have clang itself always poison mmap regions because if you write outside of your mmap range, past the page boundary (in case you aren't aligned), you'll get a segfault anyway. You couldn't poison beyond the page boundary either, for obvious reasons.

> 2. Make JavaScriptCore use system malloc when compiling with -DUSE_SYSTEM_MALLOC=1.
> 
> I think we should investigate Item 1 first since it would be the most benefit to the most people if implemented.
> 
> Item 2 is probably the last thing we should try since it would be better to instrument what customers use if we did our own poison checking in JSC for mmap regions.

Two alternatives for approach 2.

Since we aren't using FastMalloc or TCSystemAlloc, we can ignore those. The only other place that uses mmap is OSAllocatorPosix, which is a pretty simple source file.

A. Work with the mmap infrastructure

B. Use malloc/free

I'll have to look at this API a little bit. There are two dimensions of memory use in the API: reserve/release and commit/decommit, so it's not just a simple give/take notion corresponding to malloc/free.

I tested the mmap usage and it works fine, although the message given is "use-after-poison" with the poisoned bytes labeled with 0xf7. Besides the implementation detail, ASan gives you different too-far-left and too-far-right poison boundary labels when using malloc'ed regions, whereas manual poisoning just has the one label. Something to think about.