On Mon, 2017-08-07 at 11:39 -0700, Kees Cook wrote: > On Mon, Aug 7, 2017 at 11:26 AM, Kostya Serebryany <kcc@xxxxxxxxxx> > wrote: > > +eugenis@ for msan > > > > On Mon, Aug 7, 2017 at 10:33 AM, Kees Cook <keescook@xxxxxxxxxx> > > wrote: > > > > > > On Mon, Aug 7, 2017 at 10:24 AM, Dmitry Vyukov <dvyukov@xxxxxxxxxx > > > > 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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
