Message-ID: <f73f7ab81001222220jfaf2edfwca3fa4c22b0b4d72@mail.gmail.com>
Date:	Sat, 23 Jan 2010 01:20:53 -0500
From:	Kyle Moffett <kyle@...fetthome.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"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 Fri, Jan 22, 2010 at 19:22, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> There are cases where we really _want_ to have common code. We want to
> have a common VFS interface because we want to show _one_ interface to
> user space across a gazillion different filesystems. We want to have a
> common driver layer (as far as possible) because - again - we expose a
> metric shitload of drivers, and we want to have one unified interface to
> them.

So... Everybody agrees that ptrace() is horrible and a royal pain to
use, let alone use correctly and without bugs.  Everybody also agrees
that ptrace() needs to stay around for a long time to avoid breaking
all the existing users.

Now how do we get from here to a moderately portable API for
interrogating, controlling, and intercepting process state?
Essentially it would need to support all of the things that a powerful
debugger would want to do, including modifying registers and memory,
substituting syscall return values, etc.  I believe that "utrace" is
the kernel side of that API.

The killer app for this will be the ability to delete thousands of
lines of code from GDB, strace, and all the various other tools that
have to painfully work around the major interface gotchas of ptrace(),
while at the same time making their handling of complex processes much
more robust.

The *second* killer app for this is to make it much easier for people
to write new userspace debugging tools.  I love the various
crash-catching tools that different distributions or applications
provide, but they all basically have to trap the SIGSEGV and hope
they're still sensible enough to fork() and exec() a gdb process.

Furthermore, I would love to be able to write debugging tools for
scripting languages that allow me to step across Perl, C, PHP,
assembly code, etc, all within the same process.  In theory that's all
possible today, but given how much of a *pain* ptrace() is to use
correctly, nobody bothers.

Now, with all that said, "utrace" does not provide any of the
userspace side APIs today... but I think it is a necessary refactoring
if we want to provide a new ideal process-introspection interface
without breaking all the ptrace() users.

Think of the "utrace" interface as very much like the LSM interface.
Just like with LSMs, there is a lot of active research in debugging
and tracing tools, and nobody can even remotely agree what the hell
they want out of the hooks.  In theory you could add one hook for
every place each security module needs one... but then your fast-path
is littered with always-false test-and-jump statements.  What "utrace"
provides is the one single test in each fast path that then searches
for and executes the appropriate slow path(s) for that process.

I personally would be very happy to see "utrace" merged.

Cheers,
Kyle Moffett
--
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/

Powered by blists - more mailing lists