linux-kernel - Re: [PATCH 3/3] ptrace_untrace: fix the SIGNAL_STOP

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: <20090209015029.45AA7FC330@magilla.sf.frob.com>
Date:	Sun,  8 Feb 2009 17:50:29 -0800 (PST)
From:	Roland McGrath <roland@...hat.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Jerome Marchand <jmarchan@...hat.com>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] ptrace_untrace: fix the SIGNAL_STOP_STOPPED check

Yes, I believe this is correct.  It matches the flip side of the
bookkeeping where we adjust group_stop_count when going into TASK_TRACED
(ptrace_stop).  I think it warrants a comment with your change, saying that
treating group_stop_count as "we should be already stopped" is consistent
with decrementing an active group_stop_count when we enter TASK_TRACED.

> 	- if the process/thread was traced, SIGNAL_STOP_STOPPED
> 	  does not necessary means this thread group is stopped.
>
> 	- ptrace breaks the bookkeeping of ->group_stop_count.

SIGNAL_STOP_STOPPED is only set when all live threads in the group are in
either TASK_TRACED or TASK_STOPPED.  PTRACE_DETACH respects this and this
it stopped.  However, PTRACE_CONT et al (ptrace_resume) do not respect it
and can resume an individual thread regardless of SIGNAL_STOP_STOPPED.
That's what you mean here, right?

Doing that without a SIGCONT having been generated is an anomalous way for
a debugger to behave, since it's going to eat the effects of the job
control stop.  But who knows that things they do, so this could be sticky
to fix so that SIGNAL_STOP_STOPPED really means all stopped.

> (the comment above ptrace_untrace() doesn't look exactly right too).

How so?

Thanks,
Roland
--
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/