[llvm-dev] Dynamic VMA in Sanitizers for AArch64

[Jakub Jelinek via llvm-dev]

On Tue, Sep 29, 2015 at 02:38:18PM +0100, Renato Golin wrote:
> My assumption is based on what I understood from my talks with various
> people in sanitizers, libraries, GCC, LLVM and the kernel. Please,
> correct me if I'm wrong.
> 
> IIUC, using larger VMAs on kernels with smaller VMAs work, but
> restrict the space that you can use as a shadow region, thus limiting
> the size of programs you can run with the sanitizers. Also, the higher
> you go, the higher is the levels of indirection you need to use
> memory, so using higher VMAs may be more of a performance hit than it
> should. This may not be such a big deal for 42 vs. 39 bits, but the
> new kernels will come with 48 bits, and there's talks to push it up to
> 56 bits in the near future.
> 
> So, there are only three paths we can take:
> 
> 1. Keep it constant, today at 42, and increase the constant slowly, as
> kernels start popping in with higher VMAs. This could slow down for
> large values of VMA and low values on kernel.
> 
> 2. Create a compiler flag -mvma=NN. This would be as fast as native
> when chosen correctly, but could break if lower than the machine's
> VMA.
> 
> 3. Make it dynamic, so that the VMA value doesn't matter.

You are mixing things up.  The size of virtual address space in bits is one
thing, and another one is the chosen ASAN shadow offset.
The way ASAN works is that for a normal memory address
corresponding shadow memory address is (addr >> 3) + shadow_offset
(the 3 hardwired at least into GCC, not sure about llvm).
Right now at least in GCC aarch64 shadow_offset is 1UL << 36, constant.
All you need to do is the math how the address space needs to look out
for the various VMA sizes, and whether it clashes with where the kernel
will normally try to allocate shared libraries or the stack.
If you have libsanitizer built for a particular VMA size and that
1UL << 36 shadow offset, you can also just ask the library to be verbose
through env var and dump you the layout (ASAN_OPTIONS=verbosity=1).
You'll get several regions of normal memory, several regions of shadow
memory and perhaps some gaps (shadow memory of shadow memory, which isn't
really useful).  What matters is whether the normal memory regions
in all those layouts cover normal location of stack, binaries, and where
kernel maps shared libraries.

	Jakub