Increasing Automation For Program Reasoning

1
Increasing Automation For Program Reasoning

• Bill J. Ellis
• Dependable Systems Group
• School of Mathematical Computer Sciences
• Heriot-Watt University
• Edinburgh

2
Context

• Investigate the role of proof planning within the
  SPARK approach to high integrity software
• Funded by the EPSRC Critical Systems programme
  (GR/R24081) in collaboration with Praxis Critical
  Systems Ltd.
• www.macs.hw.ac.uk/air/nuspade

3
Overview

• Introducing SPARK
• Motivating Example
• Automation Problem
• Proof Planning
• Program Analysis
• Our system NuSPADE
• NuSPADE Example
• Results and Future Work
• Conclusions

4
Introducing SPARK
SPARK Approach and programming language

• SPARK Approach
• Developed by Praxis Critical
• Systems Ltd.
• For building high integrity software
• Safety, security and mission critical software
• e.g. SHOLIS - UK MoD Def Standard 00-55
• SPARK programming language
• Defined as a subset of Ada
• Analysed using the SPARK tools
• Compiled using regular Ada compilers

5
Introducing SPARK
SPARK Tools

• SPARK Examiner
• Generates conjectures (Verification Conditions
  (VCs)) to prove a selected program property
• Can generate VCs to prove
• Partial correctness (correct if program
  terminates)
• Exception freedom (no run time errors)
• SPADE proof tools
• SPADE Simplifier a special purpose theorem prover
• SPADE Proof Checker an interactive theorem prover

6
Motivating Example
SPARK code

• subtype Index is Integer range 0 .. 9
• type D_Type is array (Index) of Integer
• subtype R_Type is Integer
• R0
• For I in Index loop
• if D(I) gt 0 and D(I) lt 100 then
• R RD(I)
• end if
• end loop

7
Motivating Example
Exception freedom problem

• subtype Index is Integer range 0 .. 9
• type D_Type is array (Index) of Integer
• subtype R_Type is Integer
• R0
• For I in Index loop
• if D(I) gt 0 and D(I) lt 100 then
• R RD(I)
• end if
• end loop

RD(I) ? Integerfirst RD(I) ? Integerlast
8
Motivating Example
Exception freedom VC
Given hypotheses
R0 For I in Index loop if D(I) gt 0 and
D(I) lt 100 then R RD(I) end
if end loop
Prove conclusions
9
Motivating Example
Tackle VCs using the Simplifier

• Typically 95 of exception freedom VCs are
  discharged automatically by the Simplifier
• But the remaining 5 still account for many VCs
• In this case
• The exception freedom VC is not proved

10
Motivating Example
Manually discover why the VC was not proved
Given hypotheses
R0 For I in Index loop if D(I) gt 0 and
D(I) lt 100 then R RD(I) end
if end loop
Prove conclusions
?!
11
Motivating Example
Manually strengthen invariant
subtype Index is Integer range 0 .. 9 type
D_Type is array (Index) of Integer subtype
R_Type is Integer R0 For I in Index loop
-- assert R gt 0 and R lt I100 if D(I) gt
0 and D(I) lt 100 then R RD(I)
end if end loop
12
Motivating Example
Tackle VCs using the Simplifier (again)

• In this case
• The exception freedom VC is not proved
• Because the Simplifier is not strong enough
• The loop invariant VC is not proved
• Because the Simplifier is not strong enough

13
Motivating Example
Manually prove VCs using the Proof Checker

• Supply commands to the Proof Checker to prove the
  remaining VCs
• The exception freedom VC
• The loop invariant VC

newvc. yes. 6. consult './filter_s.rls'. consult
'../../gen_rules/fertilise.rul'. replace c2
integer__last by 32767 using filter_s_rules(4). ye
s. no. infer relement(d,loop__1__i)ltloop__1__i
100100 and loop__1__i100100lt32767 -gt
relement(d,loop__1__i)lt32767 using
inference(1). yes. yes. prove c1 by
implication. simplify. infer relement(d,loop__1_
_i)lt32767 using transitivity(1). done. done. inf
er relement(d,loop__1__i)ltloop__1__i100100
and loop__1__i100100lt32767 using
inference(1). yes. yes. infer rltloop__1__i100
and element(d,loop__1__i)lt100 and
loop__1__i100100lt32767 -gt relement(d,loop__1_
_i)ltloop__1__i100100 and loop__1__i100100lt3
2767 using inference(1). yes. yes. prove c1 by
implication. simplify. infer relement(d,loop__1_
_i)ltloop__1__i100100 using inequals(80). done.
done. infer rltloop__1__i100 and
element(d,loop__1__i)lt100 and
loop__1__i100100lt32767 using
inference(1). yes. yes. replace c1
rltloop__1__i100 by true using
fertilise(1). yes. no. replace c1
element(d,loop__1__i)lt100 by true using
fertilise(1). yes. no. replace c1 true and true
by true using logical_and(5). yes. no. replace
c1 true and loop__1__i100100lt32767 by
loop__1__i100100lt32767 using
logical_and(2). yes. no. infer i_type__last 9
using inference(1). yes. yes. replace c1
i_type__last by 9 using filter_s_rules(9). yes. no
. done. done. forwardchain h15. done. forwardchai
n h14. done.
newvc. yes. 3. consult '../../gen_rules/distribute
.rul'. consult '../../gen_rules/fertilise.rul'. re
place c2 (loop__1__i1)100 by
loop__1__i1001100 using distribute(1). yes. no.
replace c2 1100 by 100 using
arith(2). yes. no. infer rltloop__1__i100 and
element(d,loop__1__i)lt100 -gt
relement(d,loop__1__i)ltloop__1__i100100
using inference(1). yes. yes. prove c1 by
implication. simplify. infer relement(d,loop__1_
_i)ltloop__1__i100100 using inequals(80). done.
done. infer rltloop__1__i100 and
element(d,loop__1__i)lt100 using
inference(1). yes. yes. replace c1
rltloop__1__i100 by true using
fertilise(1). yes. no. replace c1 true and
element(d,loop__1__i)lt100 by
element(d,loop__1__i)lt100 using
logical_and(2). yes. no. done. forwardchain
h17. done.
14
Motivating Example
Proof completed!

