Re: extend dl-minimal malloc implementation

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

On 08/11/2017 01:54 PM, DJ Delorie wrote:
> 
> IMHO using malloc/free in ld.so should be considered as a way to avoid
> using the stack for allocations; but this means that we have to be
> careful to free everything we malloc, so that at the time we hand off
> malloc to libc.so's malloc, the size of the "free list" is as small as
> possible, which makes some of this discussion, well, "more moot" ;-)
> 
> At least, that was my design intent - the ld.so free list would normally
> be small enough to not worry about, and anything left malloc'd at
> handover would remain malloc'd for the life of the process.
> 
> If we intend to make ld.so's heap compatible with libc.so's heap, I
> think the only long term solution, for maintenance reasons, is to use
> malloc/malloc.c et all to implement both, perhaps via some #include/cpp
> magic that gives us a stripped-down-but-compatible[*] version of the
> full malloc just for ld.so.
> 
> [*] for example, without tcache/fastbins/consolidate but handing off a
> heap that can be consolidated later, but remains compatible with future
> hardening changes.

A smaller bootstrap implementation is easier to audit and avoid problematic
relocations which can't be present.

Thought at this point it might be easier to simply provide two memory alloction
APIs with distinct and separate data, one for the loader, and one for the
application, such that as Florian and Adhemerval cover up-thread, that we
can have some isolation from application overflows, and enforce some hardening
like getting allocations that can then be made read-only with a simpler API
than mmap/mprotect.

-- 
Cheers,
Carlos.