Re: [PATCH] x86 - 32-bit ptrace emulation mishandles 6th arg

2007-11-09 Thread Andi Kleen
Roland McGrath <[EMAIL PROTECTED]> writes:

> Sure has my ACK.  
> I never really understood why my old patch was not taken 2.5 years ago.

If I remember correctly the old patch back then broke some programs,
so it was reverted.

It's certainly ugly that it leaks r9 internals to ptrace.
Also it generates redundant code with CLEAR_RREGS.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] x86 - 32-bit ptrace emulation mishandles 6th arg

2007-11-09 Thread Andi Kleen
Roland McGrath [EMAIL PROTECTED] writes:

 Sure has my ACK.  
 I never really understood why my old patch was not taken 2.5 years ago.

If I remember correctly the old patch back then broke some programs,
so it was reverted.

It's certainly ugly that it leaks r9 internals to ptrace.
Also it generates redundant code with CLEAR_RREGS.

-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] x86 - 32-bit ptrace emulation mishandles 6th arg

2007-11-07 Thread Chuck Ebbert
On 11/07/2007 04:12 PM, Roland McGrath wrote:
> Sure has my ACK.  
> I never really understood why my old patch was not taken 2.5 years ago.
> 
> 

I forget the details, but I had to make some kind of trivial change
to make it work in some corner cases.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] x86 - 32-bit ptrace emulation mishandles 6th arg

2007-11-07 Thread Roland McGrath
FYI, http://sourceware.org/systemtap/wiki/utrace/tests has details on the
ptrace-tests suite we're collecting.  A test I added there is how I noticed
the PTRACE_GET_THREAD_AREA regression.  A regression test for the ebp bug
should be easy to add too.


Thanks,
Roland
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] x86 - 32-bit ptrace emulation mishandles 6th arg

2007-11-07 Thread Jeff Dike
On Wed, Nov 07, 2007 at 01:12:22PM -0800, Roland McGrath wrote:
> Sure has my ACK.  
> I never really understood why my old patch was not taken 2.5 years ago.

Nor I.  It's needed.

As is your PTRACE_SET_THREAD_INFO patch from yesterday - with these
two fixes, I can boot a 32-bit UML on a 64-bit host.

Jeff

-- 
Work email - jdike at linux dot intel dot com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] x86 - 32-bit ptrace emulation mishandles 6th arg

2007-11-07 Thread Roland McGrath
Sure has my ACK.  
I never really understood why my old patch was not taken 2.5 years ago.


Thanks,
Roland
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] x86 - 32-bit ptrace emulation mishandles 6th arg

2007-11-07 Thread Jeff Dike
From: Chuck Ebbert <[EMAIL PROTECTED]>

[ jdike - Pushing Chuck's patch - see
http://lkml.org/lkml/2005/9/16/261 for some history and a test
program.  UML is also broken without this patch - its processes get
SIGBUS from the corrupt 6th argument to mmap being interpretted as a
file offset ]

When the 32-bit vDSO is used to make a system call, the %ebp register for
the 6th syscall arg has to be loaded from the user stack (where it's pushed
by the vDSO user code).  The native i386 kernel always does this before
stopping for syscall tracing, so %ebp can be seen and modified via ptrace
to access the 6th syscall argument.  The x86-64 kernel fails to do this,
presenting the stack address to ptrace instead.  This makes the %rbp value
seen by 64-bit ptrace of a 32-bit process, and the %ebp value seen by a
32-bit caller of ptrace, both differ from the native i386 behavior.

This patch fixes the problem by putting the word loaded from the user stack
into %rbp before calling syscall_trace_enter, and reloading the 6th syscall
argument from there afterwards (so ptrace can change it).  This makes the
behavior match that of i386 kernels.

Signed-off-by: Chuck Ebbert <[EMAIL PROTECTED]>
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
Original-Patch-By: Roland McGrath <[EMAIL PROTECTED]>
---
 arch/x86_64/ia32/ia32entry.S |   19 ++-
 1 file changed, 6 insertions(+), 13 deletions(-)

diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
index 18b2318..df588f0 100644
--- a/arch/x86/ia32/ia32entry.S
+++ b/arch/x86/ia32/ia32entry.S
@@ -159,20 +159,16 @@ sysenter_do_call:
 
 sysenter_tracesys:
CFI_RESTORE_STATE
+   xchgl   %r9d,%ebp
SAVE_REST
CLEAR_RREGS
+   movq%r9,R9(%rsp)
movq$-ENOSYS,RAX(%rsp)  /* really needed? */
movq%rsp,%rdi/* _regs -> arg1 */
callsyscall_trace_enter
LOAD_ARGS32 ARGOFFSET  /* reload args from stack in case ptrace changed 
it */
RESTORE_REST
-   movl%ebp, %ebp
-   /* no need to do an access_ok check here because rbp has been
-  32bit zero extended */ 
-1: movl(%rbp),%r9d
-   .section __ex_table,"a"
-   .quad 1b,ia32_badarg
-   .previous
+   xchgl   %ebp,%r9d
jmp sysenter_do_call
CFI_ENDPROC
 ENDPROC(ia32_sysenter_target)
@@ -262,20 +258,17 @@ cstar_do_call:

 cstar_tracesys:
