linux-kernel - Re: [PATCHSET RFC] ptrace,signal: clean transition between STOPPED and TRACED

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: <20110131154117.GK7459@htj.dyndns.org>
Date:	Mon, 31 Jan 2011 16:41:17 +0100
From:	Tejun Heo <tj@...nel.org>
To:	Roland McGrath <roland@...hat.com>
Cc:	oleg@...hat.com, jan.kratochvil@...hat.com,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org
Subject: Re: [PATCHSET RFC] ptrace,signal: clean transition between STOPPED
 and TRACED

Hello,

On Fri, Jan 28, 2011 at 12:40:30PM -0800, Roland McGrath wrote:
> > Okay, just finished ran make check with and without the patchset.
> > Without the patchset, 2.6.38-rc2 failed five tests.  
> 
> Hmm.  I didn't think we were in that poor a state, but it has been quite a
> while since I looked.  I wonder if that's a regression from a few releases
> back, or what.  Oleg and Jan should know better than I do about the state
> of these tests.

Also, the first test of xcheck seems to enter infinite loop.

> > With the patchset six.  The one extra test which failed was
> > attach-sigcont-wait because the tracee now always enters TRACED after
> > PTRACE_ATTACH, which I think is the correct behavior because the previous
> > behavior where a stopped task honors SIGCONT unconditionally if it was
> > delivered before the next ptrace call (any operation other than detach)
> > doesn't make any sense to me in addition to the fact that it was buggy
> > regarding the arch hook.
> 
> Well, I can't say I'm at all sure I agree with your assessment about that.
> But we can investigate further before I make any particular assertions.
> 
> > Is there an actual use case which requires this behavior?  We can try
> > to emulate the original behavior but I don't think it's a sane one.
> 
> Most of those cases were added when Jan ran into a particular problem while
> working on GDB, and some of them from issues that arose with ptrace.  Jan
> is probably the person who knows best about the requirements each test was
> meant to verify.

Jan, do you care to chime in?

> > Another difference was how stopped-detach-sleeping failed.  It failed
> > both with and without the patchset but with the patchset it triggered
> > an assert().  The difference was because the assert() was testing
> > whether the task was in STOPPED state after attach - it's now in
> > TRACED state instead.  With the assert removed, it failed the same
> > way.
> 
> This is probably something that can change in the test.  I think some of
> those /proc/pid/status checks in the tests were either just to match
> expectations based on manifest kernel behavior, but they might also have
> been because it really did matter somehow and it was just easier to discern
> that way than to write a test that reliably found the important race
> condition or whatever it was.  So again we need Jan to help us understand
> the intent of the test and the specific GDB requirements it represents.

I see.  Yeah, if there are users which expect /proc/pid/status to be
certain value, we can either emulate it or delay TRACED transition to
the next PTRACE call *after* ATTACH/wait(2) sequence, but I think both
are quite ugly and would like to avoid if at all possible.

Thank you.

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