1. Abstraction and Modular Reasoning for the Verification of Software Corina Pasareanu, October, 2001 Thesis Committee: Matthew Dwyer, Major Advisor David Schmidt Michael Huth George Strecker Kenneth Kemp, Outside Chairperson

2. Finite-state Verification OK Finite-state system Specification Verification tool  or Error trace Line 5: … Line 12: … Line 15:… Line 21:… Line 25:… Line 27:… … Line 41:… Line 47:…

3. Finite-state Verification of Software Techniques for checking correctness of concurrent programs: Formal verification –That a program satisfies a complete specification Dynamic methods/testing –That examine the outcome of executions of the program –That check assertions during executions Finite state verification (FSV) –Automated (like testing) –Guarantees satisfaction of properties (like formal verification) –Useful for debugging (counter-examples)  FSV is a potential very useful technique for insuring high- quality software

4. Finite State Verification of Software Challenges: Creation of tractable models … software has large/infinite state space Modular reasoning about software components … using tools that reason about complete systems Solutions: Abstract interpretation … to reduce the data domains of a program Program completion … with code for missing components … use environment assumptions, assume-guarantee paradigm

5. Goals of our work … Develop multiple forms of tool support for … … abstraction and program completion … applicable to program source code … largely automated, usable by non-experts We evaluate the effectiveness of this tool support through… … implementation … application to real Java and Ada programs We concentrate on building … … finite-state models, not finite-state tools

6. SPIN, SMV, JPF… Model Checking Choose-free search and guided simulation Counter-example Analysis Heuristics for abstraction selection Data Abstraction Universal and synthesized environments Program Completion General Methodology Abstracted Completed Program Refine Selection Model of Program Property False! Translator Partial Program, Property  Assumption  Property True! yesno

7. Contributions Integration of existing technologies into a coherent methodology that enables FSV of software systems Development of new technologies: –Use of theorem proving to automatically derive abstractions of data types –Instrumentation of source code to enable assume- guarantee reasoning about partial programs –Two techniques for analysis of abstract counter- examples Formalization and implementation of these technologies Evaluation of technologies on case studies (Java, Ada)

8. Context The Bandera toolset (KSU) –Collection of program analysis and transformation components –Allows users to analyze properties of Java programs –Tailor analysis to property to minimize analysis time The Ada translation toolset Java PathFinder (NASA Ames) –Model checker for Java programs –Built on top of a custom made Java Virtual Machine –Checks for deadlock and violations of assertions

9. Related Projects The Microsoft Research SLAM project G. Holzmann’s Fever Tool (Bell Labs) Stoller’s stateless checker for Java programs Godefroid’s Verisoft (Bell Labs) David Dill’s Hardware Verification Group Eran Yahav’ s Java checking tool

10. Outline of the Talk Introduction  Data Abstraction (FSE’98, ICSE’01) Program Completion Abstract Counter-example Analysis Formal Justification Case Studies: Java and Ada Programs Conclusions, Limitations and Future Work

11. Finite-state Verification Effective for analyzing properties of hardware systems Limited success due to the enormous state spaces associated with most software systems Recent years have seen many efforts to apply those techniques to software Widespread success and adoption in industry

12. Abstraction: the key to scaling up Original system symbolic state Abstract system represents a set of states abstraction Safety: The set of behaviors of the abstract system over-approximates the set of behaviors of the original system

13. Data Type Abstraction int x = 0; if (x == 0) x = x + 1; Data domains (n<0) : NEG (n==0): ZERO (n>0) : POS Signs NEGPOSZERO int Code Signs x = ZERO; if (Signs.eq(x,ZERO)) x = Signs.add(x,POS); Collapses data domains via abstract interpretation:

14. Our hypothesis (?) Abstraction of data domains is necessary Automated support for –Defining abstract domains (and operators) –Selecting abstractions for program components –Generating abstract program models –Interpreting abstract counter-examples will make it possible to –Scale property verification to realistic systems

15. Abstraction in Bandera Abstraction Library BASL Compiler Variable Concrete Type Abstract Type Inferred Type Object x y done count o b int bool Buffer int …. Signs int bool …. Point Buffer Program Abstract Code Generator Abstracted Program Bandera Abstraction Specification Language Abstraction Definition PVS

