Abstraction and Modular Reasoning for the Verification of Software

1
Abstraction and Modular Reasoning for the
Verification of Software

• Corina Pasareanu
• NASA Ames Research Center

2
Outline

• Bandera Project (Kansas Sate University)
• Tool Support for Program Abstraction and Abstract
  Counter-example Analysis (joint work with the
  Bandera team)
• NASA Ames Projects
• Combining Symbolic Execution with (Explicit
  State) Model Checking (joint work with Willem
  Visser)
• Assumption Generation for Component Verification
  (joint work with Dimitra Giannakopoulou and
  Howard Barringer)

3
Outline

• Bandera Project (Kansas Sate University)
• Tool Support for Program Abstraction and Abstract
  Counter-example Analysis
• NASA Ames Projects
• Combining Symbolic Execution with (Explicit
  State) Model Checking
• Assumption Generation for Component Verification

4
Finite-state Verification
5
Finite-State Verification

• Effective for analyzing properties of hardware
  systems
• Widespread success and adoption 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

6
Abstraction the key to scaling up
7
Goals of our work
8
Data Type Abstraction
Collapses data domains via abstract
interpretation
Data domains
Code
int x 0 if (x 0) x x 1
9
Abstraction in Bandera
Signs
Signs
Signs
bool
Abstraction Library
int
.
Point
Buffer
10
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
11
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) /
12
Abstract Counter-example Analysis

• 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

13
Our Solutions

• Choice-bounded State Space Search
• on-the-fly, during model checking
• Abstract Counter-example Guided Concrete
  Simulation
• Exploit implementations of abstractions for Java
  programs
• Effective in practice
• Implemented in Java PathFinder tool

14
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

15
Choice-bounded Search
choose()
X
X
16
Counter-example guided simulation (?)

• Use abstract counter-example to guide simulation
  of concrete program
• Why it works
• Correspondence between concrete and abstracted
  program
• Unique initial concrete state (Java defines
  default initial values for all data)

17
Case Study DEOS Kernel (NASA Ames)

• Honeywell Dynamic Enforcement Operating System
  (DEOS)
• A real time operating system for integrated
  modular avionics
• Non-trivial concurrent program (1433 lines of
  code, 20 classes, 6 threads)
• Written in C, translated into Java and Promela
• With a known bug
• Verification of the system exhausted 4 Gigabytes
  of memory without completion abstraction needed

• Abstracted using data type abstraction
• Checked using JPF and SPIN
• Defect detected using choice-bounded search

18
Conclusion and Future Research Directions

• Tool support for abstraction enables verification
  of real properties of real programs
• Extend abstraction support for objects
• Heap abstractions to handle an unbounded number
  of dynamically allocated objects
• Handle recursive procedures, unbounded number of
  processes
• Extend automation
• For selection and refinement based on
  counter-example analysis

19
Outline

• Bandera Project (Kansas Sate University)
• Tool Support for Program Abstraction and Abstract
  Counter-example Analysis
• NASA Ames Projects
• Combining Symbolic Execution with (Explicit
  State) Model Checking
• Assumption Generation for Component Verification

20
Java Path Finder (NASA Ames)

• Model checker for Java programs
• Built on top of a custom made Java Virtual
  Machine
• Checks for deadlock and violation of assertions
  LTL properties
• Support for abstraction
• Predicate abstraction
• Banderas data abstraction
• Heuristic search

21
Symbolic Execution
Uses symbolic names to represent program inputs
Code
void test(int n) 1 if (n gt 0) 2 n
n 1 3 if (n lt 3) 4 ... 5
...
22
Symbolic Execution and JPF Applications

• Extends JPF with a new form of abstraction
• Test case generation
• Abstract counter-example analysis and refinement
• Symbolic execution of multithreaded programs
• Parameter synthesis

23
Implementation in JPF

• Easy
• Uses Banderas type abstraction
• Uses Omega library (Java version)
• Manipulates sets of linear constraints over
  integer variables
• Can be used as a symbolic execution tool with
  backtracking
• Good for finding counter-examples
• No state matching!

24
(Possible) Implementation
Code
public class SymVal public SymVal() ...
public SymVal(int n) ... public
SymVal(SymVal s1, SymVal s2, String ops) ...
... public class SymOps public SymVal
add(SymVal s1, SymVal s2) return new
SymVal(s1,s2,) public bool gt(SymVal
s1, SymVal s2) bool result
Verify.chooseBool() if(result) //
true PC.addCondition(s1,s2,gt) else
// false PC.addCondition(s1,s2,lt)
PC.simplify() return result ...
void test(int n) if (n gt 0) n n 1
...
25
Problem Convergence
Symbolic execution tree
Code
void test(int n) 1 int x 0 2
while(x lt n) 3 x x 1 4
26
Problem Convergence
Solutions?

• Limit the search depth of MC
• Unwind loops a fixed number of times (similar to
  Bounded MC?)
• Discover simple and practical widening
  techniques
• Acceleration techniques
• Heuristics?
• Combine with predicate abstraction

27
Relation to Bounded MC

• Extend BMC with symbolic variables?
• Widening for C programs?

28
Outline

• Bandera Project (Kansas Sate University)
• Tool Support for Program Abstraction and Abstract
  Counter-example Analysis
• NASA Ames Projects
• Combining Symbolic Execution with (Explicit
  State) Model Checking
• Assumption Generation for Component Verification

29
Assumption Generation for Component Verification

• Problem

Environment
Property
? Environment Assumption ?
The weakest assumption A for component C for
all environments E, E A ? E C P
30
Applications

• Support for modular verification
• Compositional verification
• Property decomposition
• Run-time monitoring of the environment
• Component retrieval
• Sub-module construction

31
Implementation

• In Labeled Transition Systems Analyzer (LTSA)
  tool - Imperial college
• Supports compositional reachability analysis
  based on software architecture
• Incremental system design and verification
• Component abstraction (hiding of internal
  actions)
• Minimization wrt. observational equivalence
• Both components and properties expressed as
  labeled transition systems

32
Example A System and A Property

33
Assumption Generation

• Step 1 composition, hiding of
• internal actions and
• minimization

34
Composite System
E.release
E.enterCS
E.acquire
E.exitCS
E.release
E.exitCS
E.enterCS
E.release
E.enterCS
E.enterCS
t
E.enterCS E.exitCS
E.exitCS
35
Backward Error Propagation (with t)
E.release
E.enterCS
E.acquire
E.exitCS
E.release
E.exitCS
E.enterCS
E.release
E.enterCS
E.enterCS
t
E.enterCS E.exitCS
E.exitCS
36
Backward Error Propagation (with t)
E.release
E.enterCS
E.exitCS
E.release
E.enterCS
E.release
E.enterCS
E.enterCS E.exitCS
E.exitCS
37
Property Extraction
E.acquire
E.enterCS
E.release
E.exitCS
E.enterCS E.release
E.enterCS E.exitCS
E.exitCS
38
Generated Assumption
E.acquire, E.release E.enterCS, E.exitCS
E.release
E.acquire
E.acquire
E.acquire
E.enterCS
E.release
E.exitCS
39
Directions for Future Work

• Liveness /fairness
• Extend to other frameworks
• LTL checking (since we are interested only in
  error behaviors)
• Is the sub-set construction needed?
• Study other forms of composition