linux-kernel - Re: RFC: PTRACE_SEIZE needs API cleanup?

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: <400150a2d773c6b7dd8f88e1b74c883d.squirrel@webmail.greenhost.nl>
Date:	Tue, 6 Sep 2011 19:19:00 +0200
From:	"Indan Zupancic" <indan@....nu>
To:	"Denys Vlasenko" <vda.linux@...glemail.com>
Cc:	"Denys Vlasenko" <dvlasenk@...hat.com>,
	"Oleg Nesterov" <oleg@...hat.com>, "Tejun Heo" <tj@...nel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: RFC: PTRACE_SEIZE needs API cleanup?

Hi,

On Tue, September 6, 2011 03:05, Denys Vlasenko wrote:
> On Monday 05 September 2011 19:44, Indan Zupancic wrote:
>> On Mon, September 5, 2011 16:06, Denys Vlasenko wrote:
>> > In case you meant that "if we request group-stop notifications by using
>> > __WALL | WSTOPPED, and we get group-stop notification, and we do
>> > PTRACE_CONT, then task does not run (it sits in group-stop until SIGCONT
>> > or death)", then we have a problem: gdb can't use this interface, it
>> > needs to be able to restart the thread (only one thread, not all of
>> > them, so sending SIGCONT is not ok!) from the group-stop. Yes, it's
>> > weird, but it's the real requirement from gdb users.
>> [...]
>> > SIGCONT's side effect of waking up from group-stop can't be blocked.
>> > SIGCONT always wakes up all threads in thread group.
>> > Using SIGCONT to control tracee will race with SIGCONTs from other
>> > sources.
>> >
>> > This makes SIGCONT a too coarse instrument for the job.
>> [...]
>> > Yes... until gdb will want to give user a choice after SIGSTOP: continue
>> > to sit in group-stop until SIGCONT (wasn't possible until
>> > PTRACE_LISTEN), or continue executing (gdb's current behavior if user
>> > uses "continue" command). Therefore, gdb needs a way to do both.
>>
>> Having thought a bit more about this, I think this is less of a problem
>> than it seems, because for a group stop we get a ptrace event for each
>> task, and this should be true for SIGCONT as well. So gdb could also
>> always let the group stop happen, and only when prompted to do so by
>> a user, continue one thread by sending SIGCONT and letting all the other
>> threads hang in trapped state.
>
> Won't work. SIGCONT unpauses all threads in the thread group,
> and _then_ it is delivered to one of the threads.

No, it is delivered to _all_ threads. With current ptrace you never see a
SIGCONT, but it should behave the same as SIGSTOP, which results in one
ptrace event for each thread.

> You can block
> or ignore it, yes, but it is too late: the unpausing already happened,
> and blocking/ignoring will only affect SIGCONT handler execution,
> if the program has one.

Not doing PTRACE_CONT will keep the thread hanging in trapped state.
All threads get a SIGCONT, not only one, so you can pause all threads
this way.

Greetings,

Indan


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