From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.161.197]) by kanga.kvack.org (Postfix) with ESMTP id 6C2856B02F3 for ; Mon, 7 Aug 2017 14:56:09 -0400 (EDT) Received: by mail-yw0-f197.google.com with SMTP id n83so17706538ywn.10 for ; Mon, 07 Aug 2017 11:56:09 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com. [2607:f8b0:4002:c05::235]) by mx.google.com with ESMTPS id h130si1790082ywc.399.2017.08.07.11.56.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Aug 2017 11:56:08 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id s143so8276218ywg.1 for ; Mon, 07 Aug 2017 11:56:08 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1502131739.1803.12.camel@gmail.com> From: Kostya Serebryany Date: Mon, 7 Aug 2017 11:56:06 -0700 Message-ID: Subject: Re: binfmt_elf: use ELF_ET_DYN_BASE only for PIE breaks asan Content-Type: multipart/alternative; boundary="001a114da36242645205562e669f" Sender: owner-linux-mm@kvack.org List-ID: To: Kees Cook Cc: Daniel Micay , Dmitry Vyukov , Michal Hocko , Andrew Morton , "linux-mm@kvack.org" , Rik van Riel , Reid Kleckner , Peter Collingbourne , Evgeniy Stepanov --001a114da36242645205562e669f Content-Type: text/plain; charset="UTF-8" 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 > --001a114da36242645205562e669f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Aug 7, 2017 at 11:52 AM, Kees Cook <keescook@google.com&= gt; wrote:
<= div class=3D"h5">On Mon, Aug 7, 2017 at 11:48 AM, Daniel Micay <danielmicay@gmail.com> 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@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 on= ly for PIE" patch:
>> > > >
>> > > > https://gith= ub.com/torvalds/linux/commit/eab09532d40090698b05a07
>> > > > c1c87f39fdbc5fab5
>> > > > breaks user-space AddressSanitizer. AddressSanitize= r makes
>> > > > assumptions
>> > > > about address space layout for substantial performa= nce gains.
>> > > > There
>> > > > are multiple people complaining about this already:=
>> > > > https://github.com/google/sanitizers/issues/837
>> > > > https://twitter.com/k= ayseesee/status/894594085608013825
>> > > > https://bugzilla.kernel.= org/show_bug.cgi?id=3D196537
>> > > > AddressSanitizer maps shadow memory at [0x00007fff7= 000-
>> > > > 0x10007fff7fff]
>> > > > expecting that non-pie binaries will be below 2GB a= nd pie
>> > > > binaries/modules will be at 0x55 or 0x7f. This is n= ot the first
>> > > > time
>> > > > kernel address space shuffling breaks sanitizers. T= he last one
>> > > > was the
>> > > > move to 0x55.
>> > >
>> > > What are the requirements for 32-bit and 64-bit memory l= ayouts 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=3Daddress dummy.c -m32 && ASAN_OPT= IONS=3Dverbosity=3D1
>> > ./a.out
>> > 2>&1 | grep '||'
>> > > > `[0x40000000, 0xffffffff]` || HighMem=C2=A0 =C2=A0 = ||
>> > > > `[0x28000000, 0x3fffffff]` || HighShadow ||
>> > > > `[0x24000000, 0x27ffffff]` || ShadowGap=C2=A0 || >> > > > `[0x20000000, 0x23ffffff]` || LowShadow=C2=A0 || >> > > > `[0x00000000, 0x1fffffff]` || LowMem=C2=A0 =C2=A0 = =C2=A0||
>> >
>> > %
>>
>> For 32-bit, it looks like the new PIE base is fine, yes? 0x0004000= 00UL
>
> Need to consider the ASLR shift which is up to 1M with a default kerne= l
> 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 sta= ck
> base to that so that's a further significant change, increasing th= e
> 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<=3D>kernel interface that will = allow applications (sanitizers)
to request *fixed* address ra= nges from the kernel at startup (so that the kernel couldn't refuse)?= =C2=A0

--kcc=C2=A0

=C2=A0=

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

--001a114da36242645205562e669f-- -- 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: email@kvack.org