On Wed, Mar 13, 2019 at 12:21:15PM +0100, Eric Botcazou wrote:
> > 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)
>
> OK, I can certainly do the last thing.
>
> > 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.
>
> Yes, you need a kernel configured for SPARC-T4 or later.
>
> > I think hardcoding one of the 4 choices in the ABI is undesirable.
>
> Frankly I'm not sure why you care about the ABI of the AddressSanitizer...
Because in real world, people do build asan instrumented shared libraries etc.,
sometimes as second set of libs and not everybody builds stuff for just his
own machine. Plus, by hardcoding it in the compiler you even don't give a
choice to change it for other systems. There is no runtime diagnostics if
you mix objects or shared libraries or executable with different settings.
> > 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.
>
> But you still need to chop the high bits, otherwise you end up in the hole.
Not if the >> 3 shift is arithmetic shift.
For the
[0x0000080000000000UL,0xfffff80000000000UL)
[0x0000800000000000UL,0xffff800000000000UL)
[0x0008000000000000UL,0xfff8000000000000UL)
[0x0010000000000000UL,0xfff0000000000000UL)
if shadow is shadow_offset + ((long) addr >> 3), then shadow_offset could be
e.g.
0x0000030000000000UL
0x0000300000000000UL
0x0003000000000000UL
0x0004000000000000UL
or something similar, the shadow memory would map into something below the
hole (of course one needs to also take into account where exactly the
dynamic linker, stack and shared libraries are usually mapped).
Jakub
