From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-f200.google.com (mail-yw0-f200.google.com [209.85.161.200]) by kanga.kvack.org (Postfix) with ESMTP id 05F2E6B025F for ; Mon, 7 Aug 2017 15:26:45 -0400 (EDT) Received: by mail-yw0-f200.google.com with SMTP id k20so19342686ywe.7 for ; Mon, 07 Aug 2017 12:26:45 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com. [2607:f8b0:4002:c05::234]) by mx.google.com with ESMTPS id w84si1929585ywb.644.2017.08.07.12.26.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Aug 2017 12:26:44 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id l82so8737195ywc.2 for ; Mon, 07 Aug 2017 12:26:44 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1502131739.1803.12.camel@gmail.com> From: Kostya Serebryany Date: Mon, 7 Aug 2017 12:26:42 -0700 Message-ID: Subject: Re: binfmt_elf: use ELF_ET_DYN_BASE only for PIE breaks asan Content-Type: multipart/alternative; boundary="001a11429310b1835505562ed39a" 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 --001a11429310b1835505562ed39a Content-Type: text/plain; charset="UTF-8" On Mon, Aug 7, 2017 at 12:21 PM, Kees Cook wrote: > On Mon, Aug 7, 2017 at 12:16 PM, Kostya Serebryany wrote: > > > > > > On Mon, Aug 7, 2017 at 12:12 PM, Kees Cook wrote: > >> > >> On Mon, Aug 7, 2017 at 12:05 PM, Kostya Serebryany > wrote: > >> > > >> > > >> > On Mon, Aug 7, 2017 at 11:59 AM, Kees Cook > wrote: > >> >> > >> >> On Mon, Aug 7, 2017 at 11:56 AM, Kostya Serebryany > >> >> wrote: > >> >> > 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)? > >> >> > >> >> Wouldn't building non-PIE accomplish this? > >> > > >> > > >> > Well, many asan users do need PIE. > >> > Then, non-PIE only applies to the main executable, all DSOs are still > >> > PIC and the old change that moved DSOs from 0x7fff to 0x5555 caused us > >> > quite > >> > a bit of trouble too, even w/o PIE > >> > >> Hm? You can build non-PIE executables leaving all the DSOs PIC. > > > > > > Yes, but this won't help if the users actually want PIE executables. > > But who wants a PIE executable that isn't randomized? (Or did I > misunderstand you? You want to allow userspace to declare the > randomization range? Kind of. > Doesn't *San use fixed addresses already, so ASLR > isn't actually a security defense? first of all, *San are not security mitigation tools, and if they weaken ASLR -- that's fine. (asan *may* be considered as a mitigation tool even though it weakens ASLR because it provides stronger memory safety guarantees, but it's still a weak mitigation, and an expensive one) > And if we did have such an > interface it would just lead us right back to security vulnerabilities > like the one this fix was trying to deal with ...) > > >> If what you want is to entirely disable userspace ASLR under *San, you > >> can just set the ADDR_NO_RANDOMIZE personality flag. > > > > > > Mmm. How? Could you please elaborate? > > Do you suggest to call personality(ADDR_NO_RANDOMIZE) and re-execute the > > process? > > Or can I somehow set ADDR_NO_RANDOMIZE at link time? > > I've normally seen it done with a launcher that sets the personality > and execs the desired executable. > Oh, a launcher (e.g. just using setarch) would be a huge pain to deploy. > > Another future path would be to collapse the PIE load range into the > DSO load range (as now done when a loader executes a PIE binary). > > -Kees > > -- > Kees Cook > Pixel Security > --001a11429310b1835505562ed39a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Aug 7, 2017 at 12:21 PM, Kees Cook <keescook@google.com&= gt; wrote:
On Mon= , Aug 7, 2017 at 12:16 PM, Kostya Serebryany <kcc@google.com> wrote:
>
>
> On Mon, Aug 7, 2017 at 12:12 PM, Kees Cook <keescook@google.com> wrote:
>>
>> On Mon, Aug 7, 2017 at 12:05 PM, Kostya Serebryany <kcc@google.com> wrote:
>> >
>> >
>> > On Mon, Aug 7, 2017 at 11:59 AM, Kees Cook <keescook@google.com> wrote:
>> >>
>> >> On Mon, Aug 7, 2017 at 11:56 AM, Kostya Serebryany <kcc@google.com>
>> >> wrote:
>> >> > Is it possible to implement some userspace<=3D>= ;kernel interface that
>> >> > will
>> >> > allow applications (sanitizers)
>> >> > to request *fixed* address ranges from the kernel at= startup (so that
>> >> > the
>> >> > kernel couldn't refuse)?
>> >>
>> >> Wouldn't building non-PIE accomplish this?
>> >
>> >
>> > Well, many asan users do need PIE.
>> > Then, non-PIE only applies to the main executable, all DSOs a= re still
>> > PIC and the old change that moved DSOs from 0x7fff to 0x5555 = caused us
>> > quite
>> > a bit of trouble too, even w/o PIE
>>
>> Hm? You can build non-PIE executables leaving all the DSOs PIC. >
>
> Yes, but this won't help if the users actually want PIE executable= s.

But who wants a PIE executable that isn't randomized? (Or did I<= br> misunderstand you? You want to allow userspace to declare the
randomization range?

Kind of.=C2=A0
=C2=A0
Doesn't *San use fixed a= ddresses already, so ASLR
isn't actually a security defense?

fir= st of all, *San are not security mitigation tools, and if they weaken ASLR = -- that's fine.=C2=A0
(asan *may* be considered as a mitigati= on tool even though it weakens ASLR because it provides stronger memory saf= ety guarantees,
but it's still a weak mitigation, and an expe= nsive one)
=C2=A0
And if we d= id have such an
interface it would just lead us right back to security vulnerabilities
like the one this fix was trying to deal with ...)

>> If what you want is to entirely disable userspace ASLR under *San,= you
>> can just set the ADDR_NO_RANDOMIZE personality flag.
>
>
> Mmm. How? Could you please elaborate?
> Do you suggest to call personality(ADDR_NO_RANDOMIZE) and re-execute t= he
> process?
> Or can I somehow set ADDR_NO_RANDOMIZE at link time?

I've normally seen it done with a launcher that sets the persona= lity
and execs the desired executable.

Oh, a= launcher (e.g. just using setarch) would be a huge pain to deploy.=C2=A0
=C2=A0

Another future path would be to collapse the PIE load range into the
DSO load range (as now done when a loader executes a PIE binary).

-Kees

--
Kees Cook
Pixel Security

--001a11429310b1835505562ed39a-- -- 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