• Now every VC has been proved
• So the code is free from exceptions!

15
Automation Problem

• User interaction that may be required
• Determine why VCs are not proved
• Patch failures by adding invariants
• Find proof scripts to prove VCs
• Automated program reasoning needs to integrate
• Theorem proving (looking at the VCs)
• Program analysis (looking at the code)

16
Proof Planning
Automated theorem proving

• Proof planning is an artificial intelligence
  technique for automated theorem proving
• Guides proof search at a high level
• Demonstrated to be applicable for both inductive
  (loop) and non-inductive (non-loop) applications

17
Proof Planning
Flexible and constrained search
Proof planning (Method Critic heuristics)
Proof checking (Proof script)
18
Program Analysis

• Program analysis automatically finds interesting
  properties about source code
• Program analysis in practice
• Flow analysis
• Performance analysis
• Discover code properties
• invariant discovery

19
NuSPADE
Code
Examiner
Strengthen Invariant
VCs
Found proof
NuSPADE
Proof Script
Critic
Proof Planner
Program Analysis
20
NuSPADE Example
SPARK code

• subtype Index is Integer range 0 .. 9
• type D_Type is array (Index) of Integer
• subtype R_Type is Integer
• R0
• For I in Index loop
• if D(I) gt 0 and D(I) lt 100 then
• R RD(I)
• end if
• end loop

21
NuSPADE Example
Exception freedom problem

• subtype Index is Integer range 0 .. 9
• type D_Type is array (Index) of Integer
• subtype R_Type is Integer
• R0
• For I in Index loop
• if D(I) gt 0 and D(I) lt 100 then
• R RD(I)
• end if
• end loop

RD(I) ? Integerfirst RD(I) ? Integerlast
22
NuSPADE Example
Exception freedom VC
Given hypotheses
R0 For I in Index loop if D(I) gt 0 and
D(I) lt 100 then R RD(I) end
if end loop
Prove conclusions
23
NuSPADE Example
Tackle VCs in the proof planner
Given hypotheses
R0 For I in Index loop if D(I) gt 0 and
D(I) lt 100 then R RD(I) end
if end loop
Prove conclusions

• Proof plan fails, as VC is not provable
• Critic notices that information is missing on r

24
NuSPADE Example
Call program analysis

• Critic calls program analysis
• Asking for bounds on R (R ? ? And R ? ??)
• Program analysis heuristics
• Type
• Bounds on variables
• Non looping code
• Looping code (recurrence relations)
• Properties from loop exit

25
NuSPADE Example
Program analysis finds invariant
subtype Index is Integer range 0 .. 9 type
D_Type is array (Index) of Integer subtype
R_Type is Integer R0 For I in Index loop
-- assert R gt 0 and R lt I100 if D(I) gt
0 and D(I) lt 100 then R RD(I)
end if end loop
26
NuSPADE Example
Tackle VCs in the proof planner (again)

• The exception freedom VC
• Proof planing is now successful
• The loop invariant VC
• Proof planing is successful
• Invariant proofs reuse the rippling methods
  developed at Edinburgh University

27
NuSPADE Example
Proof completed!

• Now every VC has been proved
• So the code is free from exceptions!

28
Results

• Prototype system
• Integration partial
• Development corpus
• Programs with simple loops and conditionals
• As typically seen in high integrity software!

29
Future Work

• Exploit other automated theorem provers
• Simplify (Note Simplify ? Simplifier)
• Look at debugging
• Detect false VCs that arise though buggy
  specification or implementation
• Evaluate performance using example corpus
  supplied by Praxis Critical Systems

30
Conclusions

• Although we focus on SPARK
• Proof planning is generic
• Program analysis is generic
• NuSPADE is generic
• NuSPADE A generic, integrated, approach to
  automated program reasoning