SAFE KERNEL EXTENSIONS WITHOUT RUN-TIME CHECKING

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

2. 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 proofthat its code adheres to the safety rules • Code receiver uses a simple and fast proof validatorto check that the code is safe

3. Starting Idea • Good idea but … Untrusted code Code Producer Code Consumer Verifiessafetyof code

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

5. Shift the burden to the producer • Works better Untrusted code +Safety Proof Code Producer Code Receiver Proves safetyof its code Validatesproof

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

7. 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 • Nocryptography • No trusted third parties • Errors are detected before code is run

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

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

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

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

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

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

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

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

17. More details Observe that all four filters are very small

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

19. BFI is worst!

20. 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 proofsare so hard to construct!