Re: safety paper redux

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -


I have mostly just editorial comments this time.


> [...]
> When not in guru mode, Systemtap should protect users from the
> following safety issues: 
> - infinite loops. Systemtap should limit looping constructs such that
>   they cannot continue to loop beyond some reasonable limit. A script
>   with an infinite loop should fail with a useful error message and
>   otherwise cause no ill-effects to the system. 

Too much of this text is replicated below.  This list could be less
bulky while communicating just as much.

> [...]
> - invalid pointer errors. An attempt to dereference an invalid pointer
>   should either be impossible or result in a graceful failure. 
> - heap memory bugs. [...]
> - priviledged instructions. [...]
>   to execute priviledged kernel instructions [...]
>   [to call arbitrary kernel functions]

If we bother enumerate these at all, they belong in some sort of "must
not happen" or "potential tool bugs" list, since normal scripts would
not be able to do any of this.  In any case let's not bother list all
these issues *twice* in the paper (once in the "problems" and again in
the "solutions" subsections).


> The data and code reference restrictions described above would impact
> only references outside the linked tap. 

(FWIW, I am irked by this term "tap" to describe a compiled probe
script.  Do we need such a term?  Does someone have another
suggestion?)


> [...]
> DESIGN OPTIONS
> Before suggesting some plans to address the above safety issues, we
> review the system components which may be of use towards this goal.
> [...]

This section, while illustrative in a paper dedicated to the subject,
should not be also transcribed into the architecture paper.  The
unchosen hyptotheticals don't really matter there.
 

>   [...]
>   There are several useful policies that are simple to implement, 
>   including: 
>   - guru mode: all writes and code references allowed
>   - default: no external writes or code references allowed
>   Other policies might be added as we accumulate experience with 
>   systemtap:
>   - unpriviledged mode: restrict memory reads based on UID
>   - device safety mode: no reads to volatile memory
>   - profile guru mode: write permission extended to kernel data
>     structures that maintain sample-based profile data. [...]

Thanks for trying to put more justificative meat behind the "portal"
concept.  I'm still not sure I buy it, but there's now something more
specific to think about.


> PROPOSED DESIGN
> [...]
> Given the above safety issues, here's a proposal for how to address
> them in Systemtap:
> - infinite loops

(Again there is too much repeated text below.)

>   - [...]
>   - For safe mode, a static checker will confirm that all loops in
>     code compiled from scripts are instrumented.

Do you imagine it would be straightforward for a static analysis
widget to identify counter-checking conditional-branching code, even
in the face of compiler optimization?


> - infinite recursion
>   [...]
> - division by zero
>   - Elaboration recognizes division/modulus and implements it using a
>     call-out to the systemtap runtime 
>   - No C division or mod operations will appear in the code generated
>     by the elaborator, so there will be no division instructions in
>     the resulting machine code. [ARE WE SURE ABOUT THIS?]

That's not at all necessary.  The translator's output can include
inline checks for stuff like this.  If the only point of indirection
into the runtime is for a static checker to be happy, that's not
a very good reason.

>   - Assumption: No tap will be linked against a module that includes
>     unprotected division operations. [CAN WE ACTUALLY PREVENT THIS?]

"must not happen", i.e., linkage is performed by the translator/driver.


>   [...]
> - array-bounds errors 
>   - Elaborator will emit explicit array-bounds checks for all array
>     references. [...]

Given that our arrays are all associative, bounds checking is not like
comparison of an index against a base-bound address interval.  The
emitted code would use whatever lookup-table API is found in the
runtime.


> - invalid pointer dereferences 
>   - The Systemtap language will not support pointer variables or
>     refs. In this way invalid pointers will not be possible for memory
>     objects created by Systemtap. [...]

Then do these items need so much detail?

> - heap memory bugs [...]
> - illegal kernel  instructions [...]
> - priviledged instructions [...]
> - memory read and write restrictions
>   [...]
>   - The Systemtap language implementation might reject kernel and user
>     memory data structures as l-values and as procedure call arguments
>     so that disallowed writes can be detected at compile time.  
>   - The elaborator will recognize references to kernel data structures
>     and user memory, directing them through the portal.

Maybe.  Still, if the raison d'etre for the portals is to enable the
concept of a static checker, then this is not very persuasive.  That's
because substantially the same checks could be performed inline and by
validity-querying calls into the runtime.


> [...]
> Given the above implementation plan, the Systemtap "guru" mode code be
> implemented as follows:
> - safety policy [...]
> Similarly, "safe" mode could be implemented as follows:
> - safety policy [...]

Alternately, they can be implemented by having the translator accept a
different subset of the input script language, and emit a different
set of checking fragments in the output C code.


> COMPARISON TO OTHER SYSTEMS
> [...]

This is definitely a good section to put into the archpaper.


> [...]
> APPENDIX: USAGE MODELS
> 
> This is an attempt to catalogue common scenarios pertaining to safety
> and security. [...]

I don't know what you intend someone to *do* with this M## list.


- FChE