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. -- Nick -- Nick Kralevich | Android Security | nnk@xxxxxxxxxx | 650.214.4037 -- 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=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>