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: <20110302145048.GK3319@htj.dyndns.org>
Date:	Wed, 2 Mar 2011 15:50:48 +0100
From:	Tejun Heo <tj@...nel.org>
To:	Indan Zupancic <indan@....nu>
Cc:	Denys Vlasenko <vda.linux@...glemail.com>,
	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

Hello,

On Wed, Mar 02, 2011 at 12:32:36PM +0100, Indan Zupancic wrote:
> What might happen is that, because the current code handles the traced
> task as stopped, the new SIGSTOP signal is first added and then cleared
> when the task continues. This doesn't explain the double SIGSTOP
> notifications, I'd expect it to either loop indefinitely or to not
> notify the SIGSTOP twice.

That happens with any stopping signals.  They're two different
notifications for two different events.  Please read the original
thread referenced in the RFC for details.

>  "When waitpid indicates stop on a *stop* signal, then it may be either:
>  * a signal delivery (strace will inject this signal with PTRACE_SYSCALL(sig));
>  * or it may be a stop notification, in which case strace *must not*
>    try to inject this signal (this would be a bug, it'd make task running).
>    Instead, strace should just go back to waiting in waitpid().
> 
>  These two possibilities can be distinquished by querying
>  PTRACE_GETSIGINFO. On stop notifications, PTRACE_GETSIGINFO
>  errors out - stop notification is not a signal delivery
>  and therefore it has no siginfo."
> 
> End quote.
> 
> You don't get the second case when not setting the WUNTRACED flag.

WUNTRACED is ignored while ptracing.

> > Again, not following.  In the proposal, job control and ptrace operate
> > independently, so on that we seem to agree, but I can't understand
> > where the STOP signal for the parent comes from?  What are you
> > referring to?
> 
> What I mean is, if you have a parent P with a child C, and C is ptraced by T,
> P shouldn't get SIGSTOP notifications when it waits for C with WUNTRACED set
> and C is stopped because of a ptrace event.

Yeah, sure, what I'm confused about is why you're bringing that up.
Nothing changes anything related to that.  There's no reason to bring
it up.  Am I missing something?

Thanks.

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