[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160714150728.GN15995@brightrain.aerifal.cx>
Date: Thu, 14 Jul 2016 11:07:28 -0400
From: Rich Felker <dalias@...c.org>
To: Jason Ramapuram <jason.ramapuram@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: Regarding whole-archive linking libc.a into a shared lib
On Thu, Jul 14, 2016 at 12:49:31PM +0200, Jason Ramapuram wrote:
> Thanks for the link. Just went through the entire thread. I think we can
> solve the problems as such though:
>
> 1. Have some form of linker that mangles all the symbols internally in
> the newly linked shared library, eg: FILE* --> FILE_mangled* so that
> internally it has it's own libc calls that are independent from anything
> that a binary might require.
This is already trivially possible via the --exclude-libs ld option,
which is confusingly named but converts all symbols in particular (or
all) static libs being linked into hidden symbols. That is sufficient
for safely linking some dependency libs statically into a shared
library without the risk of breaking things in the program that loads
the shared library (I suspect it would work well for something like
zlib), but it depends on there being no additional hidden interface
surfaces that interact with the rest of the program. For libc those
would include (some as noted by others):
- the thread structure pointed to by the thread pointer
- signal dispositions used internally
- assumptions about what actions are excluded by locks
- possible leaks of pointers to allocated memory from one libc's
malloc to the other one's free.
In addition, libc initialization (including the thread
structure/pointer for the main thread) is performed as part of the
call to __libc_start_main from the crt1 entry point. This will never
happen for a copy embedded inside your shared library, and thus you
would be running with a libc in uninitialized state. In practice the
thread pointer, which is the main thing that needs initialization,
would already have been initialized by the "real" libc, so things
might "happen to work" with an exact-same-version musl libc.so
matching the libc.a you linked with, but on the opposite end of the
spectrum things would horribly blow up when your linked-in musl finds
a glibc-format thread structure at that address.
This is probably only the tip of the iceberg as to what can go wrong
with your idea. On the flip side, I don't see what advantages you
could get by static linking libc.a into a shared library. If your
library is shared, then it necessarily already has a shared libc.so
available at runtime (simply because it's being used in a
dynamic-linked program). If your intent is to produce a shared library
that works with both musl and glibc, that's a nice idea, but a
different approach is probably needed, and it would be an interesting
discussion to spin off of this thread.
Rich
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.
