linux-kernel - Re: [RFC] Proposal for ptrace improvements

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, 1 Mar 2011 23:14:14 +0100
From:	Denys Vlasenko <vda.linux@...glemail.com>
To:	Jan Kratochvil <jan.kratochvil@...hat.com>
Cc:	Tejun Heo <tj@...nel.org>, Oleg Nesterov <oleg@...hat.com>,
	Roland McGrath <roland@...hat.com>,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org
Subject: Re: [RFC] Proposal for ptrace improvements

On Tue, Mar 1, 2011 at 8:06 PM, Jan Kratochvil
<jan.kratochvil@...hat.com> wrote:
> On Tue, 01 Mar 2011 16:24:57 +0100, Tejun Heo wrote:
>> P4. PTRACE_SEIZE
> [...]
>> Completion notification is delivered in the usual way via wait(2).  If
>> the task was in jctl stop, it would report the stop signal with the
>> matching siginfo.  If the task hits an existing ptrace trap condition,
>> the matching SIGTRAP will be reported; otherwise, SIGTRAP will be
>> reported with siginfo indicating PTRACE_SEIZE trap.
>
> This is a change from the Roland's proposed PTRACE_ATTACH_NOSTOP.

As I see it, Tejun's PTRACE_SEIZE looks almost identical to the sequence of
PTRACE_ATTACH_NOSTOP ("attach, but don't affect current state of the
tracee. In particular, if it runs normally, let it continue to run")
plus
PTRACE_INTERRUPT ("if tracee isn't stopped yet, stop it with magic SIGTRAP").

There may be reasons to have PTRACE_SEIZE operation split like that.
For one, this allows debugger to do PTRACE_CONT, and later issue
PTRACE_INTERRUPT to stop the tracee again. PTRACE_INTERRUPT stop may
be better for some scenarios where debugger wants to make the stop
invisible to the parent, or when debugger wants to stop just one
thread of the process.

> Currently it is already a problem that apps did not / do not expect the first
> waitpid after PTRACE_ATTACH may not be SIGSTOP.

That's exactly why we want to add a better alternative, which doesn't
insert that blasted SIGSTOP.

-- 
vda
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/