[uml-devel] [PATCH] RFC allow PTRACE_SYSCALL to selectively skip syscalls

[uml-devel] [PATCH] RFC allow PTRACE_SYSCALL to selectively skip syscalls

[Steven James]

Greetings,

I have been working on a few experimental system calls using a ptrace
mechanism similar to UML to implement the calls. Naturally this lead me to
look at PTRACE_SYSEMU vs. PTRACE_SYSCALL. Since the extra system calls are
implemented entirely by the ptrace thread it seems a shame to take the
context switch on entry and exit from the call. In some cases, I need to
also implement a few of the standard Linux kernel calls in the ptrace
thread as well, based on parameters of the call (for example, writes to
specific open files).

The patch below for x86_64 implements a scheme where a ptraced system call
is skipped if the ptrace thread sets a return value (in RAX) when it
handles the syscall entry. Otherwise things proceed normally.

A similar change is even easier on i386 since the needed logic is already
in entry.S for SYSEMU.

I chose changing RAX as the trigger since that is otherwise a useless
thing for a tracing thread to do at syscall entry.

G'day,
sjames


||||| |||| |||||||||||||  |||
by Linux Labs International, Inc.
   Steven James, CTO

55 Marietta Street
Suite 1830
Atlanta, Ga 30303
866 824 9737 support



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
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] RFC allow PTRACE_SYSCALL to selectively skip syscalls

[Jeff Dike]

On Sat, May 13, 2006 at 01:40:48PM -0400, Steven James wrote:
> The patch below for x86_64 implements a scheme where a ptraced system call
> is skipped if the ptrace thread sets a return value (in RAX) when it
> handles the syscall entry. Otherwise things proceed normally.

Ummmm, so where's the patch?

				Jeff


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
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] RFC allow PTRACE_SYSCALL to selectively skip syscalls

[Steven James]

On Tue, 16 May 2006, Jeff Dike wrote:

> On Sat, May 13, 2006 at 01:40:48PM -0400, Steven James wrote:
> > The patch below for x86_64 implements a scheme where a ptraced system call
>
> Ummmm, so where's the patch?
>

I suppose it WOULD help to actually send it:

diff -urN linux-2.6.12.2-nimbus1/arch/x86_64/kernel/entry.S linux-2.6.12.2-nimbus2/arch/x86_64/kernel/entry.S
--- linux-2.6.12.2-nimbus1/arch/x86_64/kernel/entry.S	2005-09-12 18:04:26.000000000 -0400
+++ linux-2.6.12.2-nimbus2/arch/x86_64/kernel/entry.S	2006-05-10 17:46:15.000000000 -0400
@@ -241,6 +241,8 @@
 	FIXUP_TOP_OF_STACK %rdi
 	movq %rsp,%rdi
 	call syscall_trace_enter
+	cmpq $0, %rax
+	jne 2f
 	LOAD_ARGS ARGOFFSET  /* reload args from stack in case ptrace changed it */
 	RESTORE_REST
 	cmpq $__NR_syscall_max,%rax
@@ -251,6 +253,7 @@
 1:	SAVE_REST
 	movq %rsp,%rdi
 	call syscall_trace_leave
+2:
 	RESTORE_TOP_OF_STACK %rbx
 	RESTORE_REST
 	jmp ret_from_sys_call
diff -urN linux-2.6.12.2-nimbus1/arch/x86_64/kernel/ptrace.c linux-2.6.12.2-nimbus2/arch/x86_64/kernel/ptrace.c
--- linux-2.6.12.2-nimbus1/arch/x86_64/kernel/ptrace.c	2005-09-12 18:04:26.000000000 -0400
+++ linux-2.6.12.2-nimbus2/arch/x86_64/kernel/ptrace.c	2006-05-10 17:50:35.000000000 -0400
@@ -623,7 +623,7 @@
 }
 EXPORT_SYMBOL_GPL(sys_ptrace);

-static void syscall_trace(struct pt_regs *regs)
+static long syscall_trace(struct pt_regs *regs)
 {

 #if 0
@@ -644,16 +644,24 @@
 		send_sig(current->exit_code, current, 1);
 		current->exit_code = 0;
 	}
