From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S968038AbcHBQ6Y (ORCPT ); Tue, 2 Aug 2016 12:58:24 -0400 Received: from mga02.intel.com ([134.134.136.20]:60388 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935581AbcHBQ6E (ORCPT ); Tue, 2 Aug 2016 12:58:04 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,461,1464678000"; d="scan'208";a="743207718" From: "Roberts, William C" To: Nick Kralevich , Jason Cooper CC: "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "kernel-hardening@lists.openwall.com" , "akpm@linux-foundation.org" , "keescook@chromium.org" , "gregkh@linuxfoundation.org" , "jeffv@google.com" , "salyzyn@android.com" , "dcashman@android.com" Subject: RE: [PATCH] [RFC] Introduce mmap randomization Thread-Topic: [PATCH] [RFC] Introduce mmap randomization Thread-Index: AQHR52qt7zrvCwCtAUyE0nuoE66zMKArl/mA//+LrpCAAAF2QIAAgqsAgAFPPICACPeIQA== Date: Tue, 2 Aug 2016 16:57:48 +0000 Message-ID: <476DC76E7D1DF2438D32BFADF679FC5601276FB4@ORSMSX103.amr.corp.intel.com> References: <1469557346-5534-1-git-send-email-william.c.roberts@intel.com> <1469557346-5534-2-git-send-email-william.c.roberts@intel.com> <20160726200309.GJ4541@io.lakedaemon.net> <476DC76E7D1DF2438D32BFADF679FC560125F29C@ORSMSX103.amr.corp.intel.com> <20160726205944.GM4541@io.lakedaemon.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMzk2ZjMwOTQtZDBiNC00OTFlLTk4ZjktNWRmMWQ4ZWQ5ZTg4IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6InVxeXlXUzZRQUZjd0ZnbXVhdVNINTRGZGxJb1c3ckswa1htMXg5UWpzbzA9In0= x-ctpclassification: CTP_IC x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u72GwTje026186 > -----Original Message----- > From: Nick Kralevich [mailto:nnk@google.com] > Sent: Wednesday, July 27, 2016 10:00 AM > To: Jason Cooper > Cc: Roberts, William C ; linux-mm@kvack.org; > linux-kernel@vger.kernel.org; kernel-hardening@lists.openwall.com; > akpm@linux-foundation.org; keescook@chromium.org; > gregkh@linuxfoundation.org; jeffv@google.com; salyzyn@android.com; > dcashman@android.com > Subject: Re: [PATCH] [RFC] Introduce mmap randomization > > On Tue, Jul 26, 2016 at 1:59 PM, Jason Cooper wrote: > >> > One thing I didn't make clear in my commit message is why this is > >> > good. Right now, if you know An address within in a process, you > >> > know all offsets done with mmap(). For instance, an offset To libX > >> > can yield libY by adding/subtracting an offset. This is meant to > >> > make rops a bit harder, or In general any mapping offset mmore difficult to > find/guess. > > > > Are you able to quantify how many bits of entropy you're imposing on > > the attacker? Is this a chair in the hallway or a significant > > increase in the chances of crashing the program before finding the desired > address? > > Quantifying the effect of many security changes is extremely difficult, especially > for a probabilistic defense like ASLR. I would urge us to not place too high of a > proof bar on this change. > Channeling Spender / grsecurity team, ASLR gets it's benefit not from it's high > benefit, but from it's low cost of implementation > (https://forums.grsecurity.net/viewtopic.php?f=7&t=3367). This patch certainly > meets the low cost of implementation bar. > > In the Project Zero Stagefright post > (http://googleprojectzero.blogspot.com/2015/09/stagefrightened.html), > we see that the linear allocation of memory combined with the low number of > bits in the initial mmap offset resulted in a much more predictable layout which > aided the attacker. The initial random mmap base range was increased by Daniel > Cashman in d07e22597d1d355829b7b18ac19afa912cf758d1, but we've done > nothing to address page relative attacks. > > Inter-mmap randomization will decrease the predictability of later > mmap() allocations, which should help make data structures harder to find in > memory. In addition, this patch will also introduce unmapped gaps between > pages, preventing linear overruns from one mapping to another another > mapping. I am unable to quantify how much this will improve security, but it > should be > 0. > > I like Dave Hansen's suggestion that this functionality be limited to > 64 bits, where concerns about running out of address space are essentially nil. I'd > be supportive of this change if it was limited to > 64 bits. Sorry for the delay on responding, I was on vacation being worthless. Nick, very eloquently, described what I failed to put in the commit message. I was thinking about this on vacation and also thought that on 64 bit the fragmentation shouldn't be an issue. @nnk, disabling ASLR via set_arch() on Android, is that only for 32 bit address spaces where you had that problem?