From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757547AbcG1VHu (ORCPT ); Thu, 28 Jul 2016 17:07:50 -0400 Received: from outbound1.eu.mailhop.org ([52.28.251.132]:29498 "EHLO outbound1.eu.mailhop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751368AbcG1VHq (ORCPT ); Thu, 28 Jul 2016 17:07:46 -0400 X-MHO-User: 57c3447a-5507-11e6-ac92-3142cfe117f2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 74.99.77.15 X-Mail-Handler: DuoCircle Outbound SMTP X-DKIM: OpenDKIM Filter v2.6.8 io 908DB80119 Date: Thu, 28 Jul 2016 21:07:34 +0000 From: Jason Cooper To: Nick Kralevich 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 Message-ID: <20160728210734.GU4541@io.lakedaemon.net> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 27, 2016 at 09:59:35AM -0700, Nick Kralevich wrote: > 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. Ok, I buy that with the 64bit-only caveat. > 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. One person calls "unmapped gaps between pages" a feature, others call it a mess. ;-) > 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. Agreed. thx, Jason.