
5c8b2be3d2db42196a462a7017726cbc.ppt
- Количество слайдов: 24
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
Abstraction: the key to scaling up represents a set of states symbolic state abstraction Original system Abstract system 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 Honeywell Dynamic Enforcement Operating System (DEOS) A real-time operating system for integrated modular avionics systems l Large C++ program, manually sliced and inspected l Slice translated to Java by NASA Ames l – 1443 lines of code, 20 classes, 6 threads l With a known bug Requirement: Application processes are guaranteed to be scheduled for their budgeted time during a scheduling unit
DEOS Architecture DEOS Kernel class Thread Environment User Process 1 User Process 2 class Scheduler class Startof. Period. Event . . . System Clock & Timer class Listof. Threads Requirement Monitor. . . if(. . . ) assert(false); . . .
Verification of DEOS We used Bandera and Java Path. Finder (JPF) l Verification of the system exhausted 4 Gigabytes of memory without completing l – no information about satisfaction of requirement l To verify property or produce a counterexample – state space must be reduced – some form of abstraction is needed
Data Type Abstraction Collapses data domains via abstract interpretation: Code int x = 0; if (x == 0) x = x + 1; Data domains int (n<0) : NEG (n==0): ZERO (n>0) : POS Signs x = ZERO; if (Signs. eq(x, ZERO)) x = Signs. add(x, POS); Signs NEG ZERO POS
Variable Selection Control dependencies: DEOS Kernel 29 conditionals class Thread Environment User Process 1 User Process 2. . . System Clock & Timer 16 methods int its. Last. Execution; . . . public void start. Charging. CPUTime(){ int cp=its. Event. current. Period(); if(cp == its. Last. Execution) {. . . } 32 variables class Startof. Period. Event its. Period. Id = 0; . . . public int current. Period() { return its. Period. Id; } public void pulse. Event(. . . ) {. . . if(count. Down == 0) { its. Period. Id=its. Period. Id + 1; . . . } Requirement Monitor. . . if(. . . ) assert(false); . . .
Variable Selection Control dependencies: DEOS Kernel 29 conditionals class Thread Environment User Process 1 User Process 2. . . System Clock & Timer 16 methods int its. Last. Execution; . . . public void start. Charging. CPUTime(){ int cp=its. Event. current. Period(); if(cp == its. Last. Execution) {. . . } 32 variables class Startof. Period. Event its. Period. Id = 0; . . . public int current. Period() { return its. Period. Id; } public void pulse. Event(. . . ) {. . . if(count. Down == 0) { its. Period. Id=its. Period. Id + 1; . . . } Requirement Monitor. . . if(. . . ) assert(false); . . .
Variable Selection Data dependencies DEOS Kernel class Thread Environment User Process 1 User Process 2. . . System Clock & Timer int its. Last. Execution; . . . public void start. Charging. CPUTime(){ int cp=its. Event. current. Period(); if(cp == its. Last. Execution) {. . . } class Startof. Period. Event its. Period. Id = 0; . . . public int current. Period() { return its. Period. Id; } public void pulse. Event(. . . ) {. . . if(count. Down == 0) { its. Period. Id=its. Period. Id + 1; . . . } Requirement Monitor. . . if(. . . ) assert(false); . . . Unbounded!
Attaching Abstract Types DEOS Kernel class Thread Environment User Process 1 User Process 2. . . System Clock & Timer SIGNS its. Last. Execution; int. . . public void start. Charging. CPUTime(){ SIGNS cp=its. Event. current. Period(); int if(cp == its. Last. Execution) {. . . } class Startof. Period. Event SIGNS its. Period. Id = 0; int. . . public int current. Period() { return its. Period. Id; } public void pulse. Event(. . . ) {. . . if(count. Down == 0) { its. Period. Id=its. Period. Id + 1; . . . } Requirement Monitor. . . if(. . . ) assert(false); . . .
Code Transformation DEOS Kernel class Thread Environment User Process 1 User Process 2. . . System Clock & Timer Signs its. Last. Execution; . . . public void start. Charging. CPUTime(){ Signs cp=its. Event. current. Period(); if(Signs. eq(cp, its. Last. Execution)){. . . } class Startof. Period. Event Signs its. Period. Id = ZERO; . . . public Signs current. Period() { return its. Period. Id; } public void pulse. Event(. . . ) {. . . if(count. Down == 0) { its. Period. Id=Signs. add(its. Period. Id , POS); . . . } Requirement Monitor. . . if(. . . ) assert(false); . . .
Verification of Abstracted DEOS l JPF completed the check – produced a 464 step counter-example l Does the counter-example correspond to a feasible execution? – difficult to determine – because of abstraction, we may get spurious errors l 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
Bandera Abstraction Specification Language Abstraction in Bandera Variable x y done count …. o b Concrete Abstract Inferred Type int bool int Object Buffer Program Signs bool int …. Point Buffer Abstract Code Generator PVS Abstraction Definition Abstraction Library Abstracted Program BASL Compiler
Definition of Abstractions in BASL abstraction Signs abstracts int begin TOKENS = { NEG, ZERO, POS }; abstract(n) begin n < 0 n == 0 n > 0 end -> {NEG}; -> {ZERO}; -> {POS}; Automatic Generation 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 Example: Start safe, then refine: +(NEG, NEG)={NEG, ZERO, POS} Proof obligations submitted to PVS. . . Forall n 1, n 2: neg? (n 1) and neg? (n 2) implies not pos? (n 1+n 2) Forall n 1, n 2: neg? (n 1) and neg? (n 2) implies not zero? (n 1+n 2) Forall n 1, n 2: neg? (n 1) and neg? (n 2) implies not neg? (n 1+n 2)
Compiling BASL Definitions abstraction Signs abstracts int begin TOKENS = { NEG, ZERO, POS }; abstract(n) begin n < 0 n == 0 n > 0 end -> {NEG}; -> {ZERO}; -> {POS}; 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; } operator + add public static int add(int arg 1, int arg 2) { begin Compiled if (arg 1==NEG && arg 2==NEG) return NEG; (NEG , NEG) -> {NEG} ; if (arg 1==NEG && arg 2==ZERO) return NEG; (NEG , ZERO) -> {NEG} ; if (arg 1==ZERO && arg 2==NEG) return NEG; (ZERO, NEG) -> {NEG} ; if (arg 1==ZERO && arg 2==ZERO) return ZERO; (ZERO, ZERO) -> {ZERO} ; if (arg 1==ZERO && arg 2==POS) return POS; (ZERO, POS) -> {POS} ; if (arg 1==POS && arg 2==ZERO) return POS; (POS , ZERO) -> {POS} ; if (arg 1==POS && arg 2==POS) return POS; (POS , POS) -> {POS} ; return Bandera. choose(7); (_, _)-> {NEG, ZERO, POS}; /* case (POS, NEG), (NEG, POS) */ } end
Data Type Abstractions l 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 l Array abstractions: index & element abstractions l Class abstractions: abstract each field
Interpreting Results l For an abstracted program, a counter-example may be infeasible because: – Over-approximation introduced by abstraction l Example: x = -2; if(x + 2 == 0) then. . . x = NEG; if(Signs. eq(Signs. add(x, POS), ZERO)) then. . . {NEG, ZERO, POS}
Choose-free state space search l Theorem [Saidi: SAS’ 00] Every path in the abstracted program where all assignments are deterministic is a path in the concrete program. l Bias the model checker – to look only at paths that do not include instructions that introduce non-determinism l JPF model checker modified – to detect non-deterministic choice (i. e. calls to Bandera. choose()); backtrack from those points
Choice-bounded Search De State space searched te ct ab le Vi ol at io n a l io e. V l on ti b ta c te de choose() Un X X
Comparison to Related Work l Predicate abstraction (Graf/Saidi) – We use PVS to abstract operator definitions, not complete systems – We can reuse abstractions for different systems l Tool support for program abstraction – e. g. , SLAM, JPF, Feaver l Abstraction at the source-code level – Supports multiple checking tools – e. g. , JPF, Java Checker/Verisoft, FLAVERS/Java, … l Counter-example analysis – Theorem prover based (In. Vest) – Forward simulation (Clarke et. al. )
Status l Bandera supports abstraction – Library of base type abstractions – Tool-support for user-defined abstraction – Array abstractions – Finding feasible counter-examples l Surprisingly effective on realistic code – 1000 s of lines, 10 s of threads – Non-trivial data that influences control
Ongoing Work l Extending abstractions – Heap abstractions – Symbolic abstractions l Automated support for selection – Counter-example driven refinement Environments and abstraction l Discrete-time abstractions l – Exploit scheduling information from RT Java
5c8b2be3d2db42196a462a7017726cbc.ppt