Bill J' Ellis

1
Proving Exception Freedom within High Integrity
Software Systems

• Bill J. Ellis
• (bill_at_macs.hw.ac.uk)
• Dependable Systems Group
• Heriot-Watt University
• (Project page http//www.macs.hw.ac.uk/air/clams
  park/)

2
High Integrity Software

• Software standards encourage or enforce proof for
  high integrity software
• MOD 00-55 requirements for the procurement of
  safety critical software in defence equipment.
• Formal methods and proof mandatory
• ITSEC Information technology security evaluation
  criteria
• Formal methods mandatory

3
Praxis and SPARK

• SPARK is developed by Praxis Critical Systems for
  building high integrity software
• Formally defined safe subset of Ada
• Information and data flow static analysis
• Supports proofs of
• Partial correctness
• Exception freedom (No run time errors)
• SPARK is used in industry
• BAE prove exception freedom (Unnamed project)
• Praxis completed SHOLLIS and MULTOS CA
• Many more...

4
SPARK Proof In Industry

• Partial correctness (Rare)
• User supplied specification
• Proofs usually deep
• Very limited automation
• Exception freedom (Increasingly common)
• Automatic specification
• Proofs usually shallow
• Good (90) automation via Praxis Simplifier
• Remaining 10 may number in the thousands...

5
Exception Freedom in SPARK

• Storage_Error ? (Static memory requirement)
• Program_Error ?
• Tasking_Error ?
• Constraint_Error ? (Some can occur in SPARK)
• Access_Check ?
• Discriminant_Check ?
• Tag_Check ?
• Division_Check ?
• Index_Check ?
• Range_Check ?
• Overflow_Check ?

Proving exception freedom in SPARK is proving
variables stay within legal bounds
6
Exception Freedom VCs
7
The Strategy
Success!
Prove Exception Freedom VCs
Try proof again
Fail
Discover properties (Typically invariants)
Prove properties
8
Abstract Interpretation (AI)

• Evaluate a program, replacing concrete variables
  with abstract values.
• Concrete integer variable -32768 to 32767
• An abstract integer variable -,0,.
• Abstract interpretation provides a framework to
  reason about programs in the abstract.

9
Abstracting to Bounds

• Variable
• type(lower, upper)
• equal(expression)
• fromto(lower, upper)...
• between(expression, expression)
• Array
• As many variables
• Generalise across ranges where possible

10
Example
subtype Index is Integer range 0 .. 9 type D is
array (Index) of Integer R0 --check
Rgt-32768 and Rlt32767 For I in Index loop
-- Want to discover invariant here! --Igt0
and Ilt9 if D(I) gt 0 and D(I) lt 100 then
R R D(I) --check Rgt-32768
and Rlt32767 end if end loop
subtype Index is Integer range 0 .. 9 type D is
array (Index) of Integer R0 For I in Index
loop if D(I) gt 0 and D(I) lt 100 then
R R D(I) end if end loop
11
Example
subtype Index is Integer range 0 .. 9 type D is
array (Index) of Integer R0 --check
Rgt-32768 and Rlt32767 For I in Index
loop --invariant Igt0 and Ilt9 and --forall J
in 0..9 D(J)gt-32768 and D(J)lt32767
--check Igt0 and Ilt9 if D(I) gt 0 and D(I)
lt 100 then R R D(I)
--check Rgt-32768 and Rlt32767 end if end
loop
12
Example (AI Flowchart)
Pre-condition
R0
I0
Invariant N
Loop junction node
Simple junction node
D(I)? 0 and D(I)? 100
II1
RRD(I)
Normalised form of a SPARK for loop
Post-condition
I9
13
Recurrence Relations(Loop junction)

• Liner recurrence relations with constant
  coefficients (LRRCs)
• anc1an-1ckan-kf(n)
• ngtk
• Only use first powers of previous terms (an-11)
• Coefficients ck are constants
• f(n) is a function
• Example ana(n-1) 1
• Can automatically solve LRRCs (and a few other
  special cases) using
