[uml-devel] [patch 1/1] SYSEMU: avoid intercepting syscall on return when using SYSCALL again.

[uml-devel] [patch 1/1] SYSEMU: avoid intercepting syscall on return when using SYSCALL again.

[blaisorblade_spam]

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

A guest process switching from using PTRACE_SYSEMU to PTRACE_SYSCALL crashes.

The problem is in arch/i386/kernel/entry.S. The current SYSEMU patch inhibits
the syscall-handler to be called, but does not prevent do_syscall_trace to be
called after this for syscall completion interception.

The appended patch fixes this. It reuses the flag TIF_SYSCALL_EMU to remember
"we come from PTRACE_SYSEMU and now are in PTRACE_SYSCALL", since the flag is
unused in the depicted situation.

The patch is tested, AFAICS, it works fine, i.e. sysemu can be switched on and
off dynamically without crash.

Bodo

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade_spam@yahoo.it>
---

 vanilla-linux-2.6.7-SKAS-paolo/arch/i386/kernel/ptrace.c |   28 +++++++++++----
 1 files changed, 21 insertions(+), 7 deletions(-)

diff -puN arch/i386/kernel/ptrace.c~avoid-intercepting-syscall-on-return-when-changing-state arch/i386/kernel/ptrace.c
--- vanilla-linux-2.6.7-SKAS/arch/i386/kernel/ptrace.c~avoid-intercepting-syscall-on-return-when-changing-state	2004-10-22 00:55:06.632837000 +0200
+++ vanilla-linux-2.6.7-SKAS-paolo/arch/i386/kernel/ptrace.c	2004-10-22 01:12:48.391425160 +0200
@@ -366,16 +366,20 @@ asmlinkage int sys_ptrace(long request, 
 		ret = -EIO;
 		if ((unsigned long) data > _NSIG)
 			break;
+		/* If we came here with PTRACE_SYSEMU and now continue with
+		 * PTRACE_SYSCALL, entry.S used to intercept the syscall return. But it
+		 * shouldn't!
+		 * So we don't clear TIF_SYSCALL_EMU, which is always unused in this
+		 * special case, to remember, we came from SYSEMU. That flag
+		 * will be cleared by do_syscall_trace().
+		 */
 		if (request == PTRACE_SYSEMU) {
 			set_tsk_thread_flag(child, TIF_SYSCALL_EMU);
 		}
-		else {
-			clear_tsk_thread_flag(child, TIF_SYSCALL_EMU);
-		}
+
 		if (request == PTRACE_SYSCALL) {
 			set_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
-		}
-		else {
+		} else {
 			clear_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
 		}
 		child->exit_code = data;
@@ -585,7 +589,7 @@ out:
 __attribute__((regparm(3)))
 int do_syscall_trace(struct pt_regs *regs, int entryexit)
 {
-	int is_sysemu;
+	int is_sysemu, is_systrace;
 	if (unlikely(current->audit_context)) {
 		if (!entryexit)
 			audit_syscall_entry(current, regs->orig_eax,
@@ -595,9 +599,19 @@ int do_syscall_trace(struct pt_regs *reg
 			audit_syscall_exit(current, regs->eax);
 	}
 	is_sysemu = test_thread_flag(TIF_SYSCALL_EMU);
+	is_systrace = test_thread_flag(TIF_SYSCALL_TRACE);
 
-	if (!test_thread_flag(TIF_SYSCALL_TRACE) && !is_sysemu)
+	if (!is_systrace && !is_sysemu)
 		return 0;
+	/* We can detect the case of coming from PTRACE_SYSEMU and now
+	 * running with PTRACE_SYSCALL, by TIF_SYSCALL_EMU being set
+	 * additionally.
+	 * If so let's reset the flag and return without action.
+	 */
+	if (is_sysemu && is_systrace) {
+		clear_thread_flag(TIF_SYSCALL_EMU);
+		return 0;
+	}
 	if (!(current->ptrace & PT_PTRACED))
 		return 0;
 	/* the 0x80 provides a way for the tracing parent to distinguish
_


-------------------------------------------------------
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] [patch 1/1] SYSEMU: avoid intercepting syscall on return when using SYSCALL again.

[BlaisorBlade]

On Friday 22 October 2004 01:18, blaisorblade_spam@yahoo.it wrote:
> From: Bodo Stroesser <bstroesser@fujitsu-siemens.com>

> A guest process switching from using PTRACE_SYSEMU to PTRACE_SYSCALL
> crashes.
>
> The problem is in arch/i386/kernel/entry.S. The current SYSEMU patch
> inhibits the syscall-handler to be called, but does not prevent
> do_syscall_trace to be called after this for syscall completion
> interception.
>
> The appended patch fixes this. It reuses the flag TIF_SYSCALL_EMU to
> remember "we come from PTRACE_SYSEMU and now are in PTRACE_SYSCALL", since
> the flag is unused in the depicted situation.
This version of the patch sets it during sys_ptrace(), instead of clearing it 
and re-enabling it as was being done. I'm going to test this version ASAP.

Bye
-- 
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: [patch 1/1] SYSEMU: avoid intercepting syscall on return when using SYSCALL again.

[Bodo Stroesser]

blaisorblade_spam@yahoo.it wrote:
> From: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
> 
> A guest process switching from using PTRACE_SYSEMU to PTRACE_SYSCALL crashes.
> 
> The problem is in arch/i386/kernel/entry.S. The current SYSEMU patch inhibits
> the syscall-handler to be called, but does not prevent do_syscall_trace to be
> called after this for syscall completion interception.
> 
> The appended patch fixes this. It reuses the flag TIF_SYSCALL_EMU to remember
> "we come from PTRACE_SYSEMU and now are in PTRACE_SYSCALL", since the flag is
> unused in the depicted situation.
> 
> The patch is tested, AFAICS, it works fine, i.e. sysemu can be switched on and
> off dynamically without crash.
> 
> Bodo
> 
> Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade_spam@yahoo.it>
> ---
> 
Fine idea to move one part of the patch to sys_ptrace()!
But maybe you missed to reset TIF_SYSCALL_EMU while resuming with PTRACE_CONT?
Here is a revised patch.

Bodo

---

--- a/arch/i386/kernel/ptrace.c	2004-10-20 16:57:25.000000000 +0200
+++ b/arch/i386/kernel/ptrace.c	2004-10-22 10:57:15.460287887 +0200
@@ -366,16 +366,21 @@ asmlinkage int sys_ptrace(long request,
  		ret = -EIO;
  		if ((unsigned long) data > _NSIG)
  			break;
+		/* If we came here with PTRACE_SYSEMU and now continue with
+		 * PTRACE_SYSCALL, entry.S used to intercept the syscall return. But it
+		 * shouldn't!
+		 * So we don't clear TIF_SYSCALL_EMU, which is always unused in this
+		 * special case, to remember, we came from SYSEMU. That flag
+		 * will be cleared by do_syscall_trace().
+		 */
  		if (request == PTRACE_SYSEMU) {
  			set_tsk_thread_flag(child, TIF_SYSCALL_EMU);
-		}
-		else {
+		} else if (request == PTRACE_CONT) {
  			clear_tsk_thread_flag(child, TIF_SYSCALL_EMU);
  		}
  		if (request == PTRACE_SYSCALL) {
  			set_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
-		}
-		else {
+		} else {
  			clear_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
  		}
  		child->exit_code = data;
@@ -585,7 +590,7 @@ out:
  __attribute__((regparm(3)))
  int do_syscall_trace(struct pt_regs *regs, int entryexit)
  {
-	int is_sysemu;
+	int is_sysemu, is_systrace;
  	if (unlikely(current->audit_context)) {
  		if (!entryexit)
  			audit_syscall_entry(current, regs->orig_eax,
@@ -595,9 +600,19 @@ int do_syscall_trace(struct pt_regs *reg
  			audit_syscall_exit(current, regs->eax);
  	}
  	is_sysemu = test_thread_flag(TIF_SYSCALL_EMU);
+	is_systrace = test_thread_flag(TIF_SYSCALL_TRACE);

-	if (!test_thread_flag(TIF_SYSCALL_TRACE) && !is_sysemu)
+	if (!is_systrace && !is_sysemu)
  		return 0;
+	/* We can detect the case of coming from PTRACE_SYSEMU and now
+	 * running with PTRACE_SYSCALL, by TIF_SYSCALL_EMU being set
+	 * additionally.
+	 * If so let's reset the flag and return without action.
+	 */
+	if (is_sysemu && is_systrace) {
+		clear_thread_flag(TIF_SYSCALL_EMU);
+		return 0;
+	}
  	if (!(current->ptrace & PT_PTRACED))
  		return 0;
  	/* the 0x80 provides a way for the tracing parent to distinguish


-------------------------------------------------------
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: [patch 1/1] SYSEMU: avoid intercepting syscall on return when using SYSCALL again.

[BlaisorBlade]

On Friday 22 October 2004 11:22, Bodo Stroesser wrote:
> blaisorblade_spam@yahoo.it wrote:
> > From: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
> >
> > A guest process switching from using PTRACE_SYSEMU to PTRACE_SYSCALL
> > crashes.
> >
> > The problem is in arch/i386/kernel/entry.S. The current SYSEMU patch
> > inhibits the syscall-handler to be called, but does not prevent
> > do_syscall_trace to be called after this for syscall completion
> > interception.
> >
> > The appended patch fixes this. It reuses the flag TIF_SYSCALL_EMU to
> > remember "we come from PTRACE_SYSEMU and now are in PTRACE_SYSCALL",
> > since the flag is unused in the depicted situation.
> >
> > The patch is tested, AFAICS, it works fine, i.e. sysemu can be switched
> > on and off dynamically without crash.
> >
> > Bodo
> >
> > Signed-off-by: Paolo 'Blaisorblade' Giarrusso
> > <blaisorblade_spam@yahoo.it> ---
>
> Fine idea to move one part of the patch to sys_ptrace()!
> But maybe you missed to reset TIF_SYSCALL_EMU while resuming with
> PTRACE_CONT? Here is a revised patch.
Yes - I forgot it. Does the revised version work? My version did not - it 
failed the startup test. In fact, PTRACE_CONT is called in the startup test 
(which fails). I'm recompiling and testing.

Thanks again.
-- 
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: [patch 1/1] SYSEMU: avoid intercepting syscall on return when using SYSCALL again.

[Bodo Stroesser]

BlaisorBlade wrote:
> On Friday 22 October 2004 11:22, Bodo Stroesser wrote:
> 
>>blaisorblade_spam@yahoo.it wrote:
>>
>>>From: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
>>>
>>>A guest process switching from using PTRACE_SYSEMU to PTRACE_SYSCALL
>>>crashes.
>>>
>>>The problem is in arch/i386/kernel/entry.S. The current SYSEMU patch
>>>inhibits the syscall-handler to be called, but does not prevent
>>>do_syscall_trace to be called after this for syscall completion
>>>interception.
>>>
>>>The appended patch fixes this. It reuses the flag TIF_SYSCALL_EMU to
>>>remember "we come from PTRACE_SYSEMU and now are in PTRACE_SYSCALL",
>>>since the flag is unused in the depicted situation.
>>>
>>>The patch is tested, AFAICS, it works fine, i.e. sysemu can be switched
>>>on and off dynamically without crash.
>>>
>>>Bodo
>>>
>>>Signed-off-by: Paolo 'Blaisorblade' Giarrusso
>>><blaisorblade_spam@yahoo.it> ---
>>
>>Fine idea to move one part of the patch to sys_ptrace()!
>>But maybe you missed to reset TIF_SYSCALL_EMU while resuming with
>>PTRACE_CONT? Here is a revised patch.
> 
> Yes - I forgot it. Does the revised version work? My version did not - it 
> failed the startup test. In fact, PTRACE_CONT is called in the startup test 
> (which fails). I'm recompiling and testing.
Yes. My system works very fine with it.

Regards
> 
> Thanks again.



-------------------------------------------------------
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: [patch 1/1] SYSEMU: avoid intercepting syscall on return when using SYSCALL again.

[Bodo Stroesser]

Bodo Stroesser wrote:
> BlaisorBlade wrote:
> 
>> Yes - I forgot it. Does the revised version work? My version did not - 
>> it failed the startup test. In fact, PTRACE_CONT is called in the 
>> startup test (which fails). I'm recompiling and testing.
> 
> Yes. My system works very fine with it.
Now I've tested with host 2.6.9 and skas3.v6 patch. I adapted my latest
patch and had problems with singlestepping on UML in SKAS with sSYSEMU.
It looped receiving SIGTRAPs without moving forward. EIP of the traced
process was the same for all SIGTRAPs.
What's missing is to handle switching from PTRACE_SYSCALL_EMU to
PTRACE_SINGLESTEP in a way very similar to what is done for the change
from PTRACE_SYSCALL_EMU to PTRACE_SYSCALL_TRACE.

Here is the corresponding patch.

Bodo

P.S.: When testing UML 2.6.9 in SAKS on host 2.6.9, UML didn't terminate
after init 0. kernel-process and userspace-process didn't go out at the end.
ps aux shows S+ for kernel and T+ for userspace. I only could kill them with
kill -9 kernel-pid. After having done this, the host can't unmount its
filesystems: "in use". Doesn't that look like a host-bug?

---

--- a/arch/i386/kernel/ptrace.c	2004-10-27 10:13:55.515622561 +0200
+++ b/arch/i386/kernel/ptrace.c	2004-10-27 10:21:01.958150451 +0200
@@ -367,16 +367,21 @@ asmlinkage int sys_ptrace(long request,
  		ret = -EIO;
  		if ((unsigned long) data > _NSIG)
  			break;
+		/* If we came here with PTRACE_SYSEMU and now continue with
+		 * PTRACE_SYSCALL, entry.S used to intercept the syscall return. But it
+		 * shouldn't!
+		 * So we don't clear TIF_SYSCALL_EMU, which is always unused in this
+		 * special case, to remember, we came from SYSEMU. That flag
+		 * will be cleared by do_syscall_trace().
+		 */
  		if (request == PTRACE_SYSEMU) {
  			set_tsk_thread_flag(child, TIF_SYSCALL_EMU);
-		}
-		else {
+		} else if (request == PTRACE_CONT) {
  			clear_tsk_thread_flag(child, TIF_SYSCALL_EMU);
  		}
  		if (request == PTRACE_SYSCALL) {
  			set_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
-		}
-		else {
+		} else {
  			clear_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
  		}
  		clear_tsk_thread_flag(child, TIF_SINGLESTEP);
@@ -415,7 +420,6 @@ asmlinkage int sys_ptrace(long request,
  		ret = -EIO;
  		if ((unsigned long) data > _NSIG)
  			break;
-		clear_tsk_thread_flag(child, TIF_SYSCALL_EMU);
  		clear_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
  		if ((child->ptrace & PT_DTRACE) == 0) {
  			/* Spurious delayed TF traps may occur */
@@ -589,7 +593,7 @@ out:
  __attribute__((regparm(3)))
  int do_syscall_trace(struct pt_regs *regs, int entryexit)
  {
-	int is_sysemu;
+	int is_sysemu, is_systrace, is_singlestep;
  	if (unlikely(current->audit_context)) {
  		if (!entryexit)
  			audit_syscall_entry(current, regs->orig_eax,
@@ -599,17 +603,26 @@ int do_syscall_trace(struct pt_regs *reg
  			audit_syscall_exit(current, regs->eax);
  	}
  	is_sysemu = test_thread_flag(TIF_SYSCALL_EMU);
+	is_systrace = test_thread_flag(TIF_SYSCALL_TRACE);
+	is_singlestep = test_thread_flag(TIF_SINGLESTEP);

-	if (!test_thread_flag(TIF_SYSCALL_TRACE) &&
-	    !test_thread_flag(TIF_SINGLESTEP) &&
-	    !is_sysemu)
+	if (!is_systrace && !is_sysemu && !is_singlestep )
  		return 0;
+	/* We can detect the case of coming from PTRACE_SYSEMU and now
+	 * running with PTRACE_SYSCALL, by TIF_SYSCALL_EMU being set
+	 * additionally.
+	 * If so let's reset the flag and return without action.
+	 */
+	if (is_sysemu && (is_systrace || is_singlestep)) {
+		clear_thread_flag(TIF_SYSCALL_EMU);
+		return 0;
+	}
  	if (!(current->ptrace & PT_PTRACED))
  		return 0;
  	/* 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) &&
-				 !test_thread_flag(TIF_SINGLESTEP) ? 0x80 : 0));
+				 !is_singlestep ? 0x80 : 0));

  	/*
  	 * this isn't the same as continuing with a signal, but it will do


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
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: [patch 1/1] SYSEMU: avoid intercepting syscall on return when using SYSCALL again.

[Blaisorblade]

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

On Wednesday 27 October 2004 16:21, Bodo Stroesser wrote:
> Bodo Stroesser wrote:
> > BlaisorBlade wrote:
> >> Yes - I forgot it. Does the revised version work? My version did not -
> >> it failed the startup test. In fact, PTRACE_CONT is called in the
> >> startup test (which fails). I'm recompiling and testing.

> > Yes. My system works very fine with it.

> Now I've tested with host 2.6.9 and skas3.v6 patch. I adapted my latest
> patch and had problems with singlestepping on UML in SKAS with sSYSEMU.
> It looped receiving SIGTRAPs without moving forward. EIP of the traced
> process was the same for all SIGTRAPs.

> What's missing is to handle switching from PTRACE_SYSCALL_EMU to
> PTRACE_SINGLESTEP in a way very similar to what is done for the change
> from PTRACE_SYSCALL_EMU to PTRACE_SYSCALL_TRACE.

> Here is the corresponding patch.

Ok, I separated it from the other one.

> P.S.: When testing UML 2.6.9 in SAKS on host 2.6.9, UML didn't terminate
> after init 0. kernel-process and userspace-process didn't go out at the
> end. ps aux shows S+ for kernel and T+ for userspace. I only could kill
> them with kill -9 kernel-pid. After having done this, the host can't
> unmount its filesystems: "in use". Doesn't that look like a host-bug?

No, simply UML should use PTRACE_KILL rather than sending SIGKILL itself. It 
always just *happened* to work.

I was just about to release -v7 - I'll hold on it a bit more to include your 
fix. Then I'll do releases for 2.6.7 and 2.6.9.

> --- a/arch/i386/kernel/ptrace.c 2004-10-27 10:13:55.515622561 +0200
> +++ b/arch/i386/kernel/ptrace.c 2004-10-27 10:21:01.958150451 +0200
> @@ -367,16 +367,21 @@ asmlinkage int sys_ptrace(long request,
>     ret = -EIO;
>     if ((unsigned long) data > _NSIG)
>      break;
> +  /* If we came here with PTRACE_SYSEMU and now continue with
> +   * PTRACE_SYSCALL, entry.S used to intercept the syscall return. But it
> +   * shouldn't!
> +   * So we don't clear TIF_SYSCALL_EMU, which is always unused in this
> +   * special case, to remember, we came from SYSEMU. That flag
> +   * will be cleared by do_syscall_trace().
> +   */

I updated this comment. Also, I'm thinking to the PTRACE_CONT case: shouldn't 
it get the same special treatment? Ok, probably not, because I guess we won't 
be running do_syscall_trace in that case. After that, it seems there is no 
other way to wake up a process, right? If there is anything else, then we 
need to fix that, too.

I have idea we need something more robust, i.e. a return path avoiding 
altogether the 2nd do_syscall_trace call, like it happened in 2.4.

Now, My Mighty Bodo, after cleaning up the issues about collecting your 
patches, could you try to understand also why strace does not work with 
SYSEMU on? Even switching SYSEMU off through /proc/sysemu avoids that. It 
seems to be a guest-only problem, since the UML debugger code seems totally 
unrelated to the syscall interception on the host.

Also, something strange is that when not enabling network support, strace 
printed out some network syscalls, with bogus return values, even with SYSEMU 
active.

Bye and thanks again!
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729

[-- Attachment #2: fix-singlestep-after-sysemu.patch --]
[-- Type: text/x-diff, Size: 3503 bytes --]


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

When testing 2.6.9 and the skas3.v6 patch, with my latest
patch and had problems with singlestepping on UML in SKAS with SYSEMU.
It looped receiving SIGTRAPs without moving forward. EIP of the traced
process was the same for all SIGTRAPs.

What's missing is to handle switching from PTRACE_SYSCALL_EMU to
PTRACE_SINGLESTEP in a way very similar to what is done for the change
from PTRACE_SYSCALL_EMU to PTRACE_SYSCALL_TRACE.

I.e., after calling ptrace(PTRACE_SYSEMU), on the return path, the debugger is
notified and then wake ups the process; the syscall is executed (or skipped,
when do_syscall_trace returns 0, i.e. when using PTRACE_SYSEMU), and
do_syscall_trace is called again. Since we are on the return path of a
SYSEMU'd syscall, if the wake up is performed through ptrace(PTRACE_SYSCALL),
we must still avoid notifying the parent of the syscall exit. Now, this
behaviour is extended even to resuming with PTRACE_SINGLESTEP.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade_spam@yahoo.it>
---

 vanilla-linux-2.6.9-paolo/arch/i386/kernel/ptrace.c |   20 ++++++++++----------
 1 files changed, 10 insertions(+), 10 deletions(-)

diff -puN arch/i386/kernel/ptrace.c~fix-singlestep-after-sysemu arch/i386/kernel/ptrace.c
--- vanilla-linux-2.6.9/arch/i386/kernel/ptrace.c~fix-singlestep-after-sysemu	2004-10-29 00:43:51.000000000 +0200
+++ vanilla-linux-2.6.9-paolo/arch/i386/kernel/ptrace.c	2004-10-29 00:52:30.744281064 +0200
@@ -419,7 +419,8 @@ asmlinkage int sys_ptrace(long request, 
 		ret = -EIO;
 		if ((unsigned long) data > _NSIG)
 			break;
-		clear_tsk_thread_flag(child, TIF_SYSCALL_EMU);
+		/*See do_syscall_trace to know why we don't clear
+		 * TIF_SYSCALL_EMU.*/
 		clear_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
 		if ((child->ptrace & PT_DTRACE) == 0) {
 			/* Spurious delayed TF traps may occur */
@@ -543,7 +544,7 @@ out:
 __attribute__((regparm(3)))
 int do_syscall_trace(struct pt_regs *regs, int entryexit)
 {
-	int is_sysemu, is_systrace;
+	int is_sysemu, is_systrace, is_singlestep;
 	if (unlikely(current->audit_context)) {
 		if (!entryexit)
 			audit_syscall_entry(current, regs->orig_eax,
@@ -554,17 +555,16 @@ int do_syscall_trace(struct pt_regs *reg
 	}
 	is_sysemu = test_thread_flag(TIF_SYSCALL_EMU);
 	is_systrace = test_thread_flag(TIF_SYSCALL_TRACE);
+	is_singlestep = test_thread_flag(TIF_SINGLESTEP);
 
-	if (!is_systrace &&
-	    !test_thread_flag(TIF_SINGLESTEP) &&
-	    !is_sysemu)
+	if (!is_systrace && !is_singlestep && !is_sysemu)
 		return 0;
-	/* We can detect the case of coming from PTRACE_SYSEMU and now
-	 * running with PTRACE_SYSCALL, by TIF_SYSCALL_EMU being set
-	 * additionally.
+	/* We can detect the case of coming from PTRACE_SYSEMU and now running
+	 * with PTRACE_SYSCALL or PTRACE_SINGLESTEP, by TIF_SYSCALL_EMU being
+	 * set additionally.
 	 * If so let's reset the flag and return without action.
 	 */
-	if (is_sysemu && is_systrace) {
+	if (is_sysemu && (is_systrace || is_singlestep)) {
 		clear_thread_flag(TIF_SYSCALL_EMU);
 		return 0;
 	}
@@ -573,7 +573,7 @@ int do_syscall_trace(struct pt_regs *reg
 	/* 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) &&
-				 !test_thread_flag(TIF_SINGLESTEP) ? 0x80 : 0));
+				 !is_singlestep ? 0x80 : 0));
 
 	/*
 	 * this isn't the same as continuing with a signal, but it will do
_

Re: [uml-devel] Re: [patch 1/1] SYSEMU: avoid intercepting syscall on return when using SYSCALL again.

[Bodo Stroesser]

Blaisorblade wrote:
> On Wednesday 27 October 2004 16:21, Bodo Stroesser wrote:
> 
>>Bodo Stroesser wrote:
>>
>>>BlaisorBlade wrote:
>>>
>>>>Yes - I forgot it. Does the revised version work? My version did not -
>>>>it failed the startup test. In fact, PTRACE_CONT is called in the
>>>>startup test (which fails). I'm recompiling and testing.
> 
> 
>>>Yes. My system works very fine with it.
> No, simply UML should use PTRACE_KILL rather than sending SIGKILL itself. It 
> always just *happened* to work.
But why can't the host's filesystem be unmounted ("Is in use"), even if
the UML-Processes were killed?

> 
> I was just about to release -v7 - I'll hold on it a bit more to include your 
> fix. Then I'll do releases for 2.6.7 and 2.6.9.
Year. But in November we hhave to talk again! Sysemu is still dangerous.
If SKAS will support SMP, no one can guarantee, that the code of a UML-process
isn't modified between "is_syscall()" and ptrace(PTRACE_SINGLESTEP, ...).
What we really need is an option for PTRACE_SYSEMU, that lets it stop
for Singlestep AND syscall-trace. Example:
	ptrace( PTRACE_SYSEMU, pid, (void *)PTRACE_SINGLESTEP, 0)
Then no more opcode-reading / checking will be needed.
> 
> I have idea we need something more robust, i.e. a return path avoiding 
> altogether the 2nd do_syscall_trace call, like it happened in 2.4.
Think, the current solution is robust. But let me know, if you find a
way to knock it out.
> 
> Now, My Mighty Bodo, after cleaning up the issues about collecting your 
> patches, could you try to understand also why strace does not work with 
> SYSEMU on? Even switching SYSEMU off through /proc/sysemu avoids that. It 
> seems to be a guest-only problem, since the UML debugger code seems totally 
> unrelated to the syscall interception on the host.
> 
> Also, something strange is that when not enabling network support, strace 
> printed out some network syscalls, with bogus return values, even with SYSEMU 
> active.
Do you talk about strace'ing the kernel?
Or do you talk about the debugger problem, Lorenzo has?

For his problem, I have an idea: writing my tests for Jeff, I saw SIGCHLD being
masked by default! No SIGCHLD, no debugging ?!

Regards
Bodo


-------------------------------------------------------
This Newsletter Sponsored by: Macrovision 
For reliable Linux application installations, use the industry's leading
setup authoring tool, InstallShield X. Learn more and evaluate 
today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/
_______________________________________________
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: [patch 1/1] SYSEMU: avoid intercepting syscall on return when using SYSCALL again.

[Bodo Stroesser]

Blaisorblade wrote:
> No. Just strace any process inside UML. Let's "strace ls". Last time I 
> checked, it does not work. Oh hell! It works (as of 2.6.9)! Well, you already 
> fixed that.
> 
No. Here you are wrong. The problem is still there (or is it again there?).
Sorry.

My latest patch "patch-singlestep-sighdlr" has been too complete!
Setting TIF_SIGPENDING after ptrace_notify() in syscall_trace() in neccessary
only on the 2nd tracepoint (entryexit == 1).
And setting it on the 1st tracepoint lets some specific systemcalls loop.
Example: sys_rt_sigaction() wants to be called without SIGPENDING. Thus it returns
with -ERESTARTNOINTR. On return do_signal() is called, which resets TIF_SIGPENDING
and sets EIP back to the syscall. Now the syscall starts, runs through
syscall_trace() and TIF_SIGPENDING is set again. Now it returns with -ERESTARTNOINTR
...
...

Here's the patch:

---

--- a/arch/um/kernel/ptrace.c	2004-10-29 02:27:42.000000000 +0200
+++ b/arch/um/kernel/ptrace.c	2004-10-29 02:28:24.000000000 +0200
@@ -330,7 +330,8 @@ void syscall_trace(union uml_pt_regs *re
  	   between a syscall stop and SIGTRAP delivery */
  	ptrace_notify(SIGTRAP | (((current->ptrace & PT_TRACESYSGOOD) &&
  				 !is_singlestep) ? SYSCALL_TRAP : 0));
-	set_thread_flag(TIF_SIGPENDING); /* force do_signal() --> is_syscall() */
+	if ( entryexit ) /* force do_signal() --> is_syscall() */
+		set_thread_flag(TIF_SIGPENDING);

  	/*
  	 * this isn't the same as continuing with a signal, but it will do



-------------------------------------------------------
This Newsletter Sponsored by: Macrovision 
For reliable Linux application installations, use the industry's leading
setup authoring tool, InstallShield X. Learn more and evaluate 
today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/
_______________________________________________
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: [patch 1/1] SYSEMU: avoid intercepting syscall on return when using SYSCALL again.

[Gerd Knorr]

> Here's the patch:

Hmm, your mailer seems to mangle whitespaces, I often can apply your
patches mailed inline with "patch -l" only (the mime attached ones are
fine).

Two small fixes I need in the big stack of patches i have now to
build kernels successfully.  The first is a simple missing include:

==============================[ cut here ]==============================
--- linux-uml-2.6.9.orig/arch/um/os-Linux/signal.c	2004-10-28 20:11:02.757586671 +0200
+++ linux-uml-2.6.9/arch/um/os-Linux/signal.c	2004-10-28 20:23:32.730183963 +0200
@@ -6,6 +6,7 @@
 #include <signal.h>
 #include "time_user.h"
 #include "mode.h"
+#include "choose-mode.h"
 #include "sysdep/signal.h"
 
 void sig_handler(int sig)
==============================[ cut here ]==============================

The second one is a fixup for the host-skas3 patch.  That one is needed
if you use one source tree for both host and uml builds.  Without that
fixup the host-skas3 patch breaks uml kernel builds (and also all other
architectures as only i386 has sysemu right now ...).

==============================[ cut here ]==============================
--- uml-2.6.9-rc2.orig/arch/um/include/skas_ptrace.h	2004-09-16 16:10:16.000000000 +0200
+++ uml-2.6.9-rc2/arch/um/include/skas_ptrace.h	2004-09-16 16:10:24.000000000 +0200
@@ -6,6 +6,7 @@
 #ifndef __SKAS_PTRACE_H
 #define __SKAS_PTRACE_H
 
+#ifndef PTRACE_FAULTINFO
 struct ptrace_faultinfo {
 	int is_write;
 	unsigned long addr;
@@ -21,6 +22,7 @@ struct ptrace_ldt {
 #define PTRACE_SIGPENDING 53
 #define PTRACE_LDT 54
 #define PTRACE_SWITCH_MM 55
+#endif
 
 #endif
 
--- uml-2.6.9-rc2.orig/kernel/fork.c	2004-09-16 16:10:21.000000000 +0200
+++ uml-2.6.9-rc2/kernel/fork.c	2004-09-16 16:12:40.000000000 +0200
@@ -1038,7 +1038,9 @@ static task_t *copy_process(unsigned lon
 	 * of CLONE_PTRACE.
 	 */
 	clear_tsk_thread_flag(p, TIF_SYSCALL_TRACE);
+#ifdef TIF_SYSCALL_EMU
 	clear_tsk_thread_flag(p, TIF_SYSCALL_EMU);
+#endif
 
 	/* Our parent execution domain becomes current domain
 	   These must match for thread signalling to apply */
==============================[ cut here ]==============================

It's kida quick&dirty, the real fix probably would be to have the skas
ptrace stuff in *one* place, guess that isn't going to happen before
skas is merged mainline through.  Whats the status on skas4 btw.?

  Gerd



-------------------------------------------------------
This Newsletter Sponsored by: Macrovision 
For reliable Linux application installations, use the industry's leading
setup authoring tool, InstallShield X. Learn more and evaluate 
today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/
_______________________________________________
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: [patch 1/1] SYSEMU: avoid intercepting syscall on return when using SYSCALL again.

[Blaisorblade]

On Friday 29 October 2004 09:51, Gerd Knorr wrote:
> > Here's the patch:
>
> Hmm, your mailer seems to mangle whitespaces, I often can apply your
> patches mailed inline with "patch -l" only (the mime attached ones are
> fine).
>
> Two small fixes I need in the big stack of patches i have now to
> build kernels successfully.  The first is a simple missing include:

> ==============================[ cut here ]==============================
> --- linux-uml-2.6.9.orig/arch/um/os-Linux/signal.c 2004-10-28
> 20:11:02.757586671 +0200 +++
> linux-uml-2.6.9/arch/um/os-Linux/signal.c 2004-10-28 20:23:32.730183963
> +0200 @@ -6,6 +6,7 @@
>  #include <signal.h>
>  #include "time_user.h"
>  #include "mode.h"
> +#include "choose-mode.h"
>  #include "sysdep/signal.h"
I'll make sure that is in.

>  void sig_handler(int sig)
> ==============================[ cut here ]==============================
>
> The second one is a fixup for the host-skas3 patch.  That one is needed
> if you use one source tree for both host and uml builds.  Without that
> fixup the host-skas3 patch breaks uml kernel builds (and also all other
> architectures as only i386 has sysemu right now ...).
Yes, I saw it in your tree. I'm including that in -v7 (I'm holding a bit on 
that to see if any other bug is found).


> It's kida quick&dirty, the real fix probably would be to have the skas
> ptrace stuff in *one* place, guess that isn't going to happen before
> skas is merged mainline through.  Whats the status on skas4 btw.?
See Jeff's diary. He has started again working on that, quite unsuccessfully 
however. If you want to look at the code, you can find it inside the UML 
amd64 patch for 2.6.4 (mm_indirect() is more or less supported for both i386 
and UML).

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



-------------------------------------------------------
This Newsletter Sponsored by: Macrovision 
For reliable Linux application installations, use the industry's leading
setup authoring tool, InstallShield X. Learn more and evaluate 
today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel