in collaboration with University of Kent Clara Benac Earle SICS Mads Dam Lars-Åke Fredlund Dilian...

in collaboration

with

University of Kent Clara Benac Earle

SICS Mads Dam

Lars-Åke Fredlund Dilian Gurov Gena Chugunov

CWI Izak van

Langevelde Wan Fokkink Jaco

van de Pol Stefan Blom

Inria Rhône-alpes Hubert Garavel Radu MateescuRWTH Aachen Thomas Noll

Martin Leucker Jürgen Giesl

LFCIA Juanjo Sánchez

Penas

in collaboration

with

University of Kent SICS

CWI Inria Rhône-alpes

RWTH AachenLFCIA

Formal verification of software

Thomas ArtsEricsson

Stockholm, Sweden

Why formal verification ?• cut down on testing/maintenance cost

• Common Criteria (ISO 15408) prescribes it

• allow more complex products to be built

For what purpose ?

• find bugs in design/software

• prove correctness

Where to apply ?

• Verify design

• Verify software

• Verify software implements design

• Verify design equivalence

• Verify program equivalence

case-studies

WAP

Database lookup

Resource locking

leader election

TCAP

Formal Verification of Design

Make a formal design (specification language)

Formalize properties

Find a technique to verify that the formal property holds for the formal design

Formal Verification of Design (example)

Design of resource locker

locker

B A

CD

client

client client

locker client

ok

request A, B

release

idle

critical

idle

request resources

ok

release

idle

idle

request resources

release

available ?

ok

idle

pending available?

add pending idle

ok

rm pending

Formal Verification of Design (example)

Client specification

idle

critical

idle

request resources

ok

release

client_idle = send(request_recources). receive(ok). client_critical

client_critical = send(release). client_idle

init locker_idle || client_idle

idle

idle

request resources

release

available ?

ok

idle

pending available?

add pending idle

ok

rm pending

locker_idle = receive(request_resources). (available. send(ok). locker_idle + not_available. add_pending. locker_idle ) + receive(release). locker_intermediate

locker_intermediate = pending_available. send(ok). rm_pending. locker_intermediate + not_pending_available. locker_idle

Locker specification

State space generationClearly there are deadlockstates in the state space

They correspond to the situation where:

- resource not available- resource available but no client waiting for it

Both situations cannot occur in reality

2 clients and a locker

Non-determinism givespossibility that both clients are waiting for the resource

Note that both clients can get access to the same resource


have to make formal design

not enough detail for interesting properties

no feeling for implementation (memory consumption, speed)

implementation may divert from design


More and more details are added to the design in order to check interesting properties.

CLAIM:For Interesting properties one need

to add details until the specification is executable, i.e. is a program.

Formal verification of a Program

IDEA: Use code as formal design document

+ Libraries can be used as-is+ Programming languages support debug facilities, testing possibilities, etc.+ Designers do not need to learn a new language

Formal verification of a Program (example)

idle

critical

idle

request resources

ok

release

-module(client).

start(Locker) -> spawn(fun() -> loop(Locker) end).

loop(Locker) -> Tag = ref(), Locker!{request,[a],self(),Tag}, receive {ok,Tag} -> critical(), Locker!{release,self()}, loop() end.


-module(locker).

loop(Locks) -> receive {request,Rs,Client,Tag} -> case available(Locks,Rs) of true -> Client ! {ok,Tag}, loop(update(Locks)); false -> loop(add(Locks,Rs, {Client,Tag})) end; {release,Client} -> ...

idle

idle

request resources

release

available ?

ok

idle

pending available?

add pending idle

ok

rm pending

Formal verification of a ProgramIDEA: Use code as formal design document

+ Libraries can be used as-is+ Programming languages support debug facilities, testing possibilities, etc.+ Designers do not need to learn a new language

design

patterns

- Too much detail no feeling for design

- Risk of infinite state space

theorem

prover or

abstraction


use the generic server design pattern to implement the locker

init(Resources) -> {ok, built_locks(Resources)}.

handle_call({request,Rs},Client,Locks) -> case available(Rs,Locks) of true -> {reply,ok,update(Locks)}; false -> {noreply,add(Locks,Rs,Client)} end;....

