On Tue, 12 Feb 2002, Pavel Machek wrote:
> > it's in alpha stages right now, but it seems pretty stable so far (It
> > Works For Me - i run it regularly on all of my machines). note that we
> > currently support only logging system calls (a-la strace) and failing
> > them with a user given parameter- rewriting system call parameters will
> > require additional hackery, but not too much of it - on the order of one
> > day of work. volunteers are welcome.
>
> Why do you need kernel module at all?
since we want to trace unknown processes. if you check the home page,
you'll see a few examples of situations in which strace, or any user-land
solution that does not trace the _entire_ system, can't handle properly.
we also want to have a minimal performance penalty - anything using ptrace
has a large performance penalty.
> BTW syscall rewriting is pretty hard (subterfugue solves that, but it definitely
> took more than a day.
>
> Imagineopen('/foo/bar')
>
> you rewrite it to open('/funny/bar')
>
> then another thread comes and rewrites it back to '/foo/bar'.
this is because you think of "rewriting the user process's memory" in
user-space. when the code is in the kernel - this is not the case.
ofcourse, you cannot insert a full python (or perl or whatever)
interpreter in the kernel [or perhaps you can? is this complete
blasphemy? :) ]. we do think of adding some interface to externalize
syscall tracing into user-land to allow people to still have such
features, but most usage we envision for this tool won't require that.
> Or imagine open(address in read-only memory).
again - you're talking about user-space intervention that actually
re-writes the user's data. we just want to invoke the syscall with
modified parameters - or to modify the data the syscall returns to the
user (whic won't stem from these race-conditions or r/o problems, since
the user _wants_ to receive that data).
i suggest that you take a look at the project's page if you wish to see
what we have in mind. personally, i hear of "a tool that already does
this" at least once a month. then i think "oh... why do we bother?". then
i go checking and see that it's not doing what we want, or its not doing
it right (user-land that slows the system and cannot trace the whole
system. or too limited filtering mechanisms. or kernel code that only
exports to user-mode, and thus affects performance. or kernel code that
requires patching a kernel, and thus cannot just be compiled and loaded
into a running machine, etc).
hope it helps,
-- guy"For world domination - press 1, or dial 0, and please hold, for the creator." -- nob o. dy
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Feb 15 2002 - 21:00:51 EST