Re: linux-next: add utrace tree

[Ingo Molnar]

* Kyle Moffett <kyle@xxxxxxxxxxxxxxx> wrote:

> On Fri, Jan 22, 2010 at 19:22, Linus Torvalds
> <torvalds@xxxxxxxxxxxxxxxxxxxx> 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 problem is, utrace does not do that really.

What utrace does is that it provides an opaque set of APIs for unspecified and 
out of tree _kernel_ modules (such as systemtap). It doesnt support any 
'application' per se. It basically removes the kernel's freedom at shaping its 
own interaction with debug application.

If utrace was a 'better ptrace' syscall, where the syscall itself is the goal 
of the hookery, it would all be rather different. People could argue about 
_that_ interface (and the hooks would be a pure kernel internal 
implementational detail - not an interface specification), and once people 
agree about that ABI and there's enough application momentum behind it, the 
hooks are really not that opaque anymore - they are for that ABI and not more.

Note that it's still a _big_ hurdle: it's hard to agree on a new syscall and 
it's hard to get 'application momentum' behind it. Special Linux system calls 
have a checkered past, they tend to not be used by much anything, and thus 
they tend to be a breeding ground of both bugs, maintenance complexity and 
security problems. Lack of attention is never good.

In that sense it might be better to fix/enhance ptrace, if there's interest. 
I've written a handful of ptrace extensions in the past (none of them went 
upstream tho), it can be done in a useful manner and the code is pretty 
hackable. There are basic problems left to be solved: for example why is there 
still no 'memory block copy' call, why are we _still_ limited to one word per 
system call PTRACE_PEEK* memory copies? It's ridiculous. SparcLinux has 
PTRACE_WRITE*/READ* support that implements this, but none of the other 
architectures have it so it's essentially unused.

Or another possible direction would be to extend the perf events syscall with 
interception capabilities. It's far more performant at extracting application 
state without scheduling than any ptrace method - and interception/injection 
would be a natural next step - if there's interest.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/