linux-kernel - Re: Explicitly defining the userspace API

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]

Date:   Thu, 21 Apr 2022 13:33:57 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Jann Horn <jannh@...gle.com>
Cc:     Spencer Baugh <sbaugh@...ern.com>,
        Linux API <linux-api@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Marcin Juszkiewicz <marcin@...zkiewicz.com.pl>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Arnd Bergmann <arnd@...db.de>
Subject: Re: Explicitly defining the userspace API

On Wed, Apr 20, 2022 at 7:18 PM Jann Horn <jannh@...gle.com> wrote:
>
> On Wed, Apr 20, 2022 at 6:30 PM Spencer Baugh <sbaugh@...ern.com> wrote:
> > Linux guarantees the stability of its userspace API, but the API
> > itself is only informally described, primarily with English prose.  I
> > want to add an explicit, authoritative machine-readable definition of
> > the Linux userspace API.
> >
> > As background, in a conventional libc like glibc, read(2) calls the
> > Linux system call read, passing arguments in an architecture-specific
> > way according to the specific details of read.
> >
> > The details of these syscalls are at best documented in manpages, and
> > often defined only by the implementation.  Anyone else who wants to
> > work with a syscall, in any way, needs to duplicate all those details.
> >
> > So the most basic definition of the API would just represent the
> > information already present in SYSCALL_DEFINE macros: the C types of
> > arguments and return values.
>
> FWIW, I believe ftrace already gets that basic information from the
> SYSCALL_DEFINE macros via struct syscall_metadata, and exports it to
> root-privileged userspace (although I think it won't actually tell you
> what the syscall number is that way):

One possible way I have considered in the past is to change the
SYSCALL_DEFINE() macros so they live in include/linux/syscalls.h,
where they expand to the wrappers for argument sanitizing (clearing
the upper bits etc) and end up calling normal functions.

When combined with the information in the syscall.tbl, this can help
provide a machine-readable list of implemented system calls and at the
same time ensure that the prototypes match what the actual functions
have.

The main missing bit for this is to convert asm-generic/unistd.h to
the syscall.tbl format, and to ensure that there is a unique mapping
between sys_*() function names and prototypes. The latter bit is
/almost/ there and should be easy to get right by renaming a couple
of nonstandard syscall entry points.

       Arnd