Automatic Non-interference Lemmas for Parameterized Model Checking

Preview:

DESCRIPTION

Automatic Non-interference Lemmas for Parameterized Model Checking. Jesse Bingham, Intel DEG FMCAD 2008. Classic CMP Approach. CMP approach [McMillan 99/01, Chou et al. 04, Krstic 05, Lv et al 07, Li 07, Talupur & Tuttle 08] human writes non-interference lemmas from counterexamples - PowerPoint PPT Presentation

Citation preview

1

Automatic Non-interference Lemmas for Parameterized Model Checking

Jesse Bingham, Intel DEG

FMCAD 2008

2

Classic CMP Approach

CMP approach [McMillan 99/01, Chou et al. 04, Krstic 05, Lv et al 07, Li 07, Talupur & Tuttle 08] human writes non-interference lemmas from

counterexamples system is iteratively strengthened with lemmas until

all lemmas and property hold

3

CMP requires human to write lemmas

0p 1p

Umm, me no think possible in real

system

Human writes “non-interference lemma”: ))((. ipblueorangei

otherp

4

What we do

our approach removes lemma-writing burden of human’s shoulders start with “non-interference conjecture” False abstract strengthened system compute abstract reachability fixpoint iterate, with concretized fixpoint as new conjecture

our contributions general theory based on abstract interpretation instantiation of theory for class of parameterized

protocols using BDDs & prototype tool

5

Roadmap

General TheorySymmetric Parameterized Protocols Case Studies/Final Thoughts

6

Theory

concrete transition system (C,I,T)C is the set of (concrete) states I C are the initial statesT CC is the transition relation

Reach(C,I,T) denotes set of reachable states p C is called an invariant if Reach(C,I,T) p for C define

post[T]() = {y | x.(x,y) T and x }

7

Strengthening

For C, the strengthening of (C,I,T) by , is the transition system (C, I, T( C)). We denote the strengthening by T # .

Theorem. is an invariant of (C,I,T) if and only if is an invariant of T # .

Strengthen with = blue states

8

Abstraction

finite abstract domain A along with partial order ⊑ , forming a lattice (A,⊑) Think of ⊑ as subset ordering on represented sets

galois connection (,) defines association between concrete states and abstract domain : 2C A : A 2C

and are order preservingother technical properties

9

: Makes Abstract Posts for Strengthened Concrete Systems (1/2)

() : A A

set of concrete states

Abstract post (a.k.a abstract interpretation) of post[T # ]

10

: Makes Abstract Posts for Strengthened Concrete Systems (2/2)

ConcreteStates

C

AbstractDomain

Aa

(a)post[T#]((a))

(post[T#]((a))

()(a)

⊑ C

“best” postrelative to

(,)

11

The Method

ConcreteStates

C

AbstractDomain

A Reach((Init),(0))Reach((Init),(1))

1

0 = False

2

Reach((Init),(k))

=Reach((Init),(k-1))

… k

(k) ⊑ (property)

12

Roadmap

General TheoryParameterized Protocols Case Studies/Final Thoughts

13

State variable types

let Pid denote the process IDs four types of variables

Bool e.g. global FSM state Pid Bool e.g. process FSM state, control

arrays indexed by Pid Pid e.g. global process pointer Pid Pid e.g. pre-process process pointer

14

Transition relation syntax

atoms w (w : Bool ) x[p] (x : Pid Bool and quantifed var p ) y=p (y : Pid and quantifed var p ) z[p]=q (z : Pid Pid and quant vars p & q) plus any of the above with priming

transition formula syntax:

where 0 and 1 are (restricted) boolean combinations of atoms

).()..( 10 que

15

Protocol Abstraction

abstract domain is symmetric sets of views galois connection is straightfoward

similar to [Lahiri & Bryant 04]’s for universally quantified predicate abstraction

thanks to a small model theorem & symmetry, we can compute a best using BDDs

16

Views [Chou et al 04]

Bool Pid Pid Bool

1

0 1 2 3

Concrete state

View (m=2) 1

Bool Pid Pid Bool

3

0 1 2 3

Concrete state

View (m=2) other

a view only includes info regarding a small number m of processes; Pid vars take values from {0,…,m-1,other}

17

Small Model Theorem

Bool Pid Pid Bool

1

0 1 2 3 4 n (arbitrarily big)

0

0 …1

0 1 2 3 4 m+L+1 (fixed & small!)

if and only if -abstract awaythis state in BDD

18

Putting It All Together

i (set of views

as BDD)

Compute BDD forT (i)

of size m+L+1

-quantify away all but first m processes

(i)i+1 = Reach((Init),(i))

Computed using BDD techniques of

[Pnueli et al 01]

19

Non-best

small model theorem allows for best can cause BDD blow-up

two orthogonal techniques allow for non-best , which typically yields smaller BDDs strengthen with subset of variables

also reduces small model theorem bound by 1

only strengthen “guarded commands” that depend on abstracted state in the guards, or even fewer

20

Roadmap

General TheorySymmetric Parameterized Protocols Case Studies/Final Thoughts

21

Prototype Tool

built prototype tool using Intel’s forte formal verification system [Seger et al 05]

protocols modeled in forte’s language reFLect user specifies “ingredients”

number of concrete processes m=2 variables to constraint during strengthening transitions to strengthen

dynamic BDD var ordering useful [Rudell 93]

22

Case Studies (1/3)

GERMAN [German 00] “hello world” for parameterized verification just one Pid var; no Pid Pid vars control & data properties verified totally

automatically with “best” GERMAN2004

more complex than GERMAN has Pid Pid vars (network) previously verified by [Lv et al 07], who needed

human to add history vars we verified the control property with non-best

23

Case Studies (2/3)

FLASH [Kuskin et al 94] “…if [a parameterized verification method]

works on FLASH, then there is a good chance that it will also work on many real-world cache coherence protocols.” [Chou et al 04]

first automatically verified by [Lv et al 07] we verified the control property using non-

best

24

Case Studies (3/3)

abstract reach iterations

outterloop

iterations

25

Final Thoughts

presented a method that automatically computers non-interference lemmas general theory applied to symmetric protocols related to Invisible Invariants [Pnueli et al 01]

BDDs aren’t necessarily bad for protocols especially parameterized model checking original work [McMillan 99/01] used SMV/BDDs

automation: intellectually pleasing…but probably won’t scale

26

Foil graveyard…

27

Motivating Example

)))(())(((., jpgreenipyellowji Want to prove invariance of something like:

28

otherp

Abstract Process other

0p 1p

Abstracts behavior of

processes {2,…,n} for arbitrary

n

)))(())(((1,01,0

jpgreenipyellowji

Model Check:

29

Counterexample Analysis

0p 1p

Umm, me no think possible in real

system

Human writes “non-interference lemma”: ))((. ipblueorangei

otherp

30

Guard Strengthening

0p 1p otherp

))((. ipblueorangei ))((

1,0ipblueorange

i

Model Check:

Strengthen with:

31

Order Preservation of Abstraction

()

()

⊑Concrete

StatesC

AbstractDomain

A

32

Order Preservation of Concretization

(a)

a

a

⊑(a)

ConcreteStates

C

AbstractDomain

A

33

Proving Invariants with & (a different view from in the paper & talk)

ConcreteStates

C

AbstractDomain

A

(i)Reach((Init),(i))

(Reach((Init),(i)))= i+1i

AbstractsT#i

AbstractsReach(I,T#i)

Theorem. i+1 i implies i

is a (concrete) invariant

34

Proving Invariants with &

ConcreteStates

C

AbstractDomain

A Reach((Init),(i))

i

⊑ (i)(i)

AbstractsReach(I,T#i)

AbstractsT#i

Theorem. Reach((Init),(i)) ⊑ (i)implies i is an invariant

Abstracts i

35

Weakening with &

ConcreteStates

C

AbstractDomain

A

(i)Reach((Init),(i))

(Reach((Init),(i)))= i+1

i

AbstractsT#i

AbstractsReach(I,T#i)

36

Abstract Post ap()

ConcreteStates

C

AbstractDomain

Aa

(a)post((a))

(post((a)))

ap(a)

37

: Makes Abstract Posts for Strengthened Concrete Systems

Concrete

StatesC

AbstractDomain

A() : A A

Abstract post image of T#

38

The Method (1/3)

ConcreteStates

C

AbstractDomain

A(i)Reach((Init),(i))

i

AbstractsT#i

AbstractsReach(I,T#i)

(i) ⊑|

(Reach((Init),(i)))= i+1

39

The Method

start with 0 = False; iteratively compute 1, 2, 3,… until a provable invariant is found

this is the strongest provable invariant provable is relative to and

if we use that is “best” then is the strongest invariant provable using

40

Protocol Abstraction

abstract domain is symmetric sets of views galois connection is conceptually

straightforward; similar to [Lahiri & Bryant 04] () = {View(s) | s and is a view map}

thanks to a small model theorem & symmetry, we can compute a best …

41

Small Model “cut-off”

m+ L + 1

number of concrete processes in view

number of existentially quantifiedvars in protocol transition relation

).()..( 10 que

can be done awayWith in certain circumstances

42

Views

type in protocol type in view

Bool Bool

Pid Bool Pidm Bool

Pid Pidmother

Pid Pid Pidm Pidmother

m a small constant (typically 2)Pidm

= {0,…,m-1}Pidother = Pidm

{other}

abstract domain is sets of views [Chou et al 04], which are assignments to protocol vars with different typing

43

Abstraction

Bool Pid Pid Bool

2

0 1 2 3

other

0

1

1

other

other

0

Concrete state s(with n=4)

Set of views (s)

44

otherp

Views (2/2) Replace this slide!!!

0p 1potherp

Pid vars have type{0,1,other}

m = 2 “concrete” processes

State of the form array[other]

is abstracted away

45

Small Model Theorem

arbitrarily large nview (m = 2)

m+ L + 1

above can do any “view transition”

iff below can

hence we -abstractthese processes away

46

TODO…

Recommended