RE: safety paper - please send feedback!

["Chen, Brad" <brad dot chen at intel dot com>]

Thanks for the feedback!

I'm afraid I wasn't clear enough in explaining the intent
of this section; I'm not suggesting we implement all of the
safety features G1..15. I am trying to capture the full
range of security features of DTrace, DProbes, Kerninst, etc.
So this section includes redundant features, and features I
wouldn't necessarily advocate implementing.

> G4: I am not sure it is worth generating runtime checks to prevent 
> levels of recursion beyond so many levels, ...
It might be good to make recursion illegal and avoid 
any runtime checks.

> G6:  I think the static portal way of specifying what calls are
allowed 
> from systemTAP scripts is a major maintenance overhead with kernel
code 
> changing at rapid pace.
In the most general case this is true, but the maintenance 
overhead of the portal would be small for trivial yet useful 
policies like "no writes allowed" or "no calls allowed".

> G9: I am not sure how easy to implement this.
You and Frank may be disconnected here. In his note he mentioned
the importance of restrictions for unpriviledged users.

G10. I'd like to talk about this more with you. I'm not 
comfortable with "any generated module". I guess I'd be okay
with this as long as the "safe mode" had sufficient capabilites
to approach (although perhaps not completely achieve) the 
"crash-proof" goal.

Brad

-----Original Message-----
From: Vara Prasad [mailto:prasadav@us.ibm.com] 
Sent: Thursday, March 24, 2005 9:10 AM
To: Chen, Brad
Cc: systemtap@sources.redhat.com
Subject: Re: safety paper - please send feedback!

Here are my quick comments

In G1 you mentioned " A "safety" mode would impose additional safety 
constraints" I am not sure which ones are you referring to in the above 
sentence.

I am not sure if G2 is a concern if the language implements G3. I am o.k

for G3 provided we have constructs like iterator in the language that 
allow us to GENERATE loops even if user is not allowed to SPECIFY loops 
directly. I don't like the Dtrace approach of not allowing loops at all 
in their language.

G4: I am not sure it is worth generating runtime checks to prevent 
levels of recursion beyond so many levels, instead it might be easy to 
have code that prevents stack overrun's using a guard mechanism. Since 
this is a simple scripting language without complications of the 
complete "C" kind of language i think we might be able to prevent
recursive calls using static code analysis, if we choose not to allow 
recursion.

G5: I am not convinced yet why we should not allow simple procedures in 
our language definition. How we generate the code for these procedures 
is entirely up to the translator. I am thinking we will still allow our 
generator to generate procedures, right.

G6:  I think the static portal way of specifying what calls are allowed 
from systemTAP scripts is a major maintenance overhead with kernel code 
changing at rapid pace. A simpler approach would be if  you are running 
in safe mode only function calls allowed to make are the exported tapset

interfaces, which is what Dtrace does.  In Guru mode you are on your 
own. I would think it is not that difficult to implement a system where 
a script
written for guru mode will not be allowed in safe mode.

G9: I am not sure how easy to implement this. We probably should 
understand what is the real goal of G9 and see what alternative ways 
might be employed to achieve the same.

G10: The only restriction should be it should be same architecture and 
running in the required Guru or Safe mode otherwise any generated module

should be allowed to run including backward compatibility or when not 
possible fail safely. This is very important for the success of
systemtap.


This is what i have so far, rest we can discuss in the call or i will 
follow up in my next review mail.