Programmability with Proof-Carrying Code

1. Programmability with Proof-Carrying Code George C. Necula University of California Berkeley Peter Lee Carnegie Mellon University

2. Why Programmable APIs • Pros: • Standardize “how” not “what” (mechanism vs. policy) • Easy to customize functionality & performance • Move the computation closer to the data • Richer API • Cons: • Security risks? • Performance degradation? • More complex system • Bigger trusted infrastructure ? • Harder (impossible?) to predict global behavior • Programming language technology can help George Necula “Programmability with Proof-Carrying Code”, OpenSig’99

3. Safety Through Run-Time Checking big and complex compiler untrusted client app. code verified? No way! host native code expensive limited safety policy Hardware memory protection / Interpreter / Monitor constrained data representation run-time aborts run-time is too late! George Necula “Programmability with Proof-Carrying Code”, OpenSig’99

4. Software Safety: Java Java app. code Javac untrusted client host Java byte code Limited, fixed safety policy Java Verifier still big and complex (and buggy?) JVM JIT slow native code still slow! not verified George Necula “Programmability with Proof-Carrying Code”, OpenSig’99

5. Our Idea: Proof-Carrying Code (PCC) • Use static checking for both safety and performance • Static checking is possible (and in fact easy) if the client supplies evidence attesting to the safety of the code • For an important class of properties, the evidence can be produced by a client-side compiler George Necula “Programmability with Proof-Carrying Code”, OpenSig’99

6. Certifying compiler application code optimized native code proof Proof checker Proof-Carrying Code (PCC) automated support in a familiar tool untrusted client small & tamper- proof host formal safety policy safety with maximum performance simple, small, & fast CPU Flexible, customizable safety policies George Necula “Programmability with Proof-Carrying Code”, OpenSig’99

7. What You Can Do With PCC • Any property with an adequate formalism can be enforced • if you can prove it, PCC can check it! • One proof-checker for all policies! • Small commitment for open-ended flexibility • Example: safety policies defined by safe interpreters • E.g, security monitors, memory safety, resource usage limits, … • The interpreter need not be directly implementable! • E.g, a pointer points to a null-terminated string • … can be enforced statically with PCC • The proof says that all run-time checks will succeed • No run-time penalty • No data representation constraints • Effective enforcement of timing constraints George Necula “Programmability with Proof-Carrying Code”, OpenSig’99

8. PCC Beyond Memory Safety Example: database with multi-level access control • Safety policy: • host invokes the agent with: • security clearance level • route and price fields readable only if access <= level • parent • communication permitted only back to parent • must terminate within MAX instructions • wait BNDW * SIZE instructions before sending SIZE bytes • Proofs are bigger now (300% of code) access route price agent • level • parent fare pricing server PCC is not limited to memory safety! George Necula “Programmability with Proof-Carrying Code”, OpenSig’99

9. Experience with PCC • Producing the proofs of safety is generally hard • But can be automated in certain cases • E.g., Type safety, monitor-based safety policies • Automation idea for type safety: • start with a type-safe language • the proof exists at source level; just preserve it! • Compile the proof while compiling the code • Experimental results for a safe-C compiler • Speed of code on par with traditional optimizing compilers • Proofs are 10%-40% the size of the code • Proof checking is fast (~ 100Kb/s) • Checker + machine code parser is small (~50Kb for x86) • A certifying compiler for Java is being built by Cedilla Systems George Necula “Programmability with Proof-Carrying Code”, OpenSig’99

10. Conclusions • The is a need for system extensibility without sacrificing safety and performance • Programming language technology can provide all of these in a small and flexible package • Type safety for optimized machine code is here • More research is needed to automate proof generation for more complex safety policies • Try proof-carrying code online • http://www.cs.berkeley.edu/~necula/pcc.html George Necula “Programmability with Proof-Carrying Code”, OpenSig’99

11. Supplemental Slides

12. Touchstone vs. C Compilers • Touchstone has the extra burden of removing bounds checks Certifying compilation and PCC coexist with optimizations! George Necula “Programmability with Proof-Carrying Code”, OpenSig’99

13. Proof Sizes • Geometric means: • proofs are 20% of code • invariant annotations are 20% of code George Necula “Programmability with Proof-Carrying Code”, OpenSig’99

14. packet filter network monitoring application network Experiment: Network Packet Filters user process space OS kernel • Safety policy: • packet read only • no loops • Wrote filters using: • Touchstone + PCC • Modula-3 • SFI (sandboxing) • BPF (interpreter) George Necula “Programmability with Proof-Carrying Code”, OpenSig’99

15. PCC Packet Filters • PCC filters are safe and fast • 10x interpretation, 2x Modula-3, 1.3x sandboxing • PCC can certify even hand-optimized packets! • Proof sizes and checking times are small • proof overhead: 20% (smaller than signatures !) • proof checking time: 1-3ms (amortized quickly) George Necula “Programmability with Proof-Carrying Code”, OpenSig’99

16. Invar Code Minimal-Cooperation PCC Host Client Safety policy Certifying Compiler Source VC Generator Logic VC Theorem Prover Code Proof Checker Proof George Necula “Programmability with Proof-Carrying Code”, OpenSig’99

17. Invar Code Firewall-based PCC Host within enclave Firewall Client Safety policy Certifying Compiler Source VC Generator Logic VC Theorem Prover Code Proof Checker Proof Code George Necula “Programmability with Proof-Carrying Code”, OpenSig’99