[PATCH, RFC] Add public function syscall_no_errno

Askar Safin safinaskar@zohomail.com
Thu Feb 1 19:32:41 GMT 2024


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.

I'm nearly sure the same is true about getpid.

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.

> 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


More information about the Libc-alpha mailing list