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

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

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

Case Study: DEOS Kernel A real-time operating system for integrated modular avionics systems Large C++ program, manually sliced and inspected Slice translated to Java by NASA Ames –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:

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

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 –state space must be reduced –some form of abstraction is needed

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:

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

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

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

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

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

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

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

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

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}

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

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: index & element abstractions Class abstractions: abstract each field

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

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

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

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 (Clarke et. al.)

Status Bandera supports abstraction –Library of base type abstractions –Tool-support for user-defined abstraction –Array abstractions –Finding feasible counter-examples Surprisingly effective on realistic code –1000s of lines, 10s of threads –Non-trivial data that influences control

Ongoing Work Extending abstractions –Heap abstractions –Symbolic abstractions Automated support for selection –Counter-example driven refinement Environments and abstraction Discrete-time abstractions –Exploit scheduling information from RT Java

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]

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

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

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

{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 ( > 0) then [2] assert(true); else [3] assert(false);... Example of Infeasible Counter-example Signs

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

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

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