CFI_RESTORE_STATE
+   xchgl %r9d,%ebp
SAVE_REST
CLEAR_RREGS
+   movq %r9,R9(%rsp)
movq $-ENOSYS,RAX(%rsp) /* really needed? */
movq %rsp,%rdi/* _regs -> arg1 */
call syscall_trace_enter
LOAD_ARGS32 ARGOFFSET  /* reload args from stack in case ptrace changed 
it */
RESTORE_REST
+   xchgl %ebp,%r9d
movl RSP-ARGOFFSET(%rsp), %r8d
-   /* no need to do an access_ok check here because r8 has been
-  32bit zero extended */ 
-1: movl(%r8),%r9d
-   .section __ex_table,"a"
-   .quad 1b,ia32_badarg
-   .previous
jmp cstar_do_call
 END(ia32_cstar_target)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] x86 - 32-bit ptrace emulation mishandles 6th arg

2007-11-07 Thread Jeff Dike
From: Chuck Ebbert [EMAIL PROTECTED]

[ jdike - Pushing Chuck's patch - see
http://lkml.org/lkml/2005/9/16/261 for some history and a test
program.  UML is also broken without this patch - its processes get
SIGBUS from the corrupt 6th argument to mmap being interpretted as a
file offset ]

When the 32-bit vDSO is used to make a system call, the %ebp register for
the 6th syscall arg has to be loaded from the user stack (where it's pushed
by the vDSO user code).  The native i386 kernel always does this before
stopping for syscall tracing, so %ebp can be seen and modified via ptrace
to access the 6th syscall argument.  The x86-64 kernel fails to do this,
presenting the stack address to ptrace instead.  This makes the %rbp value
seen by 64-bit ptrace of a 32-bit process, and the %ebp value seen by a
32-bit caller of ptrace, both differ from the native i386 behavior.

This patch fixes the problem by putting the word loaded from the user stack
into %rbp before calling syscall_trace_enter, and reloading the 6th syscall
argument from there afterwards (so ptrace can change it).  This makes the
behavior match that of i386 kernels.

Signed-off-by: Chuck Ebbert [EMAIL PROTECTED]
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
Original-Patch-By: Roland McGrath [EMAIL PROTECTED]
---
 arch/x86_64/ia32/ia32entry.S |   19 ++-
 1 file changed, 6 insertions(+), 13 deletions(-)

diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
index 18b2318..df588f0 100644
--- a/arch/x86/ia32/ia32entry.S
+++ b/arch/x86/ia32/ia32entry.S
@@ -159,20 +159,16 @@ sysenter_do_call:
 
 sysenter_tracesys:
CFI_RESTORE_STATE
+   xchgl   %r9d,%ebp
SAVE_REST
CLEAR_RREGS
+   movq%r9,R9(%rsp)
movq$-ENOSYS,RAX(%rsp)  /* really needed? */
movq%rsp,%rdi/* pt_regs - arg1 */
callsyscall_trace_enter
LOAD_ARGS32 ARGOFFSET  /* reload args from stack in case ptrace changed 
it */
RESTORE_REST
-   movl%ebp, %ebp
-   /* no need to do an access_ok check here because rbp has been
-  32bit zero extended */ 
-1: movl(%rbp),%r9d
-   .section __ex_table,a
-   .quad 1b,ia32_badarg
-   .previous
+   xchgl   %ebp,%r9d
jmp sysenter_do_call
CFI_ENDPROC
 ENDPROC(ia32_sysenter_target)
@@ -262,20 +258,17 @@ cstar_do_call:

 cstar_tracesys:
CFI_RESTORE_STATE
+   xchgl %r9d,%ebp
SAVE_REST
CLEAR_RREGS
+   movq %r9,R9(%rsp)
movq $-ENOSYS,RAX(%rsp) /* really needed? */
movq %rsp,%rdi/* pt_regs - arg1 */
call syscall_trace_enter
LOAD_ARGS32 ARGOFFSET  /* reload args from stack in case ptrace changed 
it */
RESTORE_REST
+   xchgl %ebp,%r9d
movl RSP-ARGOFFSET(%rsp), %r8d
-   /* no need to do an access_ok check here because r8 has been
-  32bit zero extended */ 
-1: movl(%r8),%r9d
-   .section __ex_table,a
-   .quad 1b,ia32_badarg
-   .previous
jmp cstar_do_call
 END(ia32_cstar_target)

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] x86 - 32-bit ptrace emulation mishandles 6th arg

2007-11-07 Thread Roland McGrath
Sure has my ACK.  
I never really understood why my old patch was not taken 2.5 years ago.


Thanks,
Roland
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] x86 - 32-bit ptrace emulation mishandles 6th arg

2007-11-07 Thread Jeff Dike
On Wed, Nov 07, 2007 at 01:12:22PM -0800, Roland McGrath wrote:
 Sure has my ACK.  
 I never really understood why my old patch was not taken 2.5 years ago.

Nor I.  It's needed.

As is your PTRACE_SET_THREAD_INFO patch from yesterday - with these
two fixes, I can boot a 32-bit UML on a 64-bit host.

Jeff

-- 
Work email - jdike at linux dot intel dot com
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] x86 - 32-bit ptrace emulation mishandles 6th arg

2007-11-07 Thread Roland McGrath
FYI, http://sourceware.org/systemtap/wiki/utrace/tests has details on the
ptrace-tests suite we're collecting.  A test I added there is how I noticed
the PTRACE_GET_THREAD_AREA regression.  A regression test for the ebp bug
should be easy to add too.


Thanks,
Roland
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] x86 - 32-bit ptrace emulation mishandles 6th arg

2007-11-07 Thread Chuck Ebbert
On 11/07/2007 04:12 PM, Roland McGrath wrote:
 Sure has my ACK.  
 I never really understood why my old patch was not taken 2.5 years ago.
 
 

I forget the details, but I had to make some kind of trivial change
to make it work in some corner cases.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/