linux.git/arch/x86/include/asm/syscall.h, branch v6.2

arch: remove unused function syscall_set_arguments()

2021-09-14T14:06:20+00:00

This function appears to have been unused since it was first introduced in
commit 828c365cc8b8 ("tracehook: asm/syscall.h").

Signed-off-by: Peter Collingbourne 
Link: https://linux-review.googlesource.com/id/I8ce04f002903a37c0b6c1d16e9b2a3afa716c097
Signed-off-by: Arnd Bergmann

x86/entry: Use int everywhere for system call numbers

2021-05-25T08:07:00+00:00

System call numbers are defined as int, so use int everywhere for system
call numbers. This is strictly a cleanup; it should not change anything
user visible; all ABI changes have been done in the preceeding patches.

[ tglx: Replaced the unsigned long cast ]

Signed-off-by: H. Peter Anvin (Intel) 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/r/20210518191303.4135296-7-hpa@zytor.com

x86/syscall: Unconditionally prototype {ia32,x32}_sys_call_table[]

2021-05-12T08:49:15+00:00

Even if these APIs are disabled, and the arrays therefore do not
exist, having the prototypes allows us to use IS_ENABLED() rather than
using #ifdefs.

If something ends up trying to actually *use* these arrays a linker
error will ensue.

Signed-off-by: H. Peter Anvin (Intel) 
Signed-off-by: Ingo Molnar 
Link: https://lore.kernel.org/r/20210510185316.3307264-4-hpa@zytor.com

x86/entry: Reverse arguments to do_syscall_64()

2021-05-12T08:49:14+00:00

Reverse the order of arguments to do_syscall_64() so that the first
argument is the pt_regs pointer. This is not only consistent with
*all* other entry points from assembly, but it actually makes the
compiled code slightly better.

Signed-off-by: H. Peter Anvin (Intel) 
Signed-off-by: Ingo Molnar 
Link: https://lore.kernel.org/r/20210510185316.3307264-3-hpa@zytor.com

Merge branch 'x86-cleanups-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2020-03-31T18:04:05+00:00

Pull x86 cleanups from Ingo Molnar:
 "This topic tree contains more commits than usual:

   - most of it are uaccess cleanups/reorganization by Al

   - there's a bunch of prototype declaration (--Wmissing-prototypes)
     cleanups

   - misc other cleanups all around the map"

* 'x86-cleanups-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (36 commits)
  x86/mm/set_memory: Fix -Wmissing-prototypes warnings
  x86/efi: Add a prototype for efi_arch_mem_reserve()
  x86/mm: Mark setup_emu2phys_nid() static
  x86/jump_label: Move 'inline' keyword placement
  x86/platform/uv: Add a missing prototype for uv_bau_message_interrupt()
  kill uaccess_try()
  x86: unsafe_put-style macro for sigmask
  x86: x32_setup_rt_frame(): consolidate uaccess areas
  x86: __setup_rt_frame(): consolidate uaccess areas
  x86: __setup_frame(): consolidate uaccess areas
  x86: setup_sigcontext(): list user_access_{begin,end}() into callers
  x86: get rid of put_user_try in __setup_rt_frame() (both 32bit and 64bit)
  x86: ia32_setup_rt_frame(): consolidate uaccess areas
  x86: ia32_setup_frame(): consolidate uaccess areas
  x86: ia32_setup_sigcontext(): lift user_access_{begin,end}() into the callers
  x86/alternatives: Mark text_poke_loc_init() static
  x86/cpu: Fix a -Wmissing-prototypes warning for init_ia32_feat_ctl()
  x86/mm: Drop pud_mknotpresent()
  x86: Replace setup_irq() by request_irq()
  x86/configs: Slightly reduce defconfigs
  ...

x86/entry: Drop asmlinkage from syscalls

2020-03-21T15:03:25+00:00

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/32: Enable pt_regs based syscalls

2020-03-21T15:03:24+00:00

Enable pt_regs based syscalls for 32-bit.  This makes the 32-bit native
kernel consistent with the 64-bit kernel, and improves the syscall
interface by not needing to push all 6 potential arguments onto the stack.

Signed-off-by: Brian Gerst 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Dominik Brodowski 
Link: https://lkml.kernel.org/r/20200313195144.164260-17-brgerst@gmail.com

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

2020-03-21T15:03:21+00:00

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/syscalls: Add prototypes for C syscall callbacks

2020-02-17T17:22:25+00:00

.. in order to fix a couple of -Wmissing-prototypes warnings.

No functional change.

 [ bp: Massage commit message and drop newlines. ]

Signed-off-by: Benjamin Thiel 
Signed-off-by: Borislav Petkov 
Link: https://lkml.kernel.org/r/20200123152754.20149-1-b.thiel@posteo.de

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

2019-07-22T08:31:23+00:00

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