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.
> > 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
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)