This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]