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

Groups > linux.kernel > #1436513 > unrolled thread

Re: [PATCH] Syscall arguments are unsigned long (full registers)

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] Syscall arguments are unsigned long (full registers) "H. Peter Anvin" <hpa@zytor.com> - 2016-07-04 20:30 +0200
    Re: [PATCH] Syscall arguments are unsigned long (full registers) "Tautschnig, Michael" <tautschn@amazon.co.uk> - 2016-07-04 22:20 +0200
      Re: [PATCH] Syscall arguments are unsigned long (full registers) "H. Peter Anvin" <hpa@zytor.com> - 2016-07-04 22:30 +0200

#1436513 — Re: [PATCH] Syscall arguments are unsigned long (full registers)

On July 4, 2016 6:52:58 AM PDT, "Tautschnig, Michael" <tautschn@amazon.co.uk> wrote:
>All syscall arguments are passed in as types of the same byte size as
>unsigned long (width of full registers). Using a smaller type without a
>cast may result in losing bits of information. In all other instances
>apart from the ones fixed by the patch the code explicitly introduces
>type casts (using, e.g., SYSCALL_DEFINE1).
>
>While goto-cc reported these problems at build time, it is noteworthy
>that the calling conventions specified in the System V AMD64 ABI do
>ensure that parameters 1-6 are passed via registers, thus there is no
>implied risk of misaligned stack access.
>
>Signed-off-by: Michael Tautschnig <tautschn@amazon.com>
>Cc: Thomas Gleixner <tglx@linutronix.de>
>Cc: Ingo Molnar <mingo@redhat.com>
>Cc: H. Peter Anvin <hpa@zytor.com>
>Cc: Jaswinder Singh <jaswinder@infradead.org>
>Cc: Andi Kleen <ak@linux.intel.com>
>---
> arch/x86/include/asm/syscalls.h | 4 ++--
> arch/x86/kernel/ioport.c        | 2 +-
> arch/x86/kernel/process_64.c    | 2 +-
> include/linux/syscalls.h        | 2 +-
> 4 files changed, 5 insertions(+), 5 deletions(-)
>
>diff --git a/arch/x86/include/asm/syscalls.h
>b/arch/x86/include/asm/syscalls.h
>index 91dfcaf..7dc3161 100644
>--- a/arch/x86/include/asm/syscalls.h
>+++ b/arch/x86/include/asm/syscalls.h
>@@ -17,7 +17,7 @@
>
> /* Common in X86_32 and X86_64 */
> /* kernel/ioport.c */
>-asmlinkage long sys_ioperm(unsigned long, unsigned long, int);
>+asmlinkage long sys_ioperm(unsigned long, unsigned long, unsigned
>long);
> asmlinkage long sys_iopl(unsigned int);
>
> /* kernel/ldt.c */
>@@ -45,7 +45,7 @@ asmlinkage long sys_vm86(unsigned long, unsigned
>long);
>
> /* X86_64 only */
> /* kernel/process_64.c */
>-asmlinkage long sys_arch_prctl(int, unsigned long);
>+asmlinkage long sys_arch_prctl(unsigned long, unsigned long);
>
> /* kernel/sys_x86_64.c */
> asmlinkage long sys_mmap(unsigned long, unsigned long, unsigned long,
>diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c
>index 589b319..ae8ce91 100644
>--- a/arch/x86/kernel/ioport.c
>+++ b/arch/x86/kernel/ioport.c
>@@ -20,7 +20,7 @@
> /*
>  * this changes the io permissions bitmap in the current task.
>  */
>-asmlinkage long sys_ioperm(unsigned long from, unsigned long num, int
>turn_on)
>+asmlinkage long sys_ioperm(unsigned long from, unsigned long num,
>unsigned long turn_on)
> {
> 	struct thread_struct *t = &current->thread;
> 	struct tss_struct *tss;
>diff --git a/arch/x86/kernel/process_64.c
>b/arch/x86/kernel/process_64.c
>index 6e789ca..a4ec3e3 100644
>--- a/arch/x86/kernel/process_64.c
>+++ b/arch/x86/kernel/process_64.c
>@@ -585,7 +585,7 @@ long do_arch_prctl(struct task_struct *task, int
>code, unsigned long addr)
> 	return ret;
> }
>
>-long sys_arch_prctl(int code, unsigned long addr)
>+long sys_arch_prctl(unsigned long code, unsigned long addr)
> {
> 	return do_arch_prctl(current, code, addr);
> }
>diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
>index d022390..ca3c03d 100644
>--- a/include/linux/syscalls.h
>+++ b/include/linux/syscalls.h
>@@ -492,7 +492,7 @@ asmlinkage long sys_pipe2(int __user *fildes, int
>flags);
> asmlinkage long sys_dup(unsigned int fildes);
> asmlinkage long sys_dup2(unsigned int oldfd, unsigned int newfd);
>asmlinkage long sys_dup3(unsigned int oldfd, unsigned int newfd, int
>flags);
>-asmlinkage long sys_ioperm(unsigned long from, unsigned long num, int
>on);
>+asmlinkage long sys_ioperm(unsigned long from, unsigned long num,
>unsigned long on);
> asmlinkage long sys_ioctl(unsigned int fd, unsigned int cmd,
> 				unsigned long arg);
> asmlinkage long sys_flock(unsigned int fd, unsigned int cmd);
>--
>2.7.3.AMZN

Wrong.  Syscall arguments aren't necessarily full registers, and on x86 truncation is already done by the callee, so we don't need any special handing.  Some other architectures have other constraints.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

[toc] | [next] | [standalone]

#1436583

> On 4 Jul 2016, at 20:27, H. Peter Anvin <hpa@zytor.com> wrote:
> 
> On July 4, 2016 6:52:58 AM PDT, "Tautschnig, Michael" <tautschn@amazon.co.uk> wrote:
>> All syscall arguments are passed in as types of the same byte size as
>> unsigned long (width of full registers). Using a smaller type without a
>> cast may result in losing bits of information. In all other instances
>> apart from the ones fixed by the patch the code explicitly introduces
>> type casts (using, e.g., SYSCALL_DEFINE1).
>> 
>> While goto-cc reported these problems at build time, it is noteworthy
>> that the calling conventions specified in the System V AMD64 ABI do
>> ensure that parameters 1-6 are passed via registers, thus there is no
>> implied risk of misaligned stack access.
>> 
>> 
[...]
> 
> Wrong.  Syscall arguments aren't necessarily full registers, and on x86 truncation is already done by the callee, so we don't need any special handing.  Some other architectures have other constraints. 

Ok - I'm assuming I have thus misunderstood eb974c62565072e10c1422eb3205f5b611dd99a1 ? Supposedly all those SYSCALL_DEFINEx are required for other architectures only?

Best,
Michael

[toc] | [prev] | [next] | [standalone]

#1436585

On July 4, 2016 1:13:21 PM PDT, "Tautschnig, Michael" <tautschn@amazon.co.uk> wrote:
>
>> On 4 Jul 2016, at 20:27, H. Peter Anvin <hpa@zytor.com> wrote:
>> 
>> On July 4, 2016 6:52:58 AM PDT, "Tautschnig, Michael"
><tautschn@amazon.co.uk> wrote:
>>> All syscall arguments are passed in as types of the same byte size
>as
>>> unsigned long (width of full registers). Using a smaller type
>without a
>>> cast may result in losing bits of information. In all other
>instances
>>> apart from the ones fixed by the patch the code explicitly
>introduces
>>> type casts (using, e.g., SYSCALL_DEFINE1).
>>> 
>>> While goto-cc reported these problems at build time, it is
>noteworthy
>>> that the calling conventions specified in the System V AMD64 ABI do
>>> ensure that parameters 1-6 are passed via registers, thus there is
>no
>>> implied risk of misaligned stack access.
>>> 
>>> 
>[...]
>> 
>> Wrong.  Syscall arguments aren't necessarily full registers, and on
>x86 truncation is already done by the callee, so we don't need any
>special handing.  Some other architectures have other constraints. 
>
>Ok - I'm assuming I have thus misunderstood
>eb974c62565072e10c1422eb3205f5b611dd99a1 ? Supposedly all those
>SYSCALL_DEFINEx are required for other architectures only?
>
>Best,
>Michael

That, and tracing.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web