Model Checking & Program Analysis Markus Mller-Olm Dortmund - - PDF document

Model Checking & Program Analysis

Markus Müller-Olm Dortmund University

Overview

Introduction Model Checking Flow Analysis Some Links between MC and FA Conclusion

Apology for not giving proper credit to

• ther researchers' work in this tutorial !

Purposes of Automatic Analysis

Optimizing compilation Validation/Verification

Type checking Functional correctness Security properties . . .

Debugging

Fundamental Limit

Rice's Theorem [Rice,1953]: All interesting semantic questions about programs from a universal programming language are undecidable.

Example: Detection of Constants

read(new); π; write(new) write(new) can be replaced by write(k) for some constant k ⇔ π terminates Hence: Constant Detection is undecidable read(new); π; write(k)

?

Two Solutions

Weaker formalisms

• analyze abstract

models of systems

• e.g.: automata, labelled

transition systems,...

Approximate analyses

• yield sound but, in

general, incomplete results

• e.g.: detects some

instead of all constants

Model checking Flow analysis Abstract interpretation Type checking

Weaker Formalisms

Abstract model Exact analyzer for abstract model Program

Exact Approximate

• ut(x);

Overview

Introduction Model Checking Flow Analysis Some Links between MC and FA Conclusion

Model Checking

G( F Φ → Ψ)

OK Error trace

• r

Finite-state structure Temporal logic formula Model Checker

What is a Model Checker?

M φ

• an automatic procedure for deciding

where

• M is a model structure
• φ

is a (temporal-logic) formula

means satisfaction

M φ

• Model Structures

Model Structures

• wn

¬ use

• wn

use ¬ own ¬ use

Kripke structure Labeled Transition System

release acquire end start

Kripke Transition System

release acquire end start P ¬Q P Q ¬P ¬Q

Kripke Structures

= ⊆ × → ( , , ), where states transition relation, total : 2 interpretation atomic propositions

K S R I S R S S I S AP

• wn

¬ use

• wn

use ¬ own ¬ use

M φ

• Temporal Logics

Temporal Logics

Linear-Time Logics

formulas specify properties of program paths state satisfies property if all paths starting in this

state do

Branching-Time Logic

can specify properties sensitive to branching has (or can simulate) path quantifiers A and E

Branching vs. Linear-Time Logics

LT logics cannot distinguish P and Q:

P and Q have same execution paths

BT logics can:

P [coin] <tea> true

but Q [coin] <tea> true coin tea coffee P coin tea coffee coin Q

A Linear-Time Logic: PLTL

1.

• wn the resource

before using it

2.

release the resource in finite time ( )

• wn

F

• wn

⇒ ¬ use U own ¬ PLTL formulas

1 2 1 2

:: | | | | p X U φ φ φ φ φ φ φ = ¬ ∨

Abbreviations

• wn

¬ use

• wn

use ¬ own ¬ use

: : ( ) : F trueU G F WU U G φ φ φ φ φ ψ φ ψ φ = = ¬ ¬ = ∨

Linear-Time Modalities

G φ: φ . . . φ φ φ φ

Generally

X φ: φ . . .

neXt

F φ: φ . . .

Finally

φ U ψ: φ . . . φ ψ φ

Until

φ WU ψ: φ U ψ or G φ

Weak Until

ψ φ ψ φ φ φ

Until

φ

Linear-time: blue nodes

satisfy v φ U ψ

Branching-time: blue

nodes satisfy v A(φ U ψ)

ψ φ ψ φ φ φ

Weak Until

φ

Linear-time: blue nodes

satisfy v φ WU ψ

Branching-time: blue

nodes satisfy v A (φ WU ψ)

A Branching-Time Logic: CTL

1.

• wn the resource

before using it

2.

release the resource in finite time ( )

• wn

AF

• wn

⇒ ¬ ( ) A use U own ¬ State formulas φ

1 2

:: | | | | p E A φ φ φ φ ψ ψ = ¬ ∨

Path formulas ψ

1 2

:: | | | F X U G ψ φ φ φ φ φ =

• wn

¬ use

• wn

use ¬ own ¬ use

Duality

Path quantifiers are duals:

Until and weak until are almost duals (on

paths):

Modal mu-Calculus

a branching-time logic with local modalities…

φ : all successor states satisfy φ ◊ φ : some successor state satisfies φ

… and fixpoint formulae.

