Re: [RFC PATCH] ptrace: add PTRACE_GET_SYSCALL_INFO request

[Dmitry V. Levin]

On Wed, Nov 07, 2018 at 12:44:58PM -0800, Andy Lutomirski wrote:
> > On Nov 6, 2018, at 7:27 PM, Elvira Khabirova <lineprinter@xxxxxxxxxxxx> wrote:
> >
> > PTRACE_GET_SYSCALL_INFO lets ptracer obtain details of the syscall
> > the tracee is blocked in. The request returns meaningful data only
> > when the tracee is in a syscall-enter-stop or a syscall-exit-stop.
> >
> > There are two reasons for a special syscall-related ptrace request.
> >
> > Firstly, with the current ptrace API there are cases when ptracer cannot
> > retrieve necessary information about syscalls. Some examples include:
> > * The notorious int-0x80-from-64-bit-task issue. See [1] for details.
> > In short, if a 64-bit task performs a syscall through int 0x80, its tracer
> > has no reliable means to find out that the syscall was, in fact,
> > a compat syscall, and misidentifies it.
> > * Syscall-enter-stop and syscall-exit-stop look the same for the tracer.
> > Common practice is to keep track of the sequence of ptrace-stops in order
> > not to mix the two syscall-stops up. But it is not as simple as it looks;
> > for example, strace had a (just recently fixed) long-standing bug where
> > attaching strace to a tracee that is performing the execve system call
> > led to the tracer identifying the following syscall-exit-stop as
> > syscall-enter-stop, which messed up all the state tracking.
> > * Since the introduction of commit 84d77d3f06e7e8dea057d10e8ec77ad71f721be3
> > ("ptrace: Don't allow accessing an undumpable mm"), both PTRACE_PEEKDATA
> > and process_vm_readv become unavailable when the process dumpable flag
> > is cleared. On ia64 this results in all syscall arguments being unavailable.
> >
> > Secondly, ptracers also have to support a lot of arch-specific code for
> > obtaining information about the tracee. For some architectures, this
> > requires a ptrace(PTRACE_PEEKUSER, ...) invocation for every syscall
> > argument and return value.
> >
> > PTRACE_GET_SYSCALL_INFO returns the following structure:
> >
> > struct ptrace_syscall_info {
> >    __u8 op; /* 0 for entry, 1 for exit */
> 
> Please consider adding another op for a seccomp stop.

If there are going to be more than two values, I'd suggest introducing
a enum or at least define appropriate macros.

wrt PTRACE_EVENT_SECCOMP, I don't see how the current proposed
implementation of PTRACE_GET_SYSCALL_INFO (based on ptrace_message)
could work in case of PTRACE_EVENT_SECCOMP (which also sets
ptrace_message).  Any ideas?


-- 
ldv