1. Mobility, Security, and Proof-Carrying Code Peter Lee Carnegie Mellon University Lecture 2 July 11, 2001 Overview of PCC and Safety Policies Lipari School on Foundations of Wide Area Network Programming

2. Carnegie Mellon Key Idea: Explicit Proofs Certifying Prover CPU Proof Engine Code Proof Trusted Host

3. Carnegie Mellon Proof-Carrying Code Certifying Prover CPU Code Proof No longer need to trust this component. Proof Checker

4. Carnegie Mellon Questions What is meant by “safety”? Or security or privacy or …? How does the proof checker work? How does it connect code with proof? How are proofs represented? For compactness, speed, and simplicity? How are proofs generated?

5. Carnegie Mellon Today’s Lecture Overview of approaches. High-level architecture. Safety properties. Several detailed examples. Next time: Proof representation, checking, and generation.

6. Overview of Approaches to Certified Code TAL and PCC

7. [To be supplied]

8. High-Level Architecture

9. Carnegie Mellon High-Level Architecture Explanation Code Verification condition generator Checker Safety policy Agent Host

10. Carnegie Mellon High-Level Architecture Explanation Code Verification condition generator Checker Safety policy Agent Host

11. Carnegie Mellon The VCGen The verification condition generator (VCGen) examines each instruction. It essentially encodes the operational semantics of the language. It checks some simple properties. E.g., direct jumps go to legal addrs. It invokes the Checker when dangerous instructions are encountered.

12. Carnegie Mellon The VCGen, cont’d Examples of dangerous instructions: memory operations procedure calls procedure returns For each such instruction, VCGen creates a verification condition (VC). A VC is a logical predicate whose truth implies the instruction is safe.

13. Carnegie Mellon High-Level Architecture Explanation Code Verification condition generator Checker Safety policy Agent Host

14. Carnegie Mellon The Checker When given a VC, the Checker looks in the “explanation” for its proof. If found, it then checks whether the proof is valid. The set of allowable VCs and their valid proofs is defined by the safety policy.

15. Carnegie Mellon A “Dialog” VCGen: Scanning code… VCGen: Danger! This memory-write is safe only if VC = r.P(r) under assumptions  is true. Checker: Looking for proof of VC. Checker: Found proof    : VC. Checker: Checking with safety policy to see whether  is a valid proof.

16. Carnegie Mellon High-Level Architecture Explanation Code Verification condition generator Checker Safety policy Agent Host

17. Carnegie Mellon The Safety Policy The safety policy is defined by an inference system that defines the language of predicates (for VCs) the axioms and inference rules for writing valid proofs of VCs. specifications (pre/post-conditions) for each entry point in the code. Informally, one thinks of the safety policy as defining the constraints on the execution of safe programs.

18. Carnegie Mellon Reference Interpreters A reference interpreter (RI) is a standard interpreter extended with instrumentation to check the safety of each instruction before it is executed, and abort execution if anything unsafe is about to happen. In other words, an RI is capable only of safe execution.

19. Carnegie Mellon Reference Interpreters cont’d The reference interpreter is never actually implemented. The point will be to prove (by using the proof rules given in the safety policy) that execution of the code on the RI never aborts, and thus execution on the real hardware will be identical to execution on the RI.

20. Carnegie Mellon Reference Interpreters cont’d Rule of Thumb: Any notion of safety that can be enforced by a reference interpreter can be encoded in a PCC safety policy.

21. Carnegie Mellon Example Consider a safety policy for x86 code where the code must provide a function whose precondition is that register %eax contains a pointer to a float array and %ebx contains the array’s length. the code is allowed to read and write floating-point values into the given array, but nowhere else in the heap memory.

22. Carnegie Mellon Example, cont’d As the RI executes, it must perform a special check every time the code attempts to read or write to memory. When reading, it must check that the address is within the bounds of the array. When writing, it must check that the value being written is actually a floating-point value, and check that the address is within bounds. As the RI executes, it must perform a special check every time the code attempts to read or write to memory. When reading, it must check that the address is within the bounds of the array. When writing, it must check that the value being written is actually a floating-point value, and check that the address is within bounds.

23. Carnegie Mellon Example, cont’d To do this kind of type-checking, it will be useful for the RI to maintain information about the types of values in the registers. E.g., execution of xxxxxxx fadd %eax  %ebx should result in the knowledge that %ebx contains a floating- point value, if %eax and %ebx held floating-point values before execution.

24. Carnegie Mellon Exercises 1. Suppose that we require the code to execute no more than N instructions? Is such a safety property enforceable by an RI? 2. Suppose we require the code to terminate eventually. Is such a safety property enforceable by an RI?

25. Carnegie Mellon Reference Interpreters and Safety Policies A reference interpreter, if actually implemented, would enforce safety at run-time. PCC can be used to enforce the same safety at load-time. Essentially, the proofs given with the code attest to the fact that the code will never abort.

26. Carnegie Mellon Operational Semantics In terms of operational semantics, the RI defines a “safe machine”. The proofs show that the code always makes progress (or halts normally) in the operational semantics. This leads to a standard notion of soundness.

