Re: safety paper - please send feedback!

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

Hi -


On Thu, Mar 24, 2005 at 02:16:46PM -0800, Chen, Brad wrote:
> [...]
> >> G7. No non-Algol control flow. Excludes goto, longjmp [...]
> > How is this a *safety* issue?  (I'm not proposing to support them
> > in the script language, but why did you bring it up?)
>
> If we could establish a few properties such as compiled scripts 
> can't jump into the kernel then we could use such properties to
> recognize bad scripts.

But even if we wanted goto and longjmp in the scripting language, they
would not enable jumping into the kernel, just as a "return" from a
java function doesn't just jump into the JVM.  Having goto and longjmp
in the C code emitted by the translator is possible but I hope not
needed.


> >An unprivileged user cannot be allowed to read arbitrary kernel memory
> >either, as that's an easy way to violate privacy boundaries.
>
> Clearly there is a ton of design and implementation work  
> required to realize this, right? It is not obvious to me that
> we could get this done in the early versions of the system.

Agreed.


> >> - Illegal external instruction references. The static checker could
> >> examine external references [...]
> Such problems could accidently creep in through:

> - linking against the wrong module

I don't understand what this could be, given that the only linking is
being done during translation.

> - binary copied from a remote source

Only if it is not a systemtap-generated .ko.

> - a mistake specifying a script file (imagine tab completion)

No valid script file should result in an invalid translation.

> Many people who aren't kernel experts (and many who are) would 
> appreciate a little bit of protection.

Certainly: the devil is in the details.


> >Same as above, plus memory reads and writes would be hellish or even
> >impossible to check statically in the general case.
>
> I disagree. You are right about the most general case, but we avoid 
> the difficulty of the general case by directing references through 
> a portal. It's easy to check that all references are either statically 
> checkable or directed through the portal.

Just to make sure we are using clear-cut terminology: do you imagine
the C compiler producing only such machine instructions that all
load/stores go through some intermediate runtime function, or are
"valid" in some other trivial manner?  Take a look at the assembly
code generated from the various sample hand-written C probes that
wcohen and mhunt have posted lately.  How many of those loads/stores
do you imagine could be reasonably mapped to function calls?  How
different do you think systemtap-generated C would need to be?


> But the language implementation needs to cooperate. Trivial policies
> like "all reads okay" "all writes disallowed" are easy to implement
> by the portal.

Having only these two trivial policies to point to makes it hard to
justify the portal concept.  Such trivial policies could be
implemented by the hypothetical static checker just as easily, without
having to have a portal at all.  To motivate this idea, a more complex
example is necessary.


> >> - Illegal control flow. The static checker might disallow non-local
> >> non-procedural control flow. It might disallow backward branches,
> >> assuming the source language were loop-free.
>
> >This restriction is unlikely to be met by the object code.
>
> It should be possible to generate object code such that all 
> control transfers are either statically resolved, directed 
> through the portal, or recognizable as being a part of the 
> Systemtap runtime. [...]

Same idea as above: instead of looking at the loads/stores, look at
all the branches in the assembly code.  Are all those really easily
transformable to constructs that can be easily checked?  And can a
C compiler be made to perform those transformations?


> >> [...]
> >> Extension B: Static Checker
> >> 
> >> A static checker confirms safety properties of a compiled Systemtap
> >> script immediately prior to loading into the kernel. 
> >
> >There is little advantage to a user-level static checker that enforces
> >this stuff, unless we're talking only about unprivileged users.  A
> >root user can load anything into the kernel, bypassing the static
> >checker with "insmod" by mistake.
>
> I disagree. A root user can certainly shoot himself in the foot [...]

Many of the static checks being discussed catch those scenarios where
a user has already made some griveous error, such as bringing in an
incompatible or untrustworthy object file from someplace, or
corrupting some binary; or else some major bug in the systemtap
translator or build system.  So the foot has already started
bleeding...

I brought up the issue only to illuminate the remote possibility of
putting such a static checker into the kernel, where an errant root
user might have a harder time making a mistake.


> Do you really expect people would use "insmod" rather than
> "systemtap" for pre-compiled scripts? [...]

Not at all, mainly because it is the user-level driver program that
will extract data snapshots or traces from the running probes and show
them to the user.


- FChE

Attachment: pgp00000.pgp
Description: PGP signature