temporal-safety proofs for systems code thomas a. henzinger ranjit jhala rupak majumdar george...

Post on 21-Dec-2015

218 Views

Category:

Documents

1 Downloads

Preview:

Click to see full reader

TRANSCRIPT

Temporal-Safety Proofs Temporal-Safety Proofs for for

Systems CodeSystems Code

Thomas A. Henzinger Ranjit Jhala Rupak MajumdarGeorge Necula Westley Weimer Grégoire Sutre

UC Berkeley

2

Reliability & TrustReliability & Trust

Reliability (verification): Check that the system is “bug free”Low level systems code

Locking disciplines, interface specs, …Temporal, path-sensitive properties

Model checking

Trust (certification):

Questionable code written by third parties:

device drivers, mobile code

Model checkers are buggy (!)

Simply, efficiently checkable

avoid redoing verification

3

Our WorkOur Work

Verification: making model checking scale Lazy Abstraction [POPL ’02]

Certification:Proof carrying code based mechanism

PCC requires annotations

Lazy Abstraction:Automatically generates annotationsProvides a small decomposition of the proof

BLAST Verifying/certifying device drivers

4

VerificationVerification

5

Verification: Abstraction-RefinementVerification: Abstraction-Refinement

Abstract

Explanation

YES (Trace)

BUG

Feasible

???

Check

Refine

NO

SAFE

Seed Abstraction

Program

Abstraction

InfeasibleWhy infeasible ?

Is model unsafe ?

[Kurshan et al, Clarke et al, SLAM,...]

6

Model Checking & AbstractionModel Checking & Abstraction

ERROR STATES

Init

Existentially lift transition relation

Partition the state space

7

ERROR STATES

Init

Model Checking & AbstractionModel Checking & Abstraction

Problem: Abstraction too coarseSolution: Refine abstraction

8

ERROR STATES

Init

Model Checking & AbstractionModel Checking & Abstraction

Problem: Abstraction too coarseSolution: Refine abstraction

9

Abstract Only Where RequiredAbstract Only Where Required

ERROR STATES

Init

Abstraction is very expensive Why abstract regions that are never visited ?

Reachable States

On-the-fly abstraction: driven by the search

10

Refine Only Where RequiredRefine Only Where Required

Why be precise everywhere ?Don’t refine error-free regions

ERROR STATES

Init

ERROR FREE

11

Refine Only Where RequiredRefine Only Where Required

Why be precise everywhere ?Don’t refine error-free regions

Different precision for different regions Local Refinement : driven by the search

ERROR STATES

Init

ERROR FREE

12

Benefits of Lazy Abstraction Benefits of Lazy Abstraction

Abstract only where requiredReachable state space maybe very sparseConstruct the abstraction on-the-fly

Use greater precision only where requiredDifferent precisions/abstractions for different regionsRefine locally

Reuse work from earlier phasesBatch-oriented ) lose work from previous runsIntegrate the three phases

13

ExampleExample

Q: Is Error Reachable ?

Example ( ) {1: do { lock(); old = new;2: if (*) {3: unlock(); new ++; }4: } while ( new != old);5: unlock (); return;}

unlock() lock()

lock()

unlock()

14

Example ( ) {1: do { lock(); old = new;2: if (*) {3: unlock(); new ++; }4: } while ( new != old);5: unlock (); return;}

Example:CFAExample:CFA

lock();

old = new

[>]

[>]

[new==old]

[new!=old]

2

1

3

4

5

ret

unlock()

new++

unlock()

15

Example:CFAExample:CFA

Q: Is Error Reachable ?

2

1

3

4

5

ret

unlock() lock()

lock()

unlock()

Example ( ) {1: do { lock(); old = new;2: if (*) {3: unlock(); new ++; }4: } while ( new != old);5: unlock (); return;}

16

Step 1: SearchStep 1: Search

Set of predicates:

LOCK=0, LOCK=1

1 LOCK=0

3 LOCK=1

lock();

old = new

[>]

