[PPT] - ICFEM98, Brisbane Australia, 11 Decemb er 1998, 9am PowerPoint Presentation

SLIDE 1 ICFEM98, Brisbane Australia, 11 Decemb er 1998, 9am

SLIDE 2 Ubiquitous Abstraction: A New App roach T

Mechanized

F

rmal

V erication John Rushb y Computer Science Lab

rato

ry SRI International Menlo P a rk, CA John Rushb y , SRI Ubiquitous Abstraction: 1

SLIDE 3 F

rmal

Metho ds and Calculation

F
rmal

metho ds contribute useful mental framew

rks,

notations, and systematic metho ds to the design, do cumentation, and analysis

f

computer systems

But

the singula r b enet from sp ecically fo rmal metho ds is that they allo w certain questions ab

ut

a soft w a re

r

ha rdw a re design to b e answ ered b y symb

lic

calculation (e.g., fo rmal deduction, mo del checking)

And

those calculations can b e automated fo r sp eed, reliabilit y , rep eatabilit y

Calculations

can b e used fo r debugging (refutation) and design explo ration as w ell as p

st-ho

c verication

Augments

simulation, p rotot yping, testing

Compa

rable to the w a y mathematics is used in

ther

engineering disciplines John Rushb y , SRI Ubiquitous Abstraction: 2

SLIDE 4 Automating F

rmal

Calculations

T
ls

a re not the most imp

rtant

thing ab

ut

fo rmal metho ds

They

a re the

nly

imp

rtant

thing

Just

lik e any

ther

engineering calculations, it's to

ls

that mak e fo rmal calculations feasible and useful in p ractice

And

the imp

rtant

things ab

ut

to

ls

a re

Sp

eed, scaling, automation, p

w

er

Sp

eed, scaling, automation, p

w

er

Sp

eed, scaling, automation, p

w

er

Oh,

and soundness John Rushb y , SRI Ubiquitous Abstraction: 3

SLIDE 5 Where T

Apply

F

rmal

Metho ds T

ls?
There

is little p

int

in applying fo rmal metho ds to topics that a re handled adequately b y traditional metho ds

E.g.,

renement to co de; verication

f

co de (Except in regulated industries; even there, cost is critical)

F
cus
n

where the intractable diculties a re

Usually

in the ha rdest elements

f

design

Concurrency,

real time, fault tolerance Seconda ry advantage: these elements a re usually small, have the b est p eople

And

where the greatest costs a re incurred

Erro

rs intro duced in the ea rly lifecycle

Notably

,

missions

in requirements John Rushb y , SRI Ubiquitous Abstraction: 4

SLIDE 6 So What Should T

ls

Do?

Determine

whether sp ecications

f

complex,

ften

incomplete, designs have certain desired p rop erties

Prop

erties

ften

amount to less than full co rrectness

Can

lo

k

at this from t w

sides

Refutation: try and nd bugs

Need

not b e sound (nds all erro rs)

r

complete (nds

nly

real erro rs)

As

long as it nds enough real bugs to b e cost-eective

Should

p rovide diagnostic info rmation (counterexample) V erication: try and sho w \co rrectness"

Generally

mo re dicult than refutation

And

less helpful when bugs a re p resent

Switch

to verication when refutation runs

ut
f

steam John Rushb y , SRI Ubiquitous Abstraction: 5

SLIDE 7 Mechanizing Refutation: Mo del Checking

If

design has a nite state space, can

ften

check p rop erties b y mo del checking

Check

whether design is a Kripk e mo del

f

p rop ert y exp ressed as a temp

ral

logic fo rmula Name

ften

used fo r all related metho ds

Complexit

y is linea r in numb er

f

states

But

that gro ws as p ro duct

f

size

f

data structures, and is exp

nential

in numb er

f

interacting comp

nents
Hence,

must construct abstracted

r

do wnscaled mo dels

Do

wnscaling is aggressive (unsound) abstraction

Exp

erience is that y

u

lea rn mo re b y examining all p

ssibilities
f

do wnscaled mo del than b y p robing some

f

the p

ssibilities
f

the full thing (as b y simulation

r

testing) John Rushb y , SRI Ubiquitous Abstraction: 6

SLIDE 8 Mechanizing F

rmal

V erication

The

to

ls

a re generally based

n

interactive theo rem p roving

With

substantial automation ? Decision p ro cedures, rewriting, heuristics, lib ra ries

Guiding

the interaction requires skill, but

In

