Re: binfmt_elf: use ELF_ET_DYN_BASE only for PIE breaks asan

[Kostya Serebryany <kcc@xxxxxxxxxx>]

On Mon, Aug 7, 2017 at 12:24 PM, Kees Cook <keescook@xxxxxxxxxx> wrote:

On Mon, Aug 7, 2017 at 12:03 PM, Kostya Serebryany <kcc@xxxxxxxxxx> wrote:
>
>
> On Mon, Aug 7, 2017 at 11:57 AM, Kees Cook <keescook@xxxxxxxxxx> wrote:
>>
>> On Mon, Aug 7, 2017 at 11:51 AM, Evgenii Stepanov <eugenis@xxxxxxxxxx>
>> wrote:
>> > On Mon, Aug 7, 2017 at 11:40 AM, Kees Cook <keescook@xxxxxxxxxx> wrote:
>> >> On Mon, Aug 7, 2017 at 11:36 AM, Evgenii Stepanov <eugenis@xxxxxxxxxx>
>> >> wrote:
>> >>> MSan is 64-bit only and does not allow any mappings _outside_ of these
>> >>> regions:
>> >>> 000000000000 - 010000000000 app-1
>> >>> 510000000000 - 600000000000 app-2
>> >>> 700000000000 - 800000000000 app-3
>> >>>
>> >>> https://github.com/google/sanitizers/issues/579
>> >>>
>> >>> It sounds like the ELF_ET_DYN_BASE change should not break MSan.
>> >>
>> >> Hah, so the proposed move to 0x1000 8000 0000 for ASan would break
>> >> MSan. Lovely! :P
>> >
>> > That's unfortunate.
>> > This will not help existing binaries, but going forward the mapping
>> > can be adjusted at runtime to anything like
>> > 000000000000 .. A
>> > 500000000000 + A .. 600000000000
>> > 700000000000 .. 800000000000
>> > i.e. we can look at where the binary is mapped and set A to anything
>> > in the range of [0, 1000 0000 0000). That's still not compatible with
>> > 0x1000 8000 0000 though.
>>
>> So A is considered to be < 0x1000 0000 0000? And a future MSan could
>> handle a PIE base of 0x2000 0000 0000? If ASan an TSan can handle that
>> too, then we could use that as the future PIE base. Existing systems
>> will need some sort of reversion.
>>
>> The primary concerns with the CVEs fixed with the PIE base commit was
>> for 32-bit. While it is possible to collide on 64-bit, it is much more
>> rare. As long as we have no problems with the new 32-bit PIE base, we
>> can revert the 64-bit base default back to 0x5555 5555 4000.
>
>
> Yes, please!!

For the revert, can you clarify which architectures this is a problem
for?

We have seen complaints on x86_64 only. 

This is also the only arch where we use the small shadow offset 7fff8000. 

But I can't verify this on other platforms. :( 

On ARM/Android we use zero shadow base. 

eugenis@, do we have the problem on Android? 

Do we have the solution that will also keep the existing msan usable?  

 

And confirm that the current 32-bit PIE base is not bugged? I'd
like to minimize the revert.

0x40000000? 

Yes, that doesn't affect asan (and tsan/msan are not present in 32-bit). 

 

 

-Kees

--
Kees Cook
Pixel Security