27. Carnegie Mellon Note I will avoid formal notation for statements of some key results and theorems. See the papers (and especially Necula’s PhD thesis for these details).

28. Carnegie Mellon Examples of Safety Properties Memory safety. Which addresses are readable / writable; when, and what values. Type safety. What values can be stored and used in operations. System call safety. Which system routines can be called and when.

29. Carnegie Mellon Examples of Safety Policies cont’d Action sequence safety. E.g., no network send after reading a file. Resource usage safety. E.g., instruction counts, stack limits, etc.

30. Carnegie Mellon What Can’t Be Enforced? Informally: Safety properties.  Yes. “No bad thing will happen.” Liveness properties.  Not yet. “A good thing will eventually happen.” Information-flow properties.  ? “Confidentiality will be preserved.”

31. Carnegie Mellon What Can’t Be Enforced? Liveness properties currently cannot be enforced by PCC. Actually, PCC proofs can express proofs of such properties, but VCGen can not generate appropriate VC’s. Conjecture: In practice, safety properties are “good enough”.

32. Carnegie Mellon Safety Properties Are Good Enough? Termination is an example of a liveness property. Termination within a specified number of cycles is a safety property. In practice, the latter is often more useful than the former.

33. A Demonstration

34. Carnegie Mellon Architecture Code producerHost Ginseng Native code Proof Special J Java binary ~52KB, written in CWritten in OCaml

35. Carnegie Mellon Annotations Architecture Code producerHost Proof checker VCGen Axioms Native code Proof VC Special J Java binary

36. Carnegie Mellon Annotations Our Architecture Code producerHost Java binary Proof generator Proof checker VCGen Axioms Certifying compiler VCGen VC Native code Proof VC

37. Carnegie Mellon Java Virtual Machine JVM Java Verifier JNI Class file Native code Proof- carrying code Checker

38. Show either the Mandelbrot or NBody3D demo.

39. Carnegie Mellon Crypto Test Suite Results [Cedilla Systems] sec On average, 72.8% faster than Java, 37.5% faster than Java with a JIT.

40. Carnegie Mellon Java Grande Suite v2.0 [Cedilla Systems] sec

41. Carnegie Mellon Java Grande Bench Suite [Cedilla Systems] ops

42. Carnegie Mellon Ginseng VCGen Checker Safety Policy Dynamic loading Cross-platform support ~15KB, roughly similar to a KVM verifier (but with floating-point). ~4KB, generic. ~19KB, declarative and machine-generated. ~22KB, some optional.

43. Safety Policy Specifications

44. Carnegie Mellon Annotations Our Architecture Code producerHost Java binary Proof generator Proof checker VCGen Axioms Certifying compiler VCGen VC Native code Proof VC

45. Carnegie Mellon Ginseng VCGen Checker Safety Policy Dynamic loading Cross-platform support ~15KB, roughly similar to a KVM verifier (but with floating-point). ~4KB, generic. ~19KB, declarative and machine-generated. ~22KB, some optional. Ginseng is small and easy-to-integrate.

46. Carnegie Mellon Safety Policy The safety policy gives the inference rules for constructing valid proofs. We use a language called LF for this specification, using Pfenning’s Elf syntax. Much more on this next time.

47. Carnegie Mellon Safety Policy Sample Rules /\: pred -> pred -> pred. \/: pred -> pred -> pred. =>: pred -> pred -> pred. all: (exp -> pred) -> pred. pf: pred -> type. truei: pf true. andi: {P:pred} {Q:pred} pf P -> pf Q -> pf (/\ P Q). andel: {P:pred} {Q:pred} pf (/\ P Q) -> pf P. ander: {P:pred} {Q:pred} pf (/\ P Q) -> pf Q. …

48. Carnegie Mellon Safety Policy Some Rules =: exp -> exp -> pred. <>: exp -> exp -> pred. >: exp -> exp -> pred. eq_le: {E:exp} {E':exp} pf (csubeq E E') -> pf (csuble E E'). jbool : exp. jchar : exp. jbyte : exp. jshort : exp. jint : exp. of: exp -> exp -> pred. faddf: {E:exp} {E':exp} pf (of E jfloat) -> pf (of E' jfloat) -> pf (of (fadd E E') jfloat).

49. Carnegie Mellon Safety Policy Sample Rules aidxi: {I:exp} {LEN:exp} {SIZE:exp} pf (below I LEN) -> pf (arridx (add (imul I SIZE) 8) SIZE LEN). wrArray4: {M:exp} {A:exp} {T:exp} {OFF:exp} {E:exp} pf (of A (jarray T)) -> pf (of M mem) -> pf (nonnull A) -> pf (size T 4) -> pf (arridx OFF 4 (sel4 M (add A 4))) -> pf (of E T) -> pf (safewr4 (add A OFF) E).

50. Summary

51. Carnegie Mellon Summary The Necula/Lee approach to PCC is based on the notion of progress in a “safe” operational semantics. It makes use of a verification- condition generator to extract predicates to be proven. The approach seems to cover a wide range of practical problems.

52. Carnegie Mellon Next Time Detailed examples, and then the representation of proofs and algorithms for checking them.