domains with decision p ro cedures

r

go

d

lib ra ries

And

sp ecications a re functional

It

is

ften

no ha rder than hand p ro

f

(of compa rable detail)

But

fo r concurrent and distributed systems

Where

sp ecications a re transition relations

It

is very ha rd indeed ? Not due to lack

f

theo rem p roving p

w

er ? But to the dicult y

f

inventing strong inva riants John Rushb y , SRI Ubiquitous Abstraction: 7

SLIDE 9 A T rivial Example Sho w that when control is at B, then x

2

x := x+1 x := x+1 x

3

! x := x-2 x := 2 A B John Rushb y , SRI Ubiquitous Abstraction: 8

SLIDE 10 A ttempted Pro

f
W

e'll use the induction scheme: (8 s: init(s)

p(s))

^ (8 pre, post: p(pre) ^ tr(pre, post)

p(post))
invariant(p)(init

, tr) Whose

wn

p ro

f

in PVS is (SKOSIMP) (EXPAND "invariant") (INDUCT-AND-SIMP LI FY "j")

The

p ro

f

steps (USE "ind[state]") (GROUND) ("1" (GRIND)) ("2" (GRIND)) Yield [-1] pc(pre!1) = A [-2] pc(post!1) = B [-3] x(pre!1) = |------- [1] x(pre!1) + 1

2
Need

to strengthen inva riant: x

1

when control at A John Rushb y , SRI Ubiquitous Abstraction: 9

SLIDE 11 And In General?

Can

extract terms that need to b e added (conjoined) to the inva riant b y examining these failed subgoals (Simila r ideas fo r lo

p

inva riants go back 20 y ea rs)

La

rger example: verication

f

Bounded Retransmission Proto col (BRP)

Required

57 strengthenings

Eo

rt required generally defeats all but the most determined

The

case explosion p roblem

Everything

is p

ssible

but nothing is easy

There

is much w

rk
n

metho dologies fo r deriving suitable inva riants systematically (fo r given classes

f

p roblems)

But

w e're lo

king

fo r general metho ds. . . John Rushb y , SRI Ubiquitous Abstraction: 10

SLIDE 12 Another Direction

Mo

del checking avoids all this hassle (b y calculating a xp

int)
Substitutes

calculation fo r p ro

f
But
nly

w

rks

fo r nite-state systems

So

let's create a nite-state abstraction (i.e., app ro ximation)

And

mo del-check that

Will

also need to p rove that the abstraction is p rop ert y-p reserving John Rushb y , SRI Ubiquitous Abstraction: 11

SLIDE 13 V erication Via Prop ert y-Preserving Abstraction

In

general, w e need a (nite) abstract state space with transition relation tr a

And

an abstraction function abs from the concrete state space to the abstract

ne
And

a p redicate p a

n

the abstract states

Such

that 1. init c (cs)

init

a (abs(cs)) 2. tr c (pre c ; post c )

tr

a (abs(pre c ); abs(post c )) 3. p a (abs(cs))

p

c (cs)

Then
invariant(p

a )(init a ; tr a )

invariant(p

c )(init c ; tr c )

And

the antecedent can b e p roved b y mo del checking John Rushb y , SRI Ubiquitous Abstraction: 12

SLIDE 14 The Example: Bo

lean

Abstraction

Often

convenient to cho

se

an abstract state space consisting

f
The

control lo cations

f

the concrete system, plus

Some

b

lean

state va riables that co rresp

nd

to p redicates in the concrete system

This

is Bo

lean

abstraction

F
r

the example, w e'll have

ne

abstract Bo

lean

state va riable co rresp

nding

to the concrete state p redicate x

2

John Rushb y , SRI Ubiquitous Abstraction: 13

SLIDE 15 An Abstract T ransition Relation F

r

The Example A B x

2

x

2

A x 6 2 Clea rly , the abstract inva riant is satised John Rushb y , SRI Ubiquitous Abstraction: 14

SLIDE 16 V erication Conditions fo r the Example Abstraction

All

trivial except numb er 2: default p ro

f

strategy yields [-1] pc(post c !1) = B [-2] x(pre c !1) = |------- [1] x(pre c !1) + 1

2
Essentially

the same as in the basic inva riance p ro

f
Requires

an inva riant!

La

rger example: verication

f

Bounded Retransmission Proto col (BRP) b y abstraction

Required

45 inva riants John Rushb y , SRI Ubiquitous Abstraction: 15

SLIDE 17 So What's T

Be

