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 - please send feedback!


I agree with most of your comments. 
A few requests for clarification and exceptions are noted below. 

>> 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.

>> [...]
>> G9. Restricted reads. Disallows reads as per some policy TBD. For
>>   example, user memory read access might be restricted to processes
>>   belonging to the user running the script. 
>
>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.

>> G10. Remote compilation. Allow scripts to be compiled on one machine
>>   for use on a different machine. [...]
>
>How is this a safety issue?
It's actually an "unsafety" issue. It introduces failure 
modes that don't occur otherwise.

>>   [...] DTrace appears to be crashproof. [...]
>
>I wonder if this appearance has been tested much by an aggressive
>attempt.
I haven't tested DTrace myself. Unfortunately, in some situations, 
perception is reality.

>> [...]
>> - Illegal instructions: The tap could be disassembled to confirm that
>> it does not include priviledged system instructions or instructions 
>> that are not allowed in the kernel (floating point, MMX, SSE, etc.)
>
>But the translator will not emit such stuff, and the same compiler
>options will be used as used to build other kernel modules.  So
>systemtap kernel objects won't contain such miscreancies unless they
>have been tampered with.
>> - Illegal external instruction references. The static checker could
>> examine external references [...]
Such problems could accidently creep in through:
- linking against the wrong module
- binary copied from a remote source
- a mistake specifying a script file (imagine tab completion)
Many people who aren't kernel experts (and many who are) would 
appreciate a little bit of protection.

>> - Illegal external data references. The static checker could examine
>> memory reference instructions [...]
>
>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. But the language 
implementation needs to cooperate. Trivial policies like "all reads 
okay" "all writes disallowed" are easy to implement by the portal.

>> - 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. Case statements might cause problems but
loops and if/then/else constructs are generally fine. 
The linker does most of the hard work , so it would mostly 
be a matter of checking the work of the linker.

>> [...]
>> 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
but most won't choose to do so, and would prefer tools that make
it harder for them to do so by accident, as long as the tools 
aren't harder to use.

Do you really expect people would use "insmod" rather than
"systemtap" for pre-compiled scripts? Perhaps the reason to
have "systemtap" as a different command is that it might be
safer. I think there are many things that "insmod" can do
but that you wouldn't want to be able to do with systemtap.


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