From: "Roberts, William C" <william.c.roberts@intel.com>
To: Nick Kralevich <nnk@google.com>, Jason Cooper <jason@lakedaemon.net>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"keescook@chromium.org" <keescook@chromium.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"jeffv@google.com" <jeffv@google.com>,
"salyzyn@android.com" <salyzyn@android.com>,
"dcashman@android.com" <dcashman@android.com>
Subject: RE: [PATCH] [RFC] Introduce mmap randomization
Date: Tue, 2 Aug 2016 16:57:48 +0000 [thread overview]
Message-ID: <476DC76E7D1DF2438D32BFADF679FC5601276FB4@ORSMSX103.amr.corp.intel.com> (raw)
In-Reply-To: <CAFJ0LnEZW7Y1zfN8v0_ckXQZn1n-UKEhf_tSmNOgHwrrnNnuMg@mail.gmail.com>
> -----Original Message-----
> From: Nick Kralevich [mailto:nnk@google.com]
> Sent: Wednesday, July 27, 2016 10:00 AM
> To: Jason Cooper <jason@lakedaemon.net>
> Cc: Roberts, William C <william.c.roberts@intel.com>; 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 <jason@lakedaemon.net> 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?
next prev parent reply other threads:[~2016-08-02 16:58 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-26 18:22 [PATCH] [RFC] Introduce mmap randomization william.c.roberts
2016-07-26 18:22 ` william.c.roberts
2016-07-26 20:03 ` Jason Cooper
2016-07-26 20:11 ` Roberts, William C
2016-07-26 20:13 ` Roberts, William C
2016-07-26 20:59 ` Jason Cooper
2016-07-26 21:06 ` Roberts, William C
2016-07-26 21:44 ` Jason Cooper
2016-07-26 23:51 ` Dave Hansen
2016-08-02 17:17 ` Roberts, William C
2016-08-03 18:19 ` Roberts, William C
2016-08-02 17:15 ` Roberts, William C
2016-07-27 16:59 ` Nick Kralevich
2016-07-28 21:07 ` Jason Cooper
2016-07-29 10:10 ` [kernel-hardening] " Daniel Micay
2016-07-31 22:24 ` Jason Cooper
2016-08-01 0:24 ` Daniel Micay
2016-08-02 16:57 ` Roberts, William C [this message]
2016-08-02 17:02 ` Nick Kralevich
2016-08-14 16:31 ` Pavel Machek 1
2016-07-26 20:12 ` [kernel-hardening] " Rik van Riel
2016-07-26 20:17 ` Roberts, William C
2016-07-26 20:41 ` Nick Kralevich
2016-07-26 21:02 ` Roberts, William C
2016-07-26 21:11 ` Nick Kralevich
2016-08-14 16:22 ` Pavel Machek
2016-08-04 16:53 ` [kernel-hardening] " Daniel Micay
2016-08-04 16:55 ` Roberts, William C
2016-08-04 17:10 ` Daniel Micay
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=476DC76E7D1DF2438D32BFADF679FC5601276FB4@ORSMSX103.amr.corp.intel.com \
--to=william.c.roberts@intel.com \
--cc=akpm@linux-foundation.org \
--cc=dcashman@android.com \
--cc=gregkh@linuxfoundation.org \
--cc=jason@lakedaemon.net \
--cc=jeffv@google.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nnk@google.com \
--cc=salyzyn@android.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).