Invariant Patterns for Program Reasoning

1
Invariant Patterns for Program Reasoning

• Andrew Ireland
• Dependable Systems Group
• School of Mathematical Computer Sciences
• Heriot-Watt University
• Edinburgh

2
Outline

• Context and background
• The problem
• Our approach
• Results and future horizons

3
Context

• 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)

4
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 MoDs first Def
  Standard 00-55 project

5
SPARK code
Verification conditions
Examiner
Proofs
SPADE Simplifier
6
SPARK code
Verification conditions
Examiner
Failure!
SPADE Simplifier
7
SPARK code
Verification conditions
Examiner
Failure!
SPADE Proof Checker
8
SPARK code
Verification conditions
Examiner
SPADE Proof Checker
9
SPARK code
Verification conditions
Examiner
NuSPADE
Command file
SPADE Proof Checker
10
Achievements
Proof automation with respect to

• Exception freedom proofs prove that no
  exceptions
• will be raised at runtime, e.g. buffer
  overflows
• ASE-2003, IFM-2004

• Partial correctness proofs prove program
  correct
• with respect to a Floyd-Hoare style
  specification
• MICAI-2004

11
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
NuSPADE
Investigate the role of proof planning within
the SPARK approach to high integrity software
program analysis
specification analysis
NuSPADE
proof-failure analysis
13
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
A Broader View Of Proof Planning
Invariant Patterns
Conjectures
Theory
Proof planning methods critics
Proof checking tactics
15
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
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) gt
Table(J) then T Table(J-1)
Table(J-1) Table(J) Table(J)
T end if end loop end
loop end Bubble_Sort end BubbleSort
17
Program Analysis

• Proof construction properties

• Proof search properties

18
Specification Analysis

• Definition

• Unfolded specification

• Schematic specification

• Schematic specification

19
Proof-Failure Pattern
T1
T2
L
U

• 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

20
Proof Patch
Proof patch involves generalizing the goal,
i.e. Generalized goal represents an
auxiliary invariant
21
Alternative Generalizes
T1
T2
L
U
22
Proof-Failure Analysis
23
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
Results Future Horizons

• 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

25
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