[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <476DC76E7D1DF2438D32BFADF679FC560127815C@ORSMSX103.amr.corp.intel.com>
Date: Tue, 2 Aug 2016 17:17:19 +0000
From: "Roberts, William C" <william.c.roberts@...el.com>
To: Jason Cooper <jason@...edaemon.net>
CC: "linux-mm@...ck.org" <linux-mm@...ck.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "kernel-hardening@...ts.openwall.com"
<kernel-hardening@...ts.openwall.com>, "akpm@...ux-foundation.org"
<akpm@...ux-foundation.org>, "keescook@...omium.org" <keescook@...omium.org>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>, "nnk@...gle.com"
<nnk@...gle.com>, "jeffv@...gle.com" <jeffv@...gle.com>,
"salyzyn@...roid.com" <salyzyn@...roid.com>, "dcashman@...roid.com"
<dcashman@...roid.com>
Subject: RE: [PATCH] [RFC] Introduce mmap randomization
> -----Original Message-----
> From: Jason Cooper [mailto:jason@...edaemon.net]
> Sent: Tuesday, July 26, 2016 2:45 PM
> To: Roberts, William C <william.c.roberts@...el.com>
> Cc: linux-mm@...ck.org; linux-kernel@...r.kernel.org; kernel-
> hardening@...ts.openwall.com; akpm@...ux-foundation.org;
> keescook@...omium.org; gregkh@...uxfoundation.org; nnk@...gle.com;
> jeffv@...gle.com; salyzyn@...roid.com; dcashman@...roid.com
> Subject: Re: [PATCH] [RFC] Introduce mmap randomization
>
> On Tue, Jul 26, 2016 at 09:06:30PM +0000, Roberts, William C wrote:
> > > From: owner-linux-mm@...ck.org [mailto:owner-linux-mm@...ck.org] On
> > > Behalf Of Jason Cooper On Tue, Jul 26, 2016 at 08:13:23PM +0000,
> > > Roberts, William C wrote:
> > > > > > From: Jason Cooper [mailto:jason@...edaemon.net] On Tue, Jul
> > > > > > 26,
> > > > > > 2016 at 11:22:26AM -0700, william.c.roberts@...el.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?
>
> Well, I'm partial to scripts/objdiff, but bloat-o-meter might be more familiar to
> most of the folks who you'll be trying to convince to merge this.
Ahh I didn't know there were tools for this, thanks.
>
> But that's the least of your worries atm. :-/ I was going to dig into mmap.c to
> confirm my suspicions, but Nick answered it for me.
> Fragmentation caused by this sort of feature is known to have caused problems
> in the past.
I don't know of any mmap randomization done in the past like this. Only the ASLR stuff, which
has had known issues on 32 bit address spaces.
>
> I would highly recommend studying those prior use cases and answering those
> concerns before progressing too much further. As I've mentioned elsewhere,
> you'll need to quantify the increased difficulty to the attacker that your patch
> imposes. Personally, I would assess that first to see if it's worth the effort at all.
Yes agreed.
>
> > > > > 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.
>
> Right, after the Android feedback from Nick, I think you have a lot of work on
> your hands. Not just in design, but also in developing convincing arguments
> derived from real use cases.
>
> thx,
>
> Jason.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
