[lkml]   [2010]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: linux-next: add utrace tree

    * Kyle Moffett <> wrote:

    > On Fri, Jan 22, 2010 at 19:22, Linus Torvalds
    > <> 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.



     \ /
      Last update: 2010-01-23 12:27    [W:0.025 / U:8.456 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site