Re: Re: A running list of questions from "porting" Slackware to musl

[Rich Felker <dalias@libc.org>]

On Tue, Sep 30, 2014 at 10:49:15PM -0700, Andy Lutomirski wrote:
> >>(Even better: the loader could patch the PLT with a direct jump.  Could
> >>musl do this?  At least in the case where the symbol is within 2G of the
> >>PLT entry,
> >
> >This is really not a good idea. The old PowerPC ABI did this, and musl
> >does not support it (it requires the new "secure-plt" mode). Hardened
> >kernels have various restrictions on modifying executable pages, up to
> >and including completely forbidding this kind of usage. And even if
> >it's not forbidden, it's going to use more memory due to an additional
> >page (or more) per shared library that's not going to be sharable.
> >Also it requires complex per-arch code (minimal machine code
> >generation, instruction cache flushing/barriers, etc.).
> 
> That extra page might not be needed if the linker could end up
> removing a bunch of GOT entries for functions that don't have their
> addresses taken.  (Or, on x86_64, where unaligned access is cheap,
> the GOT could actually overlap the PLT in memory, but only if

This is not an option. It would require the page containing the GOT
(and a lot of data) to be executable. Not only is this a huge security
risk (makes exploiting other vulnerabilities a lot easier); it's also
physically impossible to do on hardened kernels which simply lack
"rwx" permission for mappings.

> >>this should be straightforward if no threads have been
> >>started yet.
> >
> >Threads having been started or not are not relevant. The newly loaded
> >code is not visible until dlopen returns, so nothing can race with
> >modifications to it.
> 
> True, at least when lazy binding is off.

musl does not do lazy binding at all, and won't. There's been some
demand for it in terms of allowing loading hacks where the symbols
needed by the loaded library are not provided until later, but that
can be satisfied by emulating it (basically, keeping a list of
unsatisfied relocs and retrying them after each dlopen) rather than
actually doing lazy binding at call time.

Rich