Model checking Timber program. Paweł Pietrzak

Transcription

1 Model checking Timber program Paweł Pietrzak 1

2 Outline Background on model checking (spam?) The SPIN model checker An exercise in SPIN - model checking Timber Deriving finite models from Timber programs 2

3 Software verification Peer reviewing - static technique: manual code inspection, no software execution - detects between 31 and 93% of defects with median of about 60% - subtle errors (concurrency and algorithm defects) hard to catch Testing - dynamic technique in which software is executed Some figures - 30% to 50% of software project costs devoted to testing - more time and effort is spent on validation than on construction - accepted defect density: about 1 defects per 1,000 code lines 3

4 Formal verification Mathematical approach towards program correctness (Turing, 1949) Syntax-based technique for sequential programs! (Hoare, 1969) - for a given input, does a computer program generate the correct output? Syntax-based technique for concurrent programs! (Pnueli, 1977) - based on proof rules expressed in temporal logic Semantic-based approach (Cousot & Cousot 1977) - abstract interpretation - collapse abstract states with lattice Automated verification of concurrent programs (Emerson & Clarke, 1981) - model-based instead of proof-rule based approach does the concurrent program/system satisfy a given (logical) property? 4

5 The 2007 Turing Award winners Edmund E. Clarke E. Allen Emerson Joseph Sifakis 5

6 Why model checking? No proofs!!! Fast Counterexamples No problem with partial specifications Logics can easily express many concurrency properties 6

7 Model checking Computation Model: A finite-state machine (Kripke structures, timed automata, etc.) Specification Language: A propositional temporal logic. Verification Procedure: Exhaustive search of the state space of the concurrent system to determine truth of specification. 7

8 Model of computation State transition graph of Kripke Model Infinite computation tree 8

9 Model of computation Microwave oven example ~ Start ~ Close ~ Heat ~ Error Start ~ Close ~ Heat Error ~ Start Close ~ Heat ~ Error ~ Start Close Heat ~ Error Start Close ~ Heat Error Start Close ~ Heat ~ Error Start Close Heat ~ Error 9

10 What properties Safety: something bad will never happen Liveness: something good will happen(but we don t know when) Fairness: something good will happen infinitely often (under certain condition) Reachability: something ( good or bad ) can happen 10

11 Temporal Logic The oven doesn t heat up until the door is closed. Not heat_up holds until door_closed! (~ heat_up) U door_closed 11

12 Linear Temporal Logic (LTL) The symbol p is an atomic proposition, e.g. Device Enabled. p! - p holds sometime in the future (Fp). p! - p holds globally in the future. (Gp) p!- p holds next time (Xp). puq!- p holds until q holds. 12

13 Example LTL formulae Always eventually p: p (fairness) Always after p there is eventually q: (p ( q)) 13

14 Computation Tree Logic (CTL) Path qualifiers A for every path E there exists a path 14

15 Semantics by pictures E red E red A red 15 A red

16 Example LTL specs Safety - mutual exclusion (C 1 C 2 ) C 1, C 2 -critical sections; can be expressed as negation of reachability E (C 1 C 2 ) (cannot in LTL) Responsiveness (request ack) 16

17 Model checking Summary I S implementation (system model) FSM, timed automata specification (system property) CTL, CTL*, LTL satisfies, implements, refines (satisfaction relation)

18 MC in practice 90s, 00s: Industrial applications Considerable success in hardware verification (e.g. Pentium arithmetic verified) Groups in all big companies: IBM, Intel, Lucent, Microsoft, Motorola, Siemens... Many commercial and non-commercial tools: FormalCheck, PEP, SMV, SPIN... (over 30 listed in WikipediA) 18

19 The SPIN model checker [Gerard J. Holzmann 1991] 19

20 Explicit State Model Checker Represents the system as an finite state machine (no clocks) Visits each reachable state (state space) explicitly On-the-fly (the state space constructed and verified at the same time) Checks a property (LTL) Property is satisfied Counterexample Can embed C code Original application: verification of communication protocols! 20

21 Promela Roots in Process Algebra Describes the system in a way similar to a programming language Asynchronous composition of independent processes Communication using channels and global variables Non-deterministic choices and interleavings 21

22 An Example type = { NONCRITICAL, TRYING, CRITICAL }; show mtype state[2]; proctype process(int id) { beginning: noncritical: state[id] = NONCRITICAL; if :: goto noncritical; :: true; fi; trying: state[id] = TRYING; if :: goto trying; :: true; fi; critical: state[id] = CRITICAL; if :: goto critical; :: true; fi; goto beginning;} init { run process(0); run process(1); } 22 NC T C

23 Other constructs Do loops do :: count = count + 1; :: count = count - 1; :: (count == 0) -> break od 23

24 Other constructs Communication over channels proctype sender(chan out) { int x; if :: x=0; :: x=1; fi out! x; } 24

25 Other constructs Assertions proctype receiver(chan in) { int value; out? value; assert(value == 0 value == 1) } 25

26 Other constructs Atomic Steps int value; proctype increment() { atomic { x = value; x = x + 1; value = x; } } 26

27 SPIN verification Should be empty! 27

