linux-kernel - Re: [RFC PATCH] ptrace: add PTRACE_GET_SYSCALL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 13 Nov 2018 06:38:02 +0300
From:   "Dmitry V. Levin" <ldv@...linux.org>
To:     Andy Lutomirski <luto@...nel.org>, Oleg Nesterov <oleg@...hat.com>,
        Elvira Khabirova <lineprinter@...linux.org>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        Ingo Molnar <mingo@...hat.com>,
        Eugene Syromiatnikov <esyr@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>, strace-devel@...ts.strace.io
Subject: Re: [RFC PATCH] ptrace: add PTRACE_GET_SYSCALL_INFO request

On Wed, Nov 07, 2018 at 12:44:58PM -0800, Andy Lutomirski wrote:
> > On Nov 6, 2018, at 7:27 PM, Elvira Khabirova <lineprinter@...linux.org> 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