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 Fri, Dec 11, 2015 at 2:45 PM, H.J. Lu <> wrote:
> On Fri, Dec 11, 2015 at 10:11 AM, Zack Weinberg <> wrote:
>> On Fri, Dec 11, 2015 at 12:02 PM, Adhemerval Zanella
>> <> 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
>> 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.


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