This is the mail archive of the libc-alpha@sourceware.org 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


Zack Weinberg <zackw@panix.com> writes:
>
> 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.

The patch brings ASLR into a similar ballpark as with 32bit (plus minus
1 or 2 bits)

You're basically arguing that running 32bit is unacceptable, and that the
main motivation for users to use 64bit is security and not performance.

I don't think users would agree with you on that. 32bit is widely used,
and clearly users find the risk from that acceptable. Also there
are no security advisories around that ask users to stop using 32bit.

There aren't because it doesn't make any sense.

Also 3% (likely more in other workloads) is a significant performance
difference, especially when we're talking about something as common as
function calls.
 
BTW the patch could be fixed to support all 4GB by guessing a hole
and using the mmap hint. But it would complicate it somewhat.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only


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