Done? Calculate the abstract system (given the abstraction function) rather than \invent and verify"

Saves

manual eo rt

f

construction

Abstract

system is an abstraction (b y construction)

But

ma y b e to

coa

rse to satisfy desired abstract inva riant John Rushb y , SRI Ubiquitous Abstraction: 16

SLIDE 18 Calculated Abstract T ransition Relation F

r

The Example A B x

2

x

2

A x 6 2 B x 6 2 Abstract inva riant is not satised John Rushb y , SRI Ubiquitous Abstraction: 17

SLIDE 19 Diagnosing The Problem

Mo

del checking p ro duces this counterexample trace

fA,

x

2g

! fB, x

2g

! fA, x 6 2g ! fB, x 6 2g

If

w e \concretize" this w e see that the last transition is imp

ssible

in the concrete system

fA,

x

2g

! fB, x

2g

! fA, x 6 2g ! fB, x 6 2g 2 3 1 2

W

e see that it is imp

rtant

to kno w x

1

at A

So

add another abstract state va riable co rresp

nding

to x

1

and rep eat

This

do es it! John Rushb y , SRI Ubiquitous Abstraction: 18

SLIDE 20 Making It Practical

(A

t least) t w

w

a ys

f

calculating the abstracted system

Sta

rt with universal transition relation; then fo r each a rc ? Generate the verication condition (V C) that allo ws it to b e removed ? Leave it in if cannot p rove the V C This app roach p reserves structure

Develop

the relation b y a fo rw a rd reachabilit y analysis ? A t each p

int

generate the V Cs that lead to successo r states with given p redicate true resp. false This app roach usually has few er states

There

a re clever techniques fo r assuming the inva riant y

u

w ant to p rove while constructing the abstraction

And

fo r rening an abstraction using counterexamples John Rushb y , SRI Ubiquitous Abstraction: 19

SLIDE 21 Making It Practical (ctd.)

Generate

as many inva riants as p

ssible

b y static analysis and thro w those into the p ro

fs/calculations
Can

easily deduce x

1

in the example

Use

heuristics to generate plausible initial abstractions

Bo
lean

abstraction

n

(atomic) gua rd p redicates

Build

to

ls

fo r concretizing counterexample traces and checking them against the concrete system

T
help

distinguish b et w een ? An excessively coa rse abstraction ? A bug in the concrete system

Can

verify Bounded Retransmission Proto col (BRP) automatically using these techniques

T

ak es a couple

f

hours to calculate the abstracted system John Rushb y , SRI Ubiquitous Abstraction: 20

SLIDE 22 Doing It Ubiquitously

Mo

del check ers usually calculate the reachable stateset (and then thro w it a w a y)

Which

is the strongest inva riant

The

concretization

f

the reachable states

f

an abstraction is an inva riant

f

the concrete system

And
ften

a strong

ne
Mo

dify a mo del check er to return the reachable states as a fo rmula that the theo rem p rover can manipulate

Use

simple abstractions to develop inva riants that enable construction

f

ner

nes
E.g.,

Bo

lean

abstraction

n

x

1

in the example p rovides the inva riant that enables construction

f

the ne abstraction

n

x

2

John Rushb y , SRI Ubiquitous Abstraction: 21

SLIDE 23 Iterated Abstractions

Can

also use dierent abstraction techniques Semantic: what w e've seen so fa r Syntactic: slicing, abstract interp retation

Slicing

extracts salient pa rt

f

a complex system

Abstract

Interp retation p rovides basis fo r strong static analyses (cf. dimensional analysis)

And

can iterate them

E.g.,

slice, abstract interp retation, then semantic abstraction John Rushb y , SRI Ubiquitous Abstraction: 22

SLIDE 24 Iterated Abstraction, Concretization, Inva riant Generation John Rushb y , SRI Ubiquitous Abstraction: 23

SLIDE 25 Integrating Abstraction With Theo rem Proving

So

fa r, w e've used abstraction

nly
n

the top-level goal

Can

also apply it in the context

f

the subgoals generated b y a theo rem p rover (e.g., in an inductive p ro

f

)

Are

then w

rking
n

simpler p roblems

And

p redicates in subgoal p rovide go

d

clues to suitable Bo

lean

abstractions John Rushb y , SRI Ubiquitous Abstraction: 24

SLIDE 26 Integrating Abstraction With Theo rem Proving (ctd.)

In

