linux-kernel - Re: Official Linux system wrapper library?

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: <alpine.DEB.2.21.1811122223350.18130@digraph.polyomino.org.uk>
Date:   Mon, 12 Nov 2018 22:34:36 +0000
From:   Joseph Myers <joseph@...esourcery.com>
To:     Florian Weimer <fweimer@...hat.com>
CC:     Daniel Colascione <dancol@...gle.com>,
        Zack Weinberg <zackw@...ix.com>,
        "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Joel Fernandes <joelaf@...gle.com>,
        Linux API <linux-api@...r.kernel.org>,
        Willy Tarreau <w@....eu>, Vlastimil Babka <vbabka@...e.cz>,
        Carlos O'Donell <carlos@...hat.com>,
        GNU C Library <libc-alpha@...rceware.org>
Subject: Re: Official Linux system wrapper library?

On Mon, 12 Nov 2018, Florian Weimer wrote:

> For that use case, a machine-readable system call ABI specification is
> the only reasonable approach: Some people want inline system calls,

I also think it's much more likely to be of use to glibc than any syscall 
library provided by the kernel.  I don't think a syscall library provided 
by the kernel is likely to be of use for implementing glibc functions, but 
some kind of textual ABI specification might at least be of use for 
checking that syscall macro calls / syscalls.list entries are consistent 
with what the kernel thinks its ABI is.  (Hopefully there would be 
automated tests on the kernel side as well of some kind of consistency 
between the ABI specification and the kernel.)

strace is indeed a more obvious potential consumer of such a description 
of syscall ABIs.

I'd think a syscall library would more likely be something a few 
applications would use if they want to access a syscall that for whatever 
reason glibc doesn't have a wrapper for yet - not something useful for 
glibc itself to call or link against.

> and for application programmer's sanity, make sure that the kernel adds
> generic system calls in a single version, across all architectures.

That would be strongly desirable for glibc as well - a way of ensuring 
that the kernel rapidly fails CI tests and does not get released if new 
syscalls are only present on some architectures (including e.g. being 
missing from some compat syscall tables, or defined in asm/unistd.h but 
not in the actual syscall table, or vice versa - or some way of making 
sure such inconsistencies cannot occur by eliminating duplicate copies of 
the syscall list information in the sources).

When we have compatibility code in glibc for the absence of some syscall, 
we can only eliminate that code when the oldest kernel version supported 
by glibc is new enough to have the syscall on whichever glibc architecture 
was slowest to introduce the syscall in the kernel - and that can often be 
years after the first architectures gained support for that syscall in the 
kernel.

-- 
Joseph S. Myers
joseph@...esourcery.com