runtime safety analysis of multithreaded programs

Runtime Safety Analysis of Multithreaded Programs

Koushik SenUniversity of Illinois at

Urbana-Champaign, USA

Co-authors Grigore Rosu and Gul Agha

04/19/232/33

JMPaX: http://fsl.cs.uiuc.edu/jmpax/

Talk Overview

Motivation

MultiPathExplorer Motivating example

Instrumentation based on vector clocks

Predict specification violations at runtime

System architecture

Further Applications

Conclusion and Future Work

04/19/233/33


Increasing Software Reliability

Current solutions Human review of code and testing

Most used in practice Usually ad-hoc, intensive human support

(Advanced) Static analysis Often scales up False positives and negatives, annotations

(Traditional) Formal methods Model checking and theorem proving General, good confidence, do not always scale up

04/19/234/33


Runtime Verification

Merge testing and temporal logic specification Specify safety properties

in proper temporal logic.

Monitor safety properties against a run of the program.

Examples: JPaX (NASA Ames), Upenn's Java MaC analyzes the observed run.

Disadvantage: Lack of coverage.

Run

Naïve Observer

04/19/235/33


Our Approach: Smart Observer

Ideas A single execution trace

contains more information than appears at first sight

Extract other possible runs from a single execution

Analyze all these runs intelligently.

A technique between model checking and testing.

Run

Smart Observer

04/19/236/33


Talk Overview

Motivation




System architecture



04/19/237/33


MultiPathExplorer – JMPaX (Java)

Based on smart observers

Smartness obtained by proper instrumentation: vector clocks

Possible global states generated dynamically form a lattice

Analysis is performed on a level-by-level basis in the lattice of global states

04/19/238/33


Motivating Example “Safe Landing”

Safe LandingLand the air/space craft only after approval from groundand only if, since then, the radio signal has not been lost

Safe LandingLand the air/space craft only after approval from groundand only if, since then, the radio signal has not been lost

Three variables: Landing indicating air/space craft is landing Approved indicating landing has been approved Radio indicating radio signal is live

Landing Approved, RadioLanding Approved, Radio

04/19/239/33


Code of a Landing Controller Two threaded program to control landing

int landing = 0, approved = 0, radio = 1;

void thread1() { askLandingApproval(); if (approved == 1) { print("Landing approved"); landing=1; print("Landing started") } else { print("Landing not approved") } }

void askLandingApproval() { if (radio == 1) { approved = 1 } else { approved = 0} }

void thread2() { while (true) { checkRadio(); } }

04/19/2310/33


Landing Safety Violation

Suppose the plane has received approval for landing and just before it started landing the radio signal went off the plane must abort landing!

A simple observer will most likely not detect the bug.

JMPaX can construct a possible run in which radio goes off between approval and landing

approved = 1

landing = 1

radio = 0

04/19/2311/33


Talk Overview

Motivation




System architecture



04/19/2312/33


Events in Multithreaded Programs

Given n threads p1, p2, ..., pn,

A multithreaded execution is a sequence of events e1 e2 … er of type:

internal or,

read of a shared variable or,

write of a shared variable.

eij represents the jth event generated by

thread pi since the start of its execution.

04/19/2313/33


Causality in Multithreaded Programs

Define the partial order Á on the set of events as follows:

eik Á ei

l if k < l;

e Á e' if there is some x 2 S such that e <x e' and at least one of e, e‘ is a write.

e Á e'' if e Á e' and e' Á e''.

eik Á ei

l

i

x

i

j e

e’

04/19/2314/33


Vector Clocks and Relevant Events

Consider a subset R of relevant events.

(typically those writing specification’s variables)

R-relevant causality is a relation C µ Á C is a projection of Á on R £ R.

We provide a technique based on vector clocks that correctly implements the relevant causality relation.

04/19/2315/33


Vector Clock Algorithm

Let Vi be an n-dimensional vector of natural numbers for each thread pi.

Let Vxa and Vx

w be vectors for each shared variable x.

1. if eik is relevant, i.e., if ei

k 2 R, then Vi[i] Ã Vi[i] + 1

2. if eik is a read of a variable x then

Vi Ã max{Vi,Vxw}

Vxa Ã max{Vx

a,Vi}

3. if eik is a write of a variable x then

Vxw Ã Vx

a Ã Vi Ã max{Vxa,Vi}

4. if eik is relevant then

send message h eik, i, Vi i to observer.

04/19/2316/33


Correspondence with Standard Vector Clocks

i x(a) x(w)

Write

i x(a) x(w)

Read

04/19/2317/33


Implementing Causality by Vector Clocks

Theorem: If he, i, Vi and he', j, V' i are messages sent by our algorithm, then

e C e' iff V[i] · V'[i]

If i and j are not given, then

e C e' iff V < V‘

04/19/2318/33


Example with Two Threads

thread T1 {

x++;

...

y = x + 1;

}

thread T2 {

z = x + 1;

...

x++;

}

T1

T2

e1: hx =0,T1, (1,0) i e3: hy =1,T1, (2,0) i

e4: hx =1,T2, (1,2) i e2: hz =1,T2, (1,1) i

(initially x = -1)

04/19/2319/33


Relevant Global State

The program state after the events ek1

1,ek22,...,ekn

n is called a relevant global multithreaded state or simply a state.

A state k1 k2 … kn is called consistent if and only if it can be seen in some possible run of the system.

04/19/2320/33


MultiThreaded Run

e1e2 … e|R| is a multithreaded run iff it generates a sequence of global states K0 K1 … K|R| such that

each Kr is consistent and

Kr after event er becomes Kr+1.

(consecutive states)

04/19/2321/33


Computation Lattice

We say À ' when there is some run in which and ' are consecutive states

Consistent global states together with the transitive closure of À form a lattice

Multithreaded runs are paths in the lattice

04/19/2322/33


Example Revisited

thread T1 {

x++;

...

y = x + 1;

}

thread T2 {

z = x + 1;

...

x++;

}

04/19/2323/33


Monitoring Safety Formula

e1 : h x=0,T1, (1,0) i

e2 : h z=1,T2, (1,1) i e3 : h y=1,T1, (2,0) i

e2 : h z=1,T2, (1,1) i e3 : h y=1,T1, (2,0) i

e4 : h x=1,T2, (1,2) i

e3 : h y=1,T1, (2,0) i e4 : h x=1,T2, (1,2) i

0,0

x = -1, y = 0, z = 0

2,2

x = 1, y = 1, z = 1

1,2

x = 1, y = 0, z = 1

2,1

x = 0, y = 1, z = 1

2,0

x = 0, y = 1, z = 0

1,1

x = 0, y = 0, z = 1

1,0

x = 0, y = 0, z = 0

(x > 0) ! [(y = 0), (y > z))s

04/19/2324/33


Safety Violation in a Possible Run

e1 : h x=0,T1, (1,0) i

e2 : h z=1,T2, (1,1) i e3 : h y=1,T1, (2,0) i

e2 : h z=1,T2, (1,1) i e3 : h y=1,T1, (2,0) i

e4 : h x=1,T2, (1,2) i

e3 : h y=1,T1, (2,0) i e4 : h x=1,T2, (1,2) i

0,0

x = -1, y = 0, z = 0

2,2

x = 1, y = 1, z = 1

1,2

x = 1, y = 0, z = 1

2,1

x = 0, y = 1, z = 1

2,0

x = 0, y = 1, z = 0

1,1

x = 0, y = 0, z = 1

1,0

x = 0, y = 0, z = 0

(x > 0) ! [(y = 0), (y > z))s

04/19/2325/33


Talk Overview

Motivation




System architecture



04/19/2326/33


Safety Against All Runs

Number of possible runs can be exponential

Traverse the state lattice level by level Avoids analyzing an exponential number of runs

Maintain a queue of events Enqueue an event as soon as it arrives

Construct a new level from the set of states in the previous level and the events in the queue

Monitor safety formula against all states in a level using dynamic programming and intelligent merging.

04/19/2327/33


Algorithm Pseudocode

for each (e 2 Q) {

if exists s 2 CurrentLevel s.t. isNextState(s,e) then

NextLevel Ã addToSet(NextLevel,createState(s,e));

if isUnnecessary(s) then

remove(s,CurrentLevel);

if isEmpty(CurrentLevel) then {

monitorAll(NextLevel);

CurrentLevel Ã NextLevel; NextLevel Ã {};

Q Ã removeUnnecessaryEvents(CurrentLevel,Q);

}

}

04/19/2328/33


Complexity

Time complexity is O(w.2m.n) w – width of the lattice m – size of the formula n – length of the run

Memory used is O(w.2m’) w – width of the lattice m’ – number of temporal operators in the

formula

Further optimizations Consider bounded width w of queue Q

04/19/2329/33


Reason for Efficiency

s00

s41

s32s31

s21

s12s11

s00

s11

s21

s31

s41

s00

s12

s21

s31

s41

s00

s11

s21

s32

s41

s00

s12

s21

s32

s41

04/19/2330/33


JMPaX Architecture

Java multithreaded

program

Bytecode

Specification

Instrumentor

Instrumented code

JVM

Translator

LTL monitor

SpecificationImpl

Events

04/19/2331/33



Security Security policies as safety requirements

Predict safety violations efficiently!

communicate(A,B,K) (sendKey(S,(A,B),K) requestKey(S,A,B))

04/19/2332/33


Contributions

Introduce vector clock algorithm in multithreaded systems to capture relevant causality.

Efficiently Predict safety errors from successful runs.

A modular implementation of the above ideas in a analysis tool, JMPaX. http://fsl.cs.uiuc.edu/jmpax/ for JMPaX

prototype.

04/19/2333/33


Future Work

Evaluate JMPaX on real, large applications Develop predictive algorithms for other

requirements specification logics Consider a superset of partial order to

gain efficiency Find more scalable techniques that can

fill the gap between model checking and testing

Integrate with NASA Ames’ Java PathExplorer Tool (JPaX).

runtime safety analysis of multithreaded programs

Documents