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: <20110304084441.GB20499@htj.dyndns.org>
Date:	Fri, 4 Mar 2011 09:44:41 +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 Thu, Mar 03, 2011 at 06:34:22PM +0100, Oleg Nesterov wrote:
> > P4. PTRACE_SEIZE
> 
> This is the new request. You know, I'd like to discuss the details
> later and separately. Actually, I think the user-space developers
> should participate and tell what they need. As for me, I certainly
> agree that SIGSTOP from PTRACE_ATTACH is very wrong, and it is very
> bad that gdb has to send SIGSTOP if it wants to stop the tracee.
> IOW, I agree that something like this is needed and useful. In
> particular,

While discussing is good, I'd like to keep things slightly more
driven.  I think, as anything else, there's a balance to hit between
discussing and just pushing things forward.  We did fair amount of
discussion past two+ months and well I think it's about time to push
forward.

By now gdb/strace ppl should be aware of what's going on, right?  So,
if you guys have something on mind w.r.t. kernel behavior, please
share, but I won't wait for some discussion elsewhere to reach a
conclusion especially because the issues which seem to cause the most
amount of delay are not really about what's necessary to achieve the
desired functionalities but wildly different wet wild dreams about
sexy unicorns.

> > A better way to solve this is simply giving the tracer the capability
> > to listen for the end of jctl stop.
> 
> Hmm. I don't understand what "the end of jctl stop" actually means.
> 
> Since you are talking about WCONTINUED below, I guess it means that
> the process is not group-stopped any longer, say, SIGCONT comes.

Yeap, I meant emssion of SIGCONT ending the job control stop in
effect.

> > What state the tracee is in can be determined by retriving siginfo
> > using PTRACE_GETSIGINFO.
> 
> I don't understand this this details right now... But I guess this
> doesn't matter right now.
> 
> Either way, debugger should have the ability to know the tracee's
> state wrt group-stop. To oversimplify, it should know the state of
> SIGNAL_STOP_STOPPED bit. Correct?

Yes, that information should be available via PTRACE_GETSIGINFO.

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/