linux-kernel - Re: [PATCH 10/16] ptrace: clean transitions between TASK

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: <20101222162155.GE8061@htj.dyndns.org>
Date:	Wed, 22 Dec 2010 17:21:55 +0100
From:	Tejun Heo <tj@...nel.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	roland@...hat.com, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	rjw@...k.pl, jan.kratochvil@...hat.com
Subject: Re: [PATCH 10/16] ptrace: clean transitions between TASK_STOPPED
 and TRACED

Hello,

On Wed, Dec 22, 2010 at 05:00:16PM +0100, Oleg Nesterov wrote:
> On 12/22, Tejun Heo wrote:
> >
> > On Wed, Dec 22, 2010 at 12:39:48PM +0100, Oleg Nesterov wrote:
> > >
> > > sys_ptrace() only works for the single thread who did PTRACE_ATTACH,
> > > but do_wait() should work for its sub-threads.
> > >
> > > 	1. the tracer knows that the tracee is stopped
> > >
> > > 	2. the tracer does ptrace(ATTACH)
> > >
> > > 	3. the tracer's sub-thread does do_wait()
> > >
> > > Note! Personally I think we can ignore this "problem", I do not
> > > think it can break anything except some specialized test-case.
> >
> > But if ptrace(ATTACH) doesn't return until the transition is complete
> > when the task is already stopped, the tracer's sub-thread's do_wait()
> > will behave exactly the same.  The only difference would be that
> > ptrace(ATTACH) may now block and/or is failed by a signal delivery.
> >
> > How would #3 behave differently if STOPPED -> TRACED transition is
> > guaranteed to be complete by the end of #2?
> 
> Ahhh, sorry. I meant, two threads can do 2. and 3. at the same time.

Ah, okay, now I see, so WNOHANG wait(2) from a different thread may
fail if it races against ptrace(ATTACH), although it would have
succeeded regardless of the timing between #2 and #3 before the
change.

> But let me repeat, it is not that I think we should worry. I mentioned
> this only because I think it is better to discuss everything we can,
> even the really minor things.

It's definitely worth documenting.  We can close off the condition by
tweaking wait(2) so that it blocks if the target thread is in
transition, but that might be reaching into the realm of unnecessary
over-engineering.  IMHO, it would be wiser to hold off implementing it
until we know it's actually necessary.  Roland, Jan, do you guys think
this can actually cause a problem?

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/