[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAC_pWX0AuopJ_xkc8FsvPb-Sas5osjsPSU14owrpqwyd3d+VrA@mail.gmail.com>
Date: Tue, 25 Nov 2025 13:04:41 -0500
From: Arjun Ramesh <arjunr2@...rew.cmu.edu>
To: musl@...ts.openwall.com
Subject: Re: [Patch Request] Name-bound syscalls within musl
>
> El mar, 25 de nov de 2025, 14:29, Arjun Ramesh <arjunr2@...rew.cmu.edu>
> escribió:
>
>> 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?
>>
>
> What about defining the functions in an x-macro table, in order to avoid
> the repeated boilerplate that this change would bring?
>
>
>> Thanks
>> Best,
>> Arjun
>>
>
That's a good idea, an x-macro syscall table might actually be a cleaner
direction without scattered changes.
Arjun
On Tue, Nov 25, 2025 at 12:41 PM Daniel Gutson <danielgutson@...il.com>
wrote:
>
>
> El mar, 25 de nov de 2025, 14:29, Arjun Ramesh <arjunr2@...rew.cmu.edu>
> escribió:
>
>> 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?
>>
>
> What about defining the functions in an x-macro table, in order to avoid
> the repeated boilerplate that this change would bring?
>
>
>> Thanks
>> Best,
>> Arjun
>>
>
Content of type "text/html" skipped
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.
