Multi-Threaded System int x, y, r; int p, q, *z; int **a; EEC 421/521: Software Engineering. Thread Interleaving SPIN. Model Checking using SPIN

Size: px

Start display at page:

Download "Multi-Threaded System int x, y, r; int *p, *q, *z; int **a; EEC 421/521: Software Engineering. Thread Interleaving SPIN. Model Checking using SPIN"

Blake Simpson
6 years ago
Views:

EEC 421/521: Software Engineering Model Checking using SPIN 4/29/08 EEC 421/521: Software Engineering 1 Multi-Threaded System int x, y, r; int *p, *q, *z; int **a; thread_1(void) /* initialize p, q,

1 EEC 421/521: Software Engineering Model Checking using SPIN 4/29/08 EEC 421/521: Software Engineering 1 Multi-Threaded System int x, y, r; int *p, *q, *z; int **a; thread_1(void) /* initialize p, q, and r */ p = &x; q = &y; z = &r; thread_2(void) /* swap contents of x and y */ r = *p; *p = *q; *q = r; thread_3(void) /* access z via a and p */ a = &p; *a = z; **a = 12;! asynchronous threads accessing shared data! statements each how many test runs are needed to check that no data corruption can occur? 4/29/08 EEC 421/521: Software Engineering 3 SPIN Simple Promela INterpreter LTL model checking tool Simulator and verifier Uses an automata-theoretic approach Directly targets software 2001 ACM Software Systems Award Distributed freely as research tool, well-documented, actively maintained, growing user-base, users in both academia and industry Thread Interleaving The number of possible thread interleavings is... Placing 3 sets of 3 tokens in 9 slots Are all these executions okay? Can we check them all? should we check them all? In classic system testing, how many would normally be checked? 4/29/08 EEC 421/521: Software Engineering 2 4/29/08 EEC 421/521: Software Engineering 4

SPIN Verification Models Spin verification models are used to define abstractions of distributed system designs The specification language must support all essential aspects of distributed systems

Global and local data objects Message channels 4/29/08 EEC 421/521: Software Engineering 5 PROMELA Process Meta Language Language for expressing and specifying verification models Focus on expressing

2 SPIN Verification Models Spin verification models are used to define abstractions of distributed system designs The specification language must support all essential aspects of distributed systems software, and discourage the specification of any redundant detail (not bearing on things that are provable) There are 3 basic types of objects in a Spin verification model: Asynchronous processes Global and local data objects Message channels 4/29/08 EEC 421/521: Software Engineering 5 PROMELA Process Meta Language Language for expressing and specifying verification models Focus on expressing communication and coordination across multiple processes No emphasis on computation No expressions with side effects No functions that return values No data and function pointers 4/29/08 EEC 421/521: Software Engineering 7 How SPIN works System: L(S) [the set of possible behaviors of S] Property: L(p) [the set of valid/desirable behaviors] Prove that: L(S)! L(p) [everything possible is valid] Method: Prove L(S) " L( (p)) = # If intersection I is empty, then S satisfies P If intersection I is non-empty, then S can violate P (and I contains at least one counter-example to prove that) Types of Objects Processes Instantiations of proctypes There must be at least one proctype in each model Process types are always declared globally Data objects Can be declared globally or process locally Message channels Used for communication across process types 4/29/08 EEC 421/521: Software Engineering 6 4/29/08 EEC 421/521: Software Engineering 8

3 Processes Finite Systems active [2] proctype you_run() printf( My pid is: %d\n, _pid) $ spin you_run.pml My pid is: 1 My pid is: 0 2 processes created Active processes are instantiated upon initiation Each process has a unique process id (_pid) 4/29/08 EEC 421/521: Software Engineering 9 Promela can only model finite systems Only finite number of processes (max 255) Data objects can only take finite number of values Finitely many channels, each with finite capacity (255) active proctype splurge(int n) pid p; printf("%d\n", n); p = run splurge(n+1) spin: too many processes (255 max) 255 processes created 4/29/08 EEC 421/521: Software Engineering 11 Instantiating Processes Running processes can instantiate other process types Processes can take parameters Parameters of active processes take default values Process init is created by default proctype you_run(byte x) printf("x = %d, pid = %d\n", x, _pid) init run you_run(0); run you_run(1); $ spin you_run2.pml x = 0, pid = 1 x = 1, pid = 0 3 processes created 4/29/08 EEC 421/521: Software Engineering 10 Message Channels Used to model exchange of data between processes chan qname = [16] of short, byte bool Send messages using! qname!expr1, expr2, expr3 Receive messages using? qname?var1, var2, var3 Send messages in order using!! FIFO channels 4/29/08 EEC 421/521: Software Engineering 12

