On Mon, Aug 7, 2017 at 11:52 AM, Kees Cook wrote: > On Mon, Aug 7, 2017 at 11:48 AM, Daniel Micay > wrote: > > On Mon, 2017-08-07 at 11:39 -0700, Kees Cook wrote: > >> On Mon, Aug 7, 2017 at 11:26 AM, Kostya Serebryany > >> wrote: > >> > +eugenis@ for msan > >> > > >> > On Mon, Aug 7, 2017 at 10:33 AM, Kees Cook > >> > wrote: > >> > > > >> > > On Mon, Aug 7, 2017 at 10:24 AM, Dmitry Vyukov >> > > > 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 > Is it possible to implement some userspace<=>kernel interface that will allow applications (sanitizers) to request *fixed* address ranges from the kernel at startup (so that the kernel couldn't refuse)? --kcc > > 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 >