linux-kernel - Re: [PATCH 03/10] ptrace: implement PTRACE

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110524102834.GC10334@htj.dyndns.org>
Date:	Tue, 24 May 2011 12:28:34 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Denys Vlasenko <vda.linux@...glemail.com>,
	jan.kratochvil@...hat.com, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	indan@....nu, bdonlan@...il.com
Subject: Re: [PATCH 03/10] ptrace: implement PTRACE_SEIZE

Hello, Oleg.

On Mon, May 23, 2011 at 02:43:14PM +0200, Oleg Nesterov wrote:
> On 05/18, Tejun Heo wrote:
> > I've been thinking about Jan's suggestion to make ATTACH and DETACH
> > not require tracee to trap. We already have this for DETACH for cases
> > where the tracer is killed
> 
> Yes, I still think that the new DETACH_XXX request which doesn't need
> the stopped tracee makes sense. Yes, we have PTRACE_INTERRUPT. But please
> recall the previous discussion, it is possible that the tracee can't
> react to PTRACE_INTERRUPT and trap because it waits for other threads
> we are tracing.

Yeah, untrapped DETACH sounds nice but as you've already acknowledged
in another reply, we have those nasty disable traps.  As the impact on
debugging capability is much lower, having a synchronization barrier
on detach might not be such a bad idea.  As for debugger building
dependency loop with debuggees, I think SIGKILL is the solution there.
Debugger can do that with PTRACE_INTERRUPT regardless of DETACH after
all.

> And. Currently there is no way to detach a zombie leader. Perhaps we
> should change do_wait(), but it is not clear what should we do if the
> tracer is the real parent (we already discussed this a bit).

Hmmm... maybe just allow detaching zombie leader?  As it's guaranteed
to be not running, we don't have problem with ptrace_disable.

> > and for that to be truly useful
> > I suppose PTRACE_SETOPTIONS shouldn't require trapped state either.
> 
> Hmm. Why? we could pass this options along with PTRACE_SEIZE?

Hmmm... I just don't see any reason to combine them.  If the tracer
wants sync points, it can INTERRUPT tracee and adjust options;
otherwise, it can just do it.  Isn't that simpler?

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/