[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 23 Apr 2020 12:16:26 +0300
From: Paul Sokolovsky <pmiscml@...il.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: foreign-dlopen: dlopen() from static binary, again (and
not the way you think!)
Hello,
On Wed, 22 Apr 2020 22:39:41 -0400
Rich Felker <dalias@...c.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@...il.com
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
