On Mon, Aug 7, 2017 at 11:48 AM, Daniel Micay <danielmicay@xxxxxxxxx> wrote: > 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. We've got two things to do upstream: - fix the default kernel for ASan - maximize the entropy optionally I.e. the first is a userspace regression that needs to be fixed for existing ASan user. The second is developing a future path to maximizing the non-default entropy, for which new versions of *San would want to detect and use. -Kees -- Kees Cook Pixel Security -- 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>
