This is the mail archive of the libc-alpha@sourceware.org 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: glibc 2.24 -- Release blockers


On Fri, Jul 15, 2016 at 4:00 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
> On 07/15/2016 04:33 PM, Florian Weimer wrote:
>>
>> This means that new processes spawned by Emacs will have ASLR disable.
>
> Yes, on second thought that's too drastic. The patch I just now installed
> into master (and sent via email to this list) doesn't do that. It disables
> ASLR only in temacs, not in ordinary Emacs invocations. (Enabling ASLR in
> ordinary Emacs broke the Emacs build on Fedora 23 x86-64.) This is how Emacs
> has worked for many years; although you indicated that it might not work
> with bleeding-edge glibc in some situations, I don't understand why not, and
> would like to understand it better before changing this aspect of Emacs..

I don't have affected hardware to test this on, but the phenomenon
seems pretty clear to me.  Emacs' bundled malloc assumes that the data
segment is contiguous with, or at least close to, the memory region
controlled by brk().  This is not true with ASLR enabled, on certain
architectures (e.g. ppc64).

That assumption is a fundamental design constraint, rather than
something done to support dumping.  Therefore, if the bundled malloc
is used in the "ordinary Emacs", ASLR must be disabled in the
"ordinary Emacs"; disabling it in temacs is not enough.  It looks like
HYBRID_MALLOC mode would avoid the problem, but from upthread, that
mode isn't ready for prime time yet...?

zw


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