linux-kernel - Re: linux-next: add utrace tree

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:	Mon, 25 Jan 2010 13:41:57 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Tom Tromey <tromey@...hat.com>
cc:	Kyle Moffett <kyle@...fetthome.net>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Peter Zijlstra <peterz@...radead.org>,
	Fr??d??ric Weisbecker <fweisbec@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	linux-next@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com>,
	utrace-devel@...hat.com, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: linux-next: add utrace tree

On Mon, 25 Jan 2010, Tom Tromey wrote:
> 
> There are definitely things we would like from such an API.  Here's a
> few I can think of immediately, there are probably others.
> 
> * Use an fd, not SIGCHLD+wait, to report inferior state changes to gdb.
>   Internally we're already using a self-pipe to integrate this into
>   gdb's main loop.  Relatedly, don't mess with the inferior's parentage.

As I kind of alluded to elsewhere, I heartily agree with this. The really 
major design mistake of ptrace (as opposed to just various ugly corners) 
is how it has no connection information, and that ends up being one of the 
main reasons why you can't have two ptracers working on the same thing.

(There are other things that complicate that too, of course, like simply 
just trying to manage various per-thread state like debug registers etc, 
but that's a separate class of complications).

> * Support "displaced stepping" in the kernel; I think this would improve
>   performance when debugging in non-stop mode.

Don't we already do that at least on x86? Just doing a single-step should 
work on an instruction even if it has a breakpoint on it, because we set 
the TF bit.

Or maybe I'm not understanding what displaced stepping means to you.

> * Support some kind of breakpoint expression in the kernel; this would
>   improve performance of conditional breakpoints.  Perhaps the existing
>   gdb agent expressions could be used.

I suspect it might be reasonable to do simple expressions on breakpoints, 
but not the kind of things gdb exports to users. IOW, maybe you could have 
a single conditional on a single value (register or memory) associated 
with an expression.

Regardless, internally to the kernel your two later issues are "details". 
The "how to connect to the debuggee" is a much more fundamental issue, and 
has the biggest design/interface impact. The other would likely just be 
new ptrace command extensions that somebody would have to just implement 
the grotty details on.

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