Re: PTRACE_SYSCALL_ENTRY/EXIT

2010-01-22 Thread Ali Polatel
Roland McGrath yazmış:
 We don't have any particular plans to extend the ptrace interface.  
 I strongly doubt we would even try to do anything like that until the
 utrace-based ptrace interface is merged into Linux and the old ptrace
 implementation gone.
 
 In general, we are not looking for extensions to the ptrace interface.
 It is an ugly hairball already and we are more interested in having 
 the utrace API layer available inside the kernel and then embarking on
 new and sane userland interfaces instead of shoehorning more into ptrace.
 

I respect that.

 That said, some particular kinds of simple enhancements to ptrace are
 really quite trivial to implement in the new utrace-based implementation.
 The particular area you suggest is one of these.
 
 What I would expect is not new variants of the one-shot interface like
 PTRACE_SYSCALL.  Rather, I would envision new PTRACE_O_* options to enable
 syscall entry and exit tracing analogous to the PTRACE_EVENT_* events you
 can now enable.  This means that you make one PTRACE_SETOPTIONS call to
 enable the set of events you want, and then use plain PTRACE_CONT (or
 whatever).
 
 If you really want exactly the one-shot behavior instead, then we could
 consider that.  But, like I said, we are not looking to add much in the
 way of new wrinkles to the dismal ptrace userland interface.

The one-shot behaviour is what I want because adding a PTRACE_O_* option
won't solve my problem if I understood correctly. I'm writing a tool
that audits system calls and *only* denied system calls need to be
stopped at the exit of the system call to set return value and errno.
System calls are checked at entry, if they're safe another
PTRACE_SYSCALL_ENTRY will be issued to continue to the next system call.
If, however, the system call needs to be denied, PTRACE_SYSCALL_EXIT
will be issued after changing system call no to something invalid so
that return value and errno can be set.

I think this will be useful for every program that audits system calls.

 
 Thanks,
 Roland

-- 
Regards,
Ali Polatel


signature.asc
Description: PGP signature


Re: PTRACE_SYSCALL_ENTRY/EXIT

2010-01-18 Thread Roland McGrath
We don't have any particular plans to extend the ptrace interface.  
I strongly doubt we would even try to do anything like that until the
utrace-based ptrace interface is merged into Linux and the old ptrace
implementation gone.

In general, we are not looking for extensions to the ptrace interface.
It is an ugly hairball already and we are more interested in having 
the utrace API layer available inside the kernel and then embarking on
new and sane userland interfaces instead of shoehorning more into ptrace.

That said, some particular kinds of simple enhancements to ptrace are
really quite trivial to implement in the new utrace-based implementation.
The particular area you suggest is one of these.

What I would expect is not new variants of the one-shot interface like
PTRACE_SYSCALL.  Rather, I would envision new PTRACE_O_* options to enable
syscall entry and exit tracing analogous to the PTRACE_EVENT_* events you
can now enable.  This means that you make one PTRACE_SETOPTIONS call to
enable the set of events you want, and then use plain PTRACE_CONT (or
whatever).

If you really want exactly the one-shot behavior instead, then we could
consider that.  But, like I said, we are not looking to add much in the
way of new wrinkles to the dismal ptrace userland interface.


Thanks,
Roland



PTRACE_SYSCALL_ENTRY/EXIT

2010-01-16 Thread Ali Polatel
Hello,

Do you guys plan to add ptrace requests possibly named
PTRACE_SYSCALL_ENTRY and PTRACE_SYSCALL_EXIT at some point akin to
FreeBSD's¹ PT_TO_SCE and PT_TO_SCX?

¹: 
http://www.freebsd.org/cgi/man.cgi?query=ptraceapropos=0sektion=0manpath=FreeBSD+8.0-RELEASEformat=ascii

-- 
Regards,
Ali Polatel


pgp4bnIgQv6gX.pgp
Description: PGP signature