Verifying regular behavior of c modules
This presentation is the property of its rightful owner.
Sponsored Links
1 / 26

Verifying Regular Behavior of C modules PowerPoint PPT Presentation


  • 43 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Verifying Regular Behavior of C modules

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Verifying regular behavior of c modules

Verifying Regular Behavior of C modules

Sagar Chaki, Edmund Clarke, Alex Groce, CMU

Somesh Jha, Wisconsin


Regular behavior

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


Regular behavior lockunlock

lock

U

L

unlock

return

S

Regular Behavior: LockUnlock

  • U = (lock -> L | return -> S),

    L = (unlock -> U).


C module pci device driver

C Module: PCI device driver

void example() {

do {

KeAcquireSpinLock();//event lock

nPackets = nPacketsOld;

if(cond) {

KeReleaseSpinLock();//event unlock

nPackets++;

}

} while(nPackets != nPacketsOld);

KeReleaseSpinLock();//event unlock

}


Our goal

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


Posix pthread spec

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

lock

ret_zero

U

inc_count

U

ret_err


Glibc pthread source code

Glibc pthread source code

int 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


C module

C module

  • Collection of C procedure definitions

    • The pthread library

  • Designated mainprocedure

    • The pthread_mutex_lock function

    • We are interested in behavior observed during an invocation of main


C module1

C module

  • For each procedure called, one of two things must be available

    • Definition of procedure

    • Information about behavior observed during invocation of procedure


Verification

Verification

  • Check that every possible behavior of mainis also a behavior of the FLTS

    • Trace-containment

  • In practice it is sufficient to check for a stronger condition viz. simulation

    • FLTS ≥ main


Flts definition

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


Example

V’

lock

ε

L’

U’

unlock

ε

return

M’

S’

Example


Simulation

Simulation

  • FLTSs: <Q1,I1,δ1>,<Q2,I2,δ2>

  • Relation ≥ Q1 X Q2 is simulation if

    • Init: For all t Є I2 exists s Є I1 s.t. s ≥ t

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

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


Overall method

Overall method

  • Step 1: Compute relation R that satisfies conditions 2 and 3

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


Step 1

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


Example1

U

L

unlock

return

S

Example

lock

{U,L,S}

V’

lock

{U,L,S}

{U,L,S}

ε

L’

U’

unlock

ε

return

M’

S’

{U,L,S}

{U,L,S}


Example2

U

L

unlock

return

S

Example

lock

{U,L,S}

V’

lock

{U,L,S}

{U}

ε

L’

U’

unlock

ε

return

M’

S’

{U,L,S}

{U,L,S}


Example3

U

L

unlock

return

S

Example

lock

{U}

V’

lock

{U,L,S}

{U}

ε

L’

U’

unlock

ε

return

M’

S’

{U,L,S}

{U,L,S}


Example4

U

L

unlock

return

S

Example

lock

{U}

V’

lock

{U,L,S}

{U}

ε

L’

U’

unlock

ε

return

M’

S’

{L}

{U,L,S}


Example5

U

L

unlock

return

S

Example

lock

{U}

V’

lock

{L}

{U}

ε

L’

U’

unlock

ε

return

M’

S’

{L}

{U,L,S}


Flts from c module

FLTS from C module

  • Based on a set of predicates

  • Each state of the FLTS consists of a controllocation of the C module and a valuation to the predicates

    • Non-context-sensitive

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


Predicates and property

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;


Additional info

Additional Info

  • Specify that call to KeAcquireSpinLock() represents a locking action

    • action call KeAcquireSpinLock = lock;

  • Similarly for KeReleaseSpinLock()

    • action call KeReleaseSpinLock = unlock;


Related work

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


Challenges

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


Major differences

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


  • Login