Re: [musl] foreign-dlopen: dlopen() from static binary, again (and not the way you think!)

[Rich Felker <dalias@libc.org>]

On Thu, Apr 23, 2020 at 02:25:31AM +0300, Paul Sokolovsky wrote:
> Hello,
> 
> Just as many (well, few) people I was surprised by the inability to
> dlopen() from a static binary
> (https://www.openwall.com/lists/musl/2012/12/08/4 , etc.). I started to
> hack into musl's dynamic linker, just to find it a bit ... tangled.
> That of course was nothing compared to taking a standalone ELF loader
> and trying to deal with glibc's dynamic loader, that was total mess
> (just look at https://github.com/robgjansen/elf-loader, which tried to
> do that; tried, because it doesn't work with recent glibc versions,
> and need constant patching).
> 
> Oh, forgot to say that I'm not looking for a way to load a
> particular musl-dynlinked shared library into musl-staticlinked binary.
> So, arguments like "but you'll need to carry around musl's libc.so"
> don't apply. What I'm looking for is a way to have a static closed-world
> application, but let it, at the user's request, to interface with
> whatever system may be outside.
> 
> So, seeing what a mess is doing "honest" dynamic loading for real
> world, and given my usecase, which is about wanting to touch that mess
> as little as possible with bare hands, I came to a cute blackbox'ish
> solution to an issue. The rest of the story and proof of concept code
> is at https://github.com/pfalcon/foreign-dlopen .

In your example it looks like you're foreign_dlopen'ing glibc. That
simply *can't* work, because part of the interface contract of all
glibc functions is that they're called with the thread pointer
register (%gs or %fs on i386 or x86_64 respectively) pointing to a
glibc TCB, which will not be the case when they're invoked from a
musl-linked (or other non-glibc-linked) program.

If you relax to the case where you're not doing that, and instead only
opening *pure library* code which has no tie-in to global state or TLS
contracts, then it should be able to work.

Rich