Re: glibc 2.24 -- Release blockers

[Florian Weimer <fweimer at redhat dot com>]

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