[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 15 Aug 2022 14:35:33 -0700
From: Colin Cross <ccross@...roid.com>
To: musl@...ts.openwall.com
Cc: Ryan Prichard <rprichard@...gle.com>
Subject: Running musl executables without a preinstalled dynamic linker
I would like to distribute dynamic binaries built against musl to
systems that do not have the musl dynamic linker installed in any
known location (e.g. /lib/ld-musl-$ARCH.so.1). I have two prototypes
that enable this, and I’d like to gauge whether either is something
that would be of interest to check in to musl, or whether it would be
something we should keep in our project.
The first solution is based on the embedded linker we use to test
bionic libc on non-Android systems. The dynamic linker is compiled as
usual, then the resulting elf file is embedded as raw data into
Scrt1.o and the PT_INTERP section removed. The entry point is changed
to point to a trampoline that modifies AT_BASE, AT_ENTRY and AT_PHDR
to simulate how the kernel would initialize them if the dynamic linker
was mapped separately by the kernel instead of as part of the main
executable, and then jumps to the dynamic linker.
This embedded linker solution works relatively well, except that the
dynamic linker’s elf sections are inside the main executable’s elf
sections, which can break reasonable assumptions. For example, musl’s
dladdr fails to find symbols in the embedded linker, and gdb has
trouble finding debug information from the linker. Musl’s reuse of
libc.so as the linker means that these problems apply to everything in
libc.so, and also increases the size of every binary by including all
of libc.so.
These problems with the embedded linker could be somewhat mitigated by
splitting the dynamic linker out of libc.so when using the embedded
linker. That requires compiling the ldso sources against a statically
linked libc.a, tweaking some of the initialization, and forwarding the
dl* calls from libc.so to the separate linker. The changes are
relatively small, but result in a pretty big difference in musl’s
internals with and without the embedded linker that may be hard to
maintain.
The second solution we call “relinterp”. It was originally designed
by Ryan Prichard as a standalone trampoline that could be used with
musl, glibc or bionic, but I’ve more tightly integrated it with musl
in order to reuse CRTJMP for architecture portability and some of
musl’s string functions to reduce the size of the code. It uses a
similar trampoline in Scrt1.o, but with a much larger implementation
that reads DT_RUNPATH to construct a path to the dynamic linker that
is relative to the executable. It then maps the dynamic linker as the
kernel would, modifies AT_BASE, AT_ENTRY and AT_PHDR, and jumps to the
dynamic linker.
The current prototype of relinterp is tricky to compile, as it
requires using -fvisibility=hidden and ld -r partial linking to build
a Scrt1.o file that uses some of the src/string/*.c sources without
any relocations, and then objcopy –keep-global-symbol to hide the
string symbols. It’s only useful if DT_RUNPATH contains $ORIGIN so
that the dynamic linker can be distributed alongside the executable,
so it is probably never going to be suitable for setuid binaries.
If relinterp were going to be included with musl I’d refactor it to
reuse the __dls* bootstrapping from dynlink.c so that it can link
against libc.a and not worry about avoiding any relocations.
An alternative solution to these two would be to distribute statically
linked binaries, which precludes the use of dlopen, or to wrap every
executable in a shell script that runs the dynamic linker directly.
Do either of these prototypes seem interesting enough to clean up and
post as upstream patches, or should I keep them as a side project that
I can bolt on to musl with minimal invasive changes?
Colin
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.
