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: <20110304181630.GA28729@redhat.com>
Date:	Fri, 4 Mar 2011 19:16:30 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Roland McGrath <roland@...hat.com>, jan.kratochvil@...hat.com,
	Denys Vlasenko <vda.linux@...glemail.com>,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org
Subject: Re: [RFC] Proposal for ptrace improvements

On 03/04, Tejun Heo wrote:
>
> > Tracee:
> >
> > 	int main(void)
> > 	{
> > 		kill(SIGSTOP, getpid());
> >
> > 		printf("I am running\n");
> >
> > 		for (;;)
> > 			;
> > 	}
> >
> > To simplify again, suppose that the debugger attaches when it is
> > already stopped, then it does PTRACE_CONT(0).
> >
> > In this case the tracee remains SIGNAL_STOP_STOPPED but prints
> > "I am running" and enters the endless loop.
> >
> > (the new debugger can do PTRACE_SEIZE after that and "return"
> >  it to the stopped state without affecting jctl state).
> >
> > Now, if SIGCONT comes (from anywhere) it clears SIGNAL_STOP_STOPPED,
> > the tracee traps and reports this event to debugger.
> >
> > Correct?
>
> * The above requires another ptrace trap site which can probably
>   shared with PTRACE_SEIZE.

OK, thanks. I was a bit confused by TASK_TRACED | TASK_STOPPED state
idea. Obviously the state can't be TASK_RUNNING | TASK_STOPPED.

> The question is whether to make group
>   stop state available for other trap sites too or just enable it in
>   the new trap site.  ATM, I'm leaning toward the latter.

Yes.

There is another corner case. Suppose that another SIGSTOP comes
while the tracee runs the endless loop above.

In this case nothing changes, the tracee should report this signal.
But what should it do if the debugger does PTRACE_CONT(SIGSTOP) after
that?

Should it stop and report another job control stop after that, or
should it ignore this signal? In the first case, at least we should
not notify the real parent again. In the latter case, perhaps the
naive debugger can be confused and this differs from the current
behaviour.

And, if it stops, should this also stop other PTRACE_CONT'ed threads
as well? Currently we do...

Not that I think this is terribly important, but I think it makes
sense to discuss/document this case anyway.

Anyway. I think this RFC is fine.

Oleg.

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