This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Add Prefer_MAP_32BIT_EXEC for Silvermont
- From: Andi Kleen <andi at firstfloor dot org>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 11 Dec 2015 12:59:00 -0800
- Subject: Re: [PATCH] Add Prefer_MAP_32BIT_EXEC for Silvermont
- Authentication-results: sourceware.org; auth=none
- References: <20151211143706 dot GA7868 at intel dot com> <alpine dot DEB dot 2 dot 10 dot 1512111539300 dot 17023 at digraph dot polyomino dot org dot uk> <CAMe9rOqbqyFw3CMa35vwOEefdFq1xK2Q9hX8GXoGMKVZ-A2y0g at mail dot gmail dot com> <566AF894 dot 4060300 at linaro dot org> <CAMe9rOr-LypZXvq4Y4uwE_JybYoTXctZXMLjo4TH517NnC6omg at mail dot gmail dot com> <566B01BE dot 1070703 at linaro dot org> <CAKCAbMhMArQ9wsXhw2y+Fvv+_3O5i4g8pdDQdWo6_1YxqfVxkQ at mail dot gmail dot com> <CAMe9rOrVjSnhp-EzmAnVBg10wbqk9U4n+hL-3xF5=DPZP5co1A at mail dot gmail dot com> <CAKCAbMhk69hUBbrQ=0j0NDYjRT6R-EK1+F43+Mmi9FwS7epexQ at mail dot gmail dot com> <CAKCAbMhA6x4r6Bhw8cnAavoWzjWsm6WM8JPzrnCsrqxbEswS_g at mail dot gmail dot com>
Zack Weinberg <email@example.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
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
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.
firstname.lastname@example.org -- Speaking for myself only