Loading in 5 sec....

Abstraction and Modular Reasoning for the Verification of SoftwarePowerPoint Presentation

Abstraction and Modular Reasoning for the Verification of Software

Download Presentation

Abstraction and Modular Reasoning for the Verification of Software

Loading in 2 Seconds...

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