lkml.org 
[lkml]   [2002]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:24    [W:1.164 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site