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]

Date:   Sun, 11 Nov 2018 06:22:59 -0800
From:   Daniel Colascione <dancol@...gle.com>
To:     Florian Weimer <fweimer@...hat.com>
Cc:     "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>,
        linux-kernel <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>,
        "libc-alpha@...rceware.org" <libc-alpha@...rceware.org>
Subject: Re: Official Linux system wrapper library?

On Sun, Nov 11, 2018 at 3:09 AM, Florian Weimer <fweimer@...hat.com> wrote:
> We had a patch for the membarrier system call, but the kernel developers
> could not tell us what the system call does in therms of the C/C++
> memory model
[snip]
> A lot of the new system calls lack clear specifications or are just
> somewhat misdesigned.  For example, pkey_alloc
[snip]
> getrandom still causes boot delays
[snip]
> For copy_file_range, we still have debates whether the system call (and
> the glibc emulation) should preserve holes or not,
[snip]

These objections illustrate my point. glibc development is not the
proper forum for raising post-hoc objections to system call design.
Withholding wrappers will not un-ship these system calls. Applications
are already using them, via syscall(2). Developers and users would be
better served by providing access to the system as it is, with
appropriate documentation caveats, than by holding out for some
alternate and more ideal set of system calls that may or may not
appear in the future. This resistance to exposing the capabilities of
the system as they are, even in flawed and warty form, is what I meant
by "misplaced idealism" in my previous message. If the kernel provides
a system call, libc should provide a C wrapper for it, even if in the
opinion of the libc maintainers, that system call is flawed.

I agree with the proposals mentioned above to split system interface
responsibility, having glibc handle higher-level concerns like stdio
while punting system call wrappers and other low-level facilities to a
kernel-provided userspace library that can move faster and more
explicitly conform to the Linux kernel's userspace ABI.