On Sat, January 21, 2012 02:23, Jamie Lokier wrote:> Roland McGrath wrote:>> On Fri, Jan 20, 2012 at 4:07 PM, Denys Vlasenko>> <vda.linux@googlemail.com> wrote:>> >> Maybe a bit telling whether it is syscall entry or exit?>> >>> > Yes, this one too. This is one of longstanding annoyances>> > that this information is not exposed.>>>> That is not really "state", it's just which event you want.>> That is much better addressed by replacing PTRACE_SYSCALL>> with PTRACE_O_TRACE_SYSCALL_{ENTRY,EXIT} and PTRACE_EVENT_SYSCALL_{ENTRY,EXIT}.>> Oleg can whip that up for you no problem.>> I agree, that is so obviously the right thing to do and it's very easy> to do in the tracehook functions.

Yes, bad place for it, much better via ptrace flags. We're usually notinterested in syscall exit events, so having a way to not always getsyscall exit events would improve performance quite a bit too.

> There is one slight problem that some archs don't use> tracehook yet. Probably that should be fixed anyway.>> (Fwiw, two other issues with arch-independent ptrace have come up in this> thread, which ought to be fairly easy to fix:> - If tracer dies, tracee is free to continue running. For security> tracers, and would be useful for strace as well, it would be good> to have an option to SIGKILL the tracee if tracer dies.

It should be easy to add a PTRACE_O_SIGKILL_ON_DEATH option.

> - Can't abort or change an unwanted syscall if the process receives> SIGKILL as it's about to start a syscall (which will be its last).)

This is very important for any syscall filtering/control via ptrace, otherwiseSIGKILL becomes a security problem. Oleg had a patch for that: