1 / 24

Proving Exception Freedom within High Integrity Software Systems

Proving Exception Freedom within High Integrity Software Systems. Bill J. Ellis (bill@macs.hw.ac.uk) Dependable Systems Group Heriot-Watt University (Project page: http://www.macs.hw.ac.uk/~air/clamspark/). Overview. High integrity software Proving exception freedom in SPARK

dora-doyle
Download Presentation

Proving Exception Freedom within High Integrity Software Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Proving Exception Freedom within High Integrity Software Systems Bill J. Ellis (bill@macs.hw.ac.uk) Dependable Systems Group Heriot-Watt University (Project page: http://www.macs.hw.ac.uk/~air/clamspark/)

  2. Overview • High integrity software • Proving exception freedom in SPARK • Property discovery • Abstract interpretation • Recurrence relations • Interval arithmetic • Proofs • Conclusions

  3. 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

  4. 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...

  5. 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...

  6. 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

  7. Example Code subtype Index is Integer range 0 .. 9; type D is array (Index) of Integer; R:=0; For I in Index loop if D(I) >= 0 and D(I) <= 100 then R := R + D(I); end if; end loop;

  8. Example Code(Exception Freedom Checks) subtype Index is Integer range 0 .. 9; type D is array (Index) of Integer; --#check 0>=-32768 and 0<=32767; R:=0; For I in Index loop --#invariant I>=0 and I<=9 and --#forall J in 0..9 D(J)>=-32768 and D(J)<=32767; --#check I>=0 and I<=9; if D(I) >= 0 and D(I) <= 100 then --#check I>=0 and I<=9; --#check R+D(I)>=-32768 and R+D(I)<=32767; R := R + D(I); end if; end loop;

  9. Pre-condition Prove properties hold between between cut points Check ... Check Check Invariant Prove exception freedom VCs using properties ... Check Check ... Post-condition Check Exception Freedom VCs

  10. Proof Strategy Success! Prove Exception Freedom VCs Try proof again Fail Discover properties (Typically invariants) Prove properties

  11. 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.

  12. Example (AI Flowchart) Pre-condition R:=0 I:=0 Loop junction node Invariant N Simple junction node D(I)0 and D(I) 100 I:=I+1 R:=R+D(I) Normalised form of a SPARK for loop Post-condition I=9

  13. Recurrence Relations • Fibonacci sequence: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144.. • Recurrence relation: A0=0, A1=1, An=A(n-1) +A(n-2) • Liner recurrence relations with constant coefficients (LRRCs): • An=c1*A(n-1)+…+ck*A(n-k)+f(n) • nk • Only use first powers of previous terms (A(n-1)^1) • Coefficients ck are constants • f(n) is a function • Can automatically solve LRRCs (and a few other special cases) using: • Mathematica • The Parma University's Recurrence Relation Solver (PURRS)

  14. Interval Arithmetic/Algebra • A theory for reasoning about bounds. • Bounds on x: x1 and x 5 • Interval: X=[1, 5], lower: X=1, upper: X=5 • Operations are defined on intervals: • X+Y = [X+Y, X+Y] • X-Y = [X-Y, X-Y] • Example: • [0, 2] + [-4, 6] = [0+(-4), 2+6] = [-4, 8] • [0, 2] - [-4, 6] = [0-6, 2-(-4)] = [-6, 6]

  15. Property Discovery • Abstract interpretation: • Focus on bounds of variables and arrays. • Discover and propagate bounds: • Using code semantics. (Of assignment, test, …) • Exploit semantics of exception freedom. • Use interval algebra and proof planning. • Loop junction nodes (Invariant discovery): • Exploit recurrence relation solvers. • Replace ‘n’ with program variables.

  16. R :[0,0] R:[min(R), max(R)] D[0,0]:[0, 100] R:[(R (n-1))+(D(I)), ((R (n-1)) +(D(I))] R:merge([(R (n-1))+0, (R (n-1)) +100], [0, 0]) Example (Variable R) Pre-condition R:=0 I:=0 Invariant N D(I)0 and D(I) 100 I:=I+1 R:=R+D(I) R:[(R (n-1))+(D(0)), ((R (n-1)) +(D(0))] R:[(R (n-1))+0, ((R (n-1)) +100] I=9 Post-condition

  17. Example (Variable R) Solve lower: Rn = R (n-1)+0 Rn=R0 0 R :[0, 0] Arriving at the loop Solve upper: Rn = R (n-1)+100 Rn=R0 + 100*n 0 + 100*n  100*n R:merge( [(R (n-1))+0, (R (n-1)) +100], [0, 0]) R:merge([0, 100*n], [0, 0]) R:[0, 100*n] Returning from first iteration Starting second iteration...

  18. Invariant Discovery (Eliminate n) Properties for I Invariant N Some details... R:[0, 100*n] I  0 and I  9 I:[n,n] | {exit([min(I), 9]) or exit([10, max(I)])} Properties for R Express n in terms of I: I=n  n=I Substitute n for I in R: R:[0, 100*I] Stabilised abstract values for R and I at the invariant R  0 and R  100*I

  19. Example (Discovered invariant) subtype Index is Integer range 0 .. 9; type D is array (Index) of Integer; --#check 0>=-32768 and 0<=32767; R:=0; For I in Index loop --#invariant I>=0 and I<=9 and R>=0 and R<=100*I and --#forall J in 0..9 D(J)>=-32768 and D(J)<=32767; --#check I>=0 and I<=9; if D(I) >= 0 and D(I) <= 100 then --#check R+D(I)>=-32768 and R+D(I)<=32767; --#I>=0 and I<=9; R := R + D(I); end if; end loop;

  20. And the proofs? • Invariant property VCs: • Rippling reduces VC to a residue • Prove residue using proof planning • Exception freedom VCs: • Middle-out reasoning? • ‘Look ahead’ using interval algebra?

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

  22. 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 • Good automatic linear property generation for programs with linear assignments and no arrays • Used for compiler optimisation, exception detection, program documentation, program visualisation...

  23. Conclusions Abstract Interpretation (Framework) + Interval Algebra (Theory) + Recurrence Relations (Off the shelf tools) + Proof Planning (Light reasoning) = Property generation for exception freedom Properties + Rippling (For invariants) + Proof Planning (Suitable methods) = Automated exception freedom proof Note: Is not complete -- Can fail!

  24. EOF

More Related