+	if(regs->rax != -ENOSYS)
+		return 1;
+
+	return 0;
 }

-asmlinkage void syscall_trace_enter(struct pt_regs *regs)
+asmlinkage long syscall_trace_enter(struct pt_regs *regs)
 {
+	long	res=0;
 	/* do the secure computing check first */
 	secure_computing(regs->orig_rax);

 	if (test_thread_flag(TIF_SYSCALL_TRACE)
 	    && (current->ptrace & PT_PTRACED))
-		syscall_trace(regs);
+		res = syscall_trace(regs);
+
+	if(res)
+		return res;

 	if (unlikely(current->audit_context)) {
 		if (test_thread_flag(TIF_IA32)) {
@@ -668,6 +676,7 @@
 					    regs->rdx, regs->r10);
 		}
 	}
+	return res;
 }

 asmlinkage void syscall_trace_leave(struct pt_regs *regs)

||||| |||| |||||||||||||  |||
by Linux Labs International, Inc.
   Steven James, CTO

55 Marietta Street
Suite 1830
Atlanta, Ga 30303
866 824 9737 support



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
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] RFC allow PTRACE_SYSCALL to selectively skip syscalls

[Blaisorblade]

On Saturday 13 May 2006 19:40, Steven James wrote:
> Greetings,
>
> I have been working on a few experimental system calls using a ptrace
> mechanism similar to UML to implement the calls. Naturally this lead me to
> look at PTRACE_SYSEMU vs. PTRACE_SYSCALL. Since the extra system calls are
> implemented entirely by the ptrace thread it seems a shame to take the
> context switch on entry and exit from the call. In some cases, I need to
> also implement a few of the standard Linux kernel calls in the ptrace
> thread as well, based on parameters of the call (for example, writes to
> specific open files).
>
> The patch below for x86_64 implements a scheme where a ptraced system call
> is skipped if the ptrace thread sets a return value (in RAX) when it
> handles the syscall entry. Otherwise things proceed normally.

Just to make things clearer: is this a different API than SYSEMU to do the 
same thing, as it seems? If so, is it faster by any way, or just more elegant 
in your opinion, or what? I think it's as fast as SYSEMU since you must 
switch to the tracer on the syscall entry, look at params, set the result and 
switch back with a ptrace call, with PTRACE_SYSEMU in my case, with 
PTRACE_SYSCALL (?) in your case.

The current problem with PTRACE_SYSEMU is that you decide whether you'll skip 
the syscall before looking at parameters (other people have already 
complained about this). If this is the problem you have, I'll recover the 
past discussions and let you know.

> A similar change is even easier on i386 since the needed logic is already
> in entry.S for SYSEMU.
>
> I chose changing RAX as the trigger since that is otherwise a useless
> thing for a tracing thread to do at syscall entry.

What if the tracing thread must set -ENOSYS as the return value?
@@ -644,16 +644,24 @@
                send_sig(current->exit_code, current, 1);
                current->exit_code = 0;
        }
+       if(regs->rax != -ENOSYS)
+               return 1;
+
+       return 0;
 }
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
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] RFC allow PTRACE_SYSCALL to selectively skip syscalls

[Steven James]

On Wed, 17 May 2006, Blaisorblade wrote:

> On Saturday 13 May 2006 19:40, Steven James wrote:
> > Greetings,
> >
> > I have been working on a few experimental system calls using a ptrace
> > mechanism similar to UML to implement the calls. Naturally this lead me to
> > look at PTRACE_SYSEMU vs. PTRACE_SYSCALL. Since the extra system calls are
> > implemented entirely by the ptrace thread it seems a shame to take the
> > context switch on entry and exit from the call. In some cases, I need to
> > also implement a few of the standard Linux kernel calls in the ptrace
> > thread as well, based on parameters of the call (for example, writes to
> > specific open files).
> >
> > The patch below for x86_64 implements a scheme where a ptraced system call
> > is skipped if the ptrace thread sets a return value (in RAX) when it
> > handles the syscall entry. Otherwise things proceed normally.
>
> Just to make things clearer: is this a different API than SYSEMU to do the
> same thing, as it seems? If so, is it faster by any way, or just more elegant
> in your opinion, or what? I think it's as fast as SYSEMU since you must
> switch to the tracer on the syscall entry, look at params, set the result and
> switch back with a ptrace call, with PTRACE_SYSEMU in my case, with
> PTRACE_SYSCALL (?) in your case.

