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]

Date:	Sat, 5 Mar 2011 09:47:08 +0100
From:	Tejun Heo <tj@...nel.org>
To:	Jan Kratochvil <jan.kratochvil@...hat.com>
Cc:	Oleg Nesterov <oleg@...hat.com>,
	Denys Vlasenko <vda.linux@...glemail.com>,
	Roland McGrath <roland@...hat.com>,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org
Subject: Re: [RFC] Proposal for ptrace improvements

On Fri, Mar 04, 2011 at 07:12:50PM +0100, Jan Kratochvil wrote:
> On Fri, 04 Mar 2011 18:07:37 +0100, Oleg Nesterov wrote:
> > Suppose that the tracee reports, say, a signal after PTRACE_SEIZE/INTERRUPT.
> > And this is possible anyway if the debugger races with kill(). Why this
> > is bad?
> 
> I was asking if it is possible or if it could be avoided.

First of all, if the conditions are distinguishible reliably, I think
things should be fine.  Also, after seizing, at least two conditions
must be distinguishible immediately - whether the tracee was in group
stop or just ptrace trapped, so I don't think guaranteeing single
condition is feasible to begin with.

> When the tracer has a function to attach a task it should be a self-sufficient
> function returning the tracee in some normal task like after other events.
> So the attach operation should neither leave pending some excessive signals
> nor it should eat some normal vital signals (like PTRACE_EVENT_FORK).

That was one of the reasons why I suggested PTRACE_SEIZE to be both
attach and interrupt.  In both cases, the possible states of the task
would be exactly the same.  As debugger is likely to travel various
paths in the interrupt case regularly, it will be much easier to get
it right and once you get that right, attach becomes right at no
additional cost!

> Sure the tracer can always handle it some way, ignore this signal,
> remember if it has seen that signal etc.  But if we design a new
> ptrace interface it should be simple to use and it should not
> suggest coding racy/buggy tracers.

There's no signal to ignore.  It might not be as simple as you fancy
but will (at least strive to) be reliable and race-free.  I think
racy/buggy tracers have a lot more to do with lack of documentation
and clear rules.  Everyone is left to guess and everyone of course
ends up with different conclusions.  Let's add a detailed
documentation of rules and subtleties.

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/