linux-kernel - Re: PTRACE_SEIZE/INTERRUPT: [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: <20110309173042.GA2936@redhat.com>
Date:	Wed, 9 Mar 2011 18:30:42 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Tejun Heo <tj@...nel.org>
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: PTRACE_SEIZE/INTERRUPT: [RFC] Proposal for ptrace improvements

Hi Tejun,

On 03/09, Tejun Heo wrote:
>
> Hello, Oleg.
>
> On Mon, Mar 07, 2011 at 04:08:03PM +0100, Oleg Nesterov wrote:
> > Now that we more or less agree with Tejun's ideas,
>
> Yay! I finally succeeded at wearing down everyone.  :-)

Yes, thanks for correcting me, this is what I actually meant ;)

> > And I think there are other reasons. Say, suppose we want to add
> > the options for ATTACH/INTERRUPT. Right now I do not see the need,
> > but who knows.
>
> I think it would actually be better to share the option flags.  The
> two operations (whether implemented as separate operations or not)
> share the interrupting aspect and I think using separate set of
> options can be a bit confusing.  Hmmm... maybe it's actually better to
> make them have different prefixes and let the attach also accept the
> interrupt flags.

Perhaps, I agree with everything. As I said, I don't have a strong
opinion, just some random thoughts.

> > Final note... Previously I thought that we should not (I meant, can
> > not) change the current behaviour of PTRACE_O_TRACECLONE/etc which
> > sends SIGSTOP during the auto-attach. Now I am not sure, probably
> > we can avoid SIGSTOP if the forking task was PTRACE_SEIZE'ed. IOW,
> > perhaps the new ATTACH can have other "side effects". But, otoh,
> > this can complicate the transition to the new requests. Say, you
> > can't simply change strace to use PTRACE_SEIZE without auditing
> > the "-f" code.
>
> We can add attach option SIGSTOP_ON_AUTOATTACH to help the transition
> but then again it requires userland application change anyway so I
> think it would be better to simply enforce the new behavior when the
> new attach is used.  It's not like lack of SIGSTOP is gonna be super
> subtle.

Agreed.

> > And. This is off-topic, but we can also add PTRACE_DETACH_XXX which
> > does not require the stopped tracee. strace certainly needs it,
> > although INTERRUPT can solve most of the problems.
>
> I don't know.  The thing is that guaranteeing the tracee is in
> TASK_TRACED on attach/detach prevents a lot of subtle corner cases.

Agreed, but detach is different. It has to work with the running
tracee anyway.

However,

> Unless there are pretty compelling reasons, I'd like to keep that
> invariant intact.  What else does strace require that can't be
> provided by INTERRUPT + DETACH?

Yes, probably INTERRUPT + DETACH is enough. At least this certainly
solves the most annoying problems. IIRC. Denys can correct me.

Oleg.

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