Re: binfmt_elf: use ELF_ET_DYN_BASE only for PIE breaks asan

[Daniel Micay <danielmicay@gmail.com>]

On Mon, 2017-08-07 at 11:39 -0700, Kees Cook wrote:
> On Mon, Aug 7, 2017 at 11:26 AM, Kostya Serebryany <kcc@google.com>
> wrote:
> > +eugenis@ for msan
> > 
> > On Mon, Aug 7, 2017 at 10:33 AM, Kees Cook <keescook@google.com>
> > wrote:
> > > 
> > > On Mon, Aug 7, 2017 at 10:24 AM, Dmitry Vyukov <dvyukov@google.com
> > > > wrote:
> > > > The recent "binfmt_elf: use ELF_ET_DYN_BASE only for PIE" patch:
> > > > 
> > > > https://github.com/torvalds/linux/commit/eab09532d40090698b05a07
> > > > c1c87f39fdbc5fab5
> > > > breaks user-space AddressSanitizer. AddressSanitizer makes
> > > > assumptions
> > > > about address space layout for substantial performance gains.
> > > > There
> > > > are multiple people complaining about this already:
> > > > https://github.com/google/sanitizers/issues/837
> > > > https://twitter.com/kayseesee/status/894594085608013825
> > > > https://bugzilla.kernel.org/show_bug.cgi?id=196537
> > > > AddressSanitizer maps shadow memory at [0x00007fff7000-
> > > > 0x10007fff7fff]
> > > > expecting that non-pie binaries will be below 2GB and pie
> > > > binaries/modules will be at 0x55 or 0x7f. This is not the first
> > > > time
> > > > kernel address space shuffling breaks sanitizers. The last one
> > > > was the
> > > > move to 0x55.
> > > 
> > > What are the requirements for 32-bit and 64-bit memory layouts for
> > > ASan currently, so we can adjust the ET_DYN base to work with
> > > existing
> > > ASan?
> > 
> > 
> > 32-bit asan shadow is 0x20000000 - 0x40000000
> > 
> > % clang -fsanitize=address dummy.c -m32 && ASAN_OPTIONS=verbosity=1
> > ./a.out
> > 2>&1 | grep '||'
> > > > `[0x40000000, 0xffffffff]` || HighMem    ||
> > > > `[0x28000000, 0x3fffffff]` || HighShadow ||
> > > > `[0x24000000, 0x27ffffff]` || ShadowGap  ||
> > > > `[0x20000000, 0x23ffffff]` || LowShadow  ||
> > > > `[0x00000000, 0x1fffffff]` || LowMem     ||
> > 
> > %
> 
> For 32-bit, it looks like the new PIE base is fine, yes? 0x000400000UL

Need to consider the ASLR shift which is up to 1M with a default kernel
configuration but up to 256M with the maximum configurable entropy.

On 64-bit, it's a lot larger... and the goal is also tying the stack
base to that so that's a further significant change, increasing the
address space used when the maximum configurable entropy is used.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>