wireguard-linux/arch/x86/entry/syscall_64.c, branch jd/unified-crypt-queue

x86/entry: Drop asmlinkage from syscalls

2020-03-21T15:03:25Z

asmlinkage is no longer required since the syscall ABI is now fully under x86 architecture control. This makes the 32-bit native syscalls a bit more effecient by passing in regs via EAX instead of on the stack. Signed-off-by: Brian Gerst Signed-off-by: Thomas Gleixner Reviewed-by: Dominik Brodowski Reviewed-by: Andy Lutomirski Link: https://lkml.kernel.org/r/20200313195144.164260-18-brgerst@gmail.com

x86/entry: Remove ABI prefixes from functions in syscall tables

2020-03-21T15:03:23Z

Move the ABI prefixes to the __SYSCALL_[abi]() macros. This allows removal of the need to strip the prefix for UML. Signed-off-by: Brian Gerst Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/20200313195144.164260-13-brgerst@gmail.com

x86/entry/64: Add __SYSCALL_COMMON()

2020-03-21T15:03:22Z

Add a __SYSCALL_COMMON() macro to the syscall table, which simplifies syscalltbl.sh. Signed-off-by: Brian Gerst Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/20200313195144.164260-12-brgerst@gmail.com

x86/entry: Remove syscall qualifier support

2020-03-21T15:03:22Z

Syscall qualifier support is no longer needed. Signed-off-by: Brian Gerst Signed-off-by: Thomas Gleixner Reviewed-by: Dominik Brodowski Link: https://lkml.kernel.org/r/20200313195144.164260-11-brgerst@gmail.com

x86/entry: Move max syscall number calculation to syscallhdr.sh

2020-03-21T15:03:21Z

Instead of using an array in asm-offsets to calculate the max syscall number, calculate it when writing out the syscall headers. Signed-off-by: Brian Gerst Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/20200313195144.164260-9-brgerst@gmail.com

x86/entry/64: Split X32 syscall table into its own file

2020-03-21T15:03:21Z

Since X32 has its own syscall table now, move it to a separate file. Signed-off-by: Brian Gerst Signed-off-by: Thomas Gleixner Reviewed-by: Dominik Brodowski Link: https://lkml.kernel.org/r/20200313195144.164260-8-brgerst@gmail.com

x86/entry/64: Move sys_ni_syscall stub to common.c

2020-03-21T15:03:20Z

so it can be available to multiple syscall tables. Also directly return -ENOSYS instead of bouncing to the generic sys_ni_syscall(). Signed-off-by: Brian Gerst Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/20200313195144.164260-7-brgerst@gmail.com

syscalls/x86: Use the correct function type for sys_ni_syscall

2019-10-11T10:49:18Z

Use the correct function type for sys_ni_syscall() in system call tables to fix indirect call mismatches with Control-Flow Integrity (CFI) checking. Signed-off-by: Sami Tolvanen Acked-by: Andy Lutomirski Cc: Borislav Petkov Cc: H . Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: https://lkml.kernel.org/r/20191008224049.115427-5-samitolvanen@google.com Signed-off-by: Ingo Molnar

x86/syscalls: Split the x32 syscalls into their own table

2019-07-22T08:31:23Z

For unfortunate historical reasons, the x32 syscalls and the x86_64 syscalls are not all numbered the same. As an example, ioctl() is nr 16 on x86_64 but 514 on x32. This has potentially nasty consequences, since it means that there are two valid RAX values to do ioctl(2) and two invalid RAX values. The valid values are 16 (i.e. ioctl(2) using the x86_64 ABI) and (514 | 0x40000000) (i.e. ioctl(2) using the x32 ABI). The invalid values are 514 and (16 | 0x40000000). 514 will enter the "COMPAT_SYSCALL_DEFINE3(ioctl, ...)" entry point with in_compat_syscall() and in_x32_syscall() returning false, whereas (16 | 0x40000000) will enter the native entry point with in_compat_syscall() and in_x32_syscall() returning true. Both are bogus, and both will exercise code paths in the kernel and in any running seccomp filters that really ought to be unreachable. Splitting out the x32 syscalls into their own tables, allows both bogus invocations to return -ENOSYS. I've checked glibc, musl, and Bionic, and all of them appear to call syscalls with their correct numbers, so this change should have no effect on them. There is an added benefit going forward: new syscalls that need special handling on x32 can share the same number on x32 and x86_64. This means that the special syscall range 512-547 can be treated as a legacy wart instead of something that may need to be extended in the future. Also add a selftest to verify the new behavior. Signed-off-by: Andy Lutomirski Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/208024256b764312598f014ebfb0a42472c19354.1562185330.git.luto@kernel.org

syscalls/x86: Unconditionally enable 'struct pt_regs' based syscalls on x86_64

2018-04-05T14:59:38Z

Removing CONFIG_SYSCALL_PTREGS from arch/x86/Kconfig and simply selecting ARCH_HAS_SYSCALL_WRAPPER unconditionally on x86-64 allows us to simplify several codepaths. Signed-off-by: Dominik Brodowski Acked-by: Linus Torvalds Cc: Al Viro Cc: Andrew Morton Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/20180405095307.3730-7-linux@dominikbrodowski.net Signed-off-by: Ingo Molnar