4 Message Channels: Example mtype = msg0, msg1, ack0, ack1 ; chan to_sndr = [2] of mtype ; chan to_rcvr = [2] of mtype ; active proctype Sender() again: to_rcvr!msg1; to_sndr?ack1; to_rcvr!msg0; to_sndr?ack0; goto again active proctype Receiver() again: to_rcvr?msg1; to_sndr!ack1; to_rcvr?msg0; to_sndr!ack0; goto again 4/29/08 EEC 421/521: Software Engineering 13 Assertions Executable statement that checks if a predicate is true or false assert(expression) Always executable What will init assert(false) produce as output? How about init assert(true)? Used in simulations 4/29/08 EEC 421/521: Software Engineering 15 Message Channels: Example Never Claims $ spin -c -u6 abp.pml proc 0 = Sender proc 1 = Receiver q\p to_rcvr!msg1 1. to_rcvr?msg1 2. to_sndr!ack1 2 to_sndr?ack1 1 to_rcvr!msg0 1. to_rcvr?msg depth-limit (-u6 steps) reached final state: #processes: 2 queue 2 (to_sndr): queue 1 (to_rcvr): 6: proc 1 (Receiver) line 20 "abp.pml" (state 4) 6: proc 0 (Sender) line 11 "abp.pml" (state 4) 2 processes created 4/29/08 EEC 421/521: Software Engineering 14 Used to specify finite or infinite system behavior that should never occur Example: Check that an invariant property is never falsified never do ::!p -> break :: else od 4/29/08 EEC 421/521: Software Engineering 16

5 Never Claims The never claim runs in its own process This process is executed once at each step of the system execution As soon as the property p is found to be false, the claim process breaks and terminates This indicates that error behavior occurred never do :: assert(p) od active proctype monitor() atomic!p -> assert(false) 4/29/08 EEC 421/521: Software Engineering 17 Model Checking Example The Ferryman Problem A Ferryman has a head of cabbage, a goat, and a wolf. He needs to get across a river. He can only take one item at a time on the boat. He can t leave the goat and the wolf by themselves He can t leave the goat and the cabbage by themselves How can he take all three items across? 4/29/08 EEC 421/521: Software Engineering 19 Never Claim Example Every system state in which p is true eventually leads to a system state in which q is true, and in the interim p remains true We are not interested in system executions that satisfy the property; only those that don t! We want to make sure that the following never happens: first p becomes true in an execution and thereafter q either remains false forever, or p becomes false before q becomes true Ferryman using SPIN /* things can be on either the original side or the destination side of the river ("mtype" sets up an enumeration of labels; we could use 0 everywhere we used original_side and 1 for destination_side, but the code is more readable this way) */ mtype = original_side, destination_side ; 4/29/08 EEC 421/521: Software Engineering 18 4/29/08 EEC 421/521: Software Engineering 20

6 Ferryman using SPIN /* we are concerned with these four entities' locations, and they all start on the near side (again we could have called them f, c, g, and w, but this is more readable) */ mtype ferryman_location = original_side, cabbage_location = original_side, goat_location = original_side, wolf_location = original_side; Ferryman using SPIN /* macro which defines what happens when the ferryman carries an object; the name is included for pretty-printing */ inline carry(object, object_name) atomic /* atomic because both locations change at the same time; we shouldn't check assertions or never in between these two lines */ swap_side(ferryman_location); swap_side(object); /* these are defined just for pretty-printing (spin doesn't do strings) */ mtype ferryman, cabbage, goat, wolf ; 4/29/08 EEC 421/521: Software Engineering 21 printf("crossing with "); printm(object_name); printf(" to "); printm(object); printf("\n"); 4/29/08 EEC 421/521: Software Engineering 23 Ferryman using SPIN /* this macro just sets its parameter to be the opposite of the side it is on */ inline swap_side(loc) if :: (loc == original_side) -> loc = destination_side :: else -> loc = original_side; fi /* macro which defines what happens when the ferryman carries nothing */ inline carry_nothing() atomic swap_side(ferryman_location); printf("crossing empty to "); printm(ferryman_location); printf("\n"); 4/29/08 EEC 421/521: Software Engineering 22 Ferryman using SPIN active proctype cross() do :: ferryman_location == goat_location -> carry(goat_location, goat) :: ferryman_location == cabbage_location -> carry(cabbage_location, cabbage) :: ferryman_location == wolf_location -> carry(wolf_location, wolf) :: true -> carry_nothing() od 4/29/08 EEC 421/521: Software Engineering 24

