Re: [PATCH, RFC] Add public function syscall_no_errno

[dalias <dalias@libc.org>]

On Wed, Feb 07, 2024 at 04:59:54AM +0400, Askar Safin wrote:
> Hi, Rich and Adhemerval!
> 
>  ---- On Fri, 02 Feb 2024 00:16:26 +0400  dalias  wrote --- 
>  > OK, but this falls under "poking around behind libc's back".
> 
> Function "syscall" exists in glibc. So it is assumed to be useful.
> Thus it is okay to have "syscall_no_errno", too. "syscall" in
> its current form has a problem: you cannot correctly call
> SYS_getuid32. Thus there is need for "syscall_no_errno".
> 
> So I will write next version of my patch. I hope in several days,
> when I have time.
> "syscall_no_errno" will be simple wrapper for "INTERNAL_SYSCALL_NCS_CALL".
> 
>  > Well that's not something syscall() gives you and it's not something
>  > syscall_no_errno() would reliably give you either unless it was
>  > specifically documented to be callable from such a context. If that's
>  > what you want, maybe that's what should be discussed.
> 
> I did some research. I have read all places where glibc calls "clone".
> And I see that in all these places if CLONE_VM specified, then
> CLONE_SETTLS or CLONE_VFORK is specified.
> 
> In fact, there is 2 places only, where glibc calls clone (in Linux x86_64).
> 
> One is implementation of pthread_create. We pass CLONE_VM and
> CLONE_SETTLS. Thus (as well as I understand) TLS is set up
> in child right from the beginning.
> There is no time gap, when TLS is not initialized yet.
> 
> Second place is implementation of posix_spawn. We pass CLONE_VM
> and CLONE_VFORK. CLONE_VFORK means that parent is suspended,
> and thus it is okay to access its TLS.
> 
> Thus glibc absolutely always (even internally!) maintains invariant
> "TLS is safe to access". I. e. glibc itself does not need a way to perform
> syscalls when TLS is not set up.

You're missing the point. Of course glibc maintains that invariant
because it's providing a consistent platform to applications. If you
have application code that uses clone() itself, it may not be meeting
those invariants necessary to be able to call into libc.

> In fact my original use case is so: I want to parse true kernel ABI
> from files /sys/kernel/debug/tracing/events/syscalls/sys_enter_*/format
> and then generate a library based on the ABI.
> 
> Such library will provide syscall wrappers with correct types. These
> wrappers will call functions "syscall" and "syscall_no_errno".
> 
> (In fact, this will be Rust library, not C one, but I don't think
> this is important for our discussion. You may say: "Then why
> you want to add syscall_no_errno to upstream glibc?"
> Well, because I want it to be available to everyone. To Rust
> programmers, to C programmers and to everyone else.
> Without the need to write assembly.)
> 
> So, I will read proper kernel ABI from /sys/kernel/..., so
> I will get ABI right.

Can you clarify *why* you want to do that? Making raw syscalls like
this is ill-advised and *will* run into mismatched ABI for certain
types (where the kernel and user types differ), poor compatibility
with kernel versions that aren't the same you expected, time64 issues
on 32-bit archs, etc.

Based on our conversations in this thread, I do not think you're
prepared to handle all that right. It most certainly cannot be handled
in an automated way by parsing the data you have in mind; doing it
right requires knowing semantic relationships between syscalls.

It sounds like you plan to hand Rust programmers a big footgun.

Rich