verifying regular behavior of c modules

26
Verifying Regular Behavior of C modules Sagar Chaki, Edmund Clarke, Alex Groce, CMU Somesh Jha, Wisconsin

Upload: sofia

Post on 07-Jan-2016

22 views

Category:

Documents


0 download

DESCRIPTION

Verifying Regular Behavior of C modules. Sagar Chaki, Edmund Clarke, Alex Groce, CMU Somesh Jha, Wisconsin. Regular Behavior. Expressed as Finite Labeled Transition Systems ( FLTS ) Locking protocols We use the FSP syntax to describe FLTSs - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Verifying Regular Behavior of C modules

Verifying Regular Behavior of C modules

Sagar Chaki, Edmund Clarke, Alex Groce, CMU

Somesh Jha, Wisconsin

Page 2: Verifying Regular Behavior of C modules

Regular Behavior• Expressed as Finite Labeled Transition

Systems (FLTS)- Locking protocols

• We use the FSP syntax to describe FLTSs- Concurrency: State Models and Java Programs –

Jeff Magee, Jeff Kramer - Wiley

Page 3: Verifying Regular Behavior of C modules

Regular Behavior: LockUnlock• U = (lock -> L | return -> S),

L = (unlock -> U).

U Llock

unlock

S

return

Page 4: Verifying Regular Behavior of C modules

C Module: PCI device drivervoid example() {

do {

KeAcquireSpinLock(); //event lock

nPackets = nPacketsOld;

if(cond) {

KeReleaseSpinLock(); //event unlock

nPackets++;

}

} while(nPackets != nPacketsOld);

KeReleaseSpinLock(); //event unlock

}

Page 5: Verifying Regular Behavior of C modules

Our Goal• To show that LockUnlock simulates the PCI

driver- Need to keep track of the predicate (nPackets ==

nPacketsOld)- Flow-insensitive analysis will fail

• Provide diagnostic feedback in case the simulation does not exist

Page 6: Verifying Regular Behavior of C modules

POSIX pthread Spec• pthread_mutex_lock()

- Acquires lock and returns 0- Increments user count on lock and returns 0- Returns non-zero error code

U

U

U

U

ret_err

ret_zerolock

inc_count

Page 7: Verifying Regular Behavior of C modules

Glibc pthread source codeint pthread_mutex_lock() {

case PTHREAD_MUTEX_RECURSIVE_NP:

self = thread_self();

if (mutex->__m_owner == self) {

mutex->__m_count++; //inc_count

return 0; //ret_zero

}

pthread_lock(&mutex->__m_lock, self); //lock

mutex->__m_owner = self;

mutex->__m_count = 0;

return 0; } //ret_zero

Page 8: Verifying Regular Behavior of C modules

C module• Collection of C procedure definitions

- The pthread library

• Designated main procedure- The pthread_mutex_lock function- We are interested in behavior observed during an

invocation of main

Page 9: Verifying Regular Behavior of C modules

C module• For each procedure called, one of two things

must be available

- Definition of procedure

- Information about behavior observed during invocation of procedure

Page 10: Verifying Regular Behavior of C modules

Verification• Check that every possible behavior of main is

also a behavior of the FLTS- Trace-containment

• In practice it is sufficient to check for a stronger condition viz. simulation- FLTS ≥ main

Page 11: Verifying Regular Behavior of C modules

FLTS: Definition• Fix an alphabet: Σ

- Assume Σ contains special symbol ε

• Three-tuple: <Q,I,δ>- Q: finite set of states- I: initial state- δ: transition relation over Q X Σ X Q

Page 12: Verifying Regular Behavior of C modules

Example

U’ L’

lock

S’

return

V’ε

M’ε

unlock

Page 13: Verifying Regular Behavior of C modules

Simulation• FLTSs: <Q1,I1,δ1>,<Q2,I2,δ2>• Relation ≥ Q1 X Q2 is simulation if

(1) Init: For all t Є I2 exists s Є I1 s.t. s ≥ t

(2) Step: s ≥ t and (t,a,t’) Є δ2 => exists s’ s.t. (s,a,s’) Є δ1 and s’ ≥ t’

(3) Stutter: s ≥ t and (t,ε,t’) Є δ2 => s ≥ t’ OR exists s’ s.t. (s,ε,s’) Є δ1 and s’ ≥ t’

Page 14: Verifying Regular Behavior of C modules

Overall method• Step 1: Compute relation R that satisfies

conditions 2 and 3

• Step 2: Check that R satisfies condition 1 as well

Page 15: Verifying Regular Behavior of C modules

Step 1• Start with R = Q1 X Q2

• Iteratively refine R using condition 2 and 3 till a fixed point is reached- If (s,t) Є R and if (t,a,t’) Є δ2 then remove (s,t) if

there does not exist s’ s.t. (s,a,s’) Є δ1 and (s’,t’) Є R

Page 16: Verifying Regular Behavior of C modules

Example

U’ L’

lock

S’

return

V’ε

M’ε

unlock

{U,L,S}

{U,L,S}

{U,L,S}

{U,L,S}

{U,L,S}

lockU L

unlock

Sreturn

Page 17: Verifying Regular Behavior of C modules

Example

U’ L’

lock

S’

return

V’ε

M’ε

unlock

{U}

{U,L,S}

{U,L,S}

{U,L,S}

{U,L,S}

lockU L

unlock

Sreturn

Page 18: Verifying Regular Behavior of C modules

Example

U’ L’

lock

S’

return

V’ε

M’ε

unlock

{U}

{U}

{U,L,S}

{U,L,S}

{U,L,S}

lockU L

unlock

Sreturn

Page 19: Verifying Regular Behavior of C modules

Example

U’ L’

lock

S’

return

V’ε

M’ε

unlock

{U}

{U}

{U,L,S}

{L}

{U,L,S}

lockU L

unlock

Sreturn

Page 20: Verifying Regular Behavior of C modules

Example

U’ L’

lock

S’

return

V’ε

M’ε

unlock

{U}

{U}

{L}

{L}

{U,L,S}

lockU L

unlock

Sreturn

Page 21: Verifying Regular Behavior of C modules

FLTS from C module• Based on a set of predicates

• Each state of the FLTS consists of a control location of the C module and a valuation to the predicates- Non-context-sensitive

• Weakest preconditions and theorem proving are used to compute the transitions on-the-fly

Page 22: Verifying Regular Behavior of C modules

Predicates and Property• Need to specify predicates to be used

- predicate (nPackets == nPacketsOld);

• Need to specify the simulation relation to be checked- property U simulates example;

Page 23: Verifying Regular Behavior of C modules

Additional Info• Specify that call to KeAcquireSpinLock()

represents a locking action- action call KeAcquireSpinLock = lock;

• Similarly for KeReleaseSpinLock()- action call KeReleaseSpinLock = unlock;

Page 24: Verifying Regular Behavior of C modules

Related Work• Based on predicate abstraction

- Graf & Saidi, Dill et. al.• Do not work with C

- SLAM, Bandera

• Specify desired behavior as patterns, or unwanted behavior as monitors- Engler et. al., SLAM, Bandera

Page 25: Verifying Regular Behavior of C modules

Challenges• Extract event information from C code• Provide diagnostic feedback in case

simulation is not found• Pointers and dynamic memory allocation• Introduce context-sensitivity• Introduce concurrency

Page 26: Verifying Regular Behavior of C modules

Major Differences• Unlike Engler et. al.

- Flow-sensitive, based on predicates- Check arbitrary regular behavior

• Unlike SLAM- On-the-fly: no boolean programs- Not context-sensitive

• Unlike Bandera- Work with C- Check arbitrary regular behavior