Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1381280

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

Show all headers | View raw

On Sun, Apr 17, 2016 at 11:01 PM, H. Peter Anvin <hpa@zytor.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

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: System call number masking Ben Hutchings <ben@decadent.org.uk> - 2016-04-18 02:50 +0200
  [PATCH] x86/entry/x32: Check top 32 bits of syscall number on the  fast path Ben Hutchings <ben@decadent.org.uk> - 2016-04-18 02:50 +0200
    Re: [PATCH] x86/entry/x32: Check top 32 bits of syscall number on the  fast path "H. Peter Anvin" <hpa@zytor.com> - 2016-04-18 07:00 +0200
      Re: [PATCH] x86/entry/x32: Check top 32 bits of syscall number on the  fast path Andy Lutomirski <luto@amacapital.net> - 2016-04-18 07:20 +0200
        Re: [PATCH] x86/entry/x32: Check top 32 bits of syscall number on the  fast path "H. Peter Anvin" <hpa@zytor.com> - 2016-04-18 07:30 +0200
        Re: [PATCH] x86/entry/x32: Check top 32 bits of syscall number on the  fast path "H. Peter Anvin" <hpa@zytor.com> - 2016-04-18 07:30 +0200
          Re: [PATCH] x86/entry/x32: Check top 32 bits of syscall number on the  fast path Andy Lutomirski <luto@amacapital.net> - 2016-04-18 07:40 +0200
            Re: [PATCH] x86/entry/x32: Check top 32 bits of syscall number on the  fast path "H. Peter Anvin" <hpa@zytor.com> - 2016-04-18 07:50 +0200
              Re: [PATCH] x86/entry/x32: Check top 32 bits of syscall number on the  fast path Andy Lutomirski <luto@amacapital.net> - 2016-04-18 07:50 +0200
                Re: [PATCH] x86/entry/x32: Check top 32 bits of syscall number on the  fast path "H. Peter Anvin" <hpa@zytor.com> - 2016-04-18 08:10 +0200
                Re: [PATCH] x86/entry/x32: Check top 32 bits of syscall number on the  fast path "H. Peter Anvin" <hpa@zytor.com> - 2016-04-18 08:20 +0200
                Re: [PATCH] x86/entry/x32: Check top 32 bits of syscall number on the  fast path Andy Lutomirski <luto@amacapital.net> - 2016-04-18 08:20 +0200

csiph-web