linux-kernel - Re: [PATCH 1/1] ptrace: make sure do_wait() won't hang after PTRACE

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 14 Feb 2011 17:01:48 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Jan Kratochvil <jan.kratochvil@...hat.com>
Cc:	Denys Vlasenko <vda.linux@...glemail.com>,
	Tejun Heo <tj@...nel.org>, Roland McGrath <roland@...hat.com>,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org
Subject: Re: [PATCH 1/1] ptrace: make sure do_wait() won't hang after
	PTRACE_ATTACH

On 02/14, Jan Kratochvil wrote:
>
> On Mon, 14 Feb 2011 00:01:47 +0100, Denys Vlasenko wrote:
> > * sleep runs in nanosleep
> > * SIGSTOP arrives, strace sees it
> > * strace logs it and allows it via ptrace(PTRACE_SYSCALL, ..., SIGSTOP)
> > * sleep process enters group-stop
>
> The last point breaks the documented behavior of ptrace:

Well, afaics no. This is what we currently do.

> 	If data is nonzero and not SIGSTOP, it is interpreted as a signal to
> 	be delivered to the child; otherwise, no signal is delivered.

Fantastic. I never knew the man states this (although the documentation
above means PTRACE_CONT).

But this is not true. And iirc this was never true. Netither PTRACE_CONT,
nor any other request threat SIGSTOP specially.

(also, please note that the signal is not necessarily delivered, only
 if we are going to resume the tracee after it reported the signal or
 syscall entry/exit)

> > * nothing happens until some other signal arrives
> > * say, SIGCONT arrives
>
> What if other signal arrives?

only SIGCONT can resume the stopped task (ignorign SIGKILL).

> The tracer probably should not be notified as
> the tracee is in a group-stop.

It is.

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/