Date post: | 19-Jan-2016 |
Category: |
Documents |
Upload: | delphia-henderson |
View: | 213 times |
Download: | 0 times |
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
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 SelectionVariable 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 SelectionVariable 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 TypesAttaching 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
SIGNS
SIGNS
Code TransformationCode 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 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