[PATCH] Add Prefer_MAP_32BIT_EXEC for Silvermont
Jeff Law
law@redhat.com
Fri Dec 11 20:50:00 GMT 2015
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
More information about the Libc-alpha
mailing list