> -----Original Message----- > From: Nick Kralevich [mailto:nnk@xxxxxxxxxx] > Sent: Wednesday, July 27, 2016 10:00 AM > To: Jason Cooper <jason@xxxxxxxxxxxxxx> > Cc: Roberts, William C <william.c.roberts@xxxxxxxxx>; linux-mm@xxxxxxxxx; > linux-kernel@xxxxxxxxxxxxxxx; kernel-hardening@xxxxxxxxxxxxxxxxxx; > akpm@xxxxxxxxxxxxxxxxxxxx; keescook@xxxxxxxxxxxx; > gregkh@xxxxxxxxxxxxxxxxxxx; jeffv@xxxxxxxxxx; salyzyn@xxxxxxxxxxx; > dcashman@xxxxxxxxxxx > Subject: Re: [PATCH] [RFC] Introduce mmap randomization > > On Tue, Jul 26, 2016 at 1:59 PM, Jason Cooper <jason@xxxxxxxxxxxxxx> 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? ��.n������g��� �a��� �&ޖ)���)��h���&������梷���� �Ǟ�m������)������^�����������v���O��zf������