RE: [PATCH] [RFC] Introduce mmap randomization

From: "Roberts, William C" <william.c.roberts@intel.com>
To: 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>,
	"nnk@google.com" <nnk@google.com>,
	"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, 26 Jul 2016 21:06:30 +0000	[thread overview]
Message-ID: <476DC76E7D1DF2438D32BFADF679FC5601260068@ORSMSX103.amr.corp.intel.com> (raw)
In-Reply-To: <20160726205944.GM4541@io.lakedaemon.net>

> -----Original Message-----
> From: owner-linux-mm@kvack.org [mailto:owner-linux-mm@kvack.org] On
> Behalf Of Jason Cooper
> Sent: Tuesday, July 26, 2016 2:00 PM
> To: Roberts, William C <william.c.roberts@intel.com>
> 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; nnk@google.com;
> jeffv@google.com; salyzyn@android.com; dcashman@android.com
> Subject: Re: [PATCH] [RFC] Introduce mmap randomization
> 
> Hi William,
> 
> On Tue, Jul 26, 2016 at 08:13:23PM +0000, Roberts, William C wrote:
> > > > From: Jason Cooper [mailto:jason@lakedaemon.net] On Tue, Jul 26,
> > > > 2016 at 11:22:26AM -0700, william.c.roberts@intel.com wrote:
> > > > > Performance Measurements:
> > > > > Using strace with -T option and filtering for mmap on the
> > > > > program ls shows a slowdown of approximate 3.7%
> > > >
> > > > I think it would be helpful to show the effect on the resulting object code.
> > >
> > > Do you mean the maps of the process? I have some captures for
> > > whoopsie on my Ubuntu system I can share.
> 
> No, I mean changes to mm/mmap.o.

Sure I can post the objdump of that, do you just want a diff of old vs new?

> 
> > > 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?

I'd likely need to take a small sample of programs and examine them, especially considering
That as gaps are harder to find, it forces the randomization down and randomization can
Be directly altered with length on mmap(), versus randomize_addr() which didn't have this
restriction but OOM'd do to fragmented easier.

> 
> thx,
> 
> Jason.
> 
> --
> 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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>