the example, the subgoal [-1] pc(pre!1) = A [-2] pc(post!1) = B [-3] x(pre!1) = |------- [1] x(pre!1) + 1

2
Suggests

abstracting

n

x = (which is equivalent to x 6 1 since x is a natural numb er)

And

mo del checking then sho ws this state to b e unreachable

Metho

d is p rovably stronger than gua rd abstraction and p recondition strengthening John Rushb y , SRI Ubiquitous Abstraction: 25

SLIDE 27 Integrating Abstraction With Theo rem Proving (ctd. 2)

No No Yes invariants newly proved conjecture new invariant: wishes granted abstract system abstract new conjecture abstract program Abstraction generator Theorem prover Invariant generator trace? violating concrete matches trace? new abstract variables new wishes wishes pending subgoals property Proof! Yes invariants analyzer Trace trace Trace simulator Counterexample! variables

John Rushb y , SRI Ubiquitous Abstraction: 26

SLIDE 28 The \New" App roach

Instead
f

trying to build ever mo re p

w

erful to

ls
T

ry to mak e the p roblems easier

Cut

them do wn to a size the existing to

ls

can handle

By

making ubiquitous use

f

automated abstraction

That

is, construction

f

simpler descriptions that igno re/app ro ximate asp ects

f

the

riginal
Within

a framew

rk

that allo ws multiple to

ls

to co

p

erate

Generate

mo dels app rop riate to dierent analyses and dierent to

ls

from a single description

Co
p

eration requires to

ls

to exchange symb

lic

values, not just true/false verication

utcomes
The

idea b ehind SAL: a (Symb

lic

Analysis Lab

rato

ry) John Rushb y , SRI Ubiquitous Abstraction: 27

SLIDE 29 The SAL Idea

Abs. Result Model2

2

Abs. Result n Modeln Analyzer Abs. Result 1 Model

System Description Analysis Results

Abstractor Concretizer Concretizer

Analyzer

1 2 1

Analyzer 2

1 1 n

Intermediate Language Model Existing Verification Tools and Analyzers

Abstractor Abstractor

2 n

Concretizern

John Rushb y , SRI Ubiquitous Abstraction: 28

SLIDE 30 The General View Theo rem Proving Abstraction Comp

sition

Metho ds Algo rithmic Abstraction and comp

sition

a re the b ridges b et w een deductive and algo rithmic metho ds

f

verication John Rushb y , SRI Ubiquitous Abstraction: 29

SLIDE 31 Related W

rk
Resea

rch in mo del checking has long fo cused

n

abstraction

Mo

re recently

n

iterated combinations justied b y theo rem p roving

E.g.,

\Minimalist Pro

f

Assistants" b y Ken McMillan ? FMCAD talk (on his w eb page at http://www-cad.ee cs. be rke le y.e du /~k en mcm il /) ? Implemented in SMV ? Used fo r T

masulo,

SGI cache coherence

Much

recent fo cus

n

logics with very p

w

erful automation

Prop
sitional

calculus (St

alma

rck's metho d)

With

uninterp reted functions (Herb rand automata)

WS1S

(Mona) And metho ds fo r reducing general p roblems to those ecient cases John Rushb y , SRI Ubiquitous Abstraction: 30

SLIDE 32 Credits None

f

this w

rk

is mine; it is due to my colleagues

Klaus

Havelund: BRP example

Hassen

Sa

di:

The Inva riant Check er

Saddek

Bensalem, Y assine Lakhnech, Sam Owre: InV eSt

Vlad

Rusu and Eli Singerman: Mini-SAL exp eriments

Shank

a r: SAL Being develop ed with David Dill (Stanfo rd) And T

m

Henzinger (Berk eley) John Rushb y , SRI Ubiquitous Abstraction: 31

SLIDE 33 T

Lea

rn Mo re

Bro

wse general pap ers and technical rep

rts

at http://www.csl.sr i. com /f m.h tml

~owre/cav98.html

and ~owre/cav98-tool.h tm l fo r InV eSt

~rusu/tacas99.ht

ml fo r mini-SAL exp eriments

~saidi/Invariant
Ch

ec ker /i nde x. htm l fo r the Inva riant Check er

Info

rmation ab

ut
ur

verication system, PVS, and the system itself a re available from http://pvs.csl.s ri .co m

F

reely available under license to SRI

Allegro

Lisp fo r Sola ris,

r

Linux

Need

64M memo ry , 100M sw ap space, 200 MHz

r

b etter John Rushb y , SRI Ubiquitous Abstraction: 32