This is the mail archive of the
mailing list for the glibc project.
Re: extend dl-minimal malloc implementation
On 08/15/2017 05:32 PM, Zack Weinberg wrote:
> On Sat, Aug 12, 2017 at 5:06 AM, Florian Weimer <firstname.lastname@example.org> 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)).
(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.