Messages in this thread | | | From | Andy Lutomirski <> | Date | Sun, 17 Apr 2016 23:14:15 -0700 | 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@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
| |