Messages in this thread | | | Date | Thu, 11 Mar 1999 16:54:21 -0800 | From | Nate Eldredge <> | Subject | Re: Tracing of vfork |
| |
Michael Elizabeth Chastain wrote: > > Hi Nate, > > > I would like for it to be possible to have the `vfork' system call > > really just act like plain `fork' when tracing is underway. > > Here is my idea on how to get this. > > In arch/i386/kernel/ptrace.c, remove the restriction that sys_ptrace > cannot touch ORIG_EAX. > > In arch/i386/kernel/entry.S, label 'tracesys', change the code to > look like this: [recheck %eax after trace runs] > Presto. Now when strace sees a vfork, it can change the child process > ORIG_EAX register to from __NR_vfork to __NR_fork. > > Note that tracesys is not a fast path anyways so the extra instructions > aren't going to hurt anybody's performance. The jump is almost never > taken anyways. > > This is a nice policy-free mechanism that helps several different > people. It helps you mess with vfork. It helps me veto system calls > (set ORIG_EAX to -1). Other people could use system-call veto to > help out with transparent process migration and write a really secure > sandbox monitor.
And if only we had a no-op system call, the entry.S change wouldn't be needed either... I suppose you could use `sync' but people might get upset about the severe performance hit.
Yes, that looks good. When I first wrote that post, I didn't correctly understand the semantics of ORIG_EAX, and so I didn't even consider using it, but I also hadn't seen the restriction on poking it.
Only disadvantage is it will have to be done separately in all the arch/ trees, and I don't know enough about any other architecture. But I suppose it can be left for others...
I will submit such a patch when I have the time, in the next few days. --
Nate Eldredge nate@cartsys.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |