Re: extend dl-minimal malloc implementation

[Carlos O'Donell <carlos at redhat dot com>]

On 08/15/2017 05:32 PM, Zack Weinberg wrote:
> On Sat, Aug 12, 2017 at 5:06 AM, Florian Weimer <fw@deneb.enyo.de> wrote:
>> * Carlos O'Donell:
>>
>>> But would we use that API for *every* allocation in the loader?
>>
>> There are probably some exceptions.  The error message returned by
>> dlsym comes to my mind.  This is the kind of project where you
>> discover the scope only after you are half-way through it. 8-/
> 
> There is also the question of what to do when the application replaces
> (the full-fledged) malloc.
> 
> I wonder if it might be more productive to work in the opposite
> direction and try to *eliminate* use of malloc within the dynamic
> linker, aiming for a point where it would be reasonable to send all of
> its memory allocations directly to mmap().
> 
> (I've also been wondering off and on, lately, whether there'd be any
> way to convert glibc over to the musl model where ld.so, libc.so, and
> libpthread.so are all the same shared object, without breaking the
> ABI.  Many things would become simpler... on the other hand, the
> bootstrap process might become more complicated!)

OK, so my suggestion is like this:

(a) Extend dl-minimal malloc.

(b) Eliminate all alloca by moving to malloc (requires (a)).

... then...

(c) Eliminate problematic malloc's with new internal API.

I don't think we know how to do (c) yet, but we could do (a) and (b)
and improve the dynamic loader's security situation.

What do you think about that?

Lastly, I think that merging ld.so/libc.so/libpthread.so is not
a tractable short-term problem for glibc. It would be a large
structural change that doesn't have clear significant benefits.

-- 
Cheers,
Carlos.