Re: malloc_set_state and heap content

[Florian Weimer <fweimer at redhat dot com>]

On 07/06/2016 09:35 PM, Samuel Thibault wrote:
> Hello,
>
> In 4cf6c72fd2a482e7499c29162349810029632c3f ('malloc: Rewrite dumped
> heap for compatibility in __malloc_set_state'), __malloc_set_state was
> reimplemented, using the following look to detect the first chunk of the
> heap:
>
>   /* Find the chunk with the lowest address with the heap.  */
>   mchunkptr chunk = NULL;
>   {
>     size_t *candidate = (size_t *) ms->sbrk_base;
>     size_t *end = (size_t *) (ms->sbrk_base + ms->sbrked_mem_bytes);
>     while (candidate < end)
>       if (*candidate != 0)
>        {
>          chunk = mem2chunk ((void *) (candidate + 1));
>          break;
>        }
>       else
>        ++candidate;
>
> That assumes that the beginning of the heap is zeroed.

Yes.  There is no in-tree glibc port which sets MORECORE_CLEARS to zero, 
so malloc already assumes that the memory is cleared.

> On Linux the space happens to be zero by luck, but with other kernels
> that may not be true (it is not with the Hurd).

How gets Hurd away with that without introducing a security 
vulnerability?  Why is MORECORE_CLEARS not defined as 0?

> So I'd say we need the attached patch, don't we?

The patch does not address the issue because it does not alter the heap 
copy in existing Emacs binaries.  It would only become effective after 
recompiling Emacs.  Such recompiled Emacs binaries will no longer use 
the heap dumping mechanism.

Florian