[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190427161936.GS23599@brightrain.aerifal.cx>
Date: Sat, 27 Apr 2019 12:19:36 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 3/3] crt: add dcrt1, with support for locating the
dynamic loader at runtime
On Sat, Apr 27, 2019 at 10:55:40AM +0200, Szabolcs Nagy wrote:
> * Rodger Combs <rodger.combs@...il.com> [2019-04-26 20:13:29 -0500]:
> > ---
>
> i think you need a lot more explanation about possible
> use-cases, failure modes, toolchain requirements etc.
I can elaborate a bit. This is long-desired functionality, to be able
to produce dynamic-linked binaries which run without the presence of a
"program interpreter" (dynamic linker) at a fixed absolute pathname
and without wrapper scripts or similar. The idea is that the entry
point works like static pie, performing sufficient self-relocation to
begin execution without a dynamic linker, but then maps the dynamic
linker into memory according to some search procedure that allows it
to be found relative to the main executable's location. More on this
later. The use case is distribution of dynamic musl-linked binaries
that can easily be run on non-musl systems.
Toolchain requirements are essentially nothing new, but the toolchain
must be invoked in a different way (alternate crt1 file and passing
--no-dynamic-linker to ld). The patches as submitted put this into the
musl-gcc and musl-clang wrapper scripts, which is a decent way of
testing, but these wrappers are not really intended for serious use,
so going forward there should be some discussion of what might be an
acceptable way to upstream this to gcc or at least include it in mcm
in a way that's maintainable and doesn't conflict with upstream.
Failure modes include at least:
- Cannot be used with suid/sgid, at all. Needs to hard fail if invoked
that way; otherwise it invites dangerous misuse. Currently this is
not handled right.
- Does not work if /proc is not mounted or /proc/self/exe is not
available. (It might be better to work from AT_EXECFN but that has
different semantics.)
- Processes and honors LD_LIBRARY_PATH and (new) LD_LOADER_PATH. These
could be wrong especially in the main intended usage case, a
non-musl system. But that would affect ldso itself already. It's not
a hard no at this point (needs discussion) but I'm skeptical of any
use of environment from crt1.
- Depends on ability to rewrite aux vector and program headers in some
possibly fragile ways (seems mostly ok from what I remember; need to
review again where we'll have a record we can look back at).
There may be others I find when reviewing the patches in more detail,
which I'm starting now.
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.
