Date: Sat, 3 Feb 2024 10:15:09 +0100 From: Mateusz Guzik <mjguzik@gmail.com> To: Brooks Davis <brooks@freebsd.org> Cc: current@freebsd.org Subject: Re: libc/libsys split coming soon Message-ID: <CAGudoHGoSW4Zwa9PT_O7AeQX%2B8Q9PKmoQBm9HrmdKD5PNfE0uw@mail.gmail.com> In-Reply-To: <Zb1tTz5LXuVQ5Caj@spindle.one-eyed-alien.net> References: <Zb1tTz5LXuVQ5Caj@spindle.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/2/24, Brooks Davis <brooks@freebsd.org> wrote: > TL;DR: The implementation of system calls is moving to a seperate > library (libsys). No changes are required to existing software (except > to ensure that libsys is present when building custom disk images). > > Code: https://github.com/freebsd/freebsd-src/pull/908 > > After nearly a decade of intermittent work, I'm about to land a series > of patches which moves system calls, vdso support, and libc's parsing of > the ELF auxiliary argument vector into a separate library (libsys). I > plan to do this early next week (February 5th). > > This change serves three primary purposes: > 1. It's easier to completely replace system call implementations for > tracing or compartmentalization purposes. > 2. It simplifies the implementation of restrictions on system calls such > as those implemented by OpenBSD's msyscall(2) > (https://man.openbsd.org/msyscall.2). > 3. It allows language runtimes to link with libsys for system call > implementations without requiring libc. > > libsys is an auxiliary filter for libc. This means that for any symbol > defined by both, the libsys version takes precedence at runtime. For > system call implementations, libc contains empty stubs. For others it > contains copies of the functions (this could be further refined at a > later date). The statically linked libc contains the full > implementations so linking libsys is not required. > Do I read it correctly that everything dynamically linked will also be linked to libsys, as in executing such a binary will now require loading one extra .so? Binary startup is very slow, for example execve of a hello world binary in a Linux-based chroot on FreeBSD is faster by a factor of 2 compared to a native one. As such perf-wise this looks like a step in the wrong direction. Is there a problem making it so that libc ends up unchanged, but all the bits are available separately in libsys if one does not want libc? -- Mateusz Guzik <mjguzik gmail.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGudoHGoSW4Zwa9PT_O7AeQX%2B8Q9PKmoQBm9HrmdKD5PNfE0uw>