This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Attachment: pgp00000.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]