SAFE KERNEL EXTENSIONS WITHOUT RUN-TIME CHECKING George C. Necula Peter Lee Carnegie Mellon U

Overview Paper presents a technique allowing kernels to check extension safety –Code receiver defines a set of safety rules that guarantee safe behavior of programs, – Code producer creates a formal safety proof that its code adheres to the safety rules –Code receiver uses a simple and fast proof validator to check that the code is safe

Starting Idea Code Producer Code Consumer Untrusted code Verifies safety of code Good idea but …

Starting Idea Code Producer Code Consumer Untrusted code Verifies safety of code Formally proving the safety of untrusted code requires a large amount of effort

Shift the burden to the producer Code Producer Code Receiver Untrusted code + Safety Proof Validates proof Works better Proves safety of its code

Proof-carrying code Code producer must establish and prove the safety of the code –Attaches proof to code Code consumer only has to validate the proof –Much simpler task

Advantages Code producer does most of the validation work Code consumer does not care how the proofs are constructed PCC programs are tamperproof –Changing the code voids the proof No cryptography No trusted third parties Errors are detected before code is run

Difficulties How to encode the formal proof? How to check the proof? –Not an easy task How to relate the proof with the program?

Implementation Basic elements: –Formal specification language used to express the safety policy –Formal semantics of the language used by the untrusted code –Language used to express the proofs –Algorithm for validating the proofs –Method for generating the safety proofs

Formal Specification Language Expresses the safety policy of the receiver Uses first-order predicate logic extended with predicates for type safety and memory safety

Formal semantics of language Describes the language used by the untrusted code – A logic relating programs to specifications Untrusted code is DEC Alpha machine code – Was at that time the fastest microprocessor

Proof language Variant of Edinburgh Logical Framework (LF) –Essentially a typed lambda calculus –Can easily encode a wide variety of logics, including higher-order logics

Proof validation Simple LF type checker Basic tenet of LF is that proofs are represented as expressions and predicates as types –In order to check the validity of a proof we only need to typecheck its representation

Generating safety proofs Uses a theorem prover –First, the code is scanned by the same verification generator that the consumer uses –Then the predicate is submitted to a theorem prover that attempts to prove that predicate –In case of success, prover emits an LF representation of the proof

Application Machine code implementation of network packet filters Safety policy was focused on fine- grained memory safety Safety proofs were smaller than 800 bytes Required no more than 3ms on a DEC Alpha to be validated.

More details Observe that all four filters are very small

Run time Average per packet runtime of the four PCC packet filters Compared with –BSD Packet Filter Interpreter (will be slow!) –Using software fault isolation –Using a safe subset of Modula 3 plus the VIEW extension for safe pointer casting

BFI is worst!

Conclusion PCC allows server or kernel to interact safely with untrusted code PCC has no runtime overhead for receiver Safety policies are defined by receiver –Much more flexible Too bad that safety proofs are so hard to construct!