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  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:   Mon, 1 Apr 2019 00:28:18 +0800
From:   Arnd Bergmann <arnd@...db.de>
To:     Michael Ellerman <mpe@...erman.id.au>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Richard Henderson <rth@...ddle.net>,
        Ivan Kokshaysky <ink@...assic.park.msu.ru>,
        Matt Turner <mattst88@...il.com>,
        Russell King <linux@...linux.org.uk>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        Tony Luck <tony.luck@...el.com>,
        Fenghua Yu <fenghua.yu@...el.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Michal Simek <monstr@...str.eu>,
        Ralf Baechle <ralf@...ux-mips.org>,
        Paul Burton <paul.burton@...s.com>,
        James Hogan <jhogan@...nel.org>,
        "James E . J . Bottomley" <James.Bottomley@...senpartnership.com>,
        Helge Deller <deller@....de>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Martin Schwidefsky <schwidefsky@...ibm.com>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        Rich Felker <dalias@...c.org>,
        "David S . Miller" <davem@...emloft.net>,
        Max Filippov <jcmvbkbc@...il.com>,
        Firoz Khan <firoz.khan@...aro.org>,
        alpha <linux-alpha@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        linux-ia64@...r.kernel.org,
        linux-m68k <linux-m68k@...ts.linux-m68k.org>,
        linux-mips@...r.kernel.org,
        Parisc List <linux-parisc@...r.kernel.org>,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
        linux-s390 <linux-s390@...r.kernel.org>,
        Linux-sh list <linux-sh@...r.kernel.org>,
        sparclinux <sparclinux@...r.kernel.org>
Subject: Re: [PATCH 2/2] arch: add pidfd and io_uring syscalls everywhere

On Sun, Mar 31, 2019 at 5:47 PM Michael Ellerman <mpe@...erman.id.au> wrote:
>
> Arnd Bergmann <arnd@...db.de> writes:
> > Add the io_uring and pidfd_send_signal system calls to all architectures.
> >
> > These system calls are designed to handle both native and compat tasks,
> > so all entries are the same across architectures, only arm-compat and
> > the generic tale still use an old format.
> >
> > Signed-off-by: Arnd Bergmann <arnd@...db.de>
> > ---
> >  arch/alpha/kernel/syscalls/syscall.tbl      | 4 ++++
> >  arch/arm/tools/syscall.tbl                  | 4 ++++
> >  arch/arm64/include/asm/unistd.h             | 2 +-
> >  arch/arm64/include/asm/unistd32.h           | 8 ++++++++
> >  arch/ia64/kernel/syscalls/syscall.tbl       | 4 ++++
> >  arch/m68k/kernel/syscalls/syscall.tbl       | 4 ++++
> >  arch/microblaze/kernel/syscalls/syscall.tbl | 4 ++++
> >  arch/mips/kernel/syscalls/syscall_n32.tbl   | 4 ++++
> >  arch/mips/kernel/syscalls/syscall_n64.tbl   | 4 ++++
> >  arch/mips/kernel/syscalls/syscall_o32.tbl   | 4 ++++
> >  arch/parisc/kernel/syscalls/syscall.tbl     | 4 ++++
> >  arch/powerpc/kernel/syscalls/syscall.tbl    | 4 ++++
>
> Have you done any testing?
>
> I'd rather not wire up syscalls that have never been tested at all on
> powerpc.

No, I have not. I did review the system calls carefully and added the first
patch to fix the bug on x86 compat mode before adding the same bug
on the other compat architectures though ;-)

Generally, my feeling is that adding system calls is not fundamentally
different from adding other ABIs, and we should really do it at
the same time across all architectures, rather than waiting for each
maintainer to get around to reviewing and testing the new calls
first. This is not a problem on powerpc, but a lot of other architectures
are less active, which is how we have always ended up with
different sets of system calls across architectures.

The problem here is that this makes it harder for the C library to
know when a system call is guaranteed to be available. glibc
still needs a feature test for newly added syscalls to see if they
are working (they might be backported to an older kernel, or
disabled), but whenever the minimum kernel version is increased,
it makes sense to drop those checks and assume non-optional
system calls will work if they were part of that minimum version.

In the future, I'd hope that any new system calls get added
right away on all architectures when they land (it was a bit
tricky this time, because I still did a bunch of reworks that
conflicted with the new calls). Bugs will happen of course, but
I think adding them sooner makes it more likely to catch those
bugs early on so we have a chance to fix them properly,
and need fewer arch specific workarounds (ideally none)
for system calls.

       Arnd

Powered by blists - more mailing lists