RE: safety paper redux

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

A few comments.

>> No. Safety mode would probably have to use a compiler 
>> optimization level that the static analyzer had been 
>> designed and tested to handle. [...so turn down to -O0...]
>
>OK.  I wonder to what extent the same would apply to other common but
>checkworth constructs. 
If we assume relatively vanilla compilation, the hardest
problem is confirming constraints on external data references.
Others are relatively straightforward.

>> I don't think inline checks are adequate to match the safety of 
>> the systems that use interpreters. The interpreters protect against
>> a bunch of problems that could arise between elaboration and insmod.
>> Considering division by zero as represenative of such problems, what 
>> might we do to make a user more comfortable he/she was protected from

>> division by zero bugs? Asking them to read a bunch of src or asm will
>> leave many users unsatisfied.
>
>But in the interpreter case, aren't they asking them to trust it
>blindly, or else read *its* source?
Not exactly. They trust that the community could read the source
and that gives them some degree of confidence, even if they don't
read it themselves. They also trust that interpreters aren't made 
to execute priviledged instructions, in the same way that shoes 
aren't made to explode.
In the case of Systemtap kernel modules, there could be real and
imaginary install or usage related problems that no amount of 
anybody reading source would address. These could arise from 
storage/reuse of compiled probe .ko's, path problems, compiler 
bugs, linker bugs, etc. I admit that some of these problems may 
be rare, but I'm not comfortable assuming all such problems are 
improbable.

>> The raison d'etre would be to allow for late binding of the safety 
>> policy. Checkability is a secondary benefit.
>
>This is an interesting idea, but any sort of "lateness" seems to occur
>temporally only if users store/distribute/reuse compiled probe .ko's.
I had been assuming that store/reuse/etc was a requirement. 
It would certainly simplify a few things if it were not, but
then everyone would have to have the compiler installed...
The late bind of security would also be useful if you wanted
to expand the policy for a script but not enable all of guru
mode. For example, you might allow external calls to an
explicit list of kernel subroutines, or writes to an explicit 
range of kernel memory addresses. Such policies would be much 
safer than guru mode. Of course a lot of this could be done at
compile time too, but to me it seems simpler architecturally
to do it at run time.

Brad

-----Original Message-----
From: systemtap-owner@sources.redhat.com
[mailto:systemtap-owner@sources.redhat.com] On Behalf Of Frank Ch.
Eigler
Sent: Wednesday, April 06, 2005 10:15 AM
To: Chen, Brad
Cc: systemtap@sources.redhat.com
Subject: Re: safety paper redux

Hi -


> > 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?
>
> No. Safety mode would probably have to use a compiler 
> optimization level that the static analyzer had been 
> designed and tested to handle. [...so turn down to -O0...]

OK.  I wonder to what extent the same would apply to other common but
checkworth constructs.


> > That's not at all necessary.  The translator's output can include
> > inline checks for stuff like this.  [...]
>
> I don't think inline checks are adequate to match the safety of 
> the systems that use interpreters. 

Why not?  A division-by-zero check must be just as explicit
(specialized, non-generic) in the interpreter as in the translated
code.  What kinds of checks are there that an interpreter could
perform, but the same logic inlined within the C code couldn't?

> The interpreters protect against a bunch of problems that could
> arise between elaboration and insmod.

I suppose, but at the cost of introducing a bunch of potential
problems within the interpreter proper.  Is it a wash?

> Considering division by zero as represenative of such problems, what 
> might we do to make a user more comfortable he/she was protected from 
> division by zero bugs? Asking them to read a bunch of src or asm will
> leave many users unsatisfied.

But in the interpreter case, aren't they asking them to trust it
blindly, or else read *its* source?


> > Maybe.  Still, if the raison d'etre for the portals is to enable the
> > concept of a static checker [...]
>
> The raison d'etre would be to allow for late binding of the safety 
> policy. Checkability is a secondary benefit.

This is an interesting idea, but any sort of "lateness" seems to occur
temporally only if users store/distribute/reuse compiled probe .ko's.

Otherwise, the .ko's are transient, and thus the translator imposes
whatever restrictions the user wishes right during the
translation/build pipeline.  Then a "later" safety binding is only
milliseconds later, and doesn't appear to buy anything extra.


- FChE