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

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

Date:   Wed, 14 Nov 2018 18:30:27 +0000
From:   Joseph Myers <joseph@...esourcery.com>
To:     Arnd Bergmann <arnd@...db.de>
CC:     <carlos@...hat.com>, Szabolcs Nagy <Szabolcs.Nagy@....com>,
        Dave Martin <Dave.Martin@....com>, <dancol@...gle.com>,
        <nd@....com>, Florian Weimer <fweimer@...hat.com>,
        Michael Kerrisk <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>,
        GNU C Library <libc-alpha@...rceware.org>,
        Firoz Khan <firoz.khan@...aro.org>
Subject: Re: Official Linux system wrapper library?

On Wed, 14 Nov 2018, Arnd Bergmann wrote:

> Firoz Khan is in the process of doing part of this, by changing the
> in-kernel per-architecture unistd.h and syscall.S files into a
> architecture independent machine-readable format that is used to
> generate the existing files. The format will be similar to what
> we have on arm/s390/x86 in the syscall.tbl files already.

Will this also mean the following are unable to occur in future (both have 
occurred in the past):

* A syscall added to unistd.h for an architecture, but not added to the 
syscall table until sometime later?

* A syscall added to the native syscall table for some ABI (e.g. 32-bit 
x86 or arm) but not added to the corresponding compat syscall table (e.g. 
32-bit x86 binaries running on x86_64, 32-bit arm binaries running on 
arm64) until sometime later?

Avoiding both of those complications is beneficial to libc (as is a third 
thing, avoiding a syscall being added to different architectures in 
different versions).

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