Formal verification of a Program

Techniques:

Theorem Provingexpressive logic allows (co-)inductionlarge manual effort

Model Checkinglimited logic (e.g. CTL)little manual effort

Ad Hoc solutions

State Space Generation

Erlang modules

ourTool

We developed a tool to generate all possible traces for simple client-server applications


In Erlang we use a supervisor design pattern to handle fault-tolerance. If a process dies, it’s supervisor restarts it.

supervisor

supervisorlocker

gen_server

clientclient client clientclient


We use supervisor design pattern to obtain initialization information for transition diagram

supervisor

supervisorlocker

gen_server

client client

start the locker with 2 clientssupervisor:start(locker_sup,init,[[[a,b],[b,c]]]).

start verification with 2 clientsetomcrl:start(locker_sup,init,[[[a,b],[b,c]]]).

We build one state space

per configuration

ourToollocker.erl

client.erl

locker_sup.erl

client_sup.erl

ourTool

ourTool

ourTool

ourTool

EtoE rest tool

locker.erlclient.erl

init.erlin

stan

tiatio

n




locker_sup.erl

client_sup.erl


init.erlin

stan

tiatio

n tomcrl.erl

inst

antia

tion

EtoE rest tool rest toolrest toolrest toolrest toolEtoPmcrl



locker_sup.erl

client_sup.erl

inst

antia

tion tomcrl.erl

inst

antia

tion

EtoE rest tool rest toolEtoPmcrl rest toolrest toolrest toolCWI toolinstantiator

locker.mCRL

toMCRL


init.erl



locker_sup.erl

client_sup.erl

inst

antia

tion tomcrl.erl

inst

antia

tion

EtoE rest tool rest toolEtoPmcrl CWI toolinstantiator

locker.mCRL

toMCRL


init.erl

CADP

locker.aut

2 clients and a locker

Model Checking Software

macro UNTIL (Act1,Act2) = [true*.(Act1).(not(Act2))*.(Act1)]falseend_macro

UNTIL('action_use(.*a.*)','action_free(.*a.*)') and UNTIL('action_use(.*b.*)','action_free(.*b.*)') and UNTIL('action_use(.*c.*)','action_free(.*c.*)')

Model Checking SoftwareNon Starvation:[-*. request(1,[A])] mu X.(<->true /\ [not reply(1,ok)]X) /\[-*. request(2,[A])] mu X.(<->true /\ [not reply(2,ok)]X) /\...[-*. request(1,[B])] mu X.(<->true /\ [not reply(1,ok)]X) /\....

request(2,[B])

requ

est(1

,[A])

reply(1,ok)

reply(2,ok)

Model Checking SoftwareNon Starvation:[-*. request(1,[A])] mu X.(<->true /\ [not reply(1,ok)]X) /\[-*. request(2,[A])] mu X.(<->true /\ [not reply(2,ok)]X) /\...

tau

tau

requ

est(1

,[A])

reply(1,ok)

Non-starvation per groupof resources.Hide all actions of whichresources are not in closureof resources you are interstedin

Safety reductio

n

(trace equivalence)

Model Checking SoftwareAbstraction may be needed to keep state space finite:

Generic abstraction mechanism by providing abstraction functions over messages and server state

This allows to obtain a design from a program!

not yet implemented in

combination with CWI tool

Results

Automatic state space generation from rich class of Erlang programs

Several case studies evaluated: model checking for software is possible

more work to do:

more design patternsproperty patterns in Erlang styleadd generic abstraction

mechanismwith

ou

t de

sig

n p

atte

rns

orco

mm

en

ts la

rges

t ca

se-s

tud

y is

abo

ut 3

00

lin

es o

f cod

e

Future

• how many configurations do we need to check?

• fault tolerance:- restarting processes

• compositionality:- N lockers exchanging information- lockers on top of leader

election

in collaboration with University of Kent Clara Benac Earle SICS Mads Dam Lars-Åke Fredlund Dilian...

Documents

Transcript of in collaboration with University of Kent Clara Benac Earle SICS Mads Dam Lars-Åke Fredlund Dilian...