It's no faster than SYSEMU and it's not necessarily any more elegant.

>
> The current problem with PTRACE_SYSEMU is that you decide whether you'll skip
> the syscall before looking at parameters (other people have already
> complained about this). If this is the problem you have, I'll recover the
> past discussions and let you know.

That's exactly the problem I had. The emulator can't decide if it wants to
handle the call itself or let the Linux kernel do it until it knows what
syscall it is and in some cases the parameters.

My objective in the patch was to fix that with minimal changes to the
kernel. I did x86_64 first because I had one that was more convieniant for
me to reboot at the time :-)

>
> > A similar change is even easier on i386 since the needed logic is already
> > in entry.S for SYSEMU.
> >
> > I chose changing RAX as the trigger since that is otherwise a useless
> > thing for a tracing thread to do at syscall entry.
>
> What if the tracing thread must set -ENOSYS as the return value?

That's a flaw in the way I'm doing it. I would have to change orig_rax to
an invalid syscall number and take the extra context switches.

An alternative would be to either add yet another process flag that is
checked after the ptrace_notify in (do_)syscall_trace or change the
behaviour of TIF_SYSCALL_EMU by checking it after ptrace_notify.


> @@ -644,16 +644,24 @@
>                 send_sig(current->exit_code, current, 1);
>                 current->exit_code = 0;
>         }
> +       if(regs->rax != -ENOSYS)
> +               return 1;
> +
> +       return 0;
>  }
> --
> Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
> Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
> http://www.user-mode-linux.org/~blaisorblade
>
>
>
>
>
> ___________________________________
> Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
> http://mail.yahoo.it
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> User-mode-linux-devel mailing list
> User-mode-linux-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
>

||||| |||| |||||||||||||  |||
by Linux Labs International, Inc.
   Steven James, CTO

55 Marietta Street
Suite 1830
Atlanta, Ga 30303
866 824 9737 support



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
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] RFC allow PTRACE_SYSCALL to selectively skip syscalls

[Blaisorblade]

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

On Wednesday 17 May 2006 16:45, Steven James wrote:
> On Wed, 17 May 2006, Blaisorblade wrote:
> > On Saturday 13 May 2006 19:40, Steven James wrote:
> > > Greetings,
> > >
> > > I have been working on a few experimental system calls using a ptrace
> > > mechanism similar to UML to implement the calls. Naturally this lead me
> > > to look at PTRACE_SYSEMU vs. PTRACE_SYSCALL. Since the extra system
> > > calls are implemented entirely by the ptrace thread it seems a shame to
> > > take the context switch on entry and exit from the call. In some cases,
> > > I need to also implement a few of the standard Linux kernel calls in
> > > the ptrace thread as well, based on parameters of the call (for
> > > example, writes to specific open files).
> > >
> > > The patch below for x86_64 implements a scheme where a ptraced system
> > > call is skipped if the ptrace thread sets a return value (in RAX) when
> > > it handles the syscall entry. Otherwise things proceed normally.

> > Just to make things clearer: is this a different API than SYSEMU to do
> > the same thing, as it seems? If so, is it faster by any way, or just more
> > elegant in your opinion, or what? I think it's as fast as SYSEMU since
> > you must switch to the tracer on the syscall entry, look at params, set
> > the result and switch back with a ptrace call, with PTRACE_SYSEMU in my
> > case, with PTRACE_SYSCALL (?) in your case.

> It's no faster than SYSEMU and it's not necessarily any more elegant.

Ok

> > The current problem with PTRACE_SYSEMU is that you decide whether you'll
> > skip the syscall before looking at parameters (other people have already
> > complained about this). If this is the problem you have, I'll recover the
> > past discussions and let you know.

> That's exactly the problem I had. The emulator can't decide if it wants to
> handle the call itself or let the Linux kernel do it until it knows what
> syscall it is and in some cases the parameters.

