linux-kernel - Re: Question regarding ptrace work for LInux v3.1

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]

Message-ID: <CALJO4zGkwAq_yTBs98vxRsvVyJW5gYU5ntGPtrPj170Px_QtbQ@mail.gmail.com>
Date:	Mon, 21 Mar 2016 14:28:34 -0400
From:	Patrick Donnelly <pdonnel3@...edu>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Tejun Heo <tj@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: Question regarding ptrace work for LInux v3.1

On Mon, Mar 21, 2016 at 1:47 PM, Oleg Nesterov <oleg@...hat.com> wrote:
>> The basic problem is that the application we are tracing spawns
>> threads which **sometimes** are not traced (or lost). For Linux v3.0,
>> we are using PTRACE_ATTACH and the PTRACE_O_TRACE(CLONE|FORK|VFORK)
>> options to follow children [3]. The problem we see is that we will
>> receive a PTRACE_EVENT_CLONE event that a thread is created but we
>> receive no other events for the thread.
>
> IOW, the new thread do not report SIGSTOP injected by implicit attach?

It does not report the SIGSTOP nor the system calls leading up to the
PTRACE_EVENT_CLONE (not even the entry into the clone syscall).

>> What's worse is that the
>> thread eventually "comes back" via a PTRACE_EVENT_CLONE when it clones
>> its own thread.
>
> OK, so at least the new child is traced too, and it also has PT_TRACE_*
> flags copied from its parent.

That seems to be the case but it will only report certain events (not
syscalls). I have observed PTRACE_EVENT_EXIT and PTRACE_EVENT_CLONE
events... Hmm, now that I think about this, it would be necessary to
see the initial SIGSTOP (or PTRACE_EVENT_STOP) in order to initiate
syscall tracing via PTRACE_SYSCALL. So that does seem to indicate the
problem.

> To clarify, the usage of SIGSTOP in ptrace was always buggy by design.
> For example, SIGCONT from somewhere can remove the pending (and not yet
> reported) SIGSTOP, and this _can_ explain the problem you hit.

The tree of processes being traced do no send any signals but an
external process may have. However, I did notice the use of futexes
near these clones. Perhaps that may be causing this?

> But unless you use PTRACE_SEIZE the same can happen on v3.1 so it seems
> there is something else.

Okay, it might be that PTRACE_SEIZE fixes it.

> It would be nice to have a test-case :/

Unfortunately, I have not yet been able to isolate a test case.

Thanks for your help!

-- 
Patrick Donnelly