16. Definition of Abstractions in BASL abstraction Signs abstracts int begin TOKENS = { NEG, ZERO, POS }; abstract(n) begin n {NEG}; n == 0 -> {ZERO}; n > 0 -> {POS}; end operator + add begin (NEG, NEG) -> {NEG} ; (NEG, ZERO) -> {NEG} ; (ZERO, NEG) -> {NEG} ; (ZERO, ZERO) -> {ZERO} ; (ZERO, POS) -> {POS} ; (POS, ZERO) -> {POS} ; (POS, POS) -> {POS} ; (_,_) -> {NEG,ZERO,POS}; /* case (POS,NEG),(NEG,POS) */ end Automatic Generation Forall n1,n2: neg?(n1) and neg?(n2) implies not pos?(n1+n2) Forall n1,n2: neg?(n1) and neg?(n2) implies not zero?(n1+n2) Forall n1,n2: neg?(n1) and neg?(n2) implies not neg?(n1+n2) Proof obligations submitted to PVS... Example: Start safe, then refine: +(NEG,NEG)={NEG,ZERO,POS}

17. Compiling BASL Definitions abstraction Signs abstracts int begin TOKENS = { NEG, ZERO, POS }; abstract(n) begin n {NEG}; n == 0 -> {ZERO}; n > 0 -> {POS}; end operator + add begin (NEG, NEG) -> {NEG} ; (NEG, ZERO) -> {NEG} ; (ZERO, NEG) -> {NEG} ; (ZERO, ZERO) -> {ZERO} ; (ZERO, POS) -> {POS} ; (POS, ZERO) -> {POS} ; (POS, POS) -> {POS} ; (_,_)-> {NEG, ZERO, POS}; /* case (POS,NEG), (NEG,POS) */ end public class Signs { public static final int NEG = 0; // mask 1 public static final int ZERO = 1; // mask 2 public static final int POS = 2; // mask 4 public static int abs(int n) { if (n < 0) return NEG; if (n == 0) return ZERO; if (n > 0) return POS; } public static int add(int arg1, int arg2) { if (arg1==NEG && arg2==NEG) return NEG; if (arg1==NEG && arg2==ZERO) return NEG; if (arg1==ZERO && arg2==NEG) return NEG; if (arg1==ZERO && arg2==ZERO) return ZERO; if (arg1==ZERO && arg2==POS) return POS; if (arg1==POS && arg2==ZERO) return POS; if (arg1==POS && arg2==POS) return POS; return Bandera.choose(7); /* case (POS,NEG), (NEG,POS) */ } Compiled

18. Data Type Abstractions Library of abstractions for base types contains: –Range(i,j), i..j modeled precisely, e.g., Range(0,0) is the signs abstraction –Modulo(k), Set(v,…) –Point maps all concrete values to unknown –User extendable for base types Array abstractions –Specified by an index abstraction and an element abstraction Class abstractions –Specified by abstractions for each field

19. Comparison to Related Work Predicate abstraction (Graf, Saidi) –We use PVS to abstract operator definitions, not complete systems –We can reuse abstractions for different systems Tool support for program abstraction –e.g., SLAM, JPF, Feaver Abstraction at the source-code level –Supports multiple checking tools –e.g., JPF, Java Checker/Verisoft, FLAVERS/Java, …

20. Outline of the Talk Introduction Data Abstraction  Program Completion (FSE’98, SPIN’99) Abstract Counter-example Analysis Formal Justification Case Studies: Java and Ada Programs Conclusions, Limitations and Future Work

21. Program Completion Software systems are collections of software components Approach similar to unit testing of software –Applied to components (units) that are code complete –Stubs and drivers simulate environment for unit We complete a system with a source code representation for missing components –Universal environments –Environment assumptions used to refine definitions of missing components

22. procedure stub is choice: Integer; theObject: Object_Type; begin loop case choice is when 1 => Insert(theObject); when 2 => theObject:=Remove; when 3 => null; when others => exit; end case; end loop; end stub; Example of Universal Environment The stub for an Ada partial program, with an Insert procedure and a Remove function

23. Assume-guarantee Model Checking A system specification is a pair –  describes the property of the system –  describes the assumption about the environment Universal environment System Linear temporal paradigm:  ->  vs. || (LTL) Synthesized environment  (LTL) System 2 nd approach:  vs. || (LTL) (ACTL) System Problem: check property  vs., assuming 

24. Synthesis of Environments Environment assumptions  –Encode behavioral info. about system interfaces –Written in LTL “Classical” tableau construction for LTL –Modified to assume that only one interface operation can occur at a time –Builds a model of  : I.e., a graph with arcs labeled by interface operations Can be easily translated into source code

25. Graph Generated from Assumption: (! Remove) U Insert 0 8 9 16 Insert  Remove Insert   Remove Insert 

26. Synthesized Code procedure stub is state,choice: Integer; theObject: Object_Type; begin state:=0; loop case state is when 0 => case choice is when 1 => Insert(theObject);state:=8; when 2 => null;state:=9; when others => exit; end case; when 8 => case choice is when 1 => Insert(theObject);state:=8; when 2 => theObject:=Remove;state:=16; when 3 => null; state:=8; when others => exit; end case; when 9 => case choice is when 1 => Insert(theObject);state:=8; when 2 => null;state:=9; when others => exit; end case; when 16=> case choice is when 1 => Insert(theObject);state:=16; when 2 => theObject:=Remove;state:=16; when 3 => null; state:=16; when others => exit; end case; end case; end loop; end stub;

27. Comparison to Related Work Much theoretical work on compositional verification Avrunin, Dillon, Corbett: –Analysis of real-time systems, described as a mixture of source code and specifications Colby, Godefroid, Jagadeesan: –Automatable approach to complete a partially specified system –Use the VeriSoft toolset –No environment assumptions Long: –Synthesis of environments from ACTL

28. Outline of the Talk Introduction Data Abstraction Program Completion  Abstract Counter-example Analysis (TACAS’01) Formal Justification Case Studies: Java and Ada Programs Conclusions, Limitations and Future Work

29. Abstract Counter-example Analysis Example: x = -2; if(x + 2 == 0) then... x = NEG; if(Signs.eq(Signs.add(x,POS),ZERO)) then... {NEG,ZERO,POS} For an abstracted program, a counter-example may be infeasible because: –Over-approximation introduced by abstraction

30. Our Solutions Choice-bounded State Space Search –“on-the-fly”, during model checking Abstract Counter-example Guided Concrete Simulation –Exploit implementations of abstractions for Java programs –Effective in practice

31. Choose-free state space search Theorem [Saidi:SAS’00] Every path in the abstracted program where all assignments are deterministic is a path in the concrete program. Bias the model checker –to look only at paths that do not include instructions that introduce non-determinism JPF model checker modified –to detect non-deterministic choice (i.e. calls to Bandera.choose()); backtrack from those points

32. Choice-bounded Search choose() X X Detectable Violation Undetectable Violation State space searched

33. Counter-example guided simulation (?) Use abstract counter-example to guide simulation of concrete program Why it works: –Correspondence between concrete and abstracted program –Unique initial concrete state (Java defines default initial values for all data)

34. Nondeterminism! Java Program: class App{ public static void main(…) { [1] new AThread().start(); … [2] int i=0; [3] while(i<2) { … [4] assert(!Global.done); [5] i++; }}} class Athread extends Thread { public void run() { … [6] Global.done=true; }} Example of Abstracted Code Choose-free counter-example: 1 - 2 - 6 - 3 - 4 i=zero Abstracted Program: class App{ public static void main(…) { [1] new AThread().start(); … [2] int i=Signs.ZERO; [3] while(Signs.lt(i,signs.POS)){ … [4] assert(!Global.done); [5] i=Signs.add(i,Signs.POS); }}} class Athread extends Thread { public void run() { … [6] Global.done=true; }}

35. Example of Abstracted Code Abstract counter-example: 1 - 2 - 3 - 4 - 5 - 3 - 4 - 5 - 3 - 6 - 4 Mismatch i=zero i=0 i=zero i=0 i=zero i=0 i=pos i=1 i=pos i=1 i=pos i=1 i=pos i=2 i=pos i=2 Java Program: class App{ public static void main(…) { [1] new AThread().start(); … [2] int i=0; [3] while(i<2) { … [4] assert(!Global.done); [5] i++; }}} class Athread extends Thread { public void run() { … [6] Global.done=true; }} Abstracted Program: class App{ public static void main(…) { [1] new AThread().start(); … [2] int i=Signs.ZERO; [3] while(Signs.lt(i,signs.POS)){ … [4] assert(!Global.done); [5] i=Signs.add(i,Signs.POS); }}} class Athread extends Thread { public void run() { … [6] Global.done=true; }}

36. Hybrid Approach Choose-free Model Check Abstraction Program & Property Model Check Abstract Program & Property Property true! Property false! (counter-example) Guided Simulation Abstract counter-example Refine selections Mismatch

37. Comparison to Related Work Previous work: –After model checking; analyze the counter-example to see if it is feasible Pre-image computations; theorem prover based (InVest) Forward simulation (CMU) Symbolic execution (SLAM)

38. Outline of the Talk Introduction Data Abstraction Program Completion Abstract Counter-example Analysis  Formal Justification Case Studies: Java and Ada Programs Conclusions, Limitations and Future Work

39. Formal Justification Our techniques build safe abstractions of software systems P < P’ means “ P’ is a safe abstraction of P” –< is a simulation relation (Milner) –Properties are expressed in universal temporal logics (LTL, ACTL) preserved by < Data Abstraction builds abstractions P abs of systems P s.t. P < Pabs Universal Environments U: P||E < P||U, for all environments E Synthesized Environments T  from assumptions  : P||E < P||T , for all environments E that satisfy 

40. Outline of the Talk Introduction Data Abstraction Program Completion Abstract Counter-example Analysis Formal Justification  Case Studies: Java and Ada Programs Conclusions, Limitations and Future Work

41. Case Studies Filter-based Model Checking of a Reusable Parameterized Programming Framework (FSE’98) –Ada implementation of the Replicated Workers Framework Model Checking Generic Container Implementations (GP’98) –Ada implementations of generic data structures: queue, stack and priority queue Abstracted using data type abstraction Completed with code for universal environments Environments’ behavior refined based on LTL assumptions We used the SPIN tool: –To check 8/5 properties; 5/3 required use of assumptions –To detect seeded errors

42. Case Studies (contnd.) Assume-guarantee Model Checking of Software: A Comparative Case Study (SPIN’99) –Ada implementations of software components: The Replicated Workers Framework, the Generic Containers The Gas Station, the Chiron Client Out of 39 properties, 15 required use of assumptions For, we compared two ways of completing systems: –Universal environment: check  ->  (LTL) –using SPIN –Synthesized environment from  (LTL): check  (LTL/ACTL) –using SPIN/SMV Synthesized environments enable faster verification

43. Case Studies (contnd.) Analysis of the Honeywell DEOS Operating System (NASA’00,ICSE’01) –A real time operating system for integrated modular avionics –Non-trivial concurrent program (1433 lines of code, 20 classes, 6 threads) –Written in C++, translated into Java and Promela –With a known bug Verification of the system exhausted 4 Gigabytes of memory without completion Abstracted using data type abstraction Completed with code for –User threads that run on the kernel –A system clock and a system timer Environments’ behavior refined based on LTL assumptions Checked using JPF and SPIN Defect detected using choice-bounded search

44. Case Studies (contnd.) Finding Feasible Counter-examples when Model Checking Abstracted Java Programs (TACAS’01) We applied the 2 counter-example analysis techniques to Java defective applications: –Remote agent experiment, Pipeline, Readers-Writers, DEOS Both techniques are fast: –Choose-free search is depth-bounded –Cost of simulation depends on the length of the counter-example Choose-free counter-examples … –are common –are short –enable more aggressive abstraction

45. Summary We integrated several technologies into a coherent methodology that enables FSV of complex, concurrent software systems We developed technologies for… –Data type abstraction: Enable non-experts to generate models that make FSV less costly Facilities to define, select and generate abstracted programs –Program completion Enable verification of properties of individual components, collections of components and entire systems Take into account assumptions about environment behavior –Analysis of abstract counter-examples Choose-free state space search Counter-example guided simulation We implemented and formalized these technologies We evaluated them on extensive case studies (Ada and Java)

46. Future Work Generalize choice-bounded search technique –CTL* model checking of abstracted programs Extend abstraction support for objects –Heap abstractions to handle an unbounded number of dynamically allocated objects Extend automation –Automated selection and refinement of abstractions based on counter-example analysis

47. Conclusions Tool support for: –Abstraction of data domains –Program completion –Interpretation of counter-examples … is essential for the verification of realistic software systems Ensures the safety of the verification process

48. Array Abstractions Specified by: –an index abstraction and –an element abstraction Example: WidgetInfo wi[k] –use signs for index –use some other abstraction for WidgetInfo Abstracted array awi has 2 elements: –awi[zero] abstracts wi[0] –awi[pos] summarizes info about wi[1] …wi[k]

49. Property Abstraction System Model Property Program Abstraction (over-approximation) Property Abstraction (under-approximation) If the abstract property holds on the abstract system, then the original property holds on the original system

50. Property Abstraction Properties are temporal logic formulas, written in negational normal form. Abstract propositions under-approximate the truth of concrete propositions. Examples: –Invariance property: –Abstracted to: –Invariance property: –Abstracted to:  (x > -1)  ((x = zero) V (x=pos))  (x > -2)  ((x = zero) V (x=pos))