• Mathematica
• The Parma University's Recurrence Relation Solver
  (PURRS)
• Others?

14
Assignment

• First assignment to a variable inside a loop
• Build recurrence relations.
• The assignment Af(A) is recorded as A n
  equal(recurrence(f(A n-1 )))
• All other assignments
• Perform the assignment.
• The assignment Af(A) is applied to all
  expressions in A.
• Eliminate non-constants from expressions
• Generalise to extreme bounds.
• Replace non-constant f(B) in Aequal(f(B)) with
  bounds of f(B).
• A fromto(extreme-lower(B), extreme-upper(B))

15
Example (Variable R)
Invariant N
II1
16
Example (Variable R)
recurrence(R (n-1)0) ? RnR(n-1)0 RnR0 ? 0
R nType(-32768, 32767), equal(0)
recurrence(R (n-1)100) ? RnR(n-1)100 RnR0100
n ? 0100n ? 100n
Arriving at the loop
between(0, 100n)
n is in range 0 to infinity 0lt100n
fromto(0, 100n)
R nType(-32768, 32767), merge(equal(0), between
(recurrence(R (n-1)0),
recurrence(R (n-1)100)))
merge(equal(0), fromto(0, 100n)) equal(0) is
inside fromto(0, 100n)
R nType(-32768, 32767), fromto(0, 100n)
Returning from first iteration
Starting second iteration...
17
Property Discovery (Eliminate n)
Properties for R
R nType(-32768, 32767), fromto(0, 100n)
Express n in terms of I I nn ? nI n
I nType(-32768, 32767), equal(n), fromtoexit(-32
7681, exc(91)), fromtoexit(exc(91), 327671)
Replace n with I in R R nType(-32768,
32767), fromto(0, 100 I)
Rule out type 0 ? -32768 100 I ? 32767 ? 100 9
? 32767
Properties for I
Some details...
R ? 0 and R ? 100I
I ? 0 and I lt 10
18
Example (Discovered invariant)
subtype Index is Integer range 0 .. 9 type D is
array (Index) of Integer R0 --check
Rgt-32768 and Rlt32767 For I in Index
loop --invariant Igt0 and Ilt9 and Rgt0 and
Rlt100I and --forall J in 0..9 D(J)gt-32768 and
D(J)lt32767 --check Igt0 and Ilt9 if
D(I) gt 0 and D(I) lt 100 then R R
D(I) --check Rgt-32768 and Rlt32767
end if end loop
19
And the proofs?

• Invariant property VCs
• Rippling reduces VC to a residue
• Prove residue using proof planning
• Exception freedom VCs
• Transitivity based proof planning

20
Implementation (Underway)
SPARK code
Add new properties to code
Light weight SPARK Parser
Praxis Examiner
VCs
Rule files
SPARK structure
NuSPADE
Subprogram Spider
Method Abstracting to bounds
Proof Planner
Subprogram Details
Method Rippling
Proof scripts
CLAM
21
Related Work

• RUNCHECK (Steven M. German) (1981)
• Proves exception freedom VCs for Pascal
• Uses a few rewrite rules (7) to solve recurrence
  relations as a final stage
• Does not exploit program context
• Limited treatment of arrays (Considered array
  initialisation)
• Abstract Interpretation (Patrick Cousot, Radhia
  Cousot) (1976)
• Is algorithmic and always generates correct
  results
• No heuristics
• Good automatic linear property generation for
  programs with linear assignments and no arrays
• Used for compiler optimisation, exception
  detection, program documentation, program
  visualisation...

22
Conclusions

• Generate properties via (unsound) abstract
  interpretation
• Will contain heuristics
• Exploit off the shelf recurrence relation solvers
• More powerful (Include arrays, generate
  non-linear relationships)
• Can fail!
• Prove via
• Proof planning
• Automated
• Can fail!

23
EOF