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 07/14/2016 12:59 PM, Paul Eggert wrote:
On 07/13/2016 07:09 PM, Florian Weimer wrote:
Apparently, ppc64 has very aggressive ASLR, and the built-in malloc in
Emacs assumes that brk will hand out addresses which are close to the
.data section in the executable: It has a direct mapping from
addresses to blocks to block information, and if there is a large gap
between .data and the heap, the block array is huge.

Is this the main problem with Emacs and draft-glibc-2.24 malloc? If so,
can you suggest a patch to Emacs, or a patch to glibc, that will work
around the problem? For example, can Emacs disable the aggressive ASLR
somehow? I assume there is a relatively simple fix to Emacs or to glibc
that could work around this specific problem.

If my analysis is right, src/gmalloc.c assumes that it can allocate an array which contains three words for every BLOCKSIZE (4096) bytes of the heap. This assumption is just not valid on 64-bit architectures. Increasing BLOCKSIZE will help somewhat, but this looks rather like a core issue with the allocation algorithm.

GDB does this to disable randomization:

      errno = 0;
      personality_orig = personality (0xffffffff);
      if (errno == 0 && !(personality_orig & ADDR_NO_RANDOMIZE))
        {
          personality_set = 1;
          personality (personality_orig | ADDR_NO_RANDOMIZE);
        }
      if (errno != 0 || (personality_set
&& !(personality (0xffffffff) & ADDR_NO_RANDOMIZE)))
        warning (_("Error disabling address space randomization: %s"),
                 safe_strerror (errno));

(0xffffffff should really be -1.)

I do not know if we can do the above early enough before glibc calls sbrk internally. Emacs may have to re-exec itself to apply this successfully. I'm not sure if this approach will be more reliable than any kludge that is put into gmalloc.

Florian


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