Proof Carrying Code and Proof Preserving Program Transformations Ando Saabas, Institute of Cybernetics CDC Seminar, 21.01.2008

Proof Carrying Code Proof-Carrying Code is based on the idea that the code producer should provide some evidence that the program she distributes is safe and/or functionally correct. The program is thus shipped with a certificate that attests that it has the desired properties. Before running a program, the code user could then check this certificate

PCC vs Digital Signatures A digital signature identifies the origin of the program It has no direct connection with program semantics A digital signature is a syntactic checksum A proof is a semantic checksum

Where would proofs come from? For basic safety properties, they can be inferred automatically For more complex safety and/or functional correctness properties, the code producer would use some verification environment to prove the source program correct But programs are distributed in compiled form

PCC framework ? Code producer Code user Yes No Specification Source program Runtime environent Yes Compiled program Program verification environment ? Compiler + Proof compiler Proof checker Proof of the compiled program No Program proof

Proof compilation For non-optimizing compilers it is easy: proof compilation is (almost) identity Not so if optimizations take place

Dead code elimination f 9 p : s = c ¤ n ^ g f s = c ¤ n ^ p g f 9 p : Precondition f 9 p : s = ^ 1 i g f s = ^ p 1 i g while i < n s = s + c; skip; i++; while i < n s = s + c; p = p * c; i++; Invariant f 9 p : s = c ¤ i ^ · n g f s = c ¤ i ^ p · n g Postcondition f 9 p : s = c ¤ n ^ g f s = c ¤ n ^ p g

Constant propagation f s = c ¤ n ^ p g f s = ^ p 1 i g f s = 5 ¤ i ^ p Precondition f s = ^ p 1 i g c = 5; while i < n s = s + c; p = p * c; i++; c = 5; while i < n s = s + 5; p = p * 5; i++; Invariant f s = 5 ¤ i ^ p · n g f s = c ¤ i ^ p · n 5 g f s = c ¤ i ^ p < n g Postcondition f s = c ¤ n ^ p g

Proof compilation For non-optimizing compilers it is easy: proof compilation is (almost) identity Not so if optimizations take place Many different optimizations, each have their own particular effect on the proof Need a systematic approach for dealing with this

Enter type systems Optimizations are mostly based on dataflow analyses Dataflow analyses can be described as type systems Type systems can have an optimization component Idea: types can guide the transformation of the proofs

Proof transformation ? ? Source Specification program Runtime Compiled Verification Environment Proof checker Runtime Source program Analyzer Type derivation Program optimizer Proof optimzer Compiled program Proof of the compiled ? Compiler + ? Program proof

Liveness and dead code elimination A variable is said to be live at the exit from a program point, if there exists a path from that program point to a use of the variable, that does not redefine the variable. Live variable analysis determines, for each program point which variables may be live at that point Used in dead code elimination

Live variable analysis The types and subtyping relation of the type system correspond to the poset of the analysis: The intuitive meaning of a program typing is that, given a set of variables d which are live at the end of the program s, the variables in the pretype d’ may be live at the beginning of the program. ( D ; · ) = P V a r ¶ s : d ¡ !

Type system for liveness analysis

Optimizations via type systems Program optimizations can be explained via an extended version of the type system. Apart from assigning types to statements, it also defines the corresponding optimized forms. A typing judgement has the form where is the s’ optimized form of s. s : d ¡ ! ,

Type system for dead code elimination

Soundness of dead code elimination The typesystematic formulation of dead code elimination leads to a simple correctness proof At corresponding program points, the states of the original and optimized program agree on all variables which are live This can be shown by induction on the typing derivation

Proof optimization Optimization preserves Hoare triple derivability (P|d is obtained from P by quantifying out all program variables not in d). The constructive proof gives us “proof optimization”: transformation of Hoare triples alongside with programs.

Scalability Applied for partial redundancy elimination performs common subexpression elimination and code motion at the same time changes the structure of the code requires 4 dataflow analyses Can applied for resource usage proofs

Scalability Can be used for optimization which require bidirectional analyses. Can be applied to CFG based program and analysis descriptions Java bytecode analyses: dead store elimination load pop pair elimination store load pair elimination etc

Conclusions We have shown the benefits of the typesystematic approach to dataflow analyses leads to simple soundness proofs is a viable option for proof transformation and can be applied to a very wide array of optimizations