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]

Message-ID: <AANLkTi=cUM9S5M7h0unMfbQ88CzqhoDN9CUEVf_9HrdS@mail.gmail.com>
Date:	Wed, 2 Mar 2011 00:16:23 +0100
From:	Denys Vlasenko <vda.linux@...glemail.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Oleg Nesterov <oleg@...hat.com>,
	Roland McGrath <roland@...hat.com>, jan.kratochvil@...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 4:24 PM, Tejun Heo <tj@...nel.org> wrote:
> PROPOSAL
> --------
> ...
> P5. "^Z" and "fg" for tracees
>
> A ptracer, as it currently stands and proposed here, has full control
> over the execution state of its tracee.  The tracer is notified
> whenever the tracee stops and can always resume its execution;
> however, there is one missing piece.
>
> As proposed, when a tracee enters jctl stop, it enters TASK_TRACED
> from which emission of SIGCONT can't resume the tracee.  This makes it
> impossible for a tracer to become transparent with respect to jctl.
> For example, after strace(1) is attached to a task, the task can be
> ^Z'd but then can't be fg'd.
>
> One approach to this problem is somehow making it work implicitly from
> the kernel - as in putting the tracee into TASK_STOPPED or somehow
> handling TASK_TRACED for jctl stop differently; however, I think such
> approach is cumbersome in both concept and implementation.  Instead of
> being able to say "while ptraced, a tracee's execution is fully under
> the control of its tracer", subtle and fragile exceptions need to be
> introduced.
>
> A better way to solve this is simply giving the tracer the capability
> to listen for the end of jctl stop.  That way, the problem is solved
> in a manner which is consistent, may not be to everyone's liking but
> nonetheless consistent, with the rest of ptrace.  Execution state of
> the tracee is always under the control of the tracer.  The only thing
> which changes is that the tracer now can find out when jctl stop ends,
> which also could be an additional useful debugging feature.
>
> It would be most fitting to use wait(2) for delivery of this
> notification.  WCONTINUED is the obvious candidate but I think it is
> better to use STOPPED notification because the task is not really
> resumed.  Only its mode of stop changes.  What state the tracee is in
> can be determined by retriving siginfo using PTRACE_GETSIGINFO.
>
> This also effectively makes the notification level-triggered instead
> of edge-triggered, which is a big plus.  No matter which state the
> tracee is in, a jctl stopped notification is guaranteed to happen
> after the lastest event and the tracer can always find out the latest
> state with PTRACE_GETSIGINFO.
>
> Using stopped notification also makes the new addition harmless to the
> existing users.  It's just another stopped notification.  Both
> strace(1) and gdb(1) don't distinguish the signal delivery and jctl
> stop notifications and react the same way by resuming the tracee
> unconditionally.  One more stopped notification on SIGCONT emission
> doesn't change much.

Let's spell this out in detail. Please correct me if
I misunderstood your proposal:

We have a stopped task under ptrace.
(More precisely: debugger got a WSTOPPED notification via waitpid.
Debugger decided to emulate the job control stop, therefore it
keeps tracee stopped, therefore it just waits on waitpid
without doing any PTRACE_CONTs).

Another task sends SIGCONT to the tracee.

Debugger gets waitpid notification of the
WSTOPPED, WSTOPSIG == SIGCONT form.

Debugger can check PTRACE_GETSIGINFO, which succeeds.
Debugger now knows it's a signal delivery notification.
(This step looks optional, since currently
WSTOPPED, WSTOPSIG == SIGCONT combination is only possible
on signal delivery, unlike, for example,
WSTOPPED, WSTOPSIG == SIGSTOP, which is ambiguous).

Debugger performs PTRACE_CONT(SIGCONT) - it injects the signal.
[Question: what if debugger doesn't? IOW: is it possible
for debugger to suppress SIGCONTs, or not?
IOW2: what should happen if debugger
(a) does not do any PTRACE_CONT at all? or
(b) does PTRACE_CONT(<other_sig>)? or
(c) does PTRACE_CONT(0)?
]

Debugger gets WCONTINUED waitpid notification.
[question: do we need this?]


-- 
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/