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: <20181123231924.GA15954@altlinux.org>
Date:   Sat, 24 Nov 2018 02:19:24 +0300
From:   "Dmitry V. Levin" <ldv@...linux.org>
To:     Daniel Colascione <dancol@...gle.com>
Cc:     Michael Kerrisk-manpages <mtk.manpages@...il.com>,
        Joel Fernandes <joelaf@...gle.com>, Willy Tarreau <w@....eu>,
        Vlastimil Babka <vbabka@...e.cz>,
        GNU C Library <libc-alpha@...rceware.org>,
        linux-api@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Official Linux system wrapper library?

On Fri, Nov 23, 2018 at 12:15:39PM -0800, Daniel Colascione wrote:
> On Fri, Nov 23, 2018 at 5:34 AM Florian Weimer wrote:
> > > On Mon, Nov 12, 2018 at 12:11 AM, Florian Weimer wrote:
> > >>
> > >>> 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.
> > >>
> > >> It's not that simple, I think.  What about bdflush?  socketcall?
> > >> getxpid?  osf_gettimeofday?  set_robust_list?
> > >
> > > What about them? Mentioning that these system calls exist is not in
> > > itself an argument.
> >
> > But socketcall does not exist on all architectures.  Neither does
> > getpid, it's called getxpid on some architectures.
> 
> So what? On systems on which a given system call does not exist,
> attempts to link against that system call should fail, or attempts to
> make that system call should fail at runtime with ENOSYS. That's
> completely expected and unsurprising behavior, not some unavoidable
> source of catastrophic confusion.

I'm sorry but you've just said that getpid() must either be unavailable or
fail on those architectures that provide no syscall with exactly the same
semantics as getpid syscall.  Nobody is going to use a libc that doesn't
provide getpid() in a reliable way.

If you really need a 1-1 correspondence between syscalls and C wrappers,
there is syscall(3) with all associated portability issues.

If you need something else, please be more specific, i.e. be ready to give
a detailed answer about every syscall ever supported by the kernel,
on every supported architecture.

My first trivial question is, do you need C wrappers for
__NR_epoll_create, __NR_eventfd, __NR_inotify_init,
and __NR_signalfd syscalls?


-- 
ldv

Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)