Re: [PATCH, RFC] Add public function syscall_no_errno

[Rich Felker <dalias@libc.org>]

On Thu, Feb 01, 2024 at 02:53:44PM -0300, Adhemerval Zanella Netto wrote:
> 
> 
> On 28/01/24 13:39, Askar Safin wrote:
> > Hi! I want glibc to have function "syscall_no_errno" on Linux.
> > It should do the same "syscall" does, but it should not interpret
> > return value and set errno. This is useful for calling syscalls
> > such as getuid. I. e. now the user can call directly all syscalls
> > including getuid and similar.
> > 
> > I add example patch. It is quick-and-dirty. I was unable to figure out
> > how to add function to headers. So, please, don't apply it as-is.
> > 
> > I just want to know do you agree with my proposal. If yes, I will try
> > to write better patch.
> > 
> > I will repeat: currently glibc is simply incomplete, because it
> > does not provide a way to call directly syscalls, such as getuid.
> > So the user have to craft assembly, which is very difficult.
> 
> Indeed there some old syscalls where trying to issue them directly with
> syscall is problematic (like 'time' and 'brk' for some ABIs), but getuid
> is not one of them.  Also, recent Linux kABI is trying to avoid such 
> problematic interfaces to return the value as the return code and make
> the invalid value similar to all cases.  So these are not very compeling
> reason to add a non-standard symbol to issue syscalls.
> 
> CCing Rich, maybe he has a different view about this.

That would be my view too. In general, it's rarely useful to make a
raw syscall() to begin with. For the majority of syscalls that are
ingredients in implementing standard or almost-standard functions
provided by libc, going around libc to call it directly risks creating
inconsistent state (brk), having inconsistent types (stat, etc.),
missing fallback cases (direct use of time64 syscalls), etc. and
really should not be encouraged by making unneeded new ways to do it.
Indeed the only syscalls I'm aware of for which there's ambiguity
about the result are of this sort.

I don't even think brk is an affected one; values >=4095UL are not
valid brk boundaries. Similarly, I don't think Linux supports setting
system clock to before the epoch (and doing so would not be accurate
anyway), so time is arguably not affected either. Even if it were,
it's superseded by clock_gettime or gettimeofday, which don't have the
problem, and might not even be available on future archs.

There is also fcntl with F_GETOWN, which was not mentioned above, but
it is superseded by F_GETOWN_EX, which the libc fcntl function
automatically uses when available instead of using F_GETOWN directly.
So I don't think it has modern relevance either.

In any case, back to my original point, the use case for syscall()
should be seen as calling newly-added extensions that don't yet have,
or that aren't suitable to have, libc functions for them. Use of it as
a means to "poke behind libc" should not be encouraged, as that tends
to break things. If someone really wants to write code that's
independent of libc -- like to run in a vforked child or CLONE_VM
context or something without a valid thread pointer/TLS state/etc. --
it can't be using libc at all, and that includes the libc syscall()
function (which not only may write errno, but might inspect TLS to
determine how to make the syscall). For this level of "raw" syscall
access, you need to write your own asm.

Rich