> -----Original Message----- > From: Nick Kralevich [mailto:n...@google.com] > Sent: Wednesday, July 27, 2016 10:00 AM > To: Jason Cooper <ja...@lakedaemon.net> > Cc: Roberts, William C <william.c.robe...@intel.com>; linux...@kvack.org; > linux-kernel@vger.kernel.org; kernel-harden...@lists.openwall.com; > a...@linux-foundation.org; keesc...@chromium.org; > gre...@linuxfoundation.org; je...@google.com; saly...@android.com; > dcash...@android.com > Subject: Re: [PATCH] [RFC] Introduce mmap randomization > > On Tue, Jul 26, 2016 at 1:59 PM, Jason Cooper <ja...@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?
