From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f70.google.com (mail-oi0-f70.google.com [209.85.218.70]) by kanga.kvack.org (Postfix) with ESMTP id B759B6B025F for ; Mon, 7 Aug 2017 15:21:47 -0400 (EDT) Received: by mail-oi0-f70.google.com with SMTP id b130so1027008oii.4 for ; Mon, 07 Aug 2017 12:21:47 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com. [2607:f8b0:4001:c06::235]) by mx.google.com with ESMTPS id e131si5202030oib.185.2017.08.07.12.21.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Aug 2017 12:21:47 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id g35so6052625ioi.3 for ; Mon, 07 Aug 2017 12:21:46 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1502131739.1803.12.camel@gmail.com> From: Kees Cook Date: Mon, 7 Aug 2017 12:21:45 -0700 Message-ID: Subject: Re: binfmt_elf: use ELF_ET_DYN_BASE only for PIE breaks asan Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: To: Kostya Serebryany Cc: Daniel Micay , Dmitry Vyukov , Michal Hocko , Andrew Morton , "linux-mm@kvack.org" , Rik van Riel , Reid Kleckner , Peter Collingbourne , Evgeniy Stepanov 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? Doesn't *San use fixed addresses already, so ASLR isn't actually a security defense? 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. 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 -- 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