1. © Andrew IrelandDependable Systems Group Invariant Patterns for Program Reasoning Andrew Ireland Dependable Systems Group School of Mathematical & Computer Sciences Heriot-Watt University Edinburgh

2. © Andrew IrelandDependable Systems Group Outline Context and background The problem Our approach Results and future horizons

3. © Andrew IrelandDependable Systems Group Investigate the role of proof planning within the SPARK approach to high integrity software EPSRC Critical Systems programme (GR/R24081) Praxis Critical Systems (collaborator) Bill Ellis (Research Associate) Tommy Ingulfsen (Undergraduate Student) Context

4. © Andrew IrelandDependable Systems Group The SPARK Approach A subset of Ada that eliminates potential ambiguities and insecurities (Praxis Critical Systems) Supports data & information flow analysis and formal verification via code level annotations Supports “correctness-by-construction” and is advocated by US National Cyber Security Partnership (April 2004) Applications include SHOLIS: UK MoD’s first Def Standard 00-55 project

5. © Andrew IrelandDependable Systems Group SPARK code Verification conditions Examiner SPADE Simplifier Proofs

6. © Andrew IrelandDependable Systems Group Failure! SPARK code Verification conditions Examiner SPADE Simplifier

7. © Andrew IrelandDependable Systems Group SPARK code Verification conditions SPADE Proof Checker Examiner Failure!

8. © Andrew IrelandDependable Systems Group SPARK code Verification conditions SPADE Proof Checker Examiner

9. © Andrew IrelandDependable Systems Group SPARK code Verification conditions NuSPADE SPADE Proof Checker Examiner Command file

10. © Andrew IrelandDependable Systems Group Achievements Partial correctness proofs: prove program correct with respect to a Floyd-Hoare style specification [ MICAI-2004 ] Exception freedom proofs: prove that no exceptions will be raised at runtime, e.g. buffer overflows [ ASE-2003, IFM-2004 ] Proof automation with respect to:

11. © Andrew IrelandDependable Systems Group Program Reasoning Challenge Long history: Goldstine & von Neumann 1947, Turing 1949, Floyd 1967, Hoare 1969 Strong AI focus dating back to 1970s: Wegbreit, German, Katz & Manna, … Renewed interest: proof carrying code, SLAM (Microsoft), ESC/Java (HP), SPARK (Praxis), Verifying Compiler – UK “grand challenges” in computing (Hoare) Key challenges: proof automation and proof annotations, e.g. loop invariants

12. © Andrew IrelandDependable Systems Group Investigate the role of proof planning within the SPARK approach to high integrity software NuSPADE program analysis specification analysis proof-failure analysis NuSPADE

13. © Andrew IrelandDependable Systems Group Proof Planning Use of high-level proof outlines, known as proof plans, to guide proof search Supports middle-out reasoning, i.e. the use of meta variables to delay choice during proof search Automatic proof patching via proof failure analysis, e.g. conjecture generalization, lemma discovery, induction revision, case splitting, loop invariant discovery, fixing faulty conjectures Inductive and non-inductive applications

14. © Andrew IrelandDependable Systems Group A Broader View Of Proof Planning Proof planning methods + critics Proof checking tactics ConjecturesTheory Invariant Patterns

15. © Andrew IrelandDependable Systems Group Bubble Sort Example package BubbleSort is Min: constant:= 0; Max: constant:= 9; subtype Index_Type is Integer range Min..Max; type Array_Type is array(Index_Type) of Integer; … procedure Bubble_Sort(Table: in out Array_Type); --# derives Table from Table; --# pre true; --# post Ordered(Table, Min, Max) and --# Perm(Table, Table~); end BubbleSort;

16. © Andrew IrelandDependable Systems Group Bubble Sort package body BubbleSort is … procedure Bubble_Sort(Table: in out Array_Type)is T: Integer; begin for I in Index_Type range 1..Max loop for J in reverse Index_Type range I..Max loop if Table(J-1) > Table(J) then T:= Table(J-1); Table(J-1):= Table(J); Table(J):= T; end if; end loop; end Bubble_Sort; end BubbleSort;

17. © Andrew IrelandDependable Systems Group Program Analysis Proof construction properties Proof search properties

18. © Andrew IrelandDependable Systems Group Specification Analysis Definition Unfolded specification Schematic specification

19. © Andrew IrelandDependable Systems Group 1.A goal is unprovable within the current proof context and matches the following pattern: 2. Terms T1 and T2 contain a counter variable in common Proof-Failure Pattern T1T2LU

20. © Andrew IrelandDependable Systems Group Proof patch involves generalizing the goal, i.e. Generalized goal represents an auxiliary invariant Proof Patch

21. © Andrew IrelandDependable Systems Group Alternative Generalizes T1T2LU

22. © Andrew IrelandDependable Systems Group Proof-Failure Analysis

23. © Andrew IrelandDependable Systems Group Outer-Loop Invariant Invariant states that the array table is partitioned into two parts, i.e. all elements in the lower part are less-than-or-equal to those in the upper part Invariant generated via program, specification and proof-failure analysis

24. © Andrew IrelandDependable Systems Group Industrial focus is on exception freedom proofs, so partial correctness examples drawn mainly from text books Currently exploring the use of external reasoners to support planning and program analysis, e.g. CLP, Simplify (ESC/Java) Building on NuSPADE project: Knowledge transfer project with Praxis (2005) NASA Ames potential collaboration Results & Future Horizons

25. © Andrew IrelandDependable Systems Group Conclusion Integrated approach to program reasoning, i.e. program, specification and proof-failure analysis Proof planning provides the basis for integration Integration broadens the role of proof planning, i.e. proof planning exploits program knowledge