1. Tool-supported Program Abstraction for Finite-state Verification Matthew Dwyer 1, John Hatcliff 1, Corina Pasareanu 1, Robby 1, Roby Joehanes 1, Shawn Laubach 1, Willem Visser 2, Hongjun Zheng 1 Kansas State University 1 NASA Ames Research Center/RIACS 2 http://www.cis.ksu.edu/santos/bandera

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

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

5. Goals of our work … Develop multiple forms of tool support for abstraction that are … … applicable to program source code … largely automated … usable by non-experts Evaluate the effectiveness of this tool support through… … implementation in the Bandera toolset … application to real multi-threaded Java programs

6. Case Study: DEOS Kernel (NASA Ames) A real-time operating system for integrated modular avionics systems Non-trivial concurrent Java program: 1443 lines of code, 20 classes, 6 threads With a known bug Honeywell Dynamic Enforcement Operating System (DEOS) Application processes are guaranteed to be scheduled for their budgeted time during a scheduling unit Requirement:

7. DEOS Architecture Requirement Monitor Environment System Clock & Timer User Process 1 User Process 2... DEOS Kernel... if(...) assert(false);... class Thread class StartofPeriodEvent class ListofThreads class Scheduler

8. Verification of DEOS We used Bandera and Java PathFinder (JPF) Verification of the system exhausted 4 Gigabytes of memory without completing –no information about satisfaction of requirement To verify property or produce a counter- example –to reduce the state space to a tractable size –some form of abstraction is needed

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

10. Variable Selection Requirement Monitor Environment System Clock & Timer User Process 1 User Process 2... Control dependencies: 29 conditionals 16 methods 32 variables DEOS Kernel int itsPeriodId = 0;... public int currentPeriod() { return itsPeriodId; } public void pulseEvent(...) {... if(countDown == 0) { itsPeriodId=itsPeriodId + 1;... } class StartofPeriodEvent int itsLastExecution;... public void startChargingCPUTime(){ int cp=itsEvent.currentPeriod(); if(cp == itsLastExecution) {... } class Thread... if(...) assert(false);...

11. Variable Selection Requirement Monitor Environment System Clock & Timer User Process 1 User Process 2... Control dependencies: 29 conditionals 16 methods 32 variables DEOS Kernel int itsPeriodId = 0;... public int currentPeriod() { return itsPeriodId; } public void pulseEvent(...) {... if(countDown == 0) { itsPeriodId=itsPeriodId + 1;... } class StartofPeriodEvent int itsLastExecution;... public void startChargingCPUTime(){ int cp=itsEvent.currentPeriod(); if(cp == itsLastExecution) {... } class Thread... if(...) assert(false);...

12. Unbounded! Variable Selection Requirement Monitor Environment System Clock & Timer User Process 1 User Process 2... DEOS Kernel int itsPeriodId = 0;... public int currentPeriod() { return itsPeriodId; } public void pulseEvent(...) {... if(countDown == 0) { itsPeriodId=itsPeriodId + 1;... } class StartofPeriodEvent int itsLastExecution;... public void startChargingCPUTime(){ int cp=itsEvent.currentPeriod(); if(cp == itsLastExecution) {... } class Thread... if(...) assert(false);... Data dependencies

13. Attaching Abstract Types Requirement Monitor Environment System Clock & Timer User Process 1 User Process 2... DEOS Kernel int itsPeriodId = 0;... public int currentPeriod() { return itsPeriodId; } public void pulseEvent(...) {... if(countDown == 0) { itsPeriodId=itsPeriodId + 1;... } class StartofPeriodEvent int itsLastExecution;... public void startChargingCPUTime(){ int cp=itsEvent.currentPeriod(); if(cp == itsLastExecution) {... } class Thread... if(...) assert(false);... SIGNS

14. Code Transformation Requirement Monitor Environment System Clock & Timer User Process 1 User Process 2... DEOS Kernel Signs itsPeriodId = ZERO;... public Signs currentPeriod() { return itsPeriodId; } public void pulseEvent(...) {... if(countDown == 0) { itsPeriodId=Signs.add(itsPeriodId,POS);... } class StartofPeriodEvent Signs itsLastExecution;... public void startChargingCPUTime(){ Signs cp=itsEvent.currentPeriod(); if(Signs.eq(cp,itsLastExecution)){... } class Thread... if(...) assert(false);...

15. Verification of Abstracted DEOS JPF completed the check –produced a 464 step counter-example Does the counter-example correspond to a feasible execution? –difficult to determine –because of abstraction, we may get spurious errors We re-ran JPF to perform a customized search –found a guaranteed feasible 318 step counter-example After fixing the bug –the requirement was verified

16. 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 –Ensure the safety of the verification process

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

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

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

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

21. Interpreting Results 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

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

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

24. 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, … Counter-example analysis –Theorem prover based (InVest) –Forward simulation (CMU)

25. Conclusions Tool support for abstraction of base and array types enables verification of real properties of real programs Extend support for objects –Heap abstractions to handle an unbounded number of dynamically allocated objects Extend automation –Automated selection and refinement based on counter-example analysis

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

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

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

29. Related Work Other DEOS case studies (promela, java) SLAM Feaver JPF Predicate Abstraction Predicate abstraction in general Invest/CMU

30. {NEG,ZERO,POS}... [1] if(Signs.gt(Signs.add(NEG,POS),ZERO)) then [2] assert(true); else [3] assert(false);... Interpreting Results [1]: [2]: Infeasible counter-example [1]: [2]: [3]: X... [ 1] if (-2 + 3 > 0) then [2] assert(true); else [3] assert(false);... Example of Infeasible Counter-example Signs

31. Abstraction: the key to scaling up Original model symbolic state Abstract model 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