7 Ferryman: Looking for the solution /* we want to find the path where goal is true */ #define goal \ ((ferryman_location == destination_side) && \ (wolf_location == destination_side) && \ (goat_location == destination_side) && \ (cabbage_location == destination_side)) /* but we don't want this restriction to happen in our path */ #define restriction \ ((wolf_location == goat_location && \ ferryman_location!= wolf_location) \ (goat_location == cabbage_location && \ ferryman_location!= goat_location)) 4/29/08 EEC 421/521: Software Engineering 25 The Verifying Compiler Grand Challenge Problem Slides from C.A.R. Hoare s talk at 2004 MSR Faculty Summit 4/29/08 EEC 421/521: Software Engineering 27 (! restriction ) U goal never T0_init: if :: ((GOAL)) -> goto accept_all :: (! ((RESTRICTION))) -> goto T0_init fi; accept_all: skip The Verifying Compiler A verifying compiler uses automated mathematical and logical reasoning to check the correctness of the programs that it compiles. Correctness is specified by types, assertions, specifications, and other redundant annotations that accompany the code of the program. 4/29/08 EEC 421/521: Software Engineering 26 4/29/08 EEC 421/521: Software Engineering 28

8 Test of success Significant software products are analysed mechanically and formally verified, ranging from safety-critical and embedded codes to open source and legacy applications verified at an appropriate level of safety/soundness/security/service. Verified programs replace existing versions in use subsequent evolution will maintain correctness. Verification is integrated into commercial toolsets 4/29/08 EEC 421/521: Software Engineering 29 Scientific Ideals The project complements commercially motivated evolution of existing products which follow market demand to discover more faults in existing programs. appeal to current educational level of programmers with many pictures But academic research pursues ideals of purity, accuracy, completeness -- and correctness far beyond the current needs of the market place 4/29/08 EEC 421/521: Software Engineering 31 Fundamental understanding What is this program for? Its specification tells you its function How does it work? Annotation at interfaces explains how. Why does it work? The theory of programming explains why. Are the answers accurate? A verifying compiler provides a reliable check Beneficial The understanding and knowledge gained on completion of the project promises benefit to mankind. Reduction in program errors could even now save $22 to $60 billion per year in US (US Dept. Commerce Planning Report 02-03, May 2002 ). 4/29/08 EEC 421/521: Software Engineering 30 4/29/08 EEC 421/521: Software Engineering 32

9 Maturity The reasons for previous failure to meet the challenge are well understood. And they can be overcome. Progress: $VC Programming language: Pi (Prove It) Specifications in Pi Compared with 1967 Gigabytes and Gigacycles are cheap Beneficiaries number in millions The state of the art is much advanced 4/29/08 EEC 421/521: Software Engineering 33 4/29/08 EEC 421/521: Software Engineering 35 Verifying Compiler Progress Spec# (MSR) Source language: C# Specifications: Method contracts, invariants, etc. Program logic: Dijkstra s weakest preconditions Automatic verification: Type checking, verification condition generation, automated theorem proving $VC (Stanford) Programming language: Pi (Prove It) Specifications in Pi 4/29/08 EEC 421/521: Software Engineering 34

The SPIN Model Checker

The SPIN Model Checker Metodi di Verifica del Software Andrea Corradini Lezione 1 2013 Slides liberamente adattate da Logic Model Checking, per gentile concessione di Gerard J. Holzmann http://spinroot.com/spin/doc/course/