© andrew irelanddependable systems group invariant patterns for program reasoning andrew ireland...

© Andrew IrelandDependable Systems Group

Invariant Patterns for Program Reasoning

Andrew IrelandDependable Systems Group

School of Mathematical & Computer Sciences Heriot-Watt University

Edinburgh


Outline

• Context and background • The problem• Our approach

• Results and future horizons


• 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


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


SPARKcode

Verificationconditions

Examiner

SPADE Simplifier

Proofs


Failure!

SPARKcode


Examiner

SPADE Simplifier


SPARKcode


SPADEProof Checker

Examiner

Failure!


SPARKcode


SPADEProof Checker

Examiner


SPARKcode


NuSPADE

SPADEProof Checker

Examiner

Commandfile


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:


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


Investigate the role of proof planning within the SPARK approach to high integrity software

NuSPADE

program analysis

specification analysis

proof-failure analysis

NuSPADE


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


A Broader View Of Proof Planning

Proof planningmethods + critics

Proof checkingtactics

Conjectures Theory

Invariant Patterns


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;


Bubble Sortpackage 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 loop;end Bubble_Sort;end BubbleSort;


Program Analysis

maxjji

maxii

1

for_loop_ji,constant

for_loop_jj,mono_dec

for_loop_ii,mono_inc

• Proof construction properties

• Proof search properties


Specification Analysis

1,,:

,,

PAelePAeleUPPLint.P

ULAordered

1,,: ptableeleptableelemaxpp0int.p

1,,: ptableeleptableeleiFpp0int.p 1

1,,: ptableeleptableelemaxppjGint.p 1

• Definition

• Unfolded specification

• Schematic specification

• Schematic specification


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

blocked

2, 1, TAele RelTAele

T1 T2L U


Proof patch involves generalizing the goal, i.e.

Generalized goal represents an auxiliary invariant

Proof Patch

YAele Rel XAele

U YYTintY

TXXLintX

,,

1.:

1.:


Alternative Generalizes

T1 T2L U


Proof-Failure Analysis

11,1, 22 iFitableeleiFitableele

qtableeleptableele

maxqqiFiintq

iFippintp

,,

1.:

10.:

2

2


Outer-Loop Invariant

maxii

qtableeleptableele

maxqqiintq

ippintp

1

,,

2.:

20.:

• 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


• 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


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

© andrew irelanddependable systems group invariant patterns for program reasoning andrew ireland...

Documents