µ X. φ(X) : minimum fixpoint formula ν X. φ(X) : maximum fixpoint formula

Fixpoint formulae can be nested

Alternation: µX.(νY.X∧Y)

Local Modalities for Labelled Edges

[a] φ: φ φ φ <a> φ: φ

. . . . . . . . . . . .

a a a a a a

Computing Fixpoint Formulae

On finite structures, meaning of fixpoint

formulae can be computed by computing Kleene chains until stabilization:

f is a function on state sets derived from the body of the fixpoint formula.

CTL and Modal mu-Calculus

CTL-formulae can inductively be transformed

to modal mu-calculus formulae

Global modalities can be expressed by

fixpoint formulae, e.g.:

( ) X.( ( X true)) ( ) X.( ( X)) A U E U φ ψ µ ψ φ φ ψ µ ψ φ = ∨ ∧ ∧ = ∨ ∧

• ◊

◊ ( ) X.( ( X)) ( ) X.( ( ( X false))) A WU E WU φ ψ ν ψ φ φ ψ ν ψ φ = ∨ ∧ = ∨ ∧ ∨

• ◊

M φ

• Model Checking Approaches

Global vs. Local Model Checking

Global model checking problem

Given: finite model structure M, formula φ Determine: {s | s φ}

Local model checking problem

Given: finite model structure M, formula φ, and

state s in M

Determine, whether s φ or not

Model Checking Approaches

• Iterative model checking
• Automata-theoretic model checking
• Tableau-based model checking

Iterative Model Checking

• Good for global model-checking of

branching-time logics

• Idea: Compute semantics of formula on

given model by structural induction on the formula

• Reduce modalities to their fixpoint definition
• Compute the fixpoints by Kleene chains
• Alternating fixpoints lead to backtracking

(→ proceedings)

Iterative Model Checking of CTL

Annotate each state with those subformulas

ψ of φ with s ψ.

Use structural induction on φ. Use backwards propagation to compute

modalities A(φ U ψ) and A(φ WU ψ).

ψ φ ψ φ φ φ

Model Checking A(φUψ)

1.

Mark all nodes v with v ψ

2.

Mark all unmarked nodes w with w φ and all successors marked

3.

Iterate 2. until stabilization

φ

ψ φ ψ φ φ φ

Model Checking A(φWUψ)

1.

Mark all nodes with v φ or v ψ

2.

Unmark all nodes v with v ψ and some unmarked successor

3.

Iterate 2. until stabilization

φ

Automata-theoretic MC

Good for linear-time logics Idea: reduce model-checking to non-

emptiness problem of an automaton

Automata-theoretic MC

Construct (Büchi-) automaton, Aφ, from φ

Construct (Büchi-) automaton, AM, from M

M iff L(A ) L(A ) iff L(A ) L(A ) iff L(A A )

φ ⊆ ∩ = ∅ × = ∅

• MOVEP'02, Nantes, June 17-21, 2002

Automata-theoretic MC

Construct (Büchi-) automaton, Aφ, from φ

Construct (Büchi-) automaton, AM, from M

Compute automaton AM× Aφ

Decide L(AM× Aφ)=∅ by reachability analysis

Automaton for F(P)∧G(Q) (Finite Maximal Paths Interpretation)

A Successful Model-Check for formula F(P)∧G(Q)

A Failing Model-Check for formula F(P)∧G(Q)

Tableau-Based Model-Checking

Idea: solve local model checking problem by

sub-goaling

Try to construct a proof tree that witnesses sφ If no proof tree can be found, then sφ For proof tree construction, tableau rules are

given that reduce goals to sub-goals

Some Tableau Rules

[ ]

a BOX if {s ,..., } { | } ,...,

s s t s t s s φ φ φ =  → ฀ ฀

• 2

AND s s s φ φ φ φ ∧

• 2

OR1 s s φ φ φ ∨

• 2

OR2 s s φ φ φ ∨

• a

DIAMOND if

s s t t φ φ  →

• MOVEP'02, Nantes, June 17-21, 2002

Tableau Rules for Fixpoints

Fixpoint formulas are analyzed with unfolding

rules, e.g.,

If fixpoint formula sequent re-appears later:

Special care needed for nested fixpoints

(→ proceedings)

• X. (X)
• UNFOLD

(

• X. (X))

s s µ φ µ φ µ φ

