1 / 20

SAFE KERNEL EXTENSIONS WITHOUT RUN-TIME CHECKING

This paper introduces a technique for kernels to enforce extension safety using safety rules defined by the receiver and proven by the producer. A proof validator ensures code safety without runtime checking. By shifting the safety burden to code producers, the system becomes tamperproof. However, difficulties arise in encoding, checking, and relating the formal proofs. The proposed implementation includes a specification language, formal semantics for untrusted code, a proof language, and algorithms for validation and proof generation. The Proof-Carrying Code (PCC) concept is applied to network packet filters with minimal runtime impact, outperforming other methods. PCC offers safe interaction with untrusted code, flexibility in defining safety policies, and zero runtime overhead.

kunze
Download Presentation

SAFE KERNEL EXTENSIONS WITHOUT RUN-TIME CHECKING

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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?

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

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

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

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

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

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

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

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

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

  18. BFI is worst!

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

More Related