This is the mail archive of the 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

On 12/11/2015 05:31 PM, Zack Weinberg wrote:
On Fri, Dec 11, 2015 at 7:14 PM, Andi Kleen <> 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.
Exactly. For a 64 bit application, this change will essentially cripple ASLR if I understand the patch correctly. That is unacceptable to me and likely to Red Hat as a whole.

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.
Right. And in fact, ASLR is the margin by which some currently known vulnerabilities have not been turned into proof of concept exploits.

ASLR, while not perfect, while bypassable via various information leaks, is still a vital component in the overall security profile for Linux, particularly for 64 bit OSs & applications.


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