unlock()

5 LOCK=0

unlock()

new++

[new==old]

4 LOCK=0

2 LOCK=1

Err LOCK=0

lock();old = new

[>][>]

[new==old]

[new!=old]

2

1

3

4

5

ret

unlock()new++

unlock()

17

Q: When can:

Step 2:Step 2: Analyze CounterexampleAnalyze Counterexample

1 LOCK=0

2 LOCK=1

3 LOCK=1

4 LOCK=0

5 LOCK=0

Err LOCK=0

n Errops

States that can = PRE( ,ops) Err

Rn Æ PRE( ,ops) = ? Err

States at node n = Rn

18

Step 2:Step 2: Analyze CounterexampleAnalyze Counterexample

1 LOCK=0

2 LOCK=1

3 LOCK=1

4 LOCK=0

5 LOCK=0

Err LOCK=0

lock();

old = new

[new==old]

unlock()

LOCK=0

LOCK=0 Æ new = old

[>]

unlock();

new++

LOCK=1 Æ new+1 = old

LOCK=1 Æ new +1 = old

lock();old = new

[>][>]

[new==old]

[new!=old]

2

1

3

4

5

ret

unlock()new++

unlock()

LOCK=0 Æ new+1 = new

Rn Æ PRE( ,ops) = ? Err

19

Step 2:Step 2: Analyze CounterexampleAnalyze Counterexample

1 LOCK=0

2 LOCK=1

3 LOCK=1

4 LOCK=0

5 LOCK=0

Err LOCK=0 LOCK=0

LOCK=0

LOCK=0 Æ new = old

LOCK=0 Æ new+1 = new

LOCK=1 Æ new+1 = old

LOCK=1 Æ new +1 = old

Track the predicate:

new = old

lock();old = new

[>][>]

[new==old]

[new!=old]

2

1

3

4

5

ret

unlock()new++

unlock()

20

Step 3: Resume SearchStep 3: Resume Search

1LOCK=0lock();

old = new

[new==old]

? 5[new!=old]

1

LOCK=0 Æ : new = old µ LOCK =0

Set of predicates:

LOCK=0, LOCK=1, new = old

3LOCK=1 Æ new = old

[>]

unlock()

new++

4LOCK=0 Æ : new = old

2LOCK=1 Æ new = old

lock();old = new

[>][>]

[new==old]

[new!=old]

2

1

3

4

5

ret

unlock()new++

unlock()

21

Step 3: Resume SearchStep 3: Resume Search

1LOCK=0

2LOCK=1 Æ new = old

3LOCK=1 Æ new = old

4LOCK=0 Æ : new = old

? 5 1

LOCK=0 Æ : new = old

4LOCK=1 Æ new=old

5 1

?

retLOCK=0Æ new=old

ERROR

Unreachable

Set of predicates:

LOCK=0, LOCK=1, new = old

lock();old = new

[>][>]

[new==old]

[new!=old]

2

1

3

4

5

ret

unlock()new++

unlock()

22

Predicate DiscoveryPredicate Discovery

Information lost in substitution

Keep substitutions explicit

Ask a proof of unsatisfiability

Pick predicates appearing in proof

1 LOCK=0

2 LOCK=1

3 LOCK=1

4 LOCK=0

5 LOCK=0

Err LOCK=0

lock();

old = new

[>]

unlock();

new++

[new==old]

unlock()

LOCK=0 Æ new+1 = new

23

Example ( ) {0: if (*) { 6: do { got_lock = 0;7: if (*) {8: lock(); got_lock ++; }9: if (got_lock) {10: unlock(); }11: } while (*) ; }1: do { lock(); old = new;2: if (*) {3: unlock(); new ++; }4: } while ( new != old);5: unlock (); return;}

Local RefinementLocal Refinement

1: do { lock(); old = new;2: if (*) {3: unlock(); new ++; }4: } while ( new != old);5: unlock (); return;}

9

8

7

11

10

6

0

2

1

3

4

5

ret

