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: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 11 Dec 2015 15:10:56 -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>
On Fri, Dec 11, 2015 at 2:45 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Fri, Dec 11, 2015 at 10:11 AM, Zack Weinberg <zackw@panix.com> wrote:
>> On Fri, Dec 11, 2015 at 12:02 PM, Adhemerval Zanella
>> <adhemerval.zanella@linaro.org> wrote:
>>> Another issue is this is basically limiting ALSR really hard on x86_64.
>>> I also would prefer to make the default to *not* include this flag and
>>> set the env. variable to actually enable it. If the cpu is slow doing
>>> what's intended because it is buggy, let it be slow at default. Do not
>>> break what was intended (full ALSR).
>>
>> FWIW, I was about to post the exact same objection. Relatedly, the
>> environment variable should be handled through the normal ld.so-tuning
>> environment variable mechanism (and, in particular, ineffective for
>> set*id binaries).
>>
>
> We have discussed it internally. Since this is very critical for performance
> on Silvermont based platforms, we want to keep it op-out for normal
> programs and disable it for SUID programs. Reduced address range is no
> worse than 32-bit programs.
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.
Consider this a formal objection to the inclusion of this "feature" on
anything other than an opt-in basis.
zw