linux-kernel - Re: [PATCH 1/1] ptrace: make sure do_wait() won't hang after 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Sat, 5 Feb 2011 14:39:26 +0100
From:	Tejun Heo <tj@...nel.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Roland McGrath <roland@...hat.com>, jan.kratochvil@...hat.com,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org
Subject: Re: [PATCH 1/1] ptrace: make sure do_wait() won't hang after
 PTRACE_ATTACH

Hello, Oleg.

On Fri, Feb 04, 2011 at 06:06:02PM +0100, Oleg Nesterov wrote:
> > I think a good compromise would be guaranteeing that when the ptracer
> > goes away, the tracee would put into the state the real parent can
> > agree to and the real parent to be notified that it has happened.
> 
> I am not sure. The tracing should be transparent as much as possible.

Yes but there are different ways to achieve that.  Please read on.

> > We are already skipping all notifications to the real parent for
> > ptraced children, there's no pressing need to change that.  If
> > there becomes a real pressing requirement to change that.
> 
> And this looks just wrong to me. Say, why the ptraced application
> doesn't react to ^Z ? It does, just it parent have no chance to see
> this. (yes, yes, we should also change do_wait).

That's the shortcomings of the current implementation.  The specific
problem sure can be fixed by putting group stop on top of ptrace but
that is not the only direction.  In fact, that actually is the
direction we CAN'T take with ptrace because changing that will create
a lot more problems that can't be worked around.

We can introduce something completely new but we can also augment the
current implementation with what's necessary to remedy the problem.
The ptracer is already notified when the ptracee enters group stop.
There's nothing stopping us giving ptracer the ability to tell ptracee
to participate in group stop completion and notify the real parent.
It will be an extra feature, probably a new PTRACE_ operation.  This
way, the existing users behave the same way while the ones which are
updated to use the new feature would behave better w.r.t. group stop
while being ptraced.

The above is one of may possibilities and it might not be possible /
desirable as described.  I haven't thought that much about it, but my
point is that "oh, we'll have something completely new which cures
everything at once, so let's reject changes to the current code as
much as possible" does not help anyone.  Approaches like that rarely
work.  For example, the problem in this thread is cleanly solved by
really examining the problem and fixing the problem at the source (the
mixup of group and ptrace stop) and accumulating those proper
improvments and thus evolving the code base is a much more effective
way.

So, let's stop chasing unicorns.  Cake is a lie.  Let's work on what
we already have and incrementally improve it.  There might be some
extreme corner cases where userland might notice differences but as I
wrote before given the wide range of inconsistencies the current code
is showing, I think we actually have good amount of latitude.  It'll
be mostly about making sensible tradeoffs and testing the existing
users.

> > I could be wrong (with pretty high probability) but I don't really see
> > the pressing need for a completely new API.  ptrace sure is ugly and
> > quirky but it's something people are already used to.
> 
> I won't argue. And yes, in any case ptrace can't go away, we should
> try to improve it anyway. The obvious problem is that almost any
> "visible" improvement breaks something.

I don't believe any 'visible' improvement breaks something.  In fact,
the current users seem quite resillient to behavior changes (they
should as the current code behaves inconsistently in many places).
There sure will be some cases which would be put into
undefined/unsupported area but there's no reason to preserve every
single inconsistent detail of the current behavior.  As everything
else, it is a trade off we can make.

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/