> My objective in the patch was to fix that with minimal changes to the
> kernel. I did x86_64 first because I had one that was more convieniant for
> me to reboot at the time :-)

Fine then.

> > > A similar change is even easier on i386 since the needed logic is
> > > already in entry.S for SYSEMU.
> > >
> > > I chose changing RAX as the trigger since that is otherwise a useless
> > > thing for a tracing thread to do at syscall entry.

> > What if the tracing thread must set -ENOSYS as the return value?

> That's a flaw in the way I'm doing it. I would have to change orig_rax to
> an invalid syscall number

or getpid(),as we do (dunno whether it makes any difference; but you're sure 
getpid is getpid, while an invalid number may become valid).

> and take the extra context switches. 

> An alternative would be to either add yet another process flag that is
> checked after the ptrace_notify in (do_)syscall_trace or change the
> behaviour of TIF_SYSCALL_EMU by checking it after ptrace_notify.

That is more or less my idea, however I've not had the time to work on it. 
Instead of changing the semantics we must add another option - I thought to 
use a ptrace option (the ones you set with PTRACE_SETOPTIONS), Charles Wright 
coded instead a PTRACE_CHECKEMU, but this is the concept.

So, I'm going to forward you the emails containing two patches:
*) PTRACE_CHECKEMU from Charles Wright
*) PTRACE_SYSCALL_MASK - to make the debugger be notified only of some 
syscalls; the only check is via syscall number though. It's unrelated to this 
but probably useful to you.

And I'm attaching my original version of the PTRACE_CHECKEMU thing 
> > @@ -644,16 +644,24 @@
> >                 send_sig(current->exit_code, current, 1);
> >                 current->exit_code = 0;
> >         }
> > +       if(regs->rax != -ENOSYS)
> > +               return 1;
> > +
> > +       return 0;
> >  }

-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

[-- Attachment #2: sysemu-new-interface --]
[-- Type: text/x-diff, Size: 4047 bytes --]

[RFC] SYSEMU: new more powerful behaviour

The current behaviour of SYSEMU allows switching between SYSEMU and SYSTRACE,
but the kind of performed tracing must be decided before allowing the process to
start a syscall.

Charles P. Wright expressed interest in "conditional emulation", i.e. he is
writing a filesystem emulator which needs to fully emulate only some syscalls (I
guess the filesystem-related ones, more or less).

Due to the current API, this cannot exploit the SYSEMU faster API.

What happens:
a) the process starts a syscall
b) the ptracer is resumed
c) it reads the syscall number and params, possibly modifies them (in UML, this
is used to avoid syscall execution, when SYSEMU is not available), and then
resumes the process
d) depending on the state at step a), the syscall is either skipped totally, or
it is executed, leading to another ptracer resumption at the end moment.

What Charles would need:
a), b) and c): the same thing
d) the syscall is executed or skipped depending not on the state at step a), but
on the resumption command used at step c, after examining the syscall type.

It turns out that the following simple patch should implement his idea.
I've added a new ptrace option for the desired behaviour.

The current one is left unaltered, for UML use - switching to the new one would
leave existing binaries unsupported and, for UML, using the new API would need
careful testing for some edge cases (especially singlestepping) for some
details.

Testing is currently needed. I'd like to get a simple test program which uses
the syscall, but I've not right now the time to support this.

CC: Charles P. Wright <cwright@cs.sunysb.edu>
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Index: linux-2.6.git/arch/i386/kernel/ptrace.c
===================================================================
--- linux-2.6.git.orig/arch/i386/kernel/ptrace.c
+++ linux-2.6.git/arch/i386/kernel/ptrace.c
@@ -779,6 +779,12 @@ int do_syscall_trace(struct pt_regs *reg
 		current->exit_code = 0;
 	}
 	ret = is_sysemu;
