From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.9 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2,T_SCC_BODY_TEXT_LINE,URIBL_BLACK autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 27094 invoked from network); 15 Aug 2022 21:36:01 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 15 Aug 2022 21:36:01 -0000 Received: (qmail 1680 invoked by uid 550); 15 Aug 2022 21:35:58 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 1648 invoked from network); 15 Aug 2022 21:35:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=android.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :mime-version:from:to:cc; bh=/0rg2j1Btg1eunRrwRSSqkhGNTpVmPnh5NX6ven8Eb4=; b=jRCNw0IQzL7khgywGARZFaW6fzR/jam8l6S7xGCWAEhv9TZ1ULC+L2G7zl3j2gOxXR XbxSGuG8eohX/SjSsMRQ+WyAYobzUWLp/Cu/SfALgzv1dw8WFZn97EfG4kdEgAGqqMRD vT87laH1uyVpuubLpSCu8lS6qylOm+TNhr0T2a71UyCen1falDULmHq3NZ3K4n3bWUlC y17b2nFrQ0lh5H0GVtcqop8zCMoEQv25BLKDTL+xjvzZqLK1WAMld19EYNVN89B8On2J 4epTdkKroTO/c7cBHqME2wO1IFHxETK1Ly60GpP8S8FxxsOgDe+f2owbSgiHdwbFOZ/f 85Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :mime-version:x-gm-message-state:from:to:cc; bh=/0rg2j1Btg1eunRrwRSSqkhGNTpVmPnh5NX6ven8Eb4=; b=tHpOz+n80bCI6WN2sp52xzLnFHMjJ/AC0g3iUOL4gdwI343r0bbXqE+gvRvv/+tAAk J9C2WS2DSuxgPpvo8mtjq5ht6EaHC4uQmcf2uqA8zHxK/9u5j/tdHz2YRJVOungJOmPc KBt2kHS5tHWjru5F91zBSGLPTnqWksIc6Xotbt+wVSz1nglJ5C9IFQIsqTwuwh4AtmdK 6ceUsQmK8qV6OpXKxBR3am36fhSLN+Dn6WuKLqFMJBTaSAXOAB6NCu51sR0wYPzFklTO aN2hcK9G4HcmHL8g9Q2OQQS3o2u9fZ5ujUHBf5qMqZxoJeGE30dpxJoncwB1PBCZ5NP9 diZA== X-Gm-Message-State: ACgBeo3uqV9vZ/ZBt4s6aukV+82LYyGhG/7hd+/QcLkTTqDmDzltLf5K 1d+f0myY/cwuF67APjB+Hf1I7Zyd1zNb9mMs7SjA0+JJEPFMZm2j X-Google-Smtp-Source: AA6agR7sfKn6+qjQbaH2DPeIOG9x3BNi1LUMaziWAEviWcnkZjvhdO1sNx/+XJuMUd1Uls845DK3oyEGq5EIbsvecqI= X-Received: by 2002:a02:a789:0:b0:33f:4ccb:3139 with SMTP id e9-20020a02a789000000b0033f4ccb3139mr7596622jaj.20.1660599344761; Mon, 15 Aug 2022 14:35:44 -0700 (PDT) MIME-Version: 1.0 From: Colin Cross Date: Mon, 15 Aug 2022 14:35:33 -0700 Message-ID: To: musl@lists.openwall.com Cc: Ryan Prichard Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: [musl] 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=E2=80=99d 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=E2=80=99s elf sections are inside the main executable=E2=80= =99s elf sections, which can break reasonable assumptions. For example, musl=E2=80= =99s dladdr fails to find symbols in the embedded linker, and gdb has trouble finding debug information from the linker. Musl=E2=80=99s 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=E2=80=99s internals with and without the embedded linker that may be hard to maintain. The second solution we call =E2=80=9Crelinterp=E2=80=9D. It was originally= designed by Ryan Prichard as a standalone trampoline that could be used with musl, glibc or bionic, but I=E2=80=99ve more tightly integrated it with mus= l in order to reuse CRTJMP for architecture portability and some of musl=E2=80=99s 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=3Dhidden 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 =E2=80=93keep-global-symbol to hide the string symbols. It=E2=80=99s 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=E2=80=99d 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