Re: [patch] Fix ASAN failures on SPARC64/Linux

[Jakub Jelinek <jakub at redhat dot com>]

On Wed, Mar 13, 2019 at 11:17:49AM +0100, Jakub Jelinek wrote:
> On Wed, Mar 13, 2019 at 10:58:41AM +0100, Eric Botcazou wrote:
> > > Is the size of the virtual address space hole constant though (and will it
> > > remain constant)?
> > 
> > The kernel sources say that it's constant and with this position for SPARC-T4 
> > and later.  It's different (larger hole) for SPARC-T3 and earlier but I cannot 
> > really test.  I don't think that it will change for a given processor.
> > 
> > > E.g. on powerpc64 or aarch64 there are in each case like 4-5 different VA
> > > size configurations over the last 10+ years of kernel history and
> > > configuration options and fortunately all that is hidden inside of libasan,
> > > if you have older gcc and run into an unsupported VA configuration, all it
> > > takes is update libasan to one that supports it and binaries continue to
> > > work.
> > 
> > But a few targets have hardcoded VA size in TARGET_ASAN_SHADOW_OFFSET too.
> 
> It actually is something that works with all the VA sizes that are
> supported.

The kernel says ATM that there are following possibilities for the hole:
[0x0000080000000000UL,0xfffff80000000000UL)
[0x0000800000000000UL,0xffff800000000000UL)
[0x0008000000000000UL,0xfff8000000000000UL)
[0x0010000000000000UL,0xfff0000000000000UL)

So, when using the MemToShadow(addr) (1UL << 43) + ((addr << 12) >> (12 + 3)) mapping,
the first valid address above the hole will have shadow at:
 0x0002070000000000UL (will not work, as it is inside of the VA hole)
 0x0001f80000000000UL (will not work, as it is inside of the VA hole)
 0x0001080000000000UL (this is the only case that will work)
 0x0000080000000000UL (will not work; that would mean that both the low and
		       high memory share the same shadow memory;
		       it could be made to work by doing mmap
		       (0xfff0000000000000UL, 0x8000000000000UL, MAP_FIXED, PROT_NONE)
		       at libasan initialization and failing if that doesn't
		       succeed)
Note for the first VA layout even the shadow offset 1UL << 43 will not work
at all even for the low part of the memory, as all of shadow memory is then in the
hole.

I think hardcoding one of the 4 choices in the ABI is undesirable.

Another possibility is instead of using constant offset + 2 shifts use a
variable offset + the normal >> 3, where the offset would be chosen by the
runtime library depending on the VA hole size and where the shadow for the
high memory would precede the shadow for the low memory.

	Jakub