+	// XXX: fix name
+	if (current->ptrace & PT_SYSEMU_CHOICE) {
+		/* The debugger might have changed the syscall intercepting mode. Apply
+		 * this update now, rather than at next syscall. */
+		ret = test_thread_flag(TIF_SYSCALL_EMU);
+	}
 out:
 	if (unlikely(current->audit_context) && !entryexit)
 		audit_syscall_entry(current, AUDIT_ARCH_I386, regs->orig_eax,
Index: linux-2.6.git/include/linux/ptrace.h
===================================================================
--- linux-2.6.git.orig/include/linux/ptrace.h
+++ linux-2.6.git/include/linux/ptrace.h
@@ -35,8 +35,10 @@
 #define PTRACE_O_TRACEEXEC	0x00000010
 #define PTRACE_O_TRACEVFORKDONE	0x00000020
 #define PTRACE_O_TRACEEXIT	0x00000040
+#define PTRACE_O_SYSEMUCHOICE	0x00000080
 
-#define PTRACE_O_MASK		0x0000007f
+/* Mask of valid codes - all the above must be or'ed here. */
+#define PTRACE_O_MASK		0x000000ff
 
 /* Wait extended result codes for the above trace options.  */
 #define PTRACE_EVENT_FORK	1
@@ -64,8 +66,14 @@
 #define PT_TRACE_VFORK_DONE	0x00000100
 #define PT_TRACE_EXIT	0x00000200
 #define PT_ATTACHED	0x00000400	/* parent != real_parent */
+#define PT_SYSEMU_CHOICE	0x00000800
 
-#define PT_TRACE_MASK	0x000003f4
+#if 0
+#define PT_TRACE_MASK	0x00000bf4
+#endif
+/* All options flags - to be cleared when using setoptions. */
+#define PT_TRACE_MASK	(PT_TRACESYSGOOD|PT_TRACE_FORK|PT_TRACE_VFORK|PT_TRACE_CLONE| \
+		PT_TRACE_EXEC|PT_TRACE_VFORK_DONE|PT_TRACE_EXIT)
 
 /* single stepping state bits (used on ARM and PA-RISC) */
 #define PT_SINGLESTEP_BIT	31
Index: linux-2.6.git/kernel/ptrace.c
===================================================================
--- linux-2.6.git.orig/kernel/ptrace.c
+++ linux-2.6.git/kernel/ptrace.c
@@ -339,6 +339,9 @@ static int ptrace_setoptions(struct task
 	if (data & PTRACE_O_TRACEEXIT)
 		child->ptrace |= PT_TRACE_EXIT;
 
+	if (data & PTRACE_O_SYSEMUCHOICE)
+		child->ptrace |= PT_SYSEMU_CHOICE;
+
 	return (data & ~PTRACE_O_MASK) ? -EINVAL : 0;
 }
 

Re: [uml-devel] [PATCH] RFC allow PTRACE_SYSCALL to selectively skip syscalls

[Blaisorblade]

On Friday 19 May 2006 16:09, Blaisorblade wrote:
> That is more or less my idea, however I've not had the time to work on it.
> Instead of changing the semantics we must add another option - I thought to
> use a ptrace option (the ones you set with PTRACE_SETOPTIONS), Charles
> Wright coded instead a PTRACE_CHECKEMU, but this is the concept.

> So, I'm going to forward you the emails containing two patches:
> *) PTRACE_CHECKEMU from Charles Wright
> *) PTRACE_SYSCALL_MASK - to make the debugger be notified only of some
> syscalls; the only check is via syscall number though. It's unrelated to
> this but probably useful to you.

> And I'm attaching my original version of the PTRACE_CHECKEMU thing

There's yet another implementation of this; look at the first 4 threads of 
this page -  Renzo Davoli posted a set of 3-patches which include his 
PTRACE_SYSVM which has also this feature.

http://marc.theaimsgroup.com/?a=106901060200003&r=1&w=2
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
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] RFC allow PTRACE_SYSCALL to selectively skip syscalls

[Steven James]

