This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add Prefer_MAP_32BIT_EXEC for Silvermont

On 12/11/2015 01:44 PM, Zack Weinberg wrote:
On Fri, Dec 11, 2015 at 3:10 PM, Zack Weinberg <> 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,
.  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
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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]