This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
RE: script safety - no outside calls
- From: "Chen, Brad" <brad dot chen at intel dot com>
- To: "Vara Prasad" <prasadav at us dot ibm dot com>
- Cc: "SystemTAP" <systemtap at sources dot redhat dot com>
- Date: Thu, 24 Feb 2005 22:58:38 -0800
- Subject: RE: script safety - no outside calls
There are definitely safety issues.
Suppose we let people call arbitrary kernel functions
from their scripts, then we better be sure the system
fails in a friendly way when an stap script calls a
kernel function with an active tap.
If on the other had systemtap scripts access kernel
routines only through a library that we provide; then we
can be responsible for the safety of the code in that
library. For example, we can be sure that code used by
the library is tap-free, or that taps set in code used
by the library are somehow deactivated or ignored. This
is the model I was assuming. I might not insist it be
the only model we support, but I would be inclined to
insist we support it or something comparable as an
option.
If the amount of kernel code reachable from a script is
small, it might be easier to simply duplicate it, so that
we could make it untappable and thereby make the recursive
failure case architecturally impossible.
In the end I think the Sun folks were pretty smart about
the safety features in DTrace, so hopefully people won't
get tired of me double-checking that we are sure when we
decide to play loose on such issues.
Did you have a different idea about how to avoid tap
recursion? Perhaps kprobes or dprobes does something
clever here?
Brad
-----Original Message-----
From: Vara Prasad [mailto:prasadav@us.ibm.com]
Sent: Thursday, February 24, 2005 5:13 PM
To: Chen, Brad
Cc: SystemTAP
Subject: Re: script safety - no outside calls
Chen, Brad wrote:
>I assume that a module loaded with insmod() can any kernel
>subroutine it cares to. In the case of modules loaded for stap,
>we might choose not to support calls into arbitrary OS routines,
>similar to DTrace. By not support calls into kernel code you
>create a clean separation (at least conceptually) between kernel
>code and systemtap code, and avoid invocation of instrumented
>kernel code by scripts.
>
>For these reasons I'm assuming that systemtap scripts can only
>call into a designated systemtap runtime. Any strong feelings
>to the contrary?
>
>Brad
>
>
I don't agree that we should limit accessing kernel functions. If we do
that,
some of the common features kernel provides that we also need example
dumpstack(), timestamp() etc we will end up duplicating the code, which
i am sure no one likes.
What we might want to provide is an easy interface for most commonly
accessed
functions by virtue of providing systemtap library functions, they
internally call kernel
functions directly. The main reason of providing these library functions
is to make
scripts portable from one version of the kernel to other. That means the
burden falls
on us to keep these libraries up to date along with kernel changes.
I am hoping we will only have few set of functions in this library and
underlying
kernel functions wont change often. If some one wants to refer to kernel
functions
directly in the scripts we should let them do so.
Dtrace uses an interpreter similar to Dprobes hence they can not access
kernel functions directly. I am not sure this is a safety issue, it is
more of
the limitations of an interpreter.