[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251126014419.GW1827@brightrain.aerifal.cx>
Date: Tue, 25 Nov 2025 20:44:20 -0500
From: Rich Felker <dalias@...c.org>
To: Arjun Ramesh <arjunr2@...rew.cmu.edu>
Cc: musl@...ts.openwall.com
Subject: Re: [Patch Request] Name-bound syscalls within musl
On Tue, Nov 25, 2025 at 12:29:08PM -0500, Arjun Ramesh wrote:
> Hi everyone,
>
> I am currently working on a research project using musl that uses
> name-bound syscalls. Skimming the codebase, nearly all references to
> "syscall" invocations within musl use the SYS_* defines. These numbers
> differ across ISAs and are susceptible to type-safety
> bugs, providing virtually no type-checking on their arguments. Syscalls
> bound statically by name will make the codebase much less prone to mistakes
> and cleaner, allowing type-checked syscall arguments and also cutting down
> on the amount of ISA-specific code surface. Below is an example of the
> patch I'm suggesting for a single syscall:
>
> ```
> diff --git a/src/fcntl/open.c b/src/fcntl/open.c
> index 4c3c8275..ff5f7973 100644
> --- a/src/fcntl/open.c
> +++ b/src/fcntl/open.c
> @@ -15,7 +15,7 @@ int open(const char *filename, int flags, ...)
>
> int fd = __sys_open_cp(filename, flags, mode);
> if (fd>=0 && (flags & O_CLOEXEC))
> - __syscall(SYS_fcntl, fd, F_SETFD, FD_CLOEXEC);
> + __syscall_SYS_fcntl(fd, F_SETFD, FD_CLOEXEC);
>
> return __syscall_ret(fd);
> }
> ```
>
> "__syscall_SYS_fcntl" can be defined with a unified static type signature
> across ISAs. Given the highly structured nature of this patch, it could
> mostly be accomplished with a simple `sed` command across the entire
> project, with no impact on functionality. Would the community be open to a
> patch of this nature?
This kind of invasive change will not be accepted upstream. It just
moves the logic for the type signatures to a different location, and
has no concrete benefit. Unnecessary churn like this has a high cost,
as it prevents users from backporting security and other bugfix
patches to older or forked versions of the codebase they may be using,
and requires users who read the commit log as a basis for trusting
changes to wade through the churn to determine that all the changes it
made were as-described and correct.
Where there have historically been issues with syscall signatures, it
has almost entirely been a consequence of weird things the kernel did
that we didn't know about, and encoding our assumption about the
signatures at a different abstraction layer would not have made the
assumptions that mismatched what the kernel was doing any more
correct. If someone does want to check signatures, this could probably
be done mechanically on the codebase as-is, extracting information
from the kernel and checking callpoints against it.
For your research project, I think it's entirely possible to do the
name-binding just by the choice of how you define the __syscallN
macros in syscall_arch.h and the SYS_* macros, so that they expand to
"name bindings". If you're targeting a system where these name-bound
syscalls are not actual syscalls but callable functions, I think you
could even do some magic in the macros to make the type checking
happen like this.
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.
