> -----Original Message----- > From: Jason Cooper [mailto:jason@xxxxxxxxxxxxxx] > Sent: Tuesday, July 26, 2016 2:45 PM > To: Roberts, William C <william.c.roberts@xxxxxxxxx> > Cc: linux-mm@xxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; kernel- > hardening@xxxxxxxxxxxxxxxxxx; akpm@xxxxxxxxxxxxxxxxxxxx; > keescook@xxxxxxxxxxxx; gregkh@xxxxxxxxxxxxxxxxxxx; nnk@xxxxxxxxxx; > jeffv@xxxxxxxxxx; salyzyn@xxxxxxxxxxx; dcashman@xxxxxxxxxxx > 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@xxxxxxxxx [mailto:owner-linux-mm@xxxxxxxxx] On > > > Behalf Of Jason Cooper On Tue, Jul 26, 2016 at 08:13:23PM +0000, > > > Roberts, William C wrote: > > > > > > From: Jason Cooper [mailto:jason@xxxxxxxxxxxxxx] On Tue, Jul > > > > > > 26, > > > > > > 2016 at 11:22:26AM -0700, william.c.roberts@xxxxxxxxx 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. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href