6: do { got_lock = 0;7: if (*) {8: lock(); got_lock ++; }9: if (got_lock) {10: unlock(); }11: } while (*) ; }

24

Local RefinementLocal Refinement

[>]

1LOCK=0

0 LOCK=0

6 LOCK=0

[>]

Err

0

7

98

1110

6

21

34

5

ret

Refine right subtree only

Different abstractions for subtrees

Search on left subtree not repeated

25

Leaves Covered (Reuse work)Leaves Covered (Reuse work)0 LOCK=0

1LOCK=0 6 LOCK=0

111

LOCK=0 Æ …

COVERED !

Leaves covered:

Avoid repeating search when paths merge

0

7

98

1110

6

21

34

5

ret

26

CertificationCertification

27

What is a Certificate ?What is a Certificate ?Proof Carrying Code (PCC)

Program + Spec

Annotations

VC Generator

Verification Condition

Annotations: Loop invariants, func. Precondition/Postcondition

Certificate: Annotations + Proof of VC

Consumer reconstructs VC, checks proof

Validity of VC guarantees correctness

28

AnnotationsFor each cntrl location q, invariant I(q)

Verification conditionInit µ I(q0)

Annotations & VCsAnnotations & VCs

Start set includes initial states

Error location is not reached

States closed under post

I(q) = false

For each edge q !op q’: POST(I(q),op) µ I(q’)

29

Ç LOCK=0 Æ : new = old

Invariants grow on TreesInvariants grow on Trees

1

4

5

LOCK=0

2

3

LOCK=1 Æ new = old

LOCK=1 Æ new = old

LOCK=0 Æ : new = old

Ç LOCK=1 Æ new=old

LOCK=1 Æ new=old

LOCK=0 Æ : new = old

1LOCK=0

2LOCK=1 Æ new = old

3LOCK=1 Æ new = old

4

? 5 1

LOCK=0 Æ : new = old

4 LOCK=1 Æ new=old

5 1

?ret

LOCK=0 Æ new=old

Reachability Tree Invariants

covered

30

Proving the VCProving the VC

Each condition dischargeable automatically (Vampyre, CVC …)

Tree yields a small decomposition

Entire proof can be extracted from model checker’s data structures

31

BLASTBLAST

LAZY

ABSTRACTION

Berkeley Lazy Abstraction Software verification Tool10K Lines of OcamlAnalyze Linux/Windows Device Drivers

CIL

(C ! CFA)

REGION

STRUCTURE

BDD Engine

(Boolean ops)

Simplify

(Post#)

Vampyre

(focus)

32

BLASTBLAST

All of C modeled except:Function pointersRecursive functions

“Logical” Model of memoryPointer arithmetic impreciseFragile on heap dependant properties

Safety checking:Checks if a given label is reachable in the C programMonitor automata specified in C

33

ExperimentsExperiments

10296751919805019361781parport.c

3.3454 465717372mouclass.c

76190.3810 3437[fixed]

1652563548

564 405412131kbflter.c

60129173954493 [fixed]

15652086 376217386floppy.c

1567875401398458517798cdaudio.c

403.33428.63 4516506tlan.c

0.0320.93 2217736aha152x.c

1790.010.52223539qpmouse.c

2530.014.5 5518131ide.c

Prf Size (bytes)

Pred. Disc. Time(sec)

Total Time(sec)

ActivePreds

TotalPreds

LinesProgram

Linux

Lock

3 state

Windows

DDK

IRP

22 state

34

ConclusionsConclusions

Lazy AbstractionReachability Tree yields certificateImplemented BLAST

Finds (only) real bugs in large device drivers … and gives proofs for correct ones !

Future work: Smarter abstractions Program analysis for model reduction Recursive functions …

35

BLASTBLAST

www.eecs.berkeley.edu/~tah/blast/www.eecs.berkeley.edu/~tah/blast/

Berkeley Lazy Abstraction Berkeley Lazy Abstraction Software * ToolSoftware * Tool

top related