Bill J. Ellis Dependable Systems Group Heriot-Watt University (Project page: Proving Exception.

Slides:



Advertisements
Similar presentations
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Advertisements

De necessariis pre condiciones consequentia sine machina P. Consobrinus, R. Consobrinus M. Aquilifer, F. Oratio.
An Abstract Interpretation Framework for Refactoring P. Cousot, NYU, ENS, CNRS, INRIA R. Cousot, ENS, CNRS, INRIA F. Logozzo, M. Barnett, Microsoft Research.
Technology from seed Automatic Equivalence Checking of UF+IA Programs Nuno Lopes and José Monteiro.
A System to Generate Test Data and Symbolically Execute Programs Lori A. Clarke September 1976.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 11.
INF 212 ANALYSIS OF PROG. LANGS Type Systems Instructors: Crista Lopes Copyright © Instructors.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 13.
Presented by David LESENS and Johannes KANIG Thursday, 16 May 2013 Astrium Space Transportation AdaCore Formal Validation of Aerospace Software DASIA 2013.
ISBN Chapter 3 Describing Syntax and Semantics.
An Integration of Program Analysis and Automated Theorem Proving Bill J. Ellis & Andrew Ireland School of Mathematical & Computer Sciences Heriot-Watt.
HCSSAS Capabilities and Limitations of Static Error Detection in Software for Critical Systems S. Tucker Taft CTO, SofCheck, Inc., Burlington, MA, USA.
Program analysis Mooly Sagiv html://
OOP #10: Correctness Fritz Henglein. Wrap-up: Types A type is a collection of objects with common behavior (operations and properties). (Abstract) types.
Michael Ernst, page 1 Improving Test Suites via Operational Abstraction Michael Ernst MIT Lab for Computer Science Joint.
Review: forward E { P } { P && E } TF { P && ! E } { P 1 } { P 2 } { P 1 || P 2 } x = E { P } { \exists … }
Overview of program analysis Mooly Sagiv html://
Review: forward E { P } { P && E } TF { P && ! E } { P 1 } { P 2 } { P 1 || P 2 } x = E { P } { \exists … }
Describing Syntax and Semantics
CSC 8310 Programming Languages Meeting 2 September 2/3, 2014.
Chapter Seven Advanced Shell Programming. 2 Lesson A Developing a Fully Featured Program.
Language Evaluation Criteria
Chapter 1 Algorithm Analysis
CHAPTER 5: CONTROL STRUCTURES II INSTRUCTOR: MOHAMMAD MOJADDAM.
EGR 2261 Unit 5 Control Structures II: Repetition  Read Malik, Chapter 5.  Homework #5 and Lab #5 due next week.  Quiz next week.
Types for Programs and Proofs Lecture 1. What are types? int, float, char, …, arrays types of procedures, functions, references, records, objects,...
Is Proof More Cost-Effective Than Testing? Presented by Yin Shi.
© Andrew IrelandDependable Systems Group Proof Automation for the SPARK Approach to High Integrity Ada Andrew Ireland Computing & Electrical Engineering.
© Andrew IrelandDependable Systems Group. © Andrew IrelandDependable Systems Group Proof Automation for the SPARK Approach to High Integrity Ada Andrew.
© Andrew IrelandDependable Systems Group Cooperative Reasoning for Automatic Software Verification Andrew Ireland School of Mathematical & Computer Sciences.
© Andrew IrelandDependable Systems Group ITI Techmedia and Technology Transfer Andrew Ireland Dependable Systems Group School of Mathematical & Computer.
(On secondment at) Praxis High Integrity Systems Bath Dependable Systems Group School of Mathematical & Computer Sciences Heriot-Watt University Edinburgh.
© Andrew IrelandDependable Systems Group Cooperative Reasoning for Automatic Software Verification Andrew Ireland Dependable Systems Group School of Mathematical.
© Andrew IrelandDependable Systems Group On the Scalability of Proof Carrying Code for Software Certification Andrew Ireland School of Mathematical & Computer.
Chapter 5: Control Structures II (Repetition). Objectives In this chapter, you will: – Learn about repetition (looping) control structures – Learn how.
Introduction to Problem Solving. Steps in Programming A Very Simplified Picture –Problem Definition & Analysis – High Level Strategy for a solution –Arriving.
Carnegie Mellon Lecture 14 Loop Optimization and Array Analysis I. Motivation II. Data dependence analysis Chapter , 11.6 Dror E. MaydanCS243:
Bill J. Ellis Dependable Systems Group Heriot-Watt University (Project page: Proving Exception.
High Integrity Ada in a UML and C world Peter Amey, Neil White Presented by Liping Cai.
© Andrew IrelandDependable Systems Group Static Analysis and Program Proof Andrew Ireland School of Mathematical & Computer Sciences Heriot-Watt University.
© Andrew IrelandDependable Systems Group Invariant Patterns for Program Reasoning Andrew Ireland Dependable Systems Group School of Mathematical & Computer.
Reasoning about programs March CSE 403, Winter 2011, Brun.
1 CSCD 326 Data Structures I Software Design. 2 The Software Life Cycle 1. Specification 2. Design 3. Risk Analysis 4. Verification 5. Coding 6. Testing.
COP4020 Programming Languages Introduction to Axiomatic Semantics Prof. Robert van Engelen.
© Andrew IrelandDependable Systems Group Proof Automation for the SPARK Approach to High Integrity Ada Andrew Ireland Computing & Electrical Engineering.
September 9, Algorithms and Data Structures Lecture II Simonas Šaltenis Nykredit Center for Database Research Aalborg University
SPADEase: The Good, the Bad and the Ugly Bill J Ellis Dependable Systems Group School of Mathematical & Computer Sciences Heriot-Watt University Edinburgh.
Random Interpretation Sumit Gulwani UC-Berkeley. 1 Program Analysis Applications in all aspects of software development, e.g. Program correctness Compiler.
1 Assertions. 2 A boolean expression or predicate that evaluates to true or false in every state In a program they express constraints on the state that.
PROGRAMMING PRE- AND POSTCONDITIONS, INVARIANTS AND METHOD CONTRACTS B MODULE 2: SOFTWARE SYSTEMS 13 NOVEMBER 2013.
Static Techniques for V&V. Hierarchy of V&V techniques Static Analysis V&V Dynamic Techniques Model Checking Simulation Symbolic Execution Testing Informal.
Loop Invariants and Binary Search Chapter 4.4, 5.1.
1 Phase Testing. Janice Regan, For each group of units Overview of Implementation phase Create Class Skeletons Define Implementation Plan (+ determine.
© Andrew IrelandDependable Systems Group The Use of Patterns to Guide Code Certification: A Proposal Andrew Ireland School of Mathematical & Computer Sciences.
© Andrew IrelandDependable Systems Group Increasing Automation for Exception Freedom Proofs Andrew Ireland School of Mathematical & Computer Sciences Heriot-Watt.
September 18, Algorithms and Data Structures Lecture II Simonas Šaltenis Aalborg University
Dr. M. Al-Mulhem Introduction 1 Chapter 6 Type Systems.
Nyhoff, ADTs, Data Structures and Problem Solving with C++, Second Edition, © 2005 Pearson Education, Inc. All rights reserved Recursion,
SWEN421 – Lecture 3 Building High Integrity Software with SPARK Ada
Chapter 3 of Programming Languages by Ravi Sethi
Spring 2016 Program Analysis and Verification
Types for Programs and Proofs
Introduction To Repetition The for loop
Reasoning about code CSE 331 University of Washington.
State your reasons or how to keep proofs while optimizing code
Levels of Software Assurance in SPARK
Cooperative Reasoning for Automatic Software Verification
Proof Automation for the SPARK Approach to High Integrity Ada
Automatic Software Verification: A Renaissance
Discrete Mathematics CS 2610
Presentation transcript:

Bill J. Ellis Dependable Systems Group Heriot-Watt University (Project page: Proving Exception Freedom within High Integrity Software Systems

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

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

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

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

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

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

Abstract Interpretation (AI) Evaluate a program, replacing concrete variables with abstract values. –Concrete integer variable: to –An abstract integer variable: {-,0,+}. Abstract interpretation provides a framework to reason about programs in the abstract.

Abstracting to Bounds Variable: –type(lower, upper) –equal(expression) –fromto(lower, upper)... –between(expression, expression)… Array: –As many variables Generalise across ranges where possible

subtype Index is Integer range 0.. 9; type D is array (Index) of Integer; R:=0; --#check R>= and R<=32767; For I in Index loop --# Want to discover invariant here! --#I>=0 and I<=9; if D(I) >= 0 and D(I) <= 100 then R := R + D(I); --#check R>= and R<=32767; end if; end loop; 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; Example

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

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

Recurrence Relations (Loop junction) Liner recurrence relations with constant coefficients (LRRCs): –a n =c 1 *a n-1 +…c k *a n-k +f(n) n>=k Only use first powers of previous terms (a n-1 ^1) Coefficients c k are constants f(n) is a function –Example: a n =a (n-1) +1 Can automatically solve LRRCs (and a few other special cases) using: –Mathematica –The Parma University's Recurrence Relation Solver (PURRS) –Others?

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

Example (Variable R) I:=I+1 Invariant N Pre-condition R:=0 I:=0 R:=R+D(I) D(I)  0 and D(I)  100 I=9 Post- condition R={Type(-32768, 32767)} R={Type(-32768, 32767), equal(0)} R n ={Type(-32768, 32767), equal(recurrence(R (n-1) +D(I n )))  between(recurrence(R (n-1) +0), recurrence(R (n-1) +100))} R n ={Type(-32768, 32767), merge([equal(0), between(recurrence(R (n-1) +0), recurrence(R (n-1) +100))])}

Example (Variable R) R n ={Type(-32768, 32767), fromto(0, 100*n)} recurrence(R (n-1) +0)  R n =R (n-1) +0 R n =R 0  0 recurrence(R (n-1) +100)  R n =R (n-1) +100 R n =R *n  0+100*n  100*n between(0, 100*n) n is in range 0 to infinity 0<=100*n merge([equal(0), fromto(0, 100*n)]) equal(0) is inside fromto(0, 100*n) fromto(0, 100*n) R n ={Type(-32768, 32767), merge([equal(0), between(recurrence(R (n-1) +0), recurrence(R (n-1) +100))])} R n ={Type(-32768, 32767), equal(0)} Returning from first iteration Arriving at the loop Starting second iteration...

Property Discovery (Eliminate n) Express n in terms of I: I n =n  n=I n Replace n with I in R: R n ={Type(-32768, 32767), fromto(0, 100* I)} Properties for R Rule out type: 0  * I   100* 9  R  0 and R  100*I R n ={Type(-32768, 32767), fromto(0, 100*n)} I n ={Type(-32768, 32767), equal(n), fromto exit ( , exc(9+1)), fromto exit (exc(9+1), )} Properties for I I  0 and I < 10 Some details...

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

And the proofs? Invariant property VCs: –Rippling reduces VC to a residue Prove residue using proof planning Exception freedom VCs: –Transitivity based proof planning

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

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

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!

EOF