Re: linux-next: add utrace tree
From: Ingo Molnar
Date: Sat Jan 23 2010 - 06:24:17 EST
* 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.
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/