This is the mail archive of the 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: 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 <> 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,, and
> 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 is not
a tractable short-term problem for glibc. It would be a large
structural change that doesn't have clear significant benefits.


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