Re: script safety - no outside calls

[Suparna Bhattacharya <suparna at in dot ibm dot com>]

On Thu, Feb 24, 2005 at 10:58:38PM -0800, Chen, Brad wrote:
> 
> 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?

kprobes/dprobes sort of silently disables probes on such
recursion.

Regards
Suparna

> 
> 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.
> 

-- 
Suparna Bhattacharya (suparna@in.ibm.com)
Linux Technology Center
IBM Software Lab, India