Re: linux-next: add utrace tree


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

Relevant Pages

  • Re: HW breakpoints perf_events request
    ... But I rather hope we can extend ptrace interface to handle such new ... having a more scalable breakpoint interface ... Yes, it uses utrace, but that's an implementation detail. ...
    (Linux-Kernel)
  • Re: linux-next: add utrace tree
    ... level of abstraction to the only interface that people actually _use_, ... namely ptrace. ... without the new abstraction layer we will never have, ... which demonstrates both the utility of utrace ...
    (Linux-Kernel)
  • [patch 0/1] x86, ptrace: execution trace support
    ... Execution trace support for application debugging. ... The following patch establishes the user interface and the low-level ... The user interface uses ptrace to expose the feature to application ... interface for utrace. ...
    (Linux-Kernel)
  • Re: [PATCH 2/3] utrace core
    ... implementing user thread tracing and debugging. ... utrace and ptrace do not play together at all. ... The "prototype utrace-ftrace interface" seems to be more a cool toy rather ...
    (Linux-Kernel)
  • Re: [take14 0/3] kevent: Generic event handling mechanism.
    ... so it is not that bad to multiplex them in one syscall. ... Think about size of the mapped buffer when there are several kevent ... feel, that all posix crap is better than epoll interface, then I can not ...
    (Linux-Kernel)