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.