© Andrew IrelandDependable Systems Group Static Analysis and Program Proof Andrew Ireland School of Mathematical & Computer Sciences Heriot-Watt University Edinburgh

© Andrew IrelandDependable Systems Group Outline Static analysis and program proof Automated reasoning and proof planning Industrial strength program proof Observations & conclusions

© Andrew IrelandDependable Systems Group Static Analysis Program Proof Program Analysis

© Andrew IrelandDependable Systems Group Static Analysis Program Proof Program Analysis Precision

© Andrew IrelandDependable Systems Group Static Analysis Program Proof Program Analysis Automation Precision

© Andrew IrelandDependable Systems Group Proof Development Goal Givens

© Andrew IrelandDependable Systems Group Proof Development Goal Givens Proof Rules & Tactics

© Andrew IrelandDependable Systems Group Proof Automation In general, the search for a proof gives rise to a combinatorial explosion in terms of proof rule applications. Heuristics are required in order to manage the search for a proof. Proof planning represents an approach to managing proof search.

© Andrew IrelandDependable Systems Group Proof Plans Proof planning Methods + Critics Proof checking Tactics Conjectures Theory Proof plans promote reuse, robustness and tool integration

© Andrew IrelandDependable Systems Group Mathematical domains: program verification, synthesis, and optimization; hardware verification; correction of faulty specifications. summing series; limit theorems. Non-mathematical domains: game playing (Bridge & Go); configuration management problems. Applications of Proof Plans

© Andrew IrelandDependable Systems Group Investigate the role of proof planning within the SPARK Approach to high integrity software Funded by EPSRC Critical Systems programme (GR/R24081) Follow-on industrial secondment funded by EPSRC RAIS Scheme (GR/T11289/01) Praxis High Integrity Systems Ltd (collaborator) Proof Plans & Industry

© Andrew IrelandDependable Systems Group The SPARK Approach A subset of Ada that eliminates potential ambiguities and insecurities. Supports “correctness-by-construction” and is advocated by US National Cyber Security Partnership (NSA). Applications include: –SHOLIS: UK MoD’s first Def Stan project. –Eurofighter Typhoon. –MONDEX smart card security.

© Andrew IrelandDependable Systems Group SPARK Toolset Data flow, e.g. variables defined before read. Information flow, i.e. code checked against program annotations, e.g. --# derives X from Y, Z; Formal verification, i.e. code is proved correct with respect to proof annotations: –Pre- and postconditions. –Assertions such as loop invariants. –Declaration of proof functions.

© Andrew IrelandDependable Systems Group Program Proofs Partial correctness proofs: –Guarantees that if preconditions hold then the postconditions will hold (if program terminates). –Requires user specified pre- and postconditions. Exception freedom proofs: –Guarantees that no exceptions occur at run-time, e.g. buffer overflows, index violations etc –Exception freedom properties are pre-defined. Note that user may be required to provide intermediate assertions in both cases.

© Andrew IrelandDependable Systems Group The SPARK Approach SPARK Examiner SPADE Simplifier SPADE Proof Checker SPARK Examiner supports data & information flow analysis, and generates verification conditions (VCs). SPADE Simplifier supports automatic proof. SPADE Proof Checker supports interactive proof. VCs Cmds Unproven VCs  SPARK code Proofs Revisions ✗

© Andrew IrelandDependable Systems Group SPADEase SPARK Examiner SPADE Simplifier SPADE Proof Checker SPADEase = proof planning + program analysis. Main focus on exception freedom proofs. Annotation generation motivated by proof-failure analysis. VCs Cmds Unproven VCs  SPARK code Proofs SPADEase Annotations ✗

© Andrew IrelandDependable Systems Group SPADEase Unproven VCs Cmds Abstract Predicates Annotations Co-operative style of integration, i.e. “productive use of failure” Proof Planner Program Analyzer