X.( [b]X)

• X. a true

b X φ ν ψ ψ µ = ∧ = ∨

s t a b b

s φ

• [ ]

b s ψ φ ∧

• s

ψ

• a true

b s ψ ∨

• a true

s true t

[ ]

b s φ

• s

φ

• A Model Check by Tableau

ν ⇒ successful !

• MOVEP'02, Nantes, June 17-21, 2002

Typical Profile of Model Checking Techniques

X X

Global

X X X

Tableau methods

X X

Automata- theoretic

X

Iterative Local Linear-time Branching- time

State-Explosion Problem

State-Explosion

components or variables

Techniques for fighting state-explosion

Other Classes of Systems

Infinite-state systems Timed systems Hybrid systems Probabilistic systems . . .

Learn more about such systems this week !

Overview

Introduction Model Checking Flow Analysis Some Links between MC and FA Conclusion

From Programs to Flow Graphs

• ut(x)

• ut(x
• ut(x);

Dead Code Elimination

Goal:

find and eliminate assignments that compute

values which are never used

Fundamental problem:

undecidability hence: use approximate algorithm; ignore guards

Technique:

propagate set of non-needed variables backwards

through the flow graph

{x,y} {y} {x} {x,y} {x} ∅ {x,y} {x,y} {x} {x,y} x := 17 x := 10 x := x+1 x := 42 y := 11 y := x+y x := y+1 x := y+1

• ut(x)

y := 17 {x} ∅ ∅ ∅ {x} ∅

{x,y} {y} {x} {x} ∅ {x} x := 17 x := 10 x := x+1 x := 42 y := 11 y := x+y x := y+1 x := y+1

• ut(x)

y := 17 {x} ∅ ∅ ∅ {x} ∅

Remarks

Forward vs. backward analyses Bitvector analyses

backward: live/dead variables, very busy

expressions,

forward: reaching definitions, available

expressions

Computation strategies

Flow Equations for Dead Code

DeadIn[ ] (DeadOut[ ] [ ]) \ [ ] DeadOut[ ] DeadIn[ ] Mod Use

i i i i i i

= ∪ = ∩

x := y+z . . .

DeadIn[ ] (DeadOut[ ] { }\{ , } i i x y z = ∪

DeadOut[ ] DeadIn[ ]

i i

= ∩

j1 jk

∩

General equations: Equations may be combined… …or replaced by inequations:

Data-Flow Frameworks

Correctness

generic properties of frameworks can be studied

and proved

Implementation

efficient, generic implementations can be

constructed

Data-Flow Frameworks

a complete lattice (D,) of data-flow facts a space F of transfer functions f: D →D

Id∈F closed under composition

initial value init∈D a control-flow graph with set of entry/exit

nodes

mapping assigning transfer functions fi to flow

graph nodes i

Framework for dead variables

lattice 2 Var control flow program graph initial value function space { : | ,d : ( ) ( ) \ } ( ) ( Mod[ ]) \ Use[ ]

D f D D d f d d d d f f d d i i ⊆ ∅ → ∃ = ∪ = ∪ ∩

What Data Flow Algorithms Compute

Forward Analysis

Backward Analysis

This is called the maximal fixpoint solution MFP[i]

Entry In[ ] (In[ ])

• therwise

init i i f j

∈  =  

Exit Out[ ] (Out[ ])

• therwise

init i i f j

∈  =  

Assessing Data Flow Frameworks

Abstraction MOP-solution Execution Semantics MFP-solution sound? how precise? sound? precise?

x := 17 x := 10 x := x+1 x := 42 y := 11 y := x+y x := y+1 x := y+1

• ut(x)

y := 17 {x,y} {x} {x,y}

MOP[ ] { , } { } { } v x y x x = ∩ =

v infinitely many such paths

Meet-Over-All-Paths Solution

Forward Analysis Backward Analysis

Paths[ , )

MOP[ ] : F ( )

p entry i p

i init

∈

=

Paths( , ]

MOP[ ] : F ( )

p i exit p

i init

∈

=

Coincidence Theorem

Definition: A framework is distributive if f(X)= {f(x)|x∈X} for all X⊆D, f∈F. Theorem: In any distributive framework, MOP[i]=MFP[i] for all program points i. Theorem: All bitvector frameworks are distributive.

Lattice for Constant Propagation

• 1

2 . . .

• 2

. . .

⊥

• 1

inconsistent value unknown value

Constant Propagation Framework

lattice Var ( { }) Var ConstVal ' : : ( ) '( ) pointwise meet ( ) f.a. x Var control flow program graph initial value function space { : | monotone} [ ( ( )

D x x x x f D D f d x e f f d ρ ρ ρ ρ → ∪ = → ⇔ ∀ = ∈ → =

• ⊥,

⊥

• )]

if annotated with :

• therwise

d i x e d  =    

x := 17 y := 3 x := 3 z := x+y

• ut(x)

x := 2 y := 2 (3,2,5) (2,3,5)

MOP[ ] ( , ,5) v = ⊥ ⊥

( ( ), ( ), ( )) x y z ρ ρ ρ

(⊥,⊥,⊥) x := 17 y := 3 x := 3 z := x+y

• ut(x)

x := 2 y := 2 (⊥,⊥,⊥) (⊥,⊥,⊥) (2,3,⊥) (3,2,⊥) (2,⊥,⊥) (3,⊥,⊥)

MOP[ ] ( , ,5) v = ⊥ ⊥ M FP[ ] ( , , ) v = ⊥ ⊥ ⊥

( ( ), ( ), ( )) x y z ρ ρ ρ

Correctness Theorem

Definition: A framework is monotone if f(x)f(y) for all x,y∈D, xy. Theorem: In any monotone framework, MFP[i]MOP[i] for all program points i. Remark: Any "reasonable" framework is monotone.

Assessing Data Flow Frameworks

Abstraction MOP-solution Execution Semantics MFP-solution

sound sound precise, if distrib.

Where Flow Analysis Looses Precision

Execution Semantic MOP MFP Widening Narrowing

Loss of Precision

Overview

Introduction Model Checking Flow Analysis Some Links between MC and FA Conclusion

Some Links between MC and FA

• Flow Analysis via Model Checking
• Model Checking via Flow Analysis
• Synergy of MC and FA

Model-Checker Flow graph transformer Interpretation flow graph Kripke structure formula yes/no annotation of Kripke structure nodes data flow information for flow graph nodes yes/no data-flow problem Design & Programming

Flow Analysis via Model Checking

Dead-Code Elimination

Flow Graph Transformation:

y := x+y

Mod(y), Use(x), Use(y)

Dead X ( use( ) WU (mod( ) use( )))

x x x = ¬ ∧ ¬

Formula specifying "x is dead": Note: more direct specification than in the

data flow framework

• ut(x)

Check: Dead X ( use( ) WU (mod( ) use( ))) x x x = ¬ ∧ ¬

Model Checking via Flow Analysis

Evaluation of (CTL) modalities can be seen

as a data flow analysis

CTL model-checking is iterated flow analysis

Framework for E(φ U ψ)

lattice {0,1} 1 control flow Kripke structure ( , , ) initial nodes Nodes s with s initial value 1 function space { .0, .1, . } . if , ( 1 ) .0 if , 1

D S R I x x x x x x i i f f d x i i ψ λ λ λ λ ψ φ λ ψ φ = = = B

• 

 

1

Why the Framework computes E(φ U ψ)

MOP[ ] 1 iff s E( U ) v φ ψ =

• 1

1

MFP[ ] v =

ψ φ,¬ψ φ,¬ψ ¬φ,¬ψ

. x x λ . x x λ

λx.0

1 ψ 1 φ,¬ψ φ,¬ψ φ,¬ψ

. x x λ . x x λ . x x λ

Model Checking E(φ U ψ)

. x x λ

ψ φ ψ φ φ φ φ

.0 x λ . x x λ . x x λ . x x λ . x x λ

1

The Model-Extraction Problem in Software Model-Checking

Abstract model Model Checker Program

Gap

Use techniques from abstract interpretation and program analysis to extract a finite-state model from program Idea:

Bandera: [Dwyer, Hatcliff, et. al.]

An open tool set for model-checking Java source code

Checker Inputs Checker Outputs

Optimization Control

Transformation & Abstraction Tools

Model Checkers Java Source

Bandera Temporal Specification Graphical User Interface Error Trace Mapping

Bandera

Conclusion

Overview on fundamentals of

Model Checking Flow Analysis Some links

Just the Beginning. . .

More complex properties Theory of Abstract Interpretation Interprocedural Flow Analysis Parallel Programs

Any Questions?