This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Add Prefer_MAP_32BIT_EXEC for Silvermont
- From: Zack Weinberg <zackw at panix dot com>
- To: Andi Kleen <andi at firstfloor dot org>
- 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 16:16:24 -0500
- 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> <87egeszoq3 dot fsf at tassilo dot jf dot intel dot com>
On Fri, Dec 11, 2015 at 3:59 PM, Andi Kleen <andi@firstfloor.org> wrote:
> 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)
For the record, the amount of entropy in each mmap() for 32-bit x86
might be as low as 8 or as high as 20 bits depending on which bit of
the code I decide to believe. arch_get_unmapped_area() is a real
mess. However, 20 bits does not strike me as adequate either, so ...
> You're basically arguing that running 32bit is unacceptable, and that the
> main motivation for users to use 64bit is security and not performance.
... essentially yes, but I'd put it differently: some subset of 64-bit
users are using it *because* it makes ASLR more effective; kneecapping
ASLR for those users would be an unacceptable regression.
> 32bit is widely used,
> and clearly users find the risk from that acceptable.
I think that reads too much into the lack of data. I would expect
that the majority of people still using 32-bit user space are doing so
either because the computer is a black box to them, or because they
have a business-critical 32-bit binary that can't be upgraded.
> Also there are no security advisories around that ask users to stop using 32bit.
The paper I cited is a counterexample.
> Also 3% (likely more in other workloads) is a significant performance
> difference, especially when we're talking about something as common as
> function calls.
I saw a claim of 3% *overall* performance increase on an artificial
benchmark and that's all. I currently suspect this will turn out to
be unmeasurable on realistic workloads.
zw