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

[Paul Sokolovsky <pmiscml@gmail.com>]

Hello,

On Wed, 22 Apr 2020 22:39:41 -0400
Rich Felker <dalias@libc.org> wrote:

[]

> > 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.
[]
> > 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.

Thanks for the response and for the word of warning. As I mentioned,
this is essentially a proof of concept, and so far was tested only by
calling glibc's printf() from a host app which was either linked with
glibc itself or -nostdlib and static. And that was already more than
with any other ELF loader which I tried (which worked for simple
functions like write(), but crashed in anything more complex like
printf()).

But it certainly doesn't touch a case you describe, when "foreign" vs
local libc expect different values of %gs/%fs (so apparently, "foreign
function call" facility would need to swap them around a call).

> 
> 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



-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com