linux-kernel - Cleaning up numbering for new x86 syscalls?

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-next>] [day] [month] [year] [list]

Message-ID: <CALCETrVPcgKarpTOsdTfODkNA76W04WvW+tNWoOx6+Em0KS04A@mail.gmail.com>
Date:   Mon, 19 Nov 2018 16:22:49 -0800
From:   Andy Lutomirski <luto@...nel.org>
To:     X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>,
        Borislav Petkov <bp@...en8.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Tycho Andersen <tycho@...ho.ws>,
        Daniel Colascione <dancol@...gle.com>,
        Florian Weimer <fweimer@...hat.com>,
        "Carlos O'Donell" <carlos@...hat.com>,
        Rich Felker <dalias@...c.org>
Subject: Cleaning up numbering for new x86 syscalls?

Hi all-

We currently have some giant turds in the way that syscalls are
numbered.  We have the x86_32 table, which is totally sane other than
some legacy multiplexers.  Then we have the x86_64 table, which is,
um, demented:

 - The numbers don't match x86_32.  I have no idea why.

 - We use bit 30, which triggers in_x32_syscall().  It should have
been bit 31, bit I digress.

 - We have this weird set of extra x32 syscalls that start at 512.
Who wants to bet whether we have no bugs if someone does syscall with,
say, nr == 512 (i.e. not 512 | BIT(30)) or nr == (16 | BIT(30))?  The
latter would be non-compat ioctl with in_x32_syscall() set and hence
in_compat_syscall() set.

 - Bloody restart_syscall() has a different number on x86_64 and
x64_32, which is a big mess.

I propose we consider some subset of the following:

1. Introduce restart_syscall_2().  Make its number be 1024.  Maybe
someday we could start using it instead of restart_syscall().  The
only issue I can see is programs that allow restart_syscall() using
seccomp but don't allow the new variant.

2. Introduce an outright ban on new syscalls with nr < 1024.

3. Introduce an outright ban on the addition of new __x32_compat
syscalls.  If new compat hacks are needed, they can use
in_compat_syscall(), thank you very much.

4. Modify the wrappers of the __x32_compat entries so that they will
return -ENOSYS if in_x32_syscall() returns false.

5. Adjust the scripts so that we only have to wire up new syscalls
once.  They'll have a nr above 1024, and they'll have the same nr on
all x86 variants.

Thoughts?