Re: [PATCH] Add Prefer_MAP_32BIT_EXEC for Silvermont

[Jeff Law <law at redhat dot com>]

On 12/11/2015 01:44 PM, Zack Weinberg wrote:
> On Fri, Dec 11, 2015 at 3:10 PM, Zack Weinberg <zackw@panix.com> wrote:
> > I don't think 3% performance hit on a fork-intensive artificial
> > benchmark qualifies as "very critical"; certainly not enough to be
> > worth rendering ASLR _completely ineffective_ over.  Randomization
> > within a 2GB address space just isn't good enough to qualify even as a
> > _hurdle_ anymore.
>
> Just to back up this assertion: 16 bits of base address randomization
> was brute-forceable in less than five minutes (on average) in 2004,
> per http://www.cs.columbia.edu/~locasto/projects/candidacy/papers/shacham2004ccs.pdf
> .  Digging into the kernel a little, it appears that MAP_32BIT (in
> 4.3) selects a page-aligned address at random from within a 1GB (not
> 2GB) space; that's *thirteen* bits of randomness, so we don't even
> have to have the argument about how many more than 16 bits it would
> take to be good enough in 2016; clearly *fewer* than 16 bits is
> unacceptable.
I'm glad someone raised this issue.  I'm back in GCC-land these days, so 
my opinion can be discounted to some degree.  But ISTM that reducing 
ASLR's effectiveness like this would be a non-starter.

I've spend a fair amount of time the last month reading about various 
vulnerabilities & exploits.  While there are ways around ASLR, it does 
represent a notable barrier for the less sophisticated attackers.


jeff