Runtime Safety Analysis of Multithreaded Programs

1. Runtime Safety Analysis of Multithreaded Programs Koushik Sen University of Illinois at Urbana-Champaign, USA Co-authors Grigore Rosu and Gul Agha

2. Talk Overview • Motivation • MultiPathExplorer • Motivating example • Instrumentation based on vector clocks • Predict specification violations at runtime • System architecture • Further Applications • Conclusion and Future Work

3. Increasing Software Reliability • Current solutions • Human review of code and testing • Most used in practice • Usuallyad-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

4. 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

5. 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

6. Talk Overview • Motivation • MultiPathExplorer • Motivating example • Instrumentation based on vector clocks • Predict specification violations at runtime • System architecture • Further Applications • Conclusion and Future Work

7. MultiPathExplorer – JMPaX (Java) • Based on smart observers • Smartnessobtained 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

8. Motivating Example “Safe Landing” Safe Landing Land the air/space craft only after approval from ground and 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, Radio

9. Code of a Landing Controller • Two threaded program to control landing intlanding = 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(); } }

10. radio = 0 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

11. Talk Overview • Motivation • MultiPathExplorer • Motivating example • Instrumentation based on vector clocks • Predict specification violations at runtime • System architecture • Further Applications • Conclusion and Future Work

12. 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 sharedvariable or, • write of a sharedvariable. • eijrepresents the jth event generated by thread pisince the start of its execution.

13. i eik Á eil e’ i x j e Causality in Multithreaded Programs • Define the partial orderÁ on the set of events as follows: • eikÁ eil 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''.

14. 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.

15. Vector Clock Algorithm • Let Vi be an n-dimensional vector of natural numbers for each thread pi. • Let Vxa and Vxw be vectors for each shared variable x. • if eik is relevant, i.e., if eik2 R, then • Vi[i] à Vi[i] + 1 • if eik is a read of a variable x then • Vià max{Vi,Vxw} • Vxaà max{Vxa,Vi} • if eikis a write of a variable x then • Vxw à Vxa à Vi à max{Vxa,Vi} • if eikis relevant then • send message h eik, i, Vii to observer.

16. Write Read i i x(a) x(a) x(w) x(w) Correspondence with Standard Vector Clocks

17. 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‘

18. thread T1 { x++; ... y = x + 1; } thread T2 { z = x + 1; ... x++; } e1: hx =0,T1, (1,0) i e3: hy =1,T1, (2,0) i T1 T2 e2: hz =1,T2, (1,1) i e4: hx =1,T2, (1,2) i Example with Two Threads (initially x = -1)

19. Relevant Global State • The program state after the events ek11,ek22,...,eknn is called a relevant global multithreaded stateor 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.

20. 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)

21. 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

22. thread T1 { x++; ... y = x + 1; } thread T2 { z = x + 1; ... x++; } Example Revisited

23. 0,0 x = -1, y = 0, z = 0 e1 : h x=0,T1, (1,0) i 1,0 x = 0, y = 0, z = 0 e3 : h y=1,T1, (2,0) i e2 : h z=1,T2, (1,1) i 2,0 x = 0, y = 1, z = 0 1,1 x = 0, y = 0, z = 1 e3 : h y=1,T1, (2,0) i e2 : h z=1,T2, (1,1) i e4 : h x=1,T2, (1,2) i 2,1 x = 0, y = 1, z = 1 1,2 x = 1, y = 0, z = 1 e3 : h y=1,T1, (2,0) i e4 : h x=1,T2, (1,2) i 2,2 x = 1, y = 1, z = 1 Monitoring Safety Formula (x > 0) ! [(y = 0), (y > z))s

24. 0,0 x = -1, y = 0, z = 0 e1 : h x=0,T1, (1,0) i 1,0 x = 0, y = 0, z = 0 e3 : h y=1,T1, (2,0) i e2 : h z=1,T2, (1,1) i 2,0 x = 0, y = 1, z = 0 1,1 x = 0, y = 0, z = 1 e3 : h y=1,T1, (2,0) i e2 : h z=1,T2, (1,1) i e4 : h x=1,T2, (1,2) i 2,1 x = 0, y = 1, z = 1 1,2 x = 1, y = 0, z = 1 e3 : h y=1,T1, (2,0) i e4 : h x=1,T2, (1,2) i 2,2 x = 1, y = 1, z = 1 Safety Violation in a Possible Run (x > 0) ! [(y = 0), (y > z))s

25. Talk Overview • Motivation • MultiPathExplorer • Motivating example • Instrumentation based on vector clocks • Predict specification violations at runtime • System architecture • Further Applications • Conclusion and Future Work

26. 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.

27. Algorithm Pseudocode for each (e 2Q) { 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); } }

28. 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

29. s00 s00 s00 s00 s11 s11 s12 s12 s21 s21 s21 s21 s31 s32 s31 s32 s41 s41 s41 s41 Reason for Efficiency s00 s11 s12 s21 s31 s32 s41

30. Specification Java multithreaded program Translator LTL monitor Instrumentor Bytecode Instrumented code SpecificationImpl Events JVM JMPaX Architecture

31. Further Applications • Security • Security policies as safety requirements • Predict safety violations efficiently! communicate(A,B,K)   (sendKey(S,(A,B),K) requestKey(S,A,B))

32. 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.

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).