linux-kernel - Re: [RFC PATCH RESEND v3 3/3] ptrace: add PTRACE_EVENT_SECCOMP support to 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:   Wed, 28 Nov 2018 15:44:11 +0300
From:   "Dmitry V. Levin" <ldv@...linux.org>
To:     Oleg Nesterov <oleg@...hat.com>
Cc:     Elvira Khabirova <lineprinter@...linux.org>,
        Eugene Syromyatnikov <esyr@...hat.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Andy Lutomirski <luto@...nel.org>,
        Ingo Molnar <mingo@...hat.com>, linux-api@...r.kernel.org,
        linux-kernel@...r.kernel.org, strace-devel@...ts.strace.io
Subject: Re: [RFC PATCH RESEND v3 3/3] ptrace: add PTRACE_EVENT_SECCOMP
 support to PTRACE_GET_SYSCALL_INFO

On Wed, Nov 28, 2018 at 01:35:46PM +0100, Oleg Nesterov wrote:
> On 11/28, Dmitry V. Levin wrote:
> >
> > > Just like ptrace_request(PTRACE_LISTEN)
> > > does but you can do this lockless (no need to lock_task_sighand()).
> >
> > Why this can be done lockless?  All other places in that file do
> > the locking,
> 
> PTRACE_LISTEN too doesn't need lock_task_sighand() to access ->last_siginfo,
> this code predates ptrace_freeze_traced() which ensures that the tracee can't
> go away and clear ->last_siginfo.
> 
> However, unlike ptrace_get_syscall(), PTRACE_LISTEN needs spin_lock_irq(siglock),
> it modifies ->jobctl and calls signal_wake_up().

What about PTRACE_GETSIGINFO?  Can it also be done lockless because
ptrace_check_attach() has already called ptrace_freeze_traced()?

> > > Of course, debugger can do PTRACE_SETSIGINFO and confuse itself but probably we
> > > do not care?
> >
> > The only potential issue I could think of is whether PTRACE_SETSIGINFO
> > could be used this way to cause an information leak by making
> > PTRACE_GET_SYSCALL_INFO access some unrelated data.
> 
> Well, afaics ptrace_get_syscall() does nothing "special", debugger can use other
> PTRACE_ requests to get the same info?

I agree.


-- 
ldv

Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)