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: <20110305083339.GD20499@htj.dyndns.org>
Date:	Sat, 5 Mar 2011 09:33:39 +0100
From:	Tejun Heo <tj@...nel.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Roland McGrath <roland@...hat.com>, jan.kratochvil@...hat.com,
	Denys Vlasenko <vda.linux@...glemail.com>,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org
Subject: Re: [RFC] Proposal for ptrace improvements

Hey, Oleg.

On Fri, Mar 04, 2011 at 07:16:30PM +0100, Oleg Nesterov wrote:
> > The question is whether to make group
> >   stop state available for other trap sites too or just enable it in
> >   the new trap site.  ATM, I'm leaning toward the latter.

I changed my mind and am now leaning toward the former.  That would
make things easier for debuggers which resume the tracee but wants to
keep track of the job control state.  Let's see how implementation
turns out.  Planning can do only so much and implementation often
comes with surprises of its own.

> There is another corner case. Suppose that another SIGSTOP comes
> while the tracee runs the endless loop above.
> 
> In this case nothing changes, the tracee should report this signal.
> But what should it do if the debugger does PTRACE_CONT(SIGSTOP) after
> that?
> 
> Should it stop and report another job control stop after that, or
> should it ignore this signal? In the first case, at least we should
> not notify the real parent again. In the latter case, perhaps the
> naive debugger can be confused and this differs from the current
> behaviour.

Interesting.  Ignoring would be the cleaner choice but I think we're
bound to deliver it to the tracer and suppress notification to the
real parent; otherwise, the behavior would change a bit too much - an
invisible stop signal mask out of nowhere wouldn't be too pleasant.

> And, if it stops, should this also stop other PTRACE_CONT'ed threads
> as well? Currently we do...

I think so; otherwise, again, the behavior would change too much for
the current users.  This definitely needs to be documented in detail.

> Not that I think this is terribly important, but I think it makes
> sense to discuss/document this case anyway.

Yeah, definitely.  I wasn't thinking about cases like the above but we
need to so please keep them coming.  :-)

> Anyway. I think this RFC is fine.

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