Proof Carrying Code and Proof Preserving Program Transformations

  • Slides: 21
Download presentation
Proof Carrying Code and Proof Preserving Program Transformations Ando Saabas, Institute of Cybernetics CDC

Proof Carrying Code and Proof Preserving Program Transformations Ando Saabas, Institute of Cybernetics CDC Seminar, 21. 01. 2008

Proof Carrying Code n n n Proof-Carrying Code is based on the idea that

Proof Carrying Code n n n 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 n n A digital signature identifies the origin of the

PCC vs Digital Signatures n n 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? n n For basic safety properties, they can be

Where would proofs come from? n n 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 q But programs are distributed in compiled form

PCC framework Code producer Specification Code user Source program Program verification environment Program proof

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

Proof compilation n n For non-optimizing compilers it is easy: proof compilation is (almost)

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

Dead code elimination Precondition = 0=^ 0 p^=p 1=^ 1 i ^= i 0

Dead code elimination Precondition = 0=^ 0 p^=p 1=^ 1 i ^= i 0 g = 0 g f s 9 p: s while i < n s = s + c; p = p * c; skip; i++; Postcondition = c=¤ ci ^¤ ip^=pc=i ^cii ^· i ng s Invariant · ng f 9 p: s s = c=¤ cn ¤^ np^=pc=n gcn g

Constant propagation s = 0 ^ p = 1 ^ i = 0 g

Constant propagation s = 0 ^ p = 1 ^ i = 0 g f. Precondition c = 5; while i < n s = s + c; 5; p = p * 5; c; i++; Postcondition f s = c ¤ n ^ p = cn g Invariant ng f s = c 5¤¤ii ^^ pp== c 5 i i^^i i< · ·=nng ^ c = 5 g

Proof compilation n n For non-optimizing compilers it is easy: proof compilation is (almost)

Proof compilation n n 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 n n Optimizations are mostly based on dataflow analyses Dataflow analyses

Enter type systems n n 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 Specification Source program Program Verification Analyzer Environment Program proof Runtime Compiled program

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

Liveness and dead code elimination n A variable is said to be live at

Liveness and dead code elimination n 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 n The types and subtyping relation of the type system correspond

Live variable analysis n The types and subtyping relation of the type system correspond to the poset of the analysis: (D ; · ) = (P (V ar ); ¶ ) n The intuitive meaning of a program typing 0 ! s: d ¡ d 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.

Type system for liveness analysis

Type system for liveness analysis

Optimizations via type systems n n n Program optimizations can be explained via an

Optimizations via type systems n n n 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 0 has the form 0 s: d ¡! d , ! s where is the s’ optimized form of s.

Type system for dead code elimination

Type system for dead code elimination

Soundness of dead code elimination n The typesystematic formulation of dead code elimination leads

Soundness of dead code elimination n 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 n Optimization preserves Hoare triple derivability n (P|d is obtained from P

Proof optimization n Optimization preserves Hoare triple derivability n (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. n

Scalability n Applied for partial redundancy elimination q q q n performs common subexpression

Scalability n Applied for partial redundancy elimination q q q n 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 n n n Can be used for optimization which require bidirectional analyses. Can

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

Conclusions n We have shown the benefits of the typesystematic approach to dataflow analyses

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