© Andrew IrelandDependable Systems Group subtype AR_T is Integer range 0..9; type A_T is array (AR_T) of Integer;... procedure Filter(A: in A_T; R: out Integer) is begin R:=0; for I in AR_T loop if A(I)>=0 and A(I)<=100 then R:=R+A(I); end if; end loop; end Filter; An Example

© Andrew IrelandDependable Systems Group H1: for_all (i___1: integer, ((i___1 >= ar_t__first) and (i___1 ((element(a, [i___1]) >= integer__first) and (element(a, [i___1]) <= integer__last))). H2: loop__1__i >= ar_t__first. H3: loop__1__i <= ar_t__last. H4: element(a, [loop__1__i]) >= 0. H5: element(a, [loop__1__i]) <= 100. H6: r >= integer__first. H7: r <= integer__last. -> C1: r + element(a, [loop__1__i]) >= integer__first. C2: r + element(a, [loop__1__i]) <= integer__last. C3: loop__1__i >= ar_t__first. C4: loop__1__i <= ar_t__last.... H4: element(a, [loop__1__i]) >= 0. H5: element(a, [loop__1__i]) <= 100. H6: r >= integer__first. H7: r <= integer__last. ->... C2: r + element(a,[loop__1__i]) <= integer__last... Exception Freedom VC

© Andrew IrelandDependable Systems Group H1: for_all (i___1: integer, ((i___1 >= ar_t__first) and (i___1 ((element(a, [i___1]) >= integer__first) and (element(a, [i___1]) <= integer__last))). H2: loop__1__i >= ar_t__first. H3: loop__1__i <= ar_t__last. H4: element(a, [loop__1__i]) >= 0. H5: element(a, [loop__1__i]) <= 100. H6: r >= integer__first. H7: r <= integer__last. -> C1: r + element(a, [loop__1__i]) >= integer__first. C2: r + element(a, [loop__1__i]) <= integer__last. C3: loop__1__i >= ar_t__first. C4: loop__1__i <= ar_t__last.... H4: element(a, [loop__1__i]) >= 0. H5: element(a, [loop__1__i]) <= 100. H6: r >= integer__first. H7: r <= integer__last. ->... C2: r + element(a,[loop__1__i]) <= integer__last... Exception Freedom VC

© Andrew IrelandDependable Systems Group H1: for_all (i___1: integer, ((i___1 >= ar_t__first) and (i___1 ((element(a, [i___1]) >= integer__first) and (element(a, [i___1]) <= integer__last))). H2: loop__1__i >= ar_t__first. H3: loop__1__i <= ar_t__last. H4: element(a, [loop__1__i]) >= 0. H5: element(a, [loop__1__i]) <= 100. H6: r >= integer__first. H7: r <= integer__last. -> C1: r + element(a, [loop__1__i]) >= integer__first. C2: r + element(a, [loop__1__i]) <= integer__last. C3: loop__1__i >= ar_t__first. C4: loop__1__i <= ar_t__last.... H4: element(a, [loop__1__i]) >= 0. H5: element(a, [loop__1__i]) <= 100. H6: r >= integer__first. H7: r <= integer__last. ->... C2: r + element(a,[loop__1__i]) <= integer__last... Exception Freedom VC If (32668 <= r <= 32767) then possible overflow, i.e. VC is unprovable

© Andrew IrelandDependable Systems Group SPADEase Unproven VCs Proof Planner Program Analyzer Abstract Predicates R >= ? and R <= ? subtype AR_T is Integer range 0..9; type A_T is array (AR_T) of Integer;... procedure Filter(A: in A_T; R: out Integer)is begin R:=0; for I in AR_T loop if A(I)>=0 and A(I)<=100 then R:=R+A(I); end if; end loop; end Filter;

© Andrew IrelandDependable Systems Group SPADEase Unproven VCs Proof Planner Program Analyzer Annotations --# assert R >= 0 and R <= I*100 Abstract Predicates subtype AR_T is Integer range 0..9; type A_T is array (AR_T) of Integer;... procedure Filter(A: in A_T; R: out Integer)is begin R:=0; for I in AR_T loop if A(I)>=0 and A(I)<=100 then R:=R+A(I); end if; end loop; end Filter; subtype AR_T is Integer range 0..9; type A_T is array (AR_T) of Integer;... procedure Filter(A: in A_T; R: out Integer)is begin R:=0; for I in AR_T loop --# assert R >= 0 and R <= I*100 if A(I)>=0 and A(I)<=100 then R:=R+A(I); end if; end loop; end Filter; R >= ? and R <= ?

© Andrew IrelandDependable Systems Group subtype AR_T is Integer range 0..9; type A_T is array (AR_T) of Integer;... procedure Filter(A: in A_T; R: out Integer) is begin R:=0; for I in AR_T loop --# assert R >= 0 and R <= I*100; if A(I)>=0 and A(I)<=100 then R:=R+A(I); end if; end loop; end Filter; Revised Filter Code

© Andrew IrelandDependable Systems Group Revised Exception Freedom VC H1: r >= 0. H2: r <= loop__1__i * 100. H3: for_all (i___1: integer, ((i___1 >= ar_t__first) and (i___1 ((element(a, [i___1]) >= integer__first) and (element(a, [i___1]) <= integer__last))). H4: loop__1__i >= ar_t__first. H5: loop__1__i <= ar_t__last. H6: element(a, [loop__1__i]) >= 0. H7: element(a, [loop__1__i]) <= 100. H8: r >= integer__first. H9: r <= integer__last. -> C1: r + element(a, [loop__1__i]) >= integer__first. C2: r + element(a, [loop__1__i]) <= integer__last. C3: loop__1__i >= ar_t__first. C4: loop__1__i <= ar_t__last. H1: r >= 0. H2: r <= loop__1__i * H6: element(a, [loop__1__i]) >= 0. H7: element(a, [loop__1__i]) <= 100. … ->... C2: r + element(a,[loop__1__i]) <= integer__last... Transitivity proof plan 

© Andrew IrelandDependable Systems Group Loop Invariant VC H1: r >= 0. H2: r <= loop__1__i * H6: element(a, [loop__1__i]) >= 0. H7: element(a, [loop__1__i]) <= 100. … -> C1: r + element(a,[loop__1__i]) >= 0. C2: r + element(a,[loop__1__i]) <= (loop__1__i + 1) * 100. … Rippling proof plan 

© Andrew IrelandDependable Systems Group Summary Code+ Spec Simplifier Proof Planner Program Analyzer Proofs Failure

© Andrew IrelandDependable Systems Group SPADEase Results Our evaluation was based upon examples drawn from industrial data provided by Praxis, e.g. SHOLIS. SPADE Simplifier is very effective on exception freedom VC, i.e. typical hit-rate of 92%. NuSPADE targeted the VCs which the SPADE Simplifier failed to prove, i.e. loop-based code. While critical software is engineered to minimize the number and complexity of loops, we found that 80% of the loops we encountered were provable using SPADEase.

© Andrew IrelandDependable Systems Group SPADEase Applicability SPARK was designed to meet the needs of advanced avionics while supporting formal analysis. Targeting language subsets: –Potential hearts-and-minds hurdle. –Limitations of niche markets. Targeting full languages: –Need to limit scope of analysis, i.e. focus on specific data and/or control properties. –Essential that the selected properties yield real value to the customer, i.e. properties where failure carries a significant cost and conventional prevention strategies are poor.

© Andrew IrelandDependable Systems Group Conclusions Static analysis benefits from an integrated approach. Other examples include Microsoft’s Static Device Verifier (SDV), Spec#, ESC/Java2. Current success stories focus on pre-defined properties, e.g. exception and deadlock freedom. More comprehensive properties will increase the need for tools that include a proof automation component. Proof planning provides a framework for integrating proof automation with a wide spectrum of program analysis techniques.