lkml.org 
[lkml]   [2008]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/1] ptrace_vm: let us simplify the code for ptrace and add useful features for VM
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


\
 
 \ /
  Last update: 2008-06-27 19:55    [W:0.038 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site