Re: libc/libsys split coming soon

On Sat, Feb 03, 2024 at 05:11:42PM +0100, Paul Floyd wrote:
> 
> On 02/02/2024 23:31, Brooks Davis 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.
> 
> Will that affect code that makes syscalls without currently linking to libc?

Such programs might be broken in these environments but it would depend
a lot on the details of both the program and the replacement syscall
layer.

> >    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).
> 
> That's one to ignore for tools that make syscalls outside of the libc memory
> mapping.

Should someone implement msyscall(2) there will certainly be an opt out
mechanism along the usual lines that uses elfctl and procctl.

> >    3. It allows language runtimes to link with libsys for system call
> >       implementations without requiring libc.
> 
> I see that pagesize is on the list of functions that are moving. There are a
> couple of other functions that might cause me problems if libc isn't linked.
> 
> Could you do a quick test with an exe linked to libsys but not libc running
> under Valgrind memcheck, please?

Could you suggest a more concrete example?

-- Brooks