tool-supported program abstraction for finite-state verification matthew dwyer 1, john hatcliff 1,...

Tool-supported Program Abstraction Tool-supported Program Abstraction for Finite-state Verificationfor Finite-state Verification

Matthew Dwyer1, John Hatcliff1, Corina Pasareanu1, Robby1, Roby Joehanes1, Shawn Laubach1, Willem Visser2, Hongjun Zheng1

Kansas State University1

NASA Ames Research Center/RIACS2

http://www.cis.ksu.edu/santos/bandera

Finite-state VerificationFinite-state Verification

OKFinite-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 VerificationFinite-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 andadoption in industry

Abstraction: the key to scaling upAbstraction: the key to scaling up

Originalsystem

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 …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 (NASA Ames)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:

DEOS ArchitectureDEOS 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 DEOSVerification 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

Data Type AbstractionData Type Abstraction

int x = 0;if (x == 0) x = x + 1;

Data domains

(n<0) : NEG(n==0): ZERO(n>0) : POS

Signs

NEG POSZERO

int

Code

Signs x = ZERO;if (Signs.eq(x,ZERO)) x = Signs.add(x,POS);

Collapses data domains via abstract interpretation:

Variable SelectionVariable Selection

Requirement Monitor

Environment


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


int itsLastExecution; ...public void startChargingCPUTime(){ int cp=itsEvent.currentPeriod(); if(cp == itsLastExecution) { ... }

class Thread


Unbounded!

Variable SelectionVariable Selection

Requirement Monitor

Environment


User Process 1

User Process 2

...

DEOS Kernel




class Thread


Data dependencies

Attaching Abstract TypesAttaching Abstract Types

Requirement Monitor

Environment


User Process 1

User Process 2

...

DEOS Kernel




class Thread


SIGNS

SIGNS

SIGNS

Code TransformationCode Transformation

Requirement Monitor

Environment


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


Signs itsLastExecution; ...public void startChargingCPUTime(){ Signs cp=itsEvent.currentPeriod(); if(Signs.eq(cp,itsLastExecution)){ ... }

class Thread


Verification of Abstracted DEOS 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

Our hypothesis 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 BanderaAbstraction in Bandera

AbstractionLibrary

BASLCompiler

VariableConcrete Type

Abstract Type

Inferred Type

Object

xydonecount

ob

intintbool

Buffer

int….

SignsSignsSigns

intbool

….PointBuffer

Program Abstract CodeGenerator

AbstractedProgram

BanderaAbstractionSpecificationLanguage

AbstractionDefinition

PVS

Definition of Abstractions in BASLDefinition of Abstractions in BASLabstraction Signs abstracts intbegin TOKENS = { NEG, ZERO, POS };

abstract(n) begin n < 0 -> {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

AutomaticGeneration

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 DefinitionsCompiling BASL Definitions

abstraction Signs abstracts intbegin TOKENS = { NEG, ZERO, POS };

abstract(n) begin n < 0 -> {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 AbstractionsData 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

Interpreting ResultsInterpreting 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 searchChoose-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 SearchChoice-bounded Search

choose()

XX

Detectable ViolationUndetectable Violation

State space searched

Comparison to Related Work 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)

ConclusionsConclusions

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

tool-supported program abstraction for finite-state verification matthew dwyer 1, john hatcliff 1,...

Documents

program abstraction

abstract domains

abstract interpretation

form of abstraction

program source code

step counterexampleafter

step counterexampledoes

verification of deoswe