[uml-devel] Bad handling of invalif systemcalls

[uml-devel] Bad handling of invalif systemcalls

[Bodo Stroesser]

[-- Attachment #1: Type: text/plain, Size: 1505 bytes --]

If a process in UML does a systemcall with the systemcall number
being less than 0, in TT-mode and SKAS-mode using SYSEMU, the
process is killed by an SIGTRAP instead of simply returning -ENOSYS.
In SKAS-mode without SYSEMU, UML even crashes, no matter if SYSEMU
is unsupported by the host or switched off in UML:

     Kernel panic - not syncing: handle_trap - failed to wait at end of syscall, errno = 4, status = 2943

The reason is, that UML can't distinguish between a debugger trap
and an systemcall interception. Currently, it checks the systemcall
number. If it is less than 0, it assumes the event to be a debugger
trap. It would be better to assume a debugger trap only, if the
syscall number is -1 (which it is guaranteed to be in case of a
debugger event), but even then UML wouldn't be safe. Syscalls with
syscall number -1 still would be a problem!

AFAICS, the only solution for this is using the PTRACE_O_TRACESYSGOOD
option. This option seems to be specific for linux, but the problem
maybe is specific for linux, too.

So, here attached are three patches. The first adds a check for
availability and function of
     ptrace(PTRACE_SETOPTIONS,,,PTRACE_O_TRACESYSGOOD) to the normal
ptrace checks.

The second implements the usage of the option in SKAS-mode.

The third does the same for TT-mode.

For the third patch I'm quite anxious, that there could go something
wrong when using the debugger. I don't understand much about this.
Maybe someone else could look into this?

Regards
Bodo

[-- Attachment #2: patch-TRACESYSGOOD-1 --]
[-- Type: text/plain, Size: 1618 bytes --]

From: Bodo Stroesser <bstroesser@fujitsu-siemens.com>

Patch 1/3 to implement usage of PTRACE_O_TRACESYSGOOD
This is necessary, to fix UMLs bad behavior when a process does
a systemcall with syscall-number less than 0.

Insert a check for availability and function of
  ptrace(PTRACE_SETOPTIONS,,,PTRACE_O_TRACESYSGOOD)
into the normal ptrace checks at startup.

Signed-off-by: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
---

--- a/arch/um/kernel/process.c	2004-10-21 11:53:30.637195537 +0200
+++ b/arch/um/kernel/process.c	2004-10-21 11:59:49.758543527 +0200
@@ -13,6 +13,7 @@
 #include <setjmp.h>
 #include <sys/time.h>
 #include <sys/ptrace.h>
+#include <linux/ptrace.h>
 #include <sys/wait.h>
 #include <sys/mman.h>
 #include <asm/ptrace.h>
@@ -255,6 +256,9 @@
 	printk("Checking that ptrace can change system call numbers...");
 	pid = start_ptraced_child(&stack);
 
+	if(ptrace(PTRACE_SETOPTIONS, pid, 0, (void *)PTRACE_O_TRACESYSGOOD) < 0)
+		panic("check_ptrace: PTRACE_SETOPTIONS failed, errno = %d", errno);
+
 	while(1){
 		if(ptrace(PTRACE_SYSCALL, pid, 0, 0) < 0)
 			panic("check_ptrace : ptrace failed, errno = %d", 
@@ -262,8 +266,8 @@
 		CATCH_EINTR(n = waitpid(pid, &status, WUNTRACED));
 		if(n < 0)
 			panic("check_ptrace : wait failed, errno = %d", errno);
-		if(!WIFSTOPPED(status) || (WSTOPSIG(status) != SIGTRAP))
-			panic("check_ptrace : expected SIGTRAP, "
+		if(!WIFSTOPPED(status) || (WSTOPSIG(status) != (SIGTRAP + 0x80)))
+			panic("check_ptrace : expected SIGTRAP + 0x80, "
 			      "got status = %d", status);
 		
 		syscall = ptrace(PTRACE_PEEKUSER, pid, PT_SYSCALL_NR_OFFSET,

[-- Attachment #3: patch-TRACESYSGOOD-2 --]
[-- Type: text/plain, Size: 2295 bytes --]

From: Bodo Stroesser <bstroesser@fujitsu-siemens.com>

Patch 2/3 to implement usage of PTRACE_O_TRACESYSGOOD
This is necessary, to fix UMLs bad behavior when a process does
a systemcall with syscall-number less than 0.

This patch makes SKAS-mode use PTRACE_O_TRACESYSGOOD and fixes
the problems in SKAS.

Signed-off-by: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
---

--- a/arch/um/kernel/skas/process.c	2004-10-21 10:50:27.770336304 +0200
+++ b/arch/um/kernel/skas/process.c	2004-10-21 11:34:50.764261057 +0200
@@ -11,6 +11,7 @@
 #include <sched.h>
 #include <sys/wait.h>
 #include <sys/ptrace.h>
+#include <linux/ptrace.h>
 #include <sys/mman.h>
 #include <sys/user.h>
 #include <asm/unistd.h>
@@ -54,14 +55,9 @@
 /*To use the same value of using_sysemu as the caller, ask it that value (in local_using_sysemu)*/
 static void handle_trap(int pid, union uml_pt_regs *regs, int local_using_sysemu)
 {
-	int err, syscall_nr, status;
+	int err, status;
 
-	syscall_nr = PT_SYSCALL_NR(regs->skas.regs);
-	UPT_SYSCALL_NR(regs) = syscall_nr;
-	if(syscall_nr < 0){
-		relay_signal(SIGTRAP, regs);
-		return;
-	}
+	UPT_SYSCALL_NR(regs) = PT_SYSCALL_NR(regs->skas.regs);
 
 	if (!local_using_sysemu)
 	{
@@ -76,7 +72,7 @@
 			      "errno = %d\n", errno);
 
 		CATCH_EINTR(err = waitpid(pid, &status, WUNTRACED));
-		if((err < 0) || !WIFSTOPPED(status) || (WSTOPSIG(status) != SIGTRAP))
+		if((err < 0) || !WIFSTOPPED(status) || (WSTOPSIG(status) != (SIGTRAP + 0x80)))
 			panic("handle_trap - failed to wait at end of syscall, "
 			      "errno = %d, status = %d\n", errno, status);
 	}
@@ -124,6 +120,10 @@
 		panic("start_userspace : expected SIGSTOP, got status = %d",
 		      status);
 
+	if (ptrace(PTRACE_SETOPTIONS, pid, NULL, (void *)PTRACE_O_TRACESYSGOOD) < 0)
+		panic("start_userspace : PTRACE_SETOPTIONS failed, errno=%d\n", 
+		      errno);
+
 	if(munmap(stack, PAGE_SIZE) < 0)
 		panic("start_userspace : munmap failed, errno = %d\n", errno);
 
@@ -160,9 +160,13 @@
 			case SIGSEGV:
 				handle_segv(pid);
 				break;
-			case SIGTRAP:
+			case SIGTRAP + 0x80:
 			        handle_trap(pid, regs, local_using_sysemu);
 				break;
+			case SIGTRAP:
+				UPT_SYSCALL_NR(regs) = -1;
+				relay_signal(SIGTRAP, regs);
+				break;
 			case SIGIO:
 			case SIGVTALRM:
 			case SIGILL:

[-- Attachment #4: patch-TRACESYSGOOD-3 --]
[-- Type: text/plain, Size: 4441 bytes --]

From: Bodo Stroesser <bstroesser@fujitsu-siemens.com>

Patch 3/3 to implement usage of PTRACE_O_TRACESYSGOOD
This is necessary, to fix UMLs bad behavior when a process does
a systemcall with syscall-number less than 0.

This patch makes TT-mode use PTRACE_O_TRACESYSGOOD and fixes
the problems in TT.
I'm not quite sure, that this patch doesn't cause problems with
debugger usage. It should be testet by someone, who has more
know how about TT-mode debugger.

Signed-off-by: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
---

--- a/arch/um/kernel/tt/include/tt.h	2004-10-21 15:00:19.909225710 +0200
+++ b/arch/um/kernel/tt/include/tt.h	2004-10-21 15:00:49.982255966 +0200
@@ -27,6 +27,7 @@
 extern void syscall_handler(int sig, union uml_pt_regs *regs);
 extern void exit_kernel(int pid, void *task);
 extern int do_syscall(void *task, int pid);
+extern void do_sigtrap(void *task);
 extern int is_valid_pid(int pid);
 extern void remap_data(void *segment_start, void *segment_end, int w);
 
--- a/arch/um/kernel/tt/tracer.c	2004-10-21 14:35:01.568140412 +0200
+++ b/arch/um/kernel/tt/tracer.c	2004-10-21 15:42:09.283536999 +0200
@@ -13,6 +13,7 @@
 #include <string.h>
 #include <sys/mman.h>
 #include <sys/ptrace.h>
+#include <linux/ptrace.h>
 #include <sys/time.h>
 #include <sys/wait.h>
 #include "user.h"
@@ -71,6 +72,8 @@
 	   (ptrace(PTRACE_CONT, pid, 0, 0) < 0))
 		tracer_panic("OP_FORK failed to attach pid");
 	wait_for_stop(pid, SIGSTOP, PTRACE_CONT, NULL);
+	if (ptrace(PTRACE_SETOPTIONS, pid, 0, (void *)PTRACE_O_TRACESYSGOOD) < 0)
+		tracer_panic("OP_FORK: PTRACE_SETOPTIONS failed, errno = %d", errno);
 	if(ptrace(PTRACE_CONT, pid, 0, 0) < 0)
 		tracer_panic("OP_FORK failed to continue process");
 }
@@ -141,7 +144,7 @@
 	 * any more, the trace of those will land here.  So, we need to just 
 	 * PTRACE_SYSCALL it.
 	 */
-	case SIGTRAP:
+	case (SIGTRAP + 0x80):
 		if(ptrace(PTRACE_SYSCALL, pid, 0, 0) < 0)
 			tracer_panic("sleeping_process_signal : Failed to "
 				     "PTRACE_SYSCALL pid %d, errno = %d\n",
@@ -196,6 +199,10 @@
 		printf("waitpid on idle thread failed, errno = %d\n", errno);
 		exit(1);
 	}
+	if (ptrace(PTRACE_SETOPTIONS, pid, 0, (void *)PTRACE_O_TRACESYSGOOD) < 0) {
+		printf("Failed to PTRACE_SETOPTIONS for idle thread, errno = %d\n", errno);
+		exit(1);
+	}
 	if((ptrace(PTRACE_CONT, pid, 0, 0) < 0)){
 		printf("Failed to continue idle thread, errno = %d\n", errno);
 		exit(1);
@@ -323,14 +330,22 @@
 				 */
 				pid = cpu_tasks[proc_id].pid;
 				break;
+			case (SIGTRAP + 0x80):
+				if(!tracing && (debugger_pid != -1)){
+					child_signal(pid, status&0x7fff);
+					continue;
+				}
+				tracing = 0;
+				do_syscall(task, pid);
+				sig = SIGUSR2;
+				break;
 			case SIGTRAP:
 				if(!tracing && (debugger_pid != -1)){
 					child_signal(pid, status);
 					continue;
 				}
 				tracing = 0;
-				if(do_syscall(task, pid))
-					sig = SIGUSR2;
+				do_sigtrap(task);
 				break;
 			case SIGPROF:
 				if(tracing) sig = 0;
--- a/arch/um/kernel/tt/syscall_user.c	2004-10-21 15:02:31.903412902 +0200
+++ b/arch/um/kernel/tt/syscall_user.c	2004-10-21 14:59:58.836708066 +0200
@@ -43,21 +43,19 @@
 	record_syscall_end(index, result);
 }
 
+void do_sigtrap(void *task)
+{
+	UPT_SYSCALL_NR(TASK_REGS(task)) = -1;
+}
+
 int do_syscall(void *task, int pid)
 {
 	unsigned long proc_regs[FRAME_SIZE];
-	union uml_pt_regs *regs;
-	int syscall;
 
 	if(ptrace_getregs(pid, proc_regs) < 0)
 		tracer_panic("Couldn't read registers");
-	syscall = PT_SYSCALL_NR(proc_regs);
-
-	regs = TASK_REGS(task);
-	UPT_SYSCALL_NR(regs) = syscall;
 
-	if(syscall < 0)
-		return(0);
+	UPT_SYSCALL_NR(TASK_REGS(task)) = PT_SYSCALL_NR(proc_regs);
 
 	if(((unsigned long *) PT_IP(proc_regs) >= &_stext) && 
 	   ((unsigned long *) PT_IP(proc_regs) <= &_etext))
--- a/arch/um/kernel/tt/exec_user.c	2004-10-21 15:37:21.876032761 +0200
+++ b/arch/um/kernel/tt/exec_user.c	2004-10-21 15:38:38.940297443 +0200
@@ -10,6 +10,7 @@
 #include <errno.h>
 #include <sys/wait.h>
 #include <sys/ptrace.h>
+#include <linux/ptrace.h>
 #include <signal.h>
 #include "user_util.h"
 #include "kern_util.h"
@@ -37,6 +38,9 @@
 
 	kill(old_pid, SIGKILL);
 
+	if (ptrace(PTRACE_SETOPTIONS, new_pid, 0, (void *)PTRACE_O_TRACESYSGOOD) < 0)
+		tracer_panic("do_exec: PTRACE_SETOPTIONS failed, errno = %d", errno);
+
 	if(ptrace_setregs(new_pid, regs) < 0)
 		tracer_panic("do_exec failed to start new proc - errno = %d",
 			     errno);

Re: [uml-devel] Bad handling of invalif systemcalls

[BlaisorBlade]

On Thursday 21 October 2004 17:25, Bodo Stroesser wrote:
> If a process in UML does a systemcall with the systemcall number
> being less than 0, in TT-mode and SKAS-mode using SYSEMU, the
> process is killed by an SIGTRAP instead of simply returning -ENOSYS.
> In SKAS-mode without SYSEMU, UML even crashes, no matter if SYSEMU
> is unsupported by the host or switched off in UML:

>      Kernel panic - not syncing: handle_trap - failed to wait at end of
> syscall, errno = 4, status = 2943

> The reason is, that UML can't distinguish between a debugger trap
> and an systemcall interception. Currently, it checks the systemcall
> number. If it is less than 0, it assumes the event to be a debugger
> trap. It would be better to assume a debugger trap only, if the
> syscall number is -1 (which it is guaranteed to be in case of a
> debugger event), but even then UML wouldn't be safe. Syscalls with
> syscall number -1 still would be a problem!

> AFAICS, the only solution for this is using the PTRACE_O_TRACESYSGOOD
> option. This option seems to be specific for linux, but the problem
> maybe is specific for linux, too.

I have been thinking to using SYSGOOD, but without finding a good reason for 
that... so thanks for this.

The first remark (the only I have for now) is that you should replace "SIGTRAP 
+ 0x80" with "SIGTRAP | 0x80". It should not make a difference in this 
particular case, but it's a style issue, which exists because the second way 
is more robust for setting bits: think about (SIGTRAP & 0x80) == 0x80 and 
using the + 0x80: it clears the bit it should set and set another one.

Remark no. 2: could you, please, in next patches, try to add -p to diff flags 
to improve readability? That makes clear which function is being changed, so 
the patch becomes more readable.
> So, here attached are three patches. The first adds a check for
> availability and function of
>      ptrace(PTRACE_SETOPTIONS,,,PTRACE_O_TRACESYSGOOD) to the normal
> ptrace checks.
>
> The second implements the usage of the option in SKAS-mode.

> The third does the same for TT-mode.

> For the third patch I'm quite anxious, that there could go something
> wrong when using the debugger. I don't understand much about this.
> Maybe someone else could look into this?
I'll give a look when I have the needed time. However, could you explain what 
makes you worry in detail?
> Regards
> Bodo

-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: Bad handling of invalif systemcalls

[Jeff Dike]

bstroesser@fujitsu-siemens.com said:
> AFAICS, the only solution for this is using the PTRACE_O_TRACESYSGOOD
> option. This option seems to be specific for linux, but the problem
> maybe is specific for linux, too. 

Another solution is to read the instruction.

However TRACESYSGOOD is cleaner.  My only concern is whether that limits the
hosts that UML will run on.  If TRACESYSGOOD has been around for the 2.4
series, then that's OK.

I would be tempted to #define SIGSYSCALL (SIGTRAP + 0x80) or something just
to make the +0x80 bit less magic-looking.

> For the third patch I'm quite anxious, that there could go something
> wrong when using the debugger. I don't understand much about this.
> Maybe someone else could look into this? 

 				if(!tracing && (debugger_pid != -1)){
 					child_signal(pid, status);
 					continue;
 				}
 				tracing = 0;
				if(do_syscall(task, pid))
					sig = SIGUSR2;

OK, what this says is
	if we are running in the kernel, not userspace (!tracing)
	and we are debugging UML (debugger_pid != -1)
	then we fake the syscall-traced gdb into thinking the SIGTRAP was sent
	to the process

	Otherwise we call do_syscall, which will check the syscall number 
	and return true if it thinks it's handling a syscall.  In that case,
	we hit the process with SUGUSR2 in order to force it into the UML
	syscall handler.

So, if we get SIGTRAP + 0x80, we know we have a syscall, and the debugging
stuff can just go away.  You can look at this sort of mathematically, and
say SIGTRAP + 0x80 => tracing, so that if(!tracing...) can just be deleted.

Similarly, do_syscall will always return true, so you don't need to check its
return, which you have removed.

In the SIGTRAP case, you might as well inline do_sigtrap.  One line functions
are pretty much a waste.  In any case, I don't understand why you're doing
that.  orig_eax should already be -1.
	
				Jeff



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: Bad handling of invalif systemcalls

[BlaisorBlade]

On Friday 22 October 2004 00:09, Jeff Dike wrote:
> bstroesser@fujitsu-siemens.com said:
> > AFAICS, the only solution for this is using the PTRACE_O_TRACESYSGOOD
> > option. This option seems to be specific for linux, but the problem
> > maybe is specific for linux, too.
>
> Another solution is to read the instruction.
>
> However TRACESYSGOOD is cleaner.  My only concern is whether that limits
> the hosts that UML will run on.  If TRACESYSGOOD has been around for the
> 2.4 series, then that's OK.
>
> I would be tempted to #define SIGSYSCALL (SIGTRAP + 0x80) or something just
> to make the +0x80 bit less magic-looking.

It should be | 0x80, not + 0x80 (style issue). See the code in 
do_syscall_trace.

-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: Bad handling of invalif systemcalls

[Jeff Dike]

blaisorblade_spam@yahoo.it said:
> It should be | 0x80, not + 0x80 (style issue). See the code in
> do_syscall_trace. 

Right, I was using his style just to not confuse things.

				Jeff



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Bad handling of invalif systemcalls

[Bodo Stroesser]

BlaisorBlade wrote:
> 
> The first remark (the only I have for now) is that you should replace "SIGTRAP 
> + 0x80" with "SIGTRAP | 0x80". It should not make a difference in this 
> particular case, but it's a style issue, which exists because the second way 
> is more robust for setting bits: think about (SIGTRAP & 0x80) == 0x80 and 
> using the + 0x80: it clears the bit it should set and set another one.
Yes. I agree.

> 
> Remark no. 2: could you, please, in next patches, try to add -p to diff flags 
> to improve readability? That makes clear which function is being changed, so 
> the patch becomes more readable.
I will do so.

> 
>>For the third patch I'm quite anxious, that there could go something
>>wrong when using the debugger. I don't understand much about this.
>>Maybe someone else could look into this?
> 
> I'll give a look when I have the needed time. However, could you explain what 
> makes you worry in detail?
I do not understand, how the debugger works. I didn't even use it, yet.
Maybe it would be a good idea to learn while testing.
I tried to mask the additional 0x80 when the debugger is called
(i.e. "(status&0x7fff)"). But I don't know, whether this is the only place, where
a special handling has to be inserted to let the debugger see no changes.

Bodo


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: Bad handling of invalif systemcalls

[Bodo Stroesser]

Jeff Dike wrote:
> bstroesser@fujitsu-siemens.com said:
> 
>>AFAICS, the only solution for this is using the PTRACE_O_TRACESYSGOOD
>>option. This option seems to be specific for linux, but the problem
>>maybe is specific for linux, too. 
> 
> 
> Another solution is to read the instruction.
It's a bit tricky to do this, if the vsyscall-page is in use. Then you also
have to know the address of the return-point for "sysenter", which the
kernel uses.
Also, the tracer thread at the moment has no access to the code of the process!
I tapped into this trap while trying to simplify the singlestepping even more by
moving the opcode-check from kernel_do_signal() to is_syscall().
So I reverted the change ...

> 
> However TRACESYSGOOD is cleaner.  My only concern is whether that limits the
> hosts that UML will run on.  If TRACESYSGOOD has been around for the 2.4
> series, then that's OK.
2.4 supports it, at least in the newer versions. I looked for it before patching.

> 
> I would be tempted to #define SIGSYSCALL (SIGTRAP + 0x80) or something just
> to make the +0x80 bit less magic-looking.
Yes. I used the 0x80, because I didn't find a definition for this in the
header files from /usr/include. So, if the host linux doesn't use a
     #define THIS_IS_A_SYSCALL_INTERCEPTION 0x80
I decided not to do it also. But feel free to change this.

> 
> 
>>For the third patch I'm quite anxious, that there could go something
>>wrong when using the debugger. I don't understand much about this.
>>Maybe someone else could look into this? 
> 
> 
>  				if(!tracing && (debugger_pid != -1)){
>  					child_signal(pid, status);
>  					continue;
>  				}
>  				tracing = 0;
> 				if(do_syscall(task, pid))
> 					sig = SIGUSR2;
> 
> OK, what this says is
> 	if we are running in the kernel, not userspace (!tracing)
> 	and we are debugging UML (debugger_pid != -1)
> 	then we fake the syscall-traced gdb into thinking the SIGTRAP was sent
> 	to the process
> 
> 	Otherwise we call do_syscall, which will check the syscall number 
> 	and return true if it thinks it's handling a syscall.  In that case,
> 	we hit the process with SUGUSR2 in order to force it into the UML
> 	syscall handler.
> 
> So, if we get SIGTRAP + 0x80, we know we have a syscall, and the debugging
> stuff can just go away.  You can look at this sort of mathematically, and
> say SIGTRAP + 0x80 => tracing, so that if(!tracing...) can just be deleted.
No. The processes in UML-TT, no matter if they run in userspace or execute the
kernel, always are ptraced processes and PTRACE_O_TRACESSYSGOOD now will be
set permanently. So, if the debugger does an syscall-trace, it will expect an
SIGTRAP, but what happens is an (SIGTRAP|0x80). Since I didn't want to change
the debugger, I masked the 0x80.
For breakpoints or singlestep-traps, the signal still will be SIGTRAP only.

Maybe it would make sense, to change the debugger-code. It could accept
(SIGTRAP|0x80) and give it to the real debugger as SIGTRAP normally. Also, it
could accept a ptrace(PTRACE_SETOTIONS,,,PTRACE_O_TRACESYSGOOD) and after this
it could relay the (SIGTRAP|0x80) without change.

> 
> Similarly, do_syscall will always return true, so you don't need to check its
> return, which you have removed.
> 
> In the SIGTRAP case, you might as well inline do_sigtrap.  One line functions
> are pretty much a waste.  In any case, I don't understand why you're doing
> that.  orig_eax should already be -1.
Yes. Inlining is a good idea.
You are right, orig_eax on the processes stack is -1. But this *has* to be saved
in the tt-regs structure for later use. What I'm doing is the same that
     UPT_SYSCALL_NR(TASK_REGS(task)) = PT_SYSCALL_NR(proc_regs);
does in the case of a systemcall. I used "-1" instead of "PT_SYSCALL_NR(proc_regs)"
because it *is* the same in this situation.
> 	
> 				Jeff
> 



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: Bad handling of invalif systemcalls

[Bodo Stroesser]

BlaisorBlade wrote:
> On Friday 22 October 2004 00:09, Jeff Dike wrote:
> 
>>bstroesser@fujitsu-siemens.com said:
>>
>>>AFAICS, the only solution for this is using the PTRACE_O_TRACESYSGOOD
>>>option. This option seems to be specific for linux, but the problem
>>>maybe is specific for linux, too.
>>
>>Another solution is to read the instruction.
>>
>>However TRACESYSGOOD is cleaner.  My only concern is whether that limits
>>the hosts that UML will run on.  If TRACESYSGOOD has been around for the
>>2.4 series, then that's OK.
>>
>>I would be tempted to #define SIGSYSCALL (SIGTRAP + 0x80) or something just
>>to make the +0x80 bit less magic-looking.
> 
> 
> It should be | 0x80, not + 0x80 (style issue). See the code in 
> do_syscall_trace.
> 
Yes. Should I submit new patches, or will you do the changes yourself?

Bodo


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: Bad handling of invalif systemcalls

[Jeff Dike]

bstroesser@fujitsu-siemens.com said:
> Maybe it would make sense, to change the debugger-code. It could
> accept (SIGTRAP|0x80) and give it to the real debugger as SIGTRAP
> normally. Also, it could accept a ptrace(PTRACE_SETOTIONS,,,PTRACE_O_TR
> ACESYSGOOD) and after this it could relay the (SIGTRAP|0x80) without
> change. 

Yeah, it would, but what you have now will work for the time being.

> You are right, orig_eax on the processes stack is -1. But this *has*
> to be saved in the tt-regs structure for later use. What I'm doing is
> the same that
>      UPT_SYSCALL_NR(TASK_REGS(task)) = PT_SYSCALL_NR(proc_regs); does
> in the case of a systemcall. I used "-1" instead of
> "PT_SYSCALL_NR(proc_regs)" because it *is* the same in this situation.

Right, good point.

				Jeff


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: Bad handling of invalif systemcalls

[Bodo Stroesser]

[-- Attachment #1: Type: text/plain, Size: 688 bytes --]

Jeff Dike wrote:
> 
> I would be tempted to #define SIGSYSCALL (SIGTRAP + 0x80) or something just
> to make the +0x80 bit less magic-looking.
O.K. I defined it in signal_user.h, hope it's OK there. Consequently the
definition is used in arch/um/kernel/ptrace.c to replace the 0x80 at the
call to ptrace_notify().
> 
> In the SIGTRAP case, you might as well inline do_sigtrap.  One line functions
> are pretty much a waste.
Sorry, I tried to inline it, but it failed to compile. At the moment tracer.c
contains functions without much knowledge about task structure only. Without
including the specific headers, inlining cannot be used.

So, attached you'll find the revised patches.

Bodo

[-- Attachment #2: patch-TRACESYSGOOD-1 --]
[-- Type: text/plain, Size: 2873 bytes --]

From: Bodo Stroesser <bstroesser@fujitsu-siemens.com>

Patch 1/3 to implement usage of PTRACE_O_TRACESYSGOOD
This is necessary, to fix UMLs bad behavior when a process does
a systemcall with syscall-number less than 0.

Insert a check for availability and function of
  ptrace(PTRACE_SETOPTIONS,,,PTRACE_O_TRACESYSGOOD)
into the normal ptrace checks at startup.

Signed-off-by: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
---

diff -puNr a/arch/um/include/signal_user.h b/arch/um/include/signal_user.h
--- a/arch/um/include/signal_user.h	2004-10-25 13:05:37.008823813 +0200
+++ b/arch/um/include/signal_user.h	2004-10-25 12:18:02.060620621 +0200
@@ -14,6 +14,8 @@ extern void set_handler(int sig, void (*
 extern int set_signals(int enable);
 extern int get_signals(void);
 
+#define SYSCALL_TRAP 0x80
+
 #endif
 
 /*
diff -puNr a/arch/um/kernel/process.c b/arch/um/kernel/process.c
--- a/arch/um/kernel/process.c	2004-10-25 13:05:37.008823813 +0200
+++ b/arch/um/kernel/process.c	2004-10-25 11:41:57.287362002 +0200
@@ -13,6 +13,7 @@
 #include <setjmp.h>
 #include <sys/time.h>
 #include <sys/ptrace.h>
+#include <linux/ptrace.h>
 #include <sys/wait.h>
 #include <sys/mman.h>
 #include <asm/ptrace.h>
@@ -255,6 +256,9 @@ void __init check_ptrace(void)
 	printk("Checking that ptrace can change system call numbers...");
 	pid = start_ptraced_child(&stack);
 
+	if(ptrace(PTRACE_SETOPTIONS, pid, 0, (void *)PTRACE_O_TRACESYSGOOD) < 0)
+		panic("check_ptrace: PTRACE_SETOPTIONS failed, errno = %d", errno);
+
 	while(1){
 		if(ptrace(PTRACE_SYSCALL, pid, 0, 0) < 0)
 			panic("check_ptrace : ptrace failed, errno = %d", 
@@ -262,8 +266,8 @@ void __init check_ptrace(void)
 		CATCH_EINTR(n = waitpid(pid, &status, WUNTRACED));
 		if(n < 0)
 			panic("check_ptrace : wait failed, errno = %d", errno);
-		if(!WIFSTOPPED(status) || (WSTOPSIG(status) != SIGTRAP))
-			panic("check_ptrace : expected SIGTRAP, "
+		if(!WIFSTOPPED(status) || (WSTOPSIG(status) != (SIGTRAP | 0x80)))
+			panic("check_ptrace : expected (SIGTRAP | 0x80), "
 			      "got status = %d", status);
 		
 		syscall = ptrace(PTRACE_PEEKUSER, pid, PT_SYSCALL_NR_OFFSET,
diff -puNr a/arch/um/kernel/ptrace.c b/arch/um/kernel/ptrace.c
--- a/arch/um/kernel/ptrace.c	2004-10-25 13:05:37.009823648 +0200
+++ b/arch/um/kernel/ptrace.c	2004-10-25 12:27:41.169919438 +0200
@@ -17,6 +17,7 @@
 #include "kern_util.h"
 #include "ptrace_user.h"
 #include "skas_ptrace.h"
+#include "signal_user.h"
 
 /*
  * Called by kernel/ptrace.c when detaching..
@@ -319,7 +320,7 @@ void syscall_trace(union uml_pt_regs *re
 	/* the 0x80 provides a way for the tracing parent to distinguish
 	   between a syscall stop and SIGTRAP delivery */
 	ptrace_notify(SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD)
-				 ? 0x80 : 0));
+				 ? SYSCALL_TRAP : 0));
 
 	/*
 	 * this isn't the same as continuing with a signal, but it will do

[-- Attachment #3: patch-TRACESYSGOOD-2 --]
[-- Type: text/plain, Size: 2547 bytes --]

From: Bodo Stroesser <bstroesser@fujitsu-siemens.com>

Patch 2/3 to implement usage of PTRACE_O_TRACESYSGOOD
This is necessary, to fix UMLs bad behavior when a process does
a systemcall with syscall-number less than 0.

This patch makes SKAS-mode use PTRACE_O_TRACESYSGOOD and fixes
the problems in SKAS.

Signed-off-by: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
---

diff -puNr a/arch/um/kernel/skas/process.c b/arch/um/kernel/skas/process.c
--- a/arch/um/kernel/skas/process.c	2004-10-25 12:58:06.944199612 +0200
+++ b/arch/um/kernel/skas/process.c	2004-10-25 12:57:31.217103722 +0200
@@ -11,6 +11,7 @@
 #include <sched.h>
 #include <sys/wait.h>
 #include <sys/ptrace.h>
+#include <linux/ptrace.h>
 #include <sys/mman.h>
 #include <sys/user.h>
 #include <asm/unistd.h>
@@ -54,14 +55,9 @@ static void handle_segv(int pid)
 /*To use the same value of using_sysemu as the caller, ask it that value (in local_using_sysemu)*/
 static void handle_trap(int pid, union uml_pt_regs *regs, int local_using_sysemu)
 {
-	int err, syscall_nr, status;
+	int err, status;
 
-	syscall_nr = PT_SYSCALL_NR(regs->skas.regs);
-	UPT_SYSCALL_NR(regs) = syscall_nr;
-	if(syscall_nr < 0){
-		relay_signal(SIGTRAP, regs);
-		return;
-	}
+	UPT_SYSCALL_NR(regs) = PT_SYSCALL_NR(regs->skas.regs);
 
 	if (!local_using_sysemu)
 	{
@@ -76,7 +72,8 @@ static void handle_trap(int pid, union u
 			      "errno = %d\n", errno);
 
 		CATCH_EINTR(err = waitpid(pid, &status, WUNTRACED));
-		if((err < 0) || !WIFSTOPPED(status) || (WSTOPSIG(status) != SIGTRAP))
+		if((err < 0) || !WIFSTOPPED(status) ||
+		                (WSTOPSIG(status) != (SIGTRAP|SYSCALL_TRAP)))
 			panic("handle_trap - failed to wait at end of syscall, "
 			      "errno = %d, status = %d\n", errno, status);
 	}
@@ -125,6 +122,10 @@ void start_userspace(int cpu)
 		panic("start_userspace : expected SIGSTOP, got status = %d",
 		      status);
 
+	if (ptrace(PTRACE_SETOPTIONS, pid, NULL, (void *)PTRACE_O_TRACESYSGOOD) < 0)
+		panic("start_userspace : PTRACE_SETOPTIONS failed, errno=%d\n", 
+		      errno);
+
 	if(munmap(stack, PAGE_SIZE) < 0)
 		panic("start_userspace : munmap failed, errno = %d\n", errno);
 
@@ -161,9 +162,13 @@ void userspace(union uml_pt_regs *regs)
 			case SIGSEGV:
 				handle_segv(pid);
 				break;
-			case SIGTRAP:
+			case (SIGTRAP|SYSCALL_TRAP):
 			        handle_trap(pid, regs, local_using_sysemu);
 				break;
+			case SIGTRAP:
+				UPT_SYSCALL_NR(regs) = -1;
+				relay_signal(SIGTRAP, regs);
+				break;
 			case SIGIO:
 			case SIGVTALRM:
 			case SIGILL:

[-- Attachment #4: patch-TRACESYSGOOD-3 --]
[-- Type: text/plain, Size: 5028 bytes --]

From: Bodo Stroesser <bstroesser@fujitsu-siemens.com>

Patch 3/3 to implement usage of PTRACE_O_TRACESYSGOOD
This is necessary, to fix UMLs bad behavior when a process does
a systemcall with syscall-number less than 0.

This patch makes TT-mode use PTRACE_O_TRACESYSGOOD and fixes
the problems in TT.
I'm not quite sure, that this patch doesn't cause problems with
debugger usage. It should be testet by someone, who has more
know how about TT-mode debugger.

Signed-off-by: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
---

diff -puNr a/arch/um/kernel/tt/exec_user.c b/arch/um/kernel/tt/exec_user.c
--- a/arch/um/kernel/tt/exec_user.c	2004-10-25 12:37:19.166402155 +0200
+++ b/arch/um/kernel/tt/exec_user.c	2004-10-25 11:52:33.462230402 +0200
@@ -10,6 +10,7 @@
 #include <errno.h>
 #include <sys/wait.h>
 #include <sys/ptrace.h>
+#include <linux/ptrace.h>
 #include <signal.h>
 #include "user_util.h"
 #include "kern_util.h"
@@ -37,6 +38,9 @@ void do_exec(int old_pid, int new_pid)
 
 	kill(old_pid, SIGKILL);
 
+	if (ptrace(PTRACE_SETOPTIONS, new_pid, 0, (void *)PTRACE_O_TRACESYSGOOD) < 0)
+		tracer_panic("do_exec: PTRACE_SETOPTIONS failed, errno = %d", errno);
+
 	if(ptrace_setregs(new_pid, regs) < 0)
 		tracer_panic("do_exec failed to start new proc - errno = %d",
 			     errno);
diff -puNr a/arch/um/kernel/tt/include/tt.h b/arch/um/kernel/tt/include/tt.h
--- a/arch/um/kernel/tt/include/tt.h	2004-10-25 12:37:19.164402486 +0200
+++ b/arch/um/kernel/tt/include/tt.h	2004-10-25 11:52:33.461230567 +0200
@@ -27,6 +27,7 @@ extern int is_tracing(void *task);
 extern void syscall_handler(int sig, union uml_pt_regs *regs);
 extern void exit_kernel(int pid, void *task);
 extern int do_syscall(void *task, int pid);
+extern void do_sigtrap(void *task);
 extern int is_valid_pid(int pid);
 extern void remap_data(void *segment_start, void *segment_end, int w);
 
diff -puNr a/arch/um/kernel/tt/syscall_user.c b/arch/um/kernel/tt/syscall_user.c
--- a/arch/um/kernel/tt/syscall_user.c	2004-10-25 12:37:19.165402321 +0200
+++ b/arch/um/kernel/tt/syscall_user.c	2004-10-25 11:52:33.462230402 +0200
@@ -43,21 +43,19 @@ void syscall_handler_tt(int sig, union u
 	record_syscall_end(index, result);
 }
 
+void do_sigtrap(void *task)
+{
+	UPT_SYSCALL_NR(TASK_REGS(task)) = -1;
+}
+
 int do_syscall(void *task, int pid)
 {
 	unsigned long proc_regs[FRAME_SIZE];
-	union uml_pt_regs *regs;
-	int syscall;
 
 	if(ptrace_getregs(pid, proc_regs) < 0)
 		tracer_panic("Couldn't read registers");
-	syscall = PT_SYSCALL_NR(proc_regs);
-
-	regs = TASK_REGS(task);
-	UPT_SYSCALL_NR(regs) = syscall;
 
-	if(syscall < 0)
-		return(0);
+	UPT_SYSCALL_NR(TASK_REGS(task)) = PT_SYSCALL_NR(proc_regs);
 
 	if(((unsigned long *) PT_IP(proc_regs) >= &_stext) && 
 	   ((unsigned long *) PT_IP(proc_regs) <= &_etext))
diff -puNr a/arch/um/kernel/tt/tracer.c b/arch/um/kernel/tt/tracer.c
--- a/arch/um/kernel/tt/tracer.c	2004-10-25 12:37:19.165402321 +0200
+++ b/arch/um/kernel/tt/tracer.c	2004-10-25 12:34:44.695929300 +0200
@@ -13,6 +13,7 @@
 #include <string.h>
 #include <sys/mman.h>
 #include <sys/ptrace.h>
+#include <linux/ptrace.h>
 #include <sys/time.h>
 #include <sys/wait.h>
 #include "user.h"
@@ -71,6 +72,8 @@ void attach_process(int pid)
 	   (ptrace(PTRACE_CONT, pid, 0, 0) < 0))
 		tracer_panic("OP_FORK failed to attach pid");
 	wait_for_stop(pid, SIGSTOP, PTRACE_CONT, NULL);
+	if (ptrace(PTRACE_SETOPTIONS, pid, 0, (void *)PTRACE_O_TRACESYSGOOD) < 0)
+		tracer_panic("OP_FORK: PTRACE_SETOPTIONS failed, errno = %d", errno);
 	if(ptrace(PTRACE_CONT, pid, 0, 0) < 0)
 		tracer_panic("OP_FORK failed to continue process");
 }
@@ -141,7 +144,7 @@ static void sleeping_process_signal(int 
 	 * any more, the trace of those will land here.  So, we need to just 
 	 * PTRACE_SYSCALL it.
 	 */
-	case SIGTRAP:
+	case (SIGTRAP|SYSCALL_TRAP):
 		if(ptrace(PTRACE_SYSCALL, pid, 0, 0) < 0)
 			tracer_panic("sleeping_process_signal : Failed to "
 				     "PTRACE_SYSCALL pid %d, errno = %d\n",
@@ -196,6 +199,10 @@ int tracer(int (*init_proc)(void *), voi
 		printf("waitpid on idle thread failed, errno = %d\n", errno);
 		exit(1);
 	}
+	if (ptrace(PTRACE_SETOPTIONS, pid, 0, (void *)PTRACE_O_TRACESYSGOOD) < 0) {
+		printf("Failed to PTRACE_SETOPTIONS for idle thread, errno = %d\n", errno);
+		exit(1);
+	}
 	if((ptrace(PTRACE_CONT, pid, 0, 0) < 0)){
 		printf("Failed to continue idle thread, errno = %d\n", errno);
 		exit(1);
@@ -323,14 +330,22 @@ int tracer(int (*init_proc)(void *), voi
 				 */
 				pid = cpu_tasks[proc_id].pid;
 				break;
+			case (SIGTRAP|SYSCALL_TRAP):
+				if(!tracing && (debugger_pid != -1)){
+					child_signal(pid, W_STOPCODE(SIGTRAP));
+					continue;
+				}
+				tracing = 0;
+				do_syscall(task, pid);
+				sig = SIGUSR2;
+				break;
 			case SIGTRAP:
 				if(!tracing && (debugger_pid != -1)){
 					child_signal(pid, status);
 					continue;
 				}
 				tracing = 0;
-				if(do_syscall(task, pid))
-					sig = SIGUSR2;
+				do_sigtrap(task);
 				break;
 			case SIGPROF:
 				if(tracing) sig = 0;

Re: [uml-devel] Re: Bad handling of invalif systemcalls

[Bodo Stroesser]

[-- Attachment #1: Type: text/plain, Size: 891 bytes --]

Bodo Stroesser wrote:
> Jeff Dike wrote:
> 
>>
>> I would be tempted to #define SIGSYSCALL (SIGTRAP + 0x80) or something 
>> just
>> to make the +0x80 bit less magic-looking.
> 
> O.K. I defined it in signal_user.h, hope it's OK there. Consequently the
> definition is used in arch/um/kernel/ptrace.c to replace the 0x80 at the
> call to ptrace_notify().
> 
>>
>> In the SIGTRAP case, you might as well inline do_sigtrap.  One line 
>> functions
>> are pretty much a waste.
> 
> Sorry, I tried to inline it, but it failed to compile. At the moment 
> tracer.c
> contains functions without much knowledge about task structure only. 
> Without
> including the specific headers, inlining cannot be used.
> 
> So, attached you'll find the revised patches.
> 
> Bodo
Sorry, I missed one change. There still 0x80 is used in the first patch.
Thus, attached the final version (hopefully ...)

Bodo


[-- Attachment #2: patch-TRACESYSGOOD-1 --]
[-- Type: text/plain, Size: 2885 bytes --]

From: Bodo Stroesser <bstroesser@fujitsu-siemens.com>

Patch 1/3 to implement usage of PTRACE_O_TRACESYSGOOD
This is necessary, to fix UMLs bad behavior when a process does
a systemcall with syscall-number less than 0.

Insert a check for availability and function of
  ptrace(PTRACE_SETOPTIONS,,,PTRACE_O_TRACESYSGOOD)
into the normal ptrace checks at startup.

Signed-off-by: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
---

diff -puNr a/arch/um/include/signal_user.h b/arch/um/include/signal_user.h
--- a/arch/um/include/signal_user.h	2004-10-25 13:05:37.008823813 +0200
+++ b/arch/um/include/signal_user.h	2004-10-25 12:18:02.060620621 +0200
@@ -14,6 +14,8 @@ extern void set_handler(int sig, void (*
 extern int set_signals(int enable);
 extern int get_signals(void);
 
+#define SYSCALL_TRAP 0x80
+
 #endif
 
 /*
diff -puNr a/arch/um/kernel/process.c b/arch/um/kernel/process.c
--- a/arch/um/kernel/process.c	2004-10-25 13:05:37.008823813 +0200
+++ b/arch/um/kernel/process.c	2004-10-25 11:41:57.287362002 +0200
@@ -13,6 +13,7 @@
 #include <setjmp.h>
 #include <sys/time.h>
 #include <sys/ptrace.h>
+#include <linux/ptrace.h>
 #include <sys/wait.h>
 #include <sys/mman.h>
 #include <asm/ptrace.h>
@@ -255,6 +256,9 @@ void __init check_ptrace(void)
 	printk("Checking that ptrace can change system call numbers...");
 	pid = start_ptraced_child(&stack);
 
+	if(ptrace(PTRACE_SETOPTIONS, pid, 0, (void *)PTRACE_O_TRACESYSGOOD) < 0)
+		panic("check_ptrace: PTRACE_SETOPTIONS failed, errno = %d", errno);
+
 	while(1){
 		if(ptrace(PTRACE_SYSCALL, pid, 0, 0) < 0)
 			panic("check_ptrace : ptrace failed, errno = %d", 
@@ -262,8 +266,8 @@ void __init check_ptrace(void)
 		CATCH_EINTR(n = waitpid(pid, &status, WUNTRACED));
 		if(n < 0)
 			panic("check_ptrace : wait failed, errno = %d", errno);
-		if(!WIFSTOPPED(status) || (WSTOPSIG(status) != SIGTRAP))
-			panic("check_ptrace : expected SIGTRAP, "
+		if(!WIFSTOPPED(status) || (WSTOPSIG(status) != (SIGTRAP|SYSCALL_TRAP)))
+			panic("check_ptrace : expected (SIGTRAP|SYSCALL_TRAP), "
 			      "got status = %d", status);
 		
 		syscall = ptrace(PTRACE_PEEKUSER, pid, PT_SYSCALL_NR_OFFSET,
diff -puNr a/arch/um/kernel/ptrace.c b/arch/um/kernel/ptrace.c
--- a/arch/um/kernel/ptrace.c	2004-10-25 13:05:37.009823648 +0200
+++ b/arch/um/kernel/ptrace.c	2004-10-25 12:27:41.169919438 +0200
@@ -17,6 +17,7 @@
 #include "kern_util.h"
 #include "ptrace_user.h"
 #include "skas_ptrace.h"
+#include "signal_user.h"
 
 /*
  * Called by kernel/ptrace.c when detaching..
@@ -319,7 +320,7 @@ void syscall_trace(union uml_pt_regs *re
 	/* the 0x80 provides a way for the tracing parent to distinguish
 	   between a syscall stop and SIGTRAP delivery */
 	ptrace_notify(SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD)
-				 ? 0x80 : 0));
+				 ? SYSCALL_TRAP : 0));
 
 	/*
 	 * this isn't the same as continuing with a signal, but it will do