28 Software model checking 28

29 Why it is a challenge base data types Float, String, Int large/unbound recursive procedure calls / loops unbound dynamic allocations unbound number of threads dynamic communication structure 29

30 Gets even worse... External events/interrupts/exceptions/ callbacks Use of secondary storage Self-modifying code! 30

31 The approach Use static analysis to extract finite model of communication (synchronization) patterns Then, model check that model against specification 31

32 Timber program RTS Specification φ (LTL) Abstract model M in Promela SPIN model checker M φ? yes or counterexamples 32

33 Timber program RTS Specification φ (LTL) Abstract model M in Promela SPIN model checker M φ? yes or counterexamples 33

34 Timber recap object-oriented with mutable states synchronous or asynchronous messages triggering a method execution, possibly concurrent object states protected by mutual exclusion deadlines/baselines can be specified à scheduling reacts to external, events

35 Timber Synchronous messages Asynchronous messages (with or without randezvous) S:=0 sync Method A S:=S+1 B... send C async (can have after and before annotation) Method B... Method C

36 What we want to verify Responsiveness Sound communication Absence of deadlocks Schedulability... 36

37 Timber in Promela - kernel primitives c1 = class s := 0 meth11 = action... meth12 a = request... result s result c1 {..} c2 x = class meth2 = action... send x.meth11 tmp <- x.meth result c2 {..} obj1 = new c1 obj2 = new c2 obj1 Timber chan msgq = [MAXBUF] of { byte }; bool locks[nobj]; inline async(m) { ( len(msgq) < MAXBUF ) -> msgq!m } inline lock(obj) { atomic { locks[obj] == 0 -> locks[obj] = 1} } inline unlock(obj){ locks[obj]=0; } inline dispatch(m){ if :: (m==m11) -> run meth11() :: (m==m2) -> run meth2() fi } active proctype loop() { msg m; do :: msgq?m -> dispatch(m) od } Promela

38 Timber in Promela - user program c1 = class s := 0 meth11 = action... meth12 a = request... result s result c1 {..} c2 x = class meth2 = action... send x.meth11 tmp <- x.meth result c2 {..} obj1 = new c1 obj2 = new c2 obj1 Timber proctype meth11() { lock(o1); crit1++; assert(crit1 == 1); crit1--; unlock(o1); } inline meth12() { lock(o1); /* some code */ unlock(o1); } proctype meth2() { lock(o2); async(m11); meth12(); unlock(o2); } /* external stimuli */ active proctype stimuli() { do :: async(m11) :: async(m2) od } Promela

39 We need to know at compile-time c1 = class s := 0 meth11 = action... meth12 a = request... result s result c1 {..} c2 x = class meth2 = action... send x.meth11 tmp <- x.meth result c2 {..} obj1 = new c1 obj2 = new c2 obj1 Timber proctype meth11() { lock(o1); crit1++; assert(crit1 == 1); crit1--; unlock(o1); } inline meth12() { lock(o1); /* some code */ unlock(o1); } proctype meth2() { lock(o2); async(m11); meth12(); unlock(o2); } /* external stimuli */ active proctype stimuli() { do :: async(m11) :: async(m2) od } Promela

40 Timber and static evaluation of functions in collaboration with Johan Nordlander 40

41 Timber program RTS Specification φ (LTL) Abstract model M in Promela SPIN model checker M φ? yes or counterexamples 41

42 The problem To determine at compile-time - which objects will be created at runtime - which of these objects are locked by tasks and what are the patterns of the locking In general undecidable, but for embedded applications a suitable solution exists. 42

43 Key observations For typical embedded applications: - Objects often correspond to physical components, and thus are created at top-level (root) or at initialization parts of already created objects. - Tasks, their deadlines*, and communication structure between often tasks can be statically determined. We can infer the needed information if certain expressions at functional layer can be statically evaluated. * Original motivation for this work was SRP schedulability analysis 43

44 The analysis Traverse abstract syntax of the program, and evaluate expressions as much as possible at compile-time: Eval[[E]] computes a value of E if it can, or unknown, otherwise 44

45 Some internals of the analysis The main idea due to [Might&Van Horn 2010] Abstract interpretation - a computable approximation of program s semantics Based on CESK* abstract machine - an idealized low-level model of an interpreter - a state transition system S S 45

46 The main idea state: E,ρ, σ,c expression environment store continuation cycles causing termination problems can be present in value closures or continuations both go to store 46

47 The main idea state: E,ρ, σ,c expression environment store continuation by assuring Addr to be finite we make the whole analysis terminate single abstraction point = the store 47

48 The complete machine... 48

49 Static value analysis Eval[[E]] = V iff E,[], [], mt V,,, mt 49

50 Discussion Deriving the communication structure is an absraction Is the abstraction sound/complete w.r.t. a given LTL property? 50

51 Future work Static evaluation is an ongoing work; immediate todo s: - finishing off description of the analysis - implementation (partly done) Model checking Timber/Timber-like programs - Study properties of the abstraction - Uppaal could be used as well - Could Combined with WCET info for basic blocks and max sizes of state variables - Could include internal computation into the PROMELA/Uppaal model 51