Re: [PATCH 0/1] ptrace_vm: let us simplify the code for ptrace and add useful features for VM

[Jeff Dike <jdike@addtoit.com>]

On Sun, Jun 22, 2008 at 11:11:02AM +0200, Renzo Davoli wrote:
> There are three events for a syscall:
> START - call notification
> CALL - run the SYSCALL
> EXIT - return notification.
> 
> I think that it is a non sense to write code for useless cases.
> Let us see all the combinations of doing/skipping each one of the three
> phases:
> 
> 0- DOSTART - DOCALL - DOEXIT - Standard PTRACE_SYSCALL (new option 0)
> 1- DOSTART - DOCALL - SKIPEXIT - PTRACE_VM_SKIPEXIT of my proposal
> 2- DOSTART - SKIPCALL - DOEXIT - useless, nothing has changed between
>                               the two notifications
> 3- DOSTART - SKIPCALL - SKIPEXIT - PTRACE_VM_SKIPCALL in my proposal
> 4- SKIPSTART - DOCALL - DOEXIT - is this useful? (Case 4,see below)
> 5- SKIPSTART - DOCALL - SKIPEXIT - simply don't use PTRACE_SYSCALL
> 6- SKIPSTART - SKIPCALL - DOEXIT - this is the old PTRACE_SYSEMU (case 6)
> 7- SKIPSTART - SKIPCALL - SKIPEXIT - nullify completely the syscalls
>                                 (case 7).
>                                 
> case 4: a vm or debugging monitor receives just the return value of a
> syscall. In many architectures it not even possible to read the parameters
> of the call (e.g. powerpc where the first argument and the return value
> use the same register). This choice must be done a-priori, so without
> actually know which will be the next system call.

I can see this being useful - this is kind of what strace wants,
except that it wouldn't be able to see that a system call is about to
sleep.  This could be implemented by just stashing any trashed
registers off to the side ala x86 orig_eax.

> case 6: this makes sense just for applications which virtualize *all* the
> system call, current PTRACE_SYSEMU works exactly in this way.
> My patch shows that for these applications it does not matter whether the
> virtualization takes place before skipping the call or after having just
> skipped the call. So PTRACE_VM_SKIPCALL can be used instead.

Yup.

> case 7: skip the next syscall and give no information about, there is no way
> to virtualize or trace what is going on.
> Who could be ever interested in an option like this?

No one.

> It seems that the combinations that really make sense are those skipping
> a trailing part of the sequence.
> 
> DOSTART - DOCALL - DOEXIT         my option 0
> DOSTART - DOCALL - SKIPEXIT       my option PTRACE_VM_SKIPEXIT
> DOSTART - SKIPCALL - SKIPEXIT     my option PTRACE_VM_SKIPCALL

Seems reasonable.  In this case, they should be numbered 0, 1, 2
rather than having masks or-ed together.  This happens to produce the
same numbers, except that 3 is outlawed.

> If you think that it is not clear from the tag name that PTRACE_VM_SKIPCALL
> implies PTRACE_VM_SKIPEXIT let us change the name in:
> PTRACE_VM_SKIPCALL_SKIPEXIT
> Maybe the name is quite long, but in this way it is clear what it
> does.

Maybe.  How about PTRACE_VM_TRACESTART?  Makes the naming somewhat
non-orthogonal, but shorter and descriptive.

		    	    	Jeff

-- 
Work email - jdike at linux dot intel dot com