On Sun, 21 May 2006, Blaisorblade wrote:
> On Friday 19 May 2006 16:09, Blaisorblade wrote:
> > That is more or less my idea, however I've not had the time to work on it.
> > Instead of changing the semantics we must add another option - I thought to
> > use a ptrace option (the ones you set with PTRACE_SETOPTIONS), Charles
> > Wright coded instead a PTRACE_CHECKEMU, but this is the concept.
>
> > So, I'm going to forward you the emails containing two patches:
> > *) PTRACE_CHECKEMU from Charles Wright
> > *) PTRACE_SYSCALL_MASK - to make the debugger be notified only of some
> > syscalls; the only check is via syscall number though. It's unrelated to
> > this but probably useful to you.
>
> > And I'm attaching my original version of the PTRACE_CHECKEMU thing
>
> There's yet another implementation of this; look at the first 4 threads of
> this page -  Renzo Davoli posted a set of 3-patches which include his
> PTRACE_SYSVM which has also this feature.
>
> http://marc.theaimsgroup.com/?a=106901060200003&r=1&w=2

I had hoped to test both of these today, but got caught up in a nasty bug
in 2.6.16.16 where syscall_trace_leave is sometimes getting called twice
for the same syscall.

Unfortunatly, my program counts on only being called once on entry and onc
on exit from the syscall, so it gets hopelessly confused (not to mention
the extra wasted context switches).

I haven't been keeping up quite as I should, has it bitten anyone else
and is there a fix?

The same behaviour can be seen with strace where an invalid syscall will
be reported twice.

Once I work that out, I will try the changes as well as a modification of
the SYSVM approach. It seems that a simple set of an option flag and two
task->ptrace flags set from the addr parameter from ptrace will touch less
code for the same effect.

G'day,
sjames


> --
> Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
> Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
> http://www.user-mode-linux.org/~blaisorblade
>
>
>
>
>
> ___________________________________
> Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
> http://mail.yahoo.it
>

||||| |||| |||||||||||||  |||
by Linux Labs International, Inc.
   Steven James, CTO

55 Marietta Street
Suite 1830
Atlanta, Ga 30303
866 824 9737 support



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
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] RFC allow PTRACE_SYSCALL to selectively skip syscalls

[Blaisorblade]

On Monday 22 May 2006 01:58, Steven James wrote:
> On Sun, 21 May 2006, Blaisorblade wrote:
> > On Friday 19 May 2006 16:09, Blaisorblade wrote:
> > > That is more or less my idea, however I've not had the time to work on
> > > it. Instead of changing the semantics we must add another option - I
> > > thought to use a ptrace option (the ones you set with
> > > PTRACE_SETOPTIONS), Charles Wright coded instead a PTRACE_CHECKEMU, but
> > > this is the concept.
> > >
> > > So, I'm going to forward you the emails containing two patches:
> > > *) PTRACE_CHECKEMU from Charles Wright
> > > *) PTRACE_SYSCALL_MASK - to make the debugger be notified only of some
> > > syscalls; the only check is via syscall number though. It's unrelated
> > > to this but probably useful to you.
> > >
> > > And I'm attaching my original version of the PTRACE_CHECKEMU thing
> >
> > There's yet another implementation of this; look at the first 4 threads
> > of this page -  Renzo Davoli posted a set of 3-patches which include his
> > PTRACE_SYSVM which has also this feature.
> >
> > http://marc.theaimsgroup.com/?a=106901060200003&r=1&w=2
>
> I had hoped to test both of these today, but got caught up in a nasty bug
> in 2.6.16.16 where syscall_trace_leave is sometimes getting called twice
> for the same syscall.
>
> Unfortunatly, my program counts on only being called once on entry and onc
> on exit from the syscall, so it gets hopelessly confused (not to mention
> the extra wasted context switches).
>
> I haven't been keeping up quite as I should, has it bitten anyone else
> and is there a fix?

I have uml/64-bit (AMD64) not working on 2.6.16/64bit, while uml-32bit works 
fine on it, and the same uml/64-bit binaries work fine on 2.6.15. I haven't 
tracked it down fully, but could it be related? Possibly yes because I now 
seem to recall you run 64-bit host. So you likely found our bug!

So, please, send a bug report to Roland McGrath <roland@redhat.com>, the 
ptrace maintainer (or so it seems), cc:ing uml-devel, Jeff and me at least. 
And note that neither UML works, though the UML crash hasn't been debugged 
down to verify it's this bug the cause.

I've built all 2.6.16-rc kernels, I hope I can do binary search to insulate a 
bit where the bug was introduced. Now I know which bug it is, it'll be 
easier. Thanks a lot!
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel