This is the mail archive of the
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: Jeff Law <law at redhat dot com>, "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 19:31:13 -0500
- Subject: Re: [PATCH] Add Prefer_MAP_32BIT_EXEC for Silvermont
- Authentication-results: sourceware.org; auth=none
- References: <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> <CAKCAbMibxh54DGJ6p59ah6jQK=oFkH9LCZo0UDBefQeh1y-5eg at mail dot gmail dot com> <CAMe9rOoyc4MXVz74GmjViora-iCEKitQXbpX9EB+Ln1Q_DAD_A at mail dot gmail dot com> <CAKCAbMi_noBivP+ksLaotNtfEhGrtUuUacbnZgjMg5m0PfEniw at mail dot gmail dot com> <20151211222913 dot GT15533 at two dot firstfloor dot org> <566B55DF dot 2040200 at redhat dot com> <20151212001449 dot GU15533 at two dot firstfloor dot org>
On Fri, Dec 11, 2015 at 7:14 PM, Andi Kleen <firstname.lastname@example.org> wrote:
>> And I'd argue that this is killing ASLR at a level that it should be
>> an opt-out rather than opt-in. Crippling ASLR is, IMHO,
> You're arguing then that running 32bit code is unacceptable.
I don't see that that follows.
Right now, 32-bit code has security margin X and 64-bit code has
security margin Y > X. The proposed patch *reduces* the security
margin of 64-bit code from Y to X (give or take). That may be, and
IMHO is, an unacceptable change *even if* X is agreed to be adequate,
or anyway the best that can be done for 32-bit.
Fundamentally, my issue here is that there are people right now
depending on this security margin to be Y, so a glibc upgrade should
not silently remove that. It is a compatibility break of the worst
kind: completely invisible in normal operation, but the system no
longer has a property you were counting on to protect you under
abnormal (adversarial) conditions.