Re: [PATCH, RFC] Add public function syscall_no_errno

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 01/02/24 17:16, dalias wrote:
> On Thu, Feb 01, 2024 at 11:32:41PM +0400, Askar Safin wrote:
>> Hi, Rich and Adhemerval!
>>
>>  ---- On Thu, 01 Feb 2024 21:53:44 +0400  Adhemerval Zanella Netto  wrote --- 
>>  > 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.
>> It *is* one of them!
>>
>> Keep in mind that Linux supports 32-bit uids.
>>
>> Run this code as root as 32-bit i386 binary (my letter continues
>> after code). It is okay to run it on 64-bit amd64 kernel, you just
>> have to make sure the binary itself is compiled as i386
>> =*=*=*=*=
>> #if !defined(__i386__)
>> #error
>> #endif
>>
>> #include <stdint.h>
>> #include <stdio.h>
>> #include <sys/syscall.h>
>> #include <unistd.h>
>>
>> int
>> main (void)
>> {
>>   // 4294967286 is (2^32)-10
>>   uint32_t a = 4294967286U;
>>   if (syscall (SYS_setuid32, a) == -1)
>>     {
>>       perror("setuid");
>>       return 1;
>>     }
>>
>>   uint32_t b = syscall (SYS_getuid32);
>>
>>   // Now b is equal to (uint32_t)-1 instead of wanted 4294967286 (i. e. (uint32_t)-10)
>>   printf("%u (wanted)\n", a);
>>   printf("%u (got)\n", b);
>>   return 0;
>> }
>> =*=*=*=*=
>>
>> (Also, when I said "getuid", I meant "SYS_getuid32".)
>>
>> I see this output:
>> =*=*=*=*=
>> 4294967286 (wanted)
>> 4294967295 (got)
>> =*=*=*=*=
>>
>> So, yes, function "syscall" is incompatible with SYS_getuid32.
> 
> OK, but this falls under "poking around behind libc's back". If you
> call getuid() you'll find you get the right answer (at least on musl;
> not sure about glibc).

It works as expected on glibc as well.

> 
>> I'm nearly sure the same is true about getpid.
> 
> It's not. PIDs are a 29- or 30-bit space (which is a matter of a bug I
> currently have open) on Linux. At least the high two bits are banned
> from ever being usable as a consequence of the futex interface.
> 
>> Rich:
>>> If someone really wants to write code that's
>>> independent of libc -- like to run in a vforked child or CLONE_VM
>>
>> This is another use case I want to support. I. e. I want to
>> have portable function (i. e. independent of arch) for issuing
>> syscall in such case. And I don't
>> want to write assembly.
> 
> 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.

There is another potential issue where you have multiple syscall
with slight different kABI (like the ones that have 64 bit arguments
on 32 bit architectures) and, at least for glibc, where the user
exported argument does not really match the kernel (stat/fstat/etc.).

> 
>>> but might inspect TLS to
>>> determine how to make the syscall
>>
>> Okay, so syscall_no_errno should not do this. I. e. it should
>> always do some way to make syscall, which always works,
>> even if it is slow. For i386 it is "int 0x80" as well as I understand.
>>
>> Also, even if we read TLS to determine how to make syscall,
>> what will go wrong? Child shares TLS with its parent after CLONE_VM,
>> so we simply will read parent's TLS
> 
> At least on glibc, you can pass clone flags that setup a new thread
> pointer in the child, which you may be intending to use for your own
> purposes in 'bare, no libc' code in the child. On musl this is not
> possible; the flags are rejected and you have to write your own asm to
> call clone if you want that.
> 
> In any case, "what will go wrong?" is not the right question. The
> question is whether there's a contract for the thing you want to do to
> work, and there isn't.

And I am not very found of this possible slight different contract for
a non-standard interface.