On Wed, 4 Jan 2023 18:41:05 GMT, Justin King <jck...@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
