From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) by sourceware.org (Postfix) with ESMTP id 4BC153858C3B for ; Mon, 30 Aug 2021 01:55:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4BC153858C3B Date: Mon, 30 Aug 2021 02:55:29 -0400 From: Mike Frysinger To: Richard Purdie Cc: libc-help@sourceware.org Subject: Re: glibc 2.34 and Yocto Project's "uninative" Message-ID: Mail-Followup-To: Richard Purdie , libc-help@sourceware.org References: <978104bdbebcd09d159f1713499cf1315edf40f2.camel@linuxfoundation.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hOLkpwIS2Lr488m7" Content-Disposition: inline In-Reply-To: <978104bdbebcd09d159f1713499cf1315edf40f2.camel@linuxfoundation.org> X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00, DATE_IN_FUTURE_03_06, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, KAM_SHORT, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2021 01:55:57 -0000 --hOLkpwIS2Lr488m7 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 20 Aug 2021 15:37, Richard Purdie via Libc-help wrote: > Yocto Project=C2=A0is a cross compiling build system used to build custom= ised > Linux, RTOSs, firmware and more. It has some interesting technology. One = piece > of it is "pseudo" (http://git.yoctoproject.org/cgit.cgi/pseudo/) which is= an=20 > LD_PRELOAD which intercepts calls to libc and fakes root privileges. One = way or > another we've managed to keep that working with multiple libc versions fo= r the > last decade. this sounds like Debian's fakeroot [1] & Gentoo's sandbox [2]. these have always been a challenge to keep working, and to be complete. they're always "best effort" because they require: (1) every program being dynamic. any staticly linked programs won't work. (2) every interesting call having an actual interception point by interposi= ng known functions that the C library provides. any calls the C library makes via PLT bypass cannot be captured, and any syscalls the C library or the app makes cannot be captured. (3) a superset of every symbol (versioned & unversioned) that a C library might expose. this in particular is messy. [1] https://wiki.debian.org/FakeRoot [2] https://wiki.gentoo.org/wiki/Sandbox_(Portage) a tool using ptrace to intercept the syscall addresses all these, but at the cost of being slower (since every syscall is notified). if you can require seccomp & Linux 3.5+, then things look a lot better here as you can setup a seccomp filter for the process tree and only get notified for the exact set of syscalls you're interested in. it does mean you have to handle every syscall wart across different architectures, but that's a bit easier to do than all the variety of C library ABI warts. (i'll ignore instability in the ptrace framework itself that we've observed when using the interface at scale.) i haven't reviewed the even newer seccomp notify [3] mechanism to see if that's useful. maybe that would offer even more relief. [3] https://man7.org/linux/man-pages/man2/seccomp_unotify.2.html [3] https://brauner.github.io/2020/07/23/seccomp-notify.html > A second piece of technology is uninative. We build a lot binary artefact= s, some > for the target, some as tools running natively on the build system. We ha= ve a > cache of these artefacts people can share and reuse. Uninative is our way= of > allowing one binary to run on any host distro. We do that by shipping a l= d+libc > binary shim and change the interpreter in the native binary to point at o= ur own. > As long as the shim is the same version or later than system version, it = works. we do this in CrOS with our toolchains by largely using pax-utils's lddtree= [4]. it will bundle the active C library (and any other libs), and then generate= a wrapper shell script for each program that is actually executed at runtime. that does the ldso & ldpath dance so it's all relocatable. [4] https://gitweb.gentoo.org/proj/pax-utils.git/tree/lddtree.py -mike --hOLkpwIS2Lr488m7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAmEsgNUACgkQQWM7n+g3 9YG08hAAi6/jGTBOOUpU07b3vcny56rK/BpBykZqIei2t3n0zp/EfmtnWnd82poX e7Bf3UMSzLcVOJvuXn4i0x+9qpfeSm8f8x5EuOh8YqHupvxI75leiwbPtIjdcjNV Nox7/Tnc5r5ezbZhClqucDvLISTxLKJrJ8AZ+zdI5Tu4TLU554jxZl9200ckJWV6 eHtcrX5V84tzh9Ss0UMi+bqiiUFdKnOT4TqS1S9dmjuTENkbmdGuH/VzcsYqocdL tG01agX4gVtg2ptCOXbxHPD7RwX9ReZiFNOSt+HIlyGKUE36QLwP6vNIcI6D16Rs +Et5V2yrYgBkZEay7ADxTRAjSZcRPKAqL/sIGndDlozbuz/5MHWYHww9NfKeg/bu vBgBWkUCKTcfh5ChazQBA9oSiqRQq2RhBMoWAGqJG1I4I8YcxpkGXBP7qlowJHSi InyrFJmsckN0MAHDeDxk0gIs0QCli2+6/A6wqunrA079CwgHWzAi6fxDLvvqz53q 6IRWfPPGvdX/B2Vma9sgJEv6IPqZ/4dCBiI9dFHPgKgXsTVNFrtrN49NmRMtZ/9K kNry7DQYsz2RVBaFtg9eWAAPqk6f+ByavsT1hGwwAXFr5V55zhfRO0yWe0F5JKVg DL7SZF7ydzjrj8ZglTq6ZTTPVxmXuqbWPKqrUviEAtd6mwzHmlk= =KxWs -----END PGP SIGNATURE----- --hOLkpwIS2Lr488m7--