linux-kernel - Re: [PATCH v2 07/11] um: add infrastructure to build files using nolibc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250921081318.GB16684@1wt.eu>
Date: Sun, 21 Sep 2025 10:13:18 +0200
From: Willy Tarreau <w@....eu>
To: Benjamin Berg <benjamin@...solutions.net>
Cc: linux-um@...ts.infradead.org,
        Thomas Weißschuh <linux@...ssschuh.net>,
        linux-kselftest@...r.kernel.org,
        Arnaldo Carvalho de Melo <acme@...hat.com>,
        linux-kernel@...r.kernel.org, Benjamin Berg <benjamin.berg@...el.com>
Subject: Re: [PATCH v2 07/11] um: add infrastructure to build files using
 nolibc

Hi Benjamin,

On Fri, Sep 19, 2025 at 05:34:16PM +0200, Benjamin Berg wrote:
> From: Benjamin Berg <benjamin.berg@...el.com>
> 
> Add NOLIBC_CFLAGS and NOLIBC_OBJS to build files against nolibc rather
> than libc. With this it is possible to move to nolibc in smaller steps.
> 
> Set NOLIBC_IGNORE_ERRNO, as the nolibc errno implementation is overly
> simple and cannot handle threading. nolibc provides sys_* functions that
> do not emulate the libc errno behaviour and can be used instead.

Just for my understanding, in case we can improve portability, why is it
needed to disable errno processing here ? Even if it's limited, it
shouldn't cause trouble. I mean that if a program works with it defined,
logically it should also work without since the only difference is that
the errno global variable will not be defined nor assigned on syscall
returns.

> Guard the syscall definition as it is a macro in nolibc.

This one is interesting:

  --- a/arch/um/include/shared/os.h
  +++ b/arch/um/include/shared/os.h
  @@ -327,7 +327,9 @@ extern int __ignore_sigio_fd(int fd);
   /* tty.c */
   extern int get_pty(void);

  +#ifndef NOLIBC
   long syscall(long number, ...);
  +#endif

In nolibc, the syscall() definition indeed looks like this now:

  #define __syscall_narg(_0, _1, _2, _3, _4, _5, _6, N, ...) N
  #define _syscall_narg(...) __syscall_narg(__VA_ARGS__, 6, 5, 4, 3, 2, 1, 0)
  #define _syscall(N, ...) __sysret(my_syscall##N(__VA_ARGS__))
  #define _syscall_n(N, ...) _syscall(N, __VA_ARGS__)
  #define syscall(...) _syscall_n(_syscall_narg(__VA_ARGS__), ##__VA_ARGS__)

Except by mapping all syscalls to _syscall(6, ...) and always passing
6 args, I'm not seeing any easy way to dynamically adapt to the number
of arguments if we wanted to move it to a function. Also, a static
function would still conflict with the definition above. I'm wondering
about what extent the documented "long syscall(number, ...)" is valid in
fact, as I doubt it's really implemented anywhere as a generic function
taking the maximum amount of args.

Thus I think that the guard is indeed the only option to reconciliate these
two incompatible approaches. By the way I think it could be more future-
proof to do the guard on the syscall macro definition itself (which would
thus also resist it being passed by "-Dsyscall(x)=(...)" or any other form:

  +#ifndef syscall
   long syscall(long number, ...);
  +#endif

Regards,
Willy