Proof Automation for the SPARK Approach to High Integrity Ada Andrew Ireland Computing & Electrical Engineering Heriot-Watt Univeristy Edinburgh

Executive Summary Investigate the role of proof planning within the SPARK approach to high integrity Ada Funded by the EPSRC Critical Systems programme (GR/R24081) in collaboration with Praxis Critical Systems Julian Richardson (Co-investigator) and Bill Ellis (Research Associate)

Outline Background and basic approach Proposed verification architecture Initial investigation into proof automation Future work

Program Verification Long history dating back to 70s, Wegbreit, German, Katz & Manna, … Theorem proving and heuristic components were kept separate Adopting a proof planning approach integrates high-level theorem proving and heuristic components

Ada Verification Systems ANNA: Stanford University PAVG Penelope: Odyssey Research Associates MALPAS: TA Group (RSRE Malvern) SPARK: Praxis Critical Systems (PVL)

Praxis Critical Systems Internationally leading within the sector Aerospace, Defence, Transportation, Finance, Energy and Utilities. Boeing, Lockheed-Martin, CAA, FAA, QinetiQ (DERA), Westinghouse Signals, MONDEX,...

SPARK Projects SHOLIS: Ship Helicopter Operating Limits Instrumentation System, UK MoD’s first Def Standard 00-55 project C130J: Lockheed Martin military transport aircraft MONDEX: International smart card security, developed to ITSEC E6 standard

The SPARK Language A subset of Ada that eliminates potential ambiguities and insecurities Specification supported via code level annotations

Static Analysis Data flow analysis: checks basic integrity constraints, e.g. definition-usage Information flow analysis: checks various interdependencies via program annotations Formal verification: generates verification conditions (VCs) based upon program annotations and SPARK semantics

The SPARK Tools path functions user SPADE SPARK VCs Proof Examiner Checker VCs proof code flow analysis feedback rules (lemmas) SPADE Simplifier

Clam-Oyster user conjectures planner checker tactic proof theory

NuSPADE conjectures user planner VCs checker proof cmd theory

NuSPADE: High-Level Aims Integrity: only modify the SPADE proof state via SPADE commands Compatibility: preserve SPADE at its core Transparency: provide users with the look-and-feel of a SPADE session

Proof Plans ind-strat inv-strat induction simplify ripple simplify tautology fertilize tautology fertilize

Polish Flag Problem --# pre (for all I in IndexRange => (Flag(I)=Red or Flag(I)=White)) --# post for some P in Integer range (Flag'First) .. (Flag'Last+1) => --# ((for all Q in Integer range Flag'First..(P-1) => (Flag(Q)=Red)) and --# (for all R in Integer range P..Flag'Last => (Flag(R)=White)));

Loop Invariant Flag'First I J Flag'Last --# assert Flag'First<=I and --# J<=(Flag'Last+1) and --# I<=J and --# (for all Q in Integer range Flag'First..(I-1) => (Flag(Q)=Red)) and --# (for all R in Integer range J..Flag'Last => (Flag(R)=White));

SPARK Code loop … if else J:=J-1; T:=Flag(I); Flag(I):=Flag(J); Flag(J):=T; end if; end loop; SPARK Code procedure Partition_Section(Flag: in out ArrayOfColours) is subtype JustBiggerRange is Integer range Flag'First .. Flag'Last+1; I: JustBiggerRange; J: JustBiggerRange; T: Colour; begin I:=Flag'First; J:=Flag'Last+1; loop --# assert Flag'First<=I and --# J<=(Flag'Last+1) and --# I<=J and --# (for all Q in Integer range Flag'First..(I-1) => (Flag(Q)=Red)) and --# (for all R in Integer range J..Flag'Last => (Flag(R)=White)); exit when I=J; if Flag(I)=Red then I:=I+1; else J:=J-1;T:=Flag(I); Flag(I):=Flag(J); Flag(J):=T; end if; end loop; end Partition_Section Flag(I)=White

Verification Condition procedure_partition_section_3. H1: indexrange__first <= i . H2: j <= indexrange__last + 1 . H3: i <= j . H4: for_all (q_: integer, ((q_ >= indexrange__first) and (q_ <= i - 1)) -> (element(flag, [q_]) = red)) . H5: for_all (r_: integer, ((r_ >= j) and (r_ <= indexrange__last)) -> (element(flag, [r_]) = white)) . H6: not (i = j) . H7: not (element(flag, [i]) = red) . -> C1: indexrange__first <= i . C2: j - 1 <= indexrange__last + 1 . C3: i <= j - 1 . C4: for_all (q_: integer, ((q_ >= indexrange__first) and (q_ <= i - 1)) -> element(update(update(flag, [i], element(flag, [j - 1])), [j - 1], element(flag, [i])), [q_]) = red)) . C5: for_all (r_: integer, ((r_ >= j - 1) and (r_ <= indexrange__last)) -> (element(update(update(flag, [i], element(flag, [j-1])), [j-1], element(flag, [i])), [r_]) = white)) .

Given Goal Ripple plan = difference identification + reduction

Rewrite Rules

Ripple Preconditions there exists a subterm T of the goal formula that contains a wave-front there exists a wave-rule that matches T any wave-rule conditions follow from the proof context Resulting inward directed wave-fronts are potentially cancellable Note: Stronger decision procedure required for 3

Speculative Loop Invariant Flag'First P Flag'Last --# assert Flag'First<=P and --# P<=(Flag'Last+1) and --# (for all Q in Integer range Flag'First..(P-1) => (Flag(Q)=Red)) and --# (for all R in Integer range P..Flag'Last => (Flag(R)=White));

Proof Failure Given Goal

Failure Analysis Blocked wave-front Matching wave-rule Failed precondition 3. any wave-rule conditions follow from the proof context

Productive Use Of Failure Generalization Case split Revise Induction Lemma speculation Precondition 1 2 3 4 Patch X X X X

Proof Patch Find minimal instantiation for P such that i and (j-1) lie out side r, i.e. P becomes j Ripple plan applicable to revised invariant conjecture

Range Splitting Proof Critic While the goal concerned with “white” gives rise to P = j, the complementary “red” goal gives rise to P = i This inconsistency suggests the required 3-way range split, i.e. i j

Extending Critics Mechanism Build upon current capability to analyse failures over multiple branches Integrate a constraint solving capability Develop a bottom-up invariant generation capability - also important for reasoning about the absence of run-time errors.

Future Work Complete first prototype of NuSPADE Adapt existing proof plans for SPADE Develop corresponding generic proof cmd templates (tactics) Extend critics mechanism Address proof management issues Investigate industrial strength case studies