Messages in this thread | | | Date | Tue, 12 Feb 2002 23:43:17 +0200 (EET) | From | guy keren <> | Subject | Re: faking time |
| |
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/
| |