RFR: JDK-8298908: Instrument Metaspace for ASan [v3]

[Thomas Stuefe]

On Wed, 4 Jan 2023 18:41:05 GMT, Justin King <jcking at openjdk.org> wrote:

> > Does Asan assume 8-byte-alignment? I'm hesitant to set this alignment in stone since Metaspace could be allocated, at least now, with smaller alignments. We don't do this now, but I'd like to keep the option open. But see my proposal below, if you follow that, alignment should be no problem.
> 
> IIRC ASan doesn't require 8 byte alignment, but it helps with accuracy, as ASan will need to round to the correct alignment. So it may end up over unpoisoning and under poisoning.

Okay, but that would make it pretty much unusable with fine-grained allocators that use smaller alignment since you'd risk false positives/negatives.

> 
> > How is 32-bit handled?
> 
> ASan works for both 32-bit and 64-bit. https://github.com/google/sanitizers/wiki/AddressSanitizerAlgorithm
> 
> > Can you please explain the poisoning and unpoisening a bit? How is the use-after-free instrumentation done (I assume build time instrumentation?) and how fast is it, e.g. how fine granular can you go - can you have millions of micro-ranges, is that still feasible and reasonable? Should we poison before munmap?
> 
> https://github.com/google/sanitizers/wiki/AddressSanitizerAlgorithm
> 
> `use-after-free` is implemented at runtime and is enabled by default for ASan. Detecting both `use-after-free` and `use-after-poison` is done via instrumentation at compile time. The cost to detect either should be the same. Poisoning/unpoisoning is implemented very similarly. Poisoning/unpoisoning is a simple calculation to map the address range to the shadow range and then a simple `memset` of the shadow range, effectively.

That explains (I think) another question I had. Which is how are overlapped ranges handled. Given four subsequent addresses a b c d, I should be able to poison [b,c) and then poison [a,d), right? Or do I have to take care to only pass non-overlapping mappings?

That would have mattered for Metaspace had you insisted on poisoning deallocated blocks, since those live inside chunks.



> @tstuefe Okay, I switched to per chunk handling. I also made unpoisoning on destruction of VirtualSpaceNode unconditional, to ensure future memory mapping that happens to reuse the address doesn't trigger use-after-poison unexpectedly. This should be extremely rare, but better safe than sorry.

Great. I'll take a look next week since I still have vacation.

-------------

PR: https://git.openjdk.org/jdk/pull/11702