Lecture 1: Model Checking. Edmund Clarke School of Computer Science Carnegie Mellon University

Transcription

1 Lecture 1: Model Checking Edmund Clarke School of Computer Science Carnegie Mellon University 1

2 Cost of Software Errors June 2002 Software bugs, or errors, are so prevalent and so detrimental that they cost the U.S. economy an estimated $59.5 billion annually, or about 0.6 percent of the gross domestic product At the national level, over half of the costs are borne by software users and the remainder by software developers/vendors. NIST Planning Report 02-3 The Economic Impacts of Inadequate Infrastructure for Software Testing 2

3 Cost of Software Errors The study also found that, although all errors cannot be removed, more than a third of these costs, or an estimated $22.2 billion, could be eliminated by an improved testing infrastructure that enables earlier and more effective identification and removal of software defects. 3

4 Model Checking Developed independently by Clarke and Emerson and by Queille and Sifakis in early 1980 s. Properties are written in propositional temporal logic. Systems are modeled by finite state machines. Verification procedure is an exhaustive search of the state space of the design. Model checking complements testing/simulation. 4

5 Advantages of Model Checking No proofs!!! Fast (compared to other rigorous methods) Diagnostic counterexamples No problem with partial specifications / properties Logics can easily express many concurrency properties 5

6 Model of computation Microwave Oven Example State-transition graph describes system evolving over time. st ~ 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 6

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

8 Basic Temporal Operators The symbol p is an atomic proposition, e.g. heat_up or door_closed. Fp Gp Xp puq - p holds sometime in the future. - p holds globally in the future. - p holds next time. - p holds until q holds. 8

9 Model Checking Problem Let M be a model, i.e., a state-transition graph. Let ƒ be the property in temporal logic. Find all states s such that M has property ƒ at state s. Efficient Algorithms: CE81, CES83 9

10 The EMC System 1982/83 Preprocessor Model Checker (EMC) Properties State Transition Graph 10 4 to 10 5 states True or Counterexamples 10

11 Model Checker Architecture System Description Formal Specification State Explosion Problem!! Validation or Counterexample Model Checker 11

12 The State Explosion Problem System Description Combinatorial explosion of system states renders explicit model construction infeasible. State Transition Graph Exponential Growth of global state space in number of concurrent components. memory states in memory size. Feasibility of model checking inherently tied to handling state explosion. 12

13 Combating State Explosion Binary Decision Diagrams can be used to represent state transition systems more efficiently. à Symbolic Model Checking 1992 Semantic techniques for alleviating state explosion: Partial Order Reduction. Abstraction. Compositional reasoning. Symmetry. Cone of influence reduction. Semantic minimization. 13

14 Model Checking since Clarke / Emerson: CTL Model Checking Sifakis / Quielle 1982 EMC: Explicit Model Checker Clarke, Emerson, Sistla Symbolic Model Checking Burch, Clarke, Dill, McMillan 1992 SMV: Symbolic Model Verifier McMillan 1990s: Formal Hardware Verification in Industry: Intel, IBM, Motorola, etc Bounded Model Checking using SAT Biere, Clarke, Zhu 2000 Counterexample-guided Abstraction Refinement Clarke, Grumberg, Jha, Lu, Veith

15 Model Checking since Clarke / Emerson: CTL Model Checking Sifakis / Quielle 1982 EMC: Explicit Model Checker Clarke, Emerson, Sistla 1990 Symbolic Model Checking Burch, Clarke, Dill, McMillan 1992 SMV: Symbolic Model Verifier McMillan 1998 Bounded Model Checking using SAT Biere, Clarke, Zhu 2000 Counterexample-guided Abstraction Refinement Clarke, Grumberg, Jha, Lu, Veith CBMC MAGIC 15

16 Grand Challenge: Model Check Software! What makes Software Model Checking different? 16

17 What Makes Software Model Checking Different? Large/unbounded base types: int, float, string User-defined types/classes Pointers/aliasing + unbounded # s of heapallocated cells Procedure calls/recursion/calls through pointers/ dynamic method lookup/overloading Concurrency + unbounded # s of threads 17

18 What Makes Software Model Checking Different? Templates/generics/include files Interrupts/exceptions/callbacks Use of secondary storage: files, databases Absent source code for: libraries, system calls, mobile code Esoteric features: continuations, self-modifying code Size (e.g., MS Word = 1.4 MLOC) 18

19 Grand Challenge: Model Check Software! Early attempts in the 1980s failed to scale. 2000s: renewed interest / demand: Java Pathfinder: NASA Ames SLAM: Microsoft Bandera: Kansas State BLAST: Berkeley SLAM to be shipped to Windows device driver developers. In general, these tools are unable to handle complex data 19 structures and concurrency.

20 The MAGIC Tool: Counterexample-Guided Abstraction Refinement Memory State Memory State Memory State Memory State Memory State Memory State Memory State Memory State Abstraction Abstract Memory Abstract State Memory State Abstraction maps classes of similar memory states to single abstract memory states. + Model size drastically reduced. - Invalid counterexamples possible. 20

21 The MAGIC Tool: Counterexample-Guided Abstraction Refinement C Program Abstraction Guidance Abstraction Improved Abstraction Guidance Abstract Model Verification No Yes System OK Abstraction Refinement No Counterexample Valid? Yes 21

22 CBMC: Embedded Systems Verification Method: Bounded Model Checking Implemented GUI to facilitate tech transfer Applications: Part of train controller from GE Cryptographic algorithms (DES, AES, SHS) C Models of ASICs provided by nvidia 22

23 Case Study: Verification of MicroC/OS Real-Time Operating System About 6000 lines of C code Used in commercial embedded systems UPS, Controllers, Cell-phones, ATMs Required mutual exclusion in the kernel OS_ENTER_CRITICAL() and OS_EXIT_CRITICAL() MAGIC and CBMC: Discovered one unknown bug related to the locking discipline Discovered three more bugs Verified that no similar bugs are present 23