[PATCH] D13781: [sanitizer] Use same shadow offset for aarch64

[Adhemerval Zanella via llvm-commits]

zatrazz added a comment.

In http://reviews.llvm.org/D13781#270443, @eugenis wrote:

> In http://reviews.llvm.org/D13781#268809, @zatrazz wrote:
>
> > In http://reviews.llvm.org/D13781#268230, @rengolin wrote:
> >
> > > Hi Adhemerval,
> > >
> > > What is the impact of this change? I remember that using 39-bits config on 42-bits broke a lot of tests. Is the addition a cure for all those problems?
> >
> >
> > I tested on 42-bit without no regressions. It will use different mappings, but I also sent a compiler-rt
> >  to adjust this [1]. The only downside is for 39-bits it will need to cover a 42-bit VMA in TwoLevelByteMap
> >  thus consume slight more memory in mapping (which is something I think we can live with).
> >
> > > What about the other sanitizers? Some of them, like TSAN, run together with ASAN, shouldn't the settings be the same on both?
> >
> >
> > That's not true, tsan can not be run with asan (trying to use -fsanitize=address,thread issues an error).
> >  Also conceptually it is not really possible: memory operations are handled different regarding
> >  these two sanitizers and memory mapping is defined independently for each one. You can have some
> >  sanitizer working together, like asan and lsan, but it is due both use the same infrastructure.
> >
> > > For the next steps, do you think this will work with all the other sanitizers?
> >
> >
> > I am currently trying to make it happen for msan and it looks feasible: the strategy I am using is
> >  to use the same instrumentation for both 39 and 42-bit VMA and use the same mapping for
> >  both. The idea is define a transformation that will translate 39-bit segments to 39-bit shadow
> >  addresses and for 39-bit vma only maps segments up to 39-bits. For instance, using the 
> >  39-bit msan instrumentation scheme for a 42-bit VMA:
> >
> >   {0x05500000000ULL, 0x055FFFFFFFFULL, MappingDesc::SHADOW,  "app-1"},
> >   {0x04000000000ULL, 0x04100000000ULL, MappingDesc::SHADOW,  "shadow-1"},
> >   {0x04300000000ULL, 0x04400000000ULL, MappingDesc::ORIGIN,  "origin-1"},
> >   {0x07000000000ULL, 0x07FFFFFFFFFULL, MappingDesc::SHADOW,  "app-2"},
> >   {0x04100000000ULL, 0x04300000000ULL, MappingDesc::SHADOW,  "shadow-2"},
> >   {0x04400000000ULL, 0x04600000000ULL, MappingDesc::ORIGIN,  "origin-2"},
> >   {0x2AA00000000ULL, 0x2AAFFFFFFFFULL, MappingDesc::SHADOW,  "app-3"},
> >   {0x2C300000000ULL, 0x2C400000000ULL, MappingDesc::SHADOW,  "shadow-3"},
> >   {0x2C600000000ULL, 0x2C700000000ULL, MappingDesc::ORIGIN,  "origin-3"},
> >   {0x2AA00000000ULL, 0x2AAFFFFFFFFULL, MappingDesc::SHADOW,  "app-4"},
> >   {0x2C300000000ULL, 0x2C400000000ULL, MappingDesc::SHADOW,  "shadow-4"},
> >   {0x2C600000000ULL, 0x2C700000000ULL, MappingDesc::ORIGIN,  "origin-4"},
> >   {0x3F000000000ULL, 0x3FFFFFFFFFFULL, MappingDesc::SHADOW,  "app-5"},
> >   {0x3C100000000ULL, 0x3C300000000ULL, MappingDesc::SHADOW,  "shadow-5"},
> >   {0x3C400000000ULL, 0x3C600000000ULL, MappingDesc::ORIGIN,  "origin-5"},
> >   
> >
> > For 39-bit VMA libsanitizer will only map the segments until 0x8000000000 and for 42-bit 
> >  VMA it will maps all the segments.
>
>
> Wow this is complicated :)
>  There's nothing bad about that, and the general approach sounds good.
>  Also, while you are at it, study all execution modes (PIE/non-PIE, ASLR enabled/disabled) and see if it is possible to devise a mapping that would support as many of those as possible. Also, consider MAP_32BIT - none of the regions on your list include the first 4GB of the address space.
>  See https://github.com/google/sanitizers/issues/579 for the recent linux/x86_64 mapping change.


I checked for ASLR enabled/disabled and the mappings seems fine:

- For 39 bits text segments are places between 0x00400000-00XXXXXX for binary itself with [heap] randomized between 0x0000000-0xFFFFFFFF. High text address are either place at 0x7fb7XXXXXXX or randomized between 0x7fXXXXXXXXX. For 42-bits, lower address follow the same pattern with high addresses being randomized between 0x3f00000000-0x3fFFFFFFFFF.
- I have tested for PIE build yet, I will check that.
- MAP_32BIT is valid only for x86-64 (64-bit programs).


http://reviews.llvm.org/D13781