linux-kernel - Re: Metalanguage for the Linux UAPI

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 for Android: free password hash cracker in your pocket

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

Message-ID: <A89533DF-E2F9-4536-A00D-4E3685565E67@zytor.com>
Date: Thu, 15 May 2025 21:17:14 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Willy Tarreau <w@....eu>
CC: enh <enh@...gle.com>, Arnd Bergmann <arnd@...db.de>,
        LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        libc-alpha@...rceware.org, linux-arch@...r.kernel.org
Subject: Re: Metalanguage for the Linux UAPI

On May 15, 2025 8:42:32 PM PDT, Willy Tarreau <w@....eu> wrote:
>On Thu, May 15, 2025 at 02:24:29PM -0700, H. Peter Anvin wrote:
>> On 5/15/25 13:26, enh wrote:
>> > On Thu, May 15, 2025 at 4:05 PM H. Peter Anvin <hpa@...or.com> wrote:
>> > > 
>> > > OK, so this is something I have been thinking about for quite a while.
>> > > It would be a quite large project, so I would like to hear people's
>> > > opinions on it before even starting.
>> > > 
>> > > We have finally succeeded in divorcing the Linux UAPI from the general
>> > > kernel headers, but even so, there are a lot of things in the UAPI that
>> > > means it is not possible for an arbitrary libc to use it directly; for
>> > > example "struct termios" is not the glibc "struct termios", but
>> > > redefining it breaks the ioctl numbering unless the ioctl headers are
>> > > changed as well, and so on. However, other libcs want to use the struct
>> > > termios as defined in the kernel, or, more likely, struct termios2.
>> > 
>> > bionic is a ("the only"?) libc that tries to not duplicate _anything_
>> > and always defer to the uapi headers. we have quite an extensive list
>> > of hacks we need to apply to rewrite the uapi headers into something
>> > directly usable (and a lot of awful python to apply those hacks):
>> > 
>> > https://cs.android.com/android/platform/superproject/main/+/main:bionic/libc/kernel/tools/defaults.py
>> > 
>> 
>> Not "the only".
>
>Indeed, nolibc (/tools/include/nolibc) directly includes uapi as well, and
>since nolibc doesn't compile anything but only exposes include files, these
>appear as-is in the application. So far the headers look clean enough for
>our use cases and have not caused problems. But admittedly, applications
>are small and limited (selftests and init code).
>
>One thing we've been considering which we would find convenient there
>would be to generate an indirection layer for all files that would include
>the right one depending on the detected arch so as to ease compilation for
>any arch with all the uapi files available, as it seems totally feasible
>right now (i.e. each .h file would just have "#if defined(__arch_xxx__)
>#include <arch_xxx/foo.h>" etc). We could imagine having a
>"make install-all-headers" target to produce that thing for example. I'm
>sharing this so that you can also have this in mind to consider whether or
>not your chosen approach would break that possibility.
>
>Just my two cents,
>Willy

Ah yes, nolibc; basically klibc reinvented...

<ducks and runs>