linux-kernel - Re: [PATCH] x86/entry/x32: Check top 32 bits of syscall number on the fast path

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:	Sun, 17 Apr 2016 23:14:15 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Ben Hutchings <ben@...adent.org.uk>,
	Andy Lutomirski <luto@...nel.org>, X86 ML <x86@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86/entry/x32: Check top 32 bits of syscall number on the
 fast path

On Sun, Apr 17, 2016 at 11:01 PM, H. Peter Anvin <hpa@...or.com> wrote:
> On 04/17/16 22:48, Andy Lutomirski wrote:
>>
>> I think I prefer the "reject weird input" behavior over the "accept
>> and normalize weird input" if we can get away with it, and I'm fairly
>> confident that we can get away with "reject weird input" given that
>> distro kernels do exactly that already.
>>
>
> It's not "weird", it is the ABI as defined.  We have to do this for all
> the system call arguments, too; you just don't notice it because the
> compiler does it for us.  Some other architectures, e.g. s390, has the
> opposite convention where the caller is responsible for normalizing the
> result; in that case we have to do it *again* in the kernel, which is
> one of the major reasons for the SYSCALL_*() macros.

What ABI?

Even the man page says:

       #define _GNU_SOURCE         /* See feature_test_macros(7) */
       #include <unistd.h>
       #include <sys/syscall.h>   /* For SYS_xxx definitions */

       long syscall(long number, ...);

musl's 64-bit syscall wrappers use long  I can't confidently decipher
glibc's wrappers, because they're approximately as obfuscated as the
rest of glibc, but the code that I think matters looks like:

# define DO_CALL(syscall_name, args)            \
    DOARGS_##args                               \
    movl $SYS_ify (syscall_name), %eax;         \
    syscall;

which doesn't correspond to any particular C type but leaves the high
bits clear.

For all I know, some day we'll want to use the syscall instruction for
something that isn't a normal syscall, and having high bits available
for that could be handy.

Also, the behavior in which fail the syscall if any high bits are set
is faster -- it's one fewer instruction.  Admittedly, the CPU can
probably do that instruction for free, but still...

--Andy