Abstraction and Modular Reasoning for the Verification of Software

Download Presentation

Abstraction and Modular Reasoning for the Verification of Software

Loading in 2 Seconds...

- 91 Views
- Uploaded on
- Presentation posted in: General

Abstraction and Modular Reasoning for the Verification of Software

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Abstraction and Modular Reasoning for the Verification of Software

Corina Pasareanu,

October, 2001

Thesis Committee:

Matthew Dwyer, Major Advisor

David Schmidt

Michael Huth

George Strecker

Kenneth Kemp, Outside Chairperson

OK

Finite-state system

Verification

tool

or

Error trace

(F W)

Line 5: …

Line 12: …

Line 15:…

Line 21:…

Line 25:…

Line 27:…

…

Line 41:…

Line 47:…

Specification

Techniques for checking correctness of concurrent programs:

- Formal verification
- That a program satisfies a complete specification

- Dynamic methods/testing
- That examine the outcome of executions of the program
- That check assertions during executions

- Finite state verification (FSV)
- Automated (like testing)
- Guarantees satisfaction of properties (like formal verification)
- Useful for debugging (counter-examples)

- FSV is a potential very useful technique for insuring high-quality software

Challenges:

Solutions:

Creation of tractable models

… software has large/infinite state space

Modular reasoning about software components

… using tools that reason about complete systems

Abstract interpretation

… to reduce the data domains of a program

Program completion

… with code for missing components

… use environment assumptions, assume-guarantee paradigm

Develop multiple forms of tool support for …

… abstraction and program completion

… applicable to program source code

… largely automated, usable by non-experts

We concentrate on building …

… finite-state models, not finite-state tools

We evaluate the effectiveness of this tool support through…

… implementation

… application to real Java and Ada programs

Universal and

synthesized environments

Heuristics for abstraction selection

yes

no

Property

True!

Choose-free search and guided simulation

SPIN, SMV, JPF…

Partial Program, Property Y, Assumption F

Program

Completion

Data

Abstraction

Refine Selection

Abstracted Completed Program

Translator

Model of Program

Counter-example

Analysis

Model Checking

<F,Y>

Property

False!

- Integration of existing technologies into a coherent methodology that enables FSV of software systems
- Development of new technologies:
- Use of theorem proving to automatically derive abstractions of data types
- Instrumentation of source code to enable assume-guarantee reasoning about partial programs
- Two techniques for analysis of abstract counter-examples

- Formalization and implementation of these technologies
- Evaluation of technologies on case studies (Java, Ada)

- The Bandera toolset (KSU)
- Collection of program analysis and transformation components
- Allows users to analyze properties of Java programs
- Tailor analysis to property to minimize analysis time

- The Ada translation toolset
- Java PathFinder (NASA Ames)
- Model checker for Java programs
- Built on top of a custom made Java Virtual Machine
- Checks for deadlock and violations of assertions

- The Microsoft Research SLAM project
- G. Holzmann’s Fever Tool (Bell Labs)
- Stoller’s stateless checker for Java programs
- Godefroid’s Verisoft (Bell Labs)
- David Dill’s Hardware Verification Group
- Eran Yahav’ s Java checking tool

- Introduction
- Data Abstraction (FSE’98, ICSE’01)
- Program Completion
- Abstract Counter-example Analysis
- Formal Justification
- Case Studies: Java and Ada Programs
- Conclusions, Limitations and Future Work

- 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

symbolic state

represents a set of states

Original

system

Abstract

system

abstraction

Safety:

The set of behaviors of the abstract system over-approximates

the set of behaviors of the original system

int

(n<0) : NEG

(n==0): ZERO

(n>0) : POS

Signs

Signs x = ZERO;

if (Signs.eq(x,ZERO))

x = Signs.add(x,POS);

NEG

ZERO

POS

Collapses data domains via abstract interpretation:

Code

Data domains

int x = 0;

if (x == 0)

x = x + 1;

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

Bandera

Abstraction

Specification

Language

PVS

Concrete

Type

Abstract

Type

Inferred

Type

Abstraction

Definition

Variable

x

int

y

int

done

bool

count

int

BASL

Compiler

….

o

Object

b

Buffer

Program

Abstracted

Program

Abstract Code

Generator

Signs

Signs

Signs

bool

Abstraction

Library

int

….

Point

Buffer

Automatic

Generation

Example: Start safe, then refine:+(NEG,NEG)={NEG,ZERO,POS}

Forall n1,n2: neg?(n1) and neg?(n2) implies not pos?(n1+n2)

Proof obligations submitted to PVS...

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)

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

abstraction Signs abstracts int

begin

TOKENS = { NEG, ZERO, POS };

abstract(n)

begin

n < 0 -> {NEG};

n == 0 -> {ZERO};

n > 0 -> {POS};

end

Compiled

abstraction Signs abstracts int

begin

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) */

}

- 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

- 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, …

- Introduction
- Data Abstraction
- Program Completion (FSE’98, SPIN’99)
- Abstract Counter-example Analysis
- Formal Justification
- Case Studies: Java and Ada Programs
- Conclusions, Limitations and Future Work

- Software systems are collections of software components
- Approach similar to unit testing of software
- Applied to components (units) that are code complete
- Stubs and drivers simulate environment for unit

- We complete a system with a source code representation for missing components
- Universal environments
- Environment assumptions used to refine definitions of missing components

- The stub for an Ada partial program, with an Insert procedure and a Removefunction

procedure stub is

choice: Integer;

theObject: Object_Type;

begin loop

case choice is

when 1 => Insert(theObject);

when 2 => theObject:=Remove;

when 3 => null;

when others => exit;

end case; end loop; end stub;

Problem: check property Y vs. , assuming F

System

Linear temporal paradigm:

2nd approach:

Synthesized environment

F (LTL)

Universal environment

F -> Y vs. ||

System

Y vs. ||

System

(LTL)

(LTL)

(ACTL)

- A system specification is a pair <F,Y>
- Y describes the property of the system
- F describes the assumption about the environment

- Environment assumptions F
- Encode behavioral info. about system interfaces
- Written in LTL

- “Classical” tableau construction for LTL
- Modified to assume that only one interface operation can occur at a time
- Builds a model of F :
- I.e., a graph with arcs labeled by interface operations
- Can be easily translated into source code

0

Insert

t

Insert

Insert

t

9

8

t

Remove

Remove

Insert

16

t

(! Remove) U Insert

when 9 => case choice is

when 1 => Insert(theObject);state:=8;

when 2 => null;state:=9;

when others => exit;

end case;

when 16=> case choice is

when 1 => Insert(theObject);state:=16;

when 2 => theObject:=Remove;state:=16;

when 3 => null; state:=16;

when others => exit;

end case;

end case; end loop; end stub;

procedure stub is

state,choice: Integer;

theObject: Object_Type;

begin state:=0;

loop

case state is

when 0 => case choice is

when 1 => Insert(theObject);state:=8;

when 2 => null;state:=9;

when others => exit;

end case;

when 8 => case choice is

when 1 => Insert(theObject);state:=8;

when 2 => theObject:=Remove;state:=16;

when 3 => null; state:=8;

when others => exit;

end case;

- Much theoretical work on compositional verification
- Avrunin, Dillon, Corbett:
- Analysis of real-time systems, described as a mixture of source code and specifications

- Colby, Godefroid, Jagadeesan:
- Automatable approach to complete a partially specified system
- Use the VeriSoft toolset
- No environment assumptions

- Long:
- Synthesis of environments from ACTL

- Introduction
- Data Abstraction
- Program Completion
- Abstract Counter-example Analysis (TACAS’01)
- Formal Justification
- Case Studies: Java and Ada Programs
- Conclusions, Limitations and Future Work

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

- 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

- 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

State space searched

Undetectable Violation

Detectable Violation

choose()

X

X

- 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)

- Previous work:
- After model checking; analyze the counter-example to see if it is feasible

- Pre-image computations; theorem prover based (InVest)
- Forward simulation (CMU)
- Symbolic execution (SLAM)

- Introduction
- Data Abstraction
- Program Completion
- Abstract Counter-example Analysis
- Formal Justification
- Case Studies: Java and Ada Programs
- Conclusions, Limitations and Future Work

- Our techniques build safe abstractions of software systems
P < P’ means “ P’ is a safe abstraction of P”

- < is a simulation relation (Milner)
- Properties are expressedin universal temporal logics (LTL, ACTL) preserved by <

- Data Abstraction builds abstractions Pabs of systems P s.t.
P < Pabs

- Universal Environments U:
P||E < P||U, for all environments E

- Synthesized Environments TF from assumptions F:
P||E < P||TF, for all environments E that satisfy F

- Introduction
- Data Abstraction
- Program Completion
- Abstract Counter-example Analysis
- Formal Justification
- Case Studies: Java and Ada Programs
- Conclusions, Limitations and Future Work

- Filter-based Model Checking of a Reusable Parameterized Programming Framework (FSE’98)
- Ada implementation of the Replicated Workers Framework

- Model Checking Generic Container Implementations (GP’98)
- Ada implementations of generic data structures:
- queue, stack and priority queue

- Ada implementations of generic data structures:

- Abstracted using data type abstraction
- Completed with code for universal environments
- Environments’ behavior refined based on LTL assumptions
- We used the SPIN tool:
- To check 8/5 properties; 5/3 required use of assumptions
- To detect seeded errors

- Assume-guarantee Model Checking of Software: A Comparative Case Study (SPIN’99)
- Ada implementations of software components:
- The Replicated Workers Framework, the Generic Containers
- The Gas Station, the Chiron Client

- Ada implementations of software components:

- Out of 39 properties, 15 required use of assumptions
- For < F,Y >, we compared two ways of completing systems:
- Universal environment: check F->Y (LTL)
- using SPIN

- Synthesized environment from F(LTL): check Y (LTL/ACTL)
- using SPIN/SMV

- Universal environment: check F->Y (LTL)
- Synthesized environments enable faster verification

- Analysis of the Honeywell DEOS Operating System (NASA’00,ICSE’01)
- 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

- Abstracted using data type abstraction
- Completed with code for
- User threads that run on the kernel
- A system clock and a system timer

- Environments’ behavior refined based on LTL assumptions
- Checked using JPF and SPIN
- Defect detected using choice-bounded search

- Finding Feasible Counter-examples when Model Checking Abstracted Java Programs (TACAS’01)
- We applied the 2 counter-example analysis techniques to Java defective applications:
- Remote agent experiment, Pipeline, Readers-Writers, DEOS

- Both techniques are fast:
- Choose-free search is depth-bounded
- Cost of simulation depends on the length of the counter-example

- Choose-free counter-examples …
- are common
- are short
- enable more aggressive abstraction

- We integrated several technologies into a coherent methodology that enables FSV of complex, concurrent software systems
- We developed technologies for…
- Data type abstraction:
- Enable non-experts to generate models that make FSV less costly
- Facilities to define, select and generate abstracted programs

- Program completion
- Enable verification of properties of individual components, collections of components and entire systems
- Take into account assumptions about environment behavior

- Analysis of abstract counter-examples
- Choose-free state space search
- Counter-example guided simulation

- Data type abstraction:
- We implemented and formalized these technologies
- We evaluated them on extensive case studies (Ada and Java)

- Generalize choice-bounded search technique
- CTL* model checking of abstracted programs

- Extend abstraction support for objects
- Heap abstractions tohandle an unbounded number of dynamically allocated objects

- Extend automation
- Automated selection and refinement of abstractions based on counter-example analysis

- Tool support for:
- Abstraction of data domains
- Program completion
- Interpretation of counter-examples
… is essential for the verification of realistic software systems

- Ensures the safety of the verification process