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

[Evgeniy Stepanov via llvm-commits]

eugenis added a comment.

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.


http://reviews.llvm.org/D13781