linux-kernel - Re: [PATCH v2 3/4] sparc: add system call table generation support

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:   Mon, 5 Nov 2018 11:48:43 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     David Miller <davem@...emloft.net>
Cc:     firoz.khan@...aro.org, sparclinux@...r.kernel.org,
        gregkh@...uxfoundation.org, pombredanne@...b.com,
        tglx@...utronix.de, kstewart@...uxfoundation.org,
        y2038@...ts.linaro.org, linux-kernel@...r.kernel.org,
        linux-arch@...r.kernel.org, deepa.kernel@...il.com,
        marcin.juszkiewicz@...aro.org
Subject: Re: [PATCH v2 3/4] sparc: add system call table generation support

On 11/1/18, David Miller <davem@...emloft.net> wrote:
> From: Firoz Khan <firoz.khan@...aro.org>
> Date: Thu,  1 Nov 2018 19:23:10 +0530
>
>> +141	common	getpeername		sys_getpeername			sys_nis_syscall
>  ...
>> +150	common	getsockname		sys_getsockname			sys_nis_syscall
>
> The sys_nis_syscall in these two entries is incorrect, see the patch
> below.
>
> One of my worst fears about this change has been realized, that
> instead of helping us find problems, it is so automated to the point
> that it fails to question issues like this.
>
> If sys_nis_syscall for the compat syscall shows up in a situation where the
> native 32-bit syscall does have an entry, that's a BUG and the script
> should
> point this out so that the bug can be fixed.

I see this as a multi-step process. Unfortunately, some architectures have
multiple issues in their system call tables, most importantly the ones that
include system call numbers on some architectures but have had them
removed when the implementation got removed.

The sparc sys_nis_syscall is another such issue: we don't have anything
like that on other architectures, so I think we should either move it to
kernel/sys_ni.c for everyone, or use the normal sys_ni_syscall().

Then there is inconsistency between the set of system calls per architecture,
e.g. some have both socketcall()/ipc() and the individual socket syscalls
from those multiplexors, some only have one of the two sets.
Here, I think we may want to move to the separate system calls on all
architectures and only keep the multiplexors for backwards compatibility.
A future glibc may then remove the support for socketcall() and ipc()
once they require linux-5.x or higher and always have the separate calls.

However, for all of those, I want the /format/ of the tables to be consistent
so we can create the tooling around it to find and fix the issues. The work
that Firoz is doing for now just makes sure that the /contents/ of the tables
don't change at all, which is hard enough to do (the current version gets
it all right afaict, but the previous versions missed some details).

      Arnd