Tool-supported Program Abstraction for Finite-state Verification - PowerPoint PPT Presentation

1 / 24
About This Presentation
Title:

Tool-supported Program Abstraction for Finite-state Verification

Description:

Tool-supported Program Abstraction for Finite-state Verification. Matthew Dwyer1, John Hatcliff1, Corina Pasareanu1, Robby1, Roby Joehanes1, Shawn ... – PowerPoint PPT presentation

Number of Views:25
Avg rating:3.0/5.0
Slides: 25
Provided by: johnh284
Category:

less

Transcript and Presenter's Notes

Title: Tool-supported Program Abstraction for Finite-state Verification


1
Tool-supported Program Abstraction for
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
2
Abstraction the key to scaling up
3
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
4
Case Study DEOS Kernel
Honeywell Dynamic Enforcement Operating System
(DEOS)
  • 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

5
DEOS Architecture
DEOS Kernel
Requirement Monitor
... if(...) assert(false) ...
...
System Clock Timer
6
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

7
Data Type Abstraction
Collapses data domains via abstract
interpretation
Data domains
Code
int x 0 if (x 0) x x 1
8
Variable Selection
Control dependencies 29 conditionals
16 methods 32 variables
Requirement Monitor
... if(...) assert(false) ...
...
System Clock Timer
9
Variable Selection
Control dependencies 29 conditionals
16 methods 32 variables
Requirement Monitor
... if(...) assert(false) ...
...
System Clock Timer
10
Variable Selection
Data dependencies
Requirement Monitor
... if(...) assert(false) ...
...
System Clock Timer
11
Attaching Abstract Types
SIGNS
SIGNS
Requirement Monitor
... if(...) assert(false) ...
SIGNS
...
System Clock Timer
12
Code Transformation
Requirement Monitor
... if(...) assert(false) ...
...
System Clock Timer
13
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

14
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

15
Abstraction in Bandera
Signs
Signs
Signs
bool
Abstraction Library
int
.
Point
Buffer
16
Definition of Abstractions in BASL
operator add begin (NEG , NEG) -gt NEG
(NEG , ZERO) -gt NEG (ZERO, NEG) -gt
NEG (ZERO, ZERO) -gt ZERO (ZERO,
POS) -gt POS (POS , ZERO) -gt POS
(POS , POS) -gt POS (_,_) -gt
NEG,ZERO,POS / case (POS,NEG),(NEG,POS)
/ end
abstraction Signs abstracts int begin TOKENS
NEG, ZERO, POS abstract(n) begin
n lt 0 -gt NEG n 0 -gt
ZERO n gt 0 -gt POS end
17
Compiling BASL Definitions
abstraction Signs abstracts int begin TOKENS
NEG, ZERO, POS abstract(n) begin
n lt 0 -gt NEG n 0 -gt
ZERO n gt 0 -gt POS end
operator add begin (NEG , NEG) -gt NEG
(NEG , ZERO) -gt NEG (ZERO, NEG) -gt
NEG (ZERO, ZERO) -gt ZERO (ZERO,
POS) -gt POS (POS , ZERO) -gt POS
(POS , POS) -gt POS (_,_)-gt 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 lt 0) return NEG if (n 0)
return ZERO if (n gt 0) return POS
public static int add(int arg1, int arg2)
if (arg1NEG arg2NEG) return NEG if
(arg1NEG arg2ZERO) return NEG if
(arg1ZERO arg2NEG) return NEG if
(arg1ZERO arg2ZERO) return ZERO if
(arg1ZERO arg2POS) return POS if
(arg1POS arg2ZERO) return POS if
(arg1POS arg2POS) return POS return
Bandera.choose(7) / case (POS,NEG),
(NEG,POS) /
18
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

19
Interpreting Results
  • For an abstracted program, a counter-example may
    be infeasible because
  • Over-approximation introduced by abstraction
  • Example
  • x -2 if(x 2 0) then ...
  • x NEG if(Signs.eq(Signs.add(x,POS),ZERO)) then
    ...
  • NEG,ZERO,POS

20
Choose-free state space search
  • Theorem SaidiSAS00
  • 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

21
Choice-bounded Search
choose()
X
X
22
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.)

23
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

24
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

25
Array Abstractions
  • Specified by
  • an index abstraction and
  • an element abstraction
  • Example WidgetInfo wik
  • use signs for index
  • use some other abstraction for WidgetInfo
  • Abstracted array awi has 2 elements
  • awizero abstracts wi0
  • awipos summarizes info about wi1 wik

26
Property Abstraction
Property
System Model
27
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

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

29
Interpreting Results
Example of Infeasible Counter-example
... 1 if(Signs.gt(Signs.add(NEG,POS),ZERO))
then 2 assert(true) else 3
assert(false) ...
... 1 if (-2 3 gt 0) then 2
assert(true) else 3 assert(false)
...
30
Abstraction the key to scaling up
31
Finite-state Verification
32
Finite-state Verification
  • Effective for analyzing properties of hardware
    systems

Widespread success andadoption in industry
  • Recent years have seen many efforts to apply
    those techniques to software

Limited success due to the enormous state spaces
associated with most software systems
Write a Comment
User Comments (0)
About PowerShow.com