Towards Promela verification using VerICS

Transcription

1 Part 2: Specification Towards Promela verification using VerICS Wojciech Nabia lek 1 and Pawe l Janowski 2 1 Institute of Computer Science, University of Podlasie ul. Sienkiewicza 51, Siedlce, Poland wojtek@iis.ap.siedlce.pl 2 Institute of Informatics, Warsaw University Banacha 2, Warsaw, Poland janowski@mimuw.edu.pl Abstract. This work aims at applying the powerful symbolic methods provided by VerICS to verify system specifications written in the Promela language. We shortly describe the verification system itself and the methods of translation Promela specifications into the Intermediate Language of VerICS (IL). To illustrate the method of translation the Dining Cryptographers protocol is presented. 1 Introduction Model checking, as a verification method of programming systems, has been recently considered as one of the most promising. There has been a lot of papers describing the method and proposing various variants of it. Since the state explosion is the main problem with which every attempt is faced to make the method practical, therefore the problem of reducing the state space has been the one on which most of the research has been concentrated. Also, there have been a number of tools (model checkers) that implement the method the use of which are illustrated by (rather simple) examples. Often a tool description elaborates also on the way it deals with the optimization problem. Special place among all these propositions should be reserved for the system SPIN [10] designed in mid-eighties by H. J. Holzmann from AT&T Labs. It is probably the first system proposing a complete and implemented methodology of automatic verification using model checking. An integral part of the SPIN system is its specification language Promela (Process or Protocol Meta Language) used to model distributed systems to be verified. The tool represents states directly, as they are defined in the model, applying very subtle optimization techniques to reduce the computational complexity. Promela specifications are direct inputs to SPIN verification system. Because of a quite long experience in use, SPIN so far dominates other model checkers and a lot of interesting examples are modeled in Promela going beyond the limits of toy specifications. For that reason there are some translations from other specification language to Promela but not vice versa. Another approach to the optimization problem (state space reduction) is based on symbolic (indirect) representation of states. Some systems, besides 219

2 Proc. CS&P '06 SPIN, develop the first (direct) method such as: Kronos [7, 20] or Uppal [1]. To the second category (symbolic) belongs the system VerICS [8, 15] with which we deal in this paper but also e.g., Uppaal2k [16] or SMV [13, 5]. In the second category it seems that the most promising verification tools are those which use propositional formulas to represent the verified systems because they (the tools) can directly use effective and existing so called SAT solvers as a basic support for Bounded Model Checking (BMC). VerICS exercise both BMC but also it proposes so called on-the-fly verification based on bisimulation or simulation abstractions. The translation from Promela to the VerICS input language IL will give VerICS the power comparable to SPIN with additional possibilities of checking a richer set of verification formulas (CTL) and to deal with systems with time constraints if the timed Promela will be established in the near future. For the moment we are concentrated on the translation from the original Promela constructs to those of IL making the Promela specifications indirectly acceptable for VerICS. That way one can compare efficiency of VerICS versus SPIN using some typical examples. For the reasons mentioned above we consider such translation an interesting work not only for VerICS users. The paper begins with a short description of SPIN, Promela, IL and Ver- ICS. Then the translation of basic Promela constructs into IL will be given. All these are illustrated by an example of the dining cryptographers protocol. Brief conclusions end this presentation. 1.1 Related work Development of SPIN started over 20 years ago and since that time many people work on its practical applications (i.e. Call Processing [11]) as well as on various optimization methods (partial order reductions [6] or memory management [9]) There are also works on extending SPIN functionality, such as application of parallel and distributed model checking methods [14] or time extensions [3] of Promela. At the same time the third party tools using SPIN for verification purposes appeared for example add-on to MWB [19] for translation from π-calculus into Promela [18]. 2 Model checking tool SPIN The SPIN model checker is a popular opensource software tool, used by thousands of people on whole world. It can be used for the formal verification of distributed software systems. SPIN has been used to trace logical design errors in operating systems, communication protocols, switching systems, concurrent algorithms, railway signaling protocols, etc. The tool checks the logical consistency of a specification. It reports on deadlocks, unspecified receptions, flags incompleteness, race conditions, and unwarranted assumptions about the relative speeds of processes. SPIN works on-the-fly, which means that it avoids the need to construct a global state graph or Kripke structure, as a prerequisite 220

3 Part 2: Specification for the verification of system properties. SPIN can be used as a full LTL model checking system, but it can also be used as an efficient on-the-fly verifier for more basic safety and liveness properties. Correctness properties can be specified as: system or process invariants (using assertions), linear temporal logic formulas (LTL), formal Büchi Automata or more broadly as general omega-regular properties in the syntax of never claims. 2.1 Promela of SPIN Promela is a non-deterministic language, loosely based on Dijkstra guarded command language and borrowing the notation for I/O operations from Hoare CSP language, extended by direct support for the use of embedded C code. Promela allows for describing a system as a set of processes communicating via channels (supporting rendezvous and buffered message passing methods) and/or through shared global variables. 3 Verification platform VerICS VerICS verification platform [8] is a tool developed in recent years to enable automatic verification of specifications written in various input languages. It accepts a number of high level input formalisms (like Estelle) and then translates them into the common format called Intermediate Language. It can also deal with lower level descriptions of systems such as timed automata [2] or Petri nets [17]. Systems represented in the IL form are further translated to a set of timed automata (representing components of the system) or a global timed automaton (product automaton). These automata are passed to verification modules using two complementary methods of reachability analysis, namely Bounded Model Checking with SAT-solvers or on-the-fly verification on abstract models. 3.1 Intermediate Language of VerICS Intermediate Language allows for describing a system as a set of process communicating via buffers (using simple message passing mechanism with FIFO channels) or global shared variables. A processes are defined by terms of states and transitions between them. There are no explicit time variables or clocks in the language, although it is possible to impose some restrictions on a transition execution time using delays or urgency attributes. Processes defined in a IL specification run in parallel in such a way that local transitions are interleaved and transitions with shared labels execute synchronously. The full and formal description of the recent version Intermediate Language can be found in [12]. 221

4 Proc. CS&P '06 4 Translation of Promela specification into IL In this section we present the implemented mechanisms of translation from Promela language into Intermediate Language of VerICS. Although the syntax of the Promela is quite different to that of IL, semantics of the Promela subset which we translate and semantics of IL are very close. This makes the translation rather straightforward, but the proof of its correctness shall be the subject of further studies. 4.1 Assumptions and restrictions At the begging phase of work we had to make some assumptions about Promela language to choose the subset of constructions we can deal with. Most of those restrictions shall be eliminated in the further works. The most important restriction are: Only subset of Promela keywords (some keywords are still not supported). Time extensions are not supported. The embedded C++ extensions are not supported; they are treated as comments. Dynamic process creation is disallowed an init process only is allowed to create (statically) processes. Operations on channels are possible only in processes. We disallow most operations on channels: testing fullness of channels, testing the existence of some or specific data in the channel, getting data from the inside of the channel, getting data from channels without deleting it from the channel and sorting data sent into the channel. 4.2 Translation Below, we provide the description of the translation of Promela language subset we consider. The translation is guided by the Promela syntactical constructions. Table 1 summarizes all the so far implemented elements of the Promela specification language. Constants declaration: Declarations of constants are translated in quite a straightforward way presented in Table 1 row 1. Variables declaration: In IL we are limited to the simple datatypes as bool and int only and so we limit Promela datatypes to those which can be easily represented as ints. Arrays declaration: The recent version of IL is extended with arrays, but it is still under testing so we don t use that direct translation. Instead, Promela arrays are represented as sets of variables. All variables in a given sequence have the same name prefix and unique suffixes corresponding to the appropriate array indeces in the Promela declaration (see Table 1 row 8). 222

5 Part 2: Specification N Promela IL 1 #define name value define name value ; 2 type name[, name1]* var int name[, name1]* ; 3 type name = value var int name = value ; 4 type name[, name1]* = value var int name0 = value ; var int name1 = value ;... 5 mtype [ = ] name [, name1 ]* define name n ; define name n-1 ;... define name 1 ; 6 mtype name [ = mtype name ] define name mtype name ; 7 mtype name [ const ] [ = mtype name ] define name 0 [ mtype name ] ;... define name (const-1) [ mtype name ] ; 8 type name [ const ] [ = variable ] var int name 0 [ = value ] ;... var int name (const-1) [ = value ] ; 9 proctype name ( [ declaration list ] ) { process name { stateset s [, s1]* ; actions sequence actions sequence ; } } 10 active process name { proctype name ( [ declaration list ] ) { stateset s [, s1]* ; actions sequence actions sequence ; } } 11 active [ const ] process name (number) { proctype name ( [ declaration list ] ) { stateset s [, s1]* ; actions sequence actions sequence ; } } 12 init { actions sequence } process init { actions sequence ; } 13 main { proces1 proces2... } 14 channel name! value put(channel name, value); 15 channel name? value get(channel name, value); 16 if from s1 to s2 :: (a > b) >... when (a > b) {... } from s1 to s2 :: (a < b) >... when (a < b) {... } from s1 to s2 :: else >... when (!((a > b) (a < b))) fi {... } 17 do from s1 to s1 :: (a > b) >... when (a > b) {... } from s1 to s1 :: (a < b) >... when (a < b) {... } from s1 to s2 :: else > break when (!((a > b) (a < b))) od { } 18 label:... goto label from s1 to s2 Table 1. Translation from Promela into IL constructions 223

6 Proc. CS&P '06 Symbolic names declaration: We don t use enumeration datatypes in IL - instead the elements of an enumeration datatype are defined as constants. Processes declaration: In the translation of Promela processes we assumed a few restrictions due to IL limitations. Execution parameters (if any), they are converted into global variables. The names of these variables are based on the process name, the process identifier and the name of the original variable. Dynamic creation of processes is forbidden all processes are activated in the main section of an IL specification. Whenever we encounter an array of active processes, we just multiply the process declaration adding suffixes with process identifiers to the original process name (similarly as in the case of variable arrays). The special init process, an active process whose definition may occur only once in the specification is instantiated as process called init in the main section of an IL specification. Operations on communication channels: Basic channel operations are quite similar in both languages. At the moment, IL supports only two operations: sending data into a channel (which means appending data to the end of channel buffer) and receiving data from it (which means getting date from the front of channel buffer), although it is also possible to test the value of the first message in the channel before getting it. Intermediate Language does not support random channel access, data sorting and data copying from channels, so we do not accept such constructions (see Table 1 rows 14-15). Conditional instructions: Conditional instructions are translated into a set of transitions leading from one common state with different guards (see Table 1 row 16). If guards are the same or if they overlap we deal with non-deterministic behaviour. Loops: Loops in Promela are translated in a similar way as conditional instructions. They are represented as a set of transitions going out and coming back to the same state. The possible break instruction inside the loop introduces a transition going out of that state. In loops we deal with non-determinism as well. Jumps: and goto instructions are translated as unconditional transitions. Of course Promela language is much richer than the one we described in this paper and includes many more keywords and constructions. Some parts of SPIN are not currently supported in the process of translation from SPIN into IL. 4.3 Promela never claim Never claim is an automaton that represents a behaviour of a system that should never happen and must be handled in a special way. Generally, the never claim is translated into a process called never and contains all constructions of processes 224

7 Part 2: Specification and declaration of local propositional variables corresponding to the reachability of the end states of never claim. This process may synchronize with others via channels and global variables in the same way as ordinary processes do. 5 Verification of Dining Cryptographers In this section we explain the idea of Dinning Cryptographers protocol as well as all translation steps from its Promela specification into Intermediate Language. 5.1 Dining Cryptographers protocol The Dining Cryptographers protocol was originally presented in 1988 by Chaum [4]. It is used to hide information about the message sender, but may be easily adopted to other practical uses. The story about three cryptographers sitting at the table in the restaurant is the best way to illustrate the idea of protocol. The dinner must be paid anonymously by one of them or by the sponsoring agency and this can be done as follows: Each cryptographer throws a coin. The menu card is placed between him and his neighbour on the right hand in such a way that it is only them who can see the coin. Each cryptographer always sees only two coins, his own and his left hand neighbour s. It says to everybody if these coins have fallen on the same or the opposite sides, but the one who pays the bill cheats. If a number of differences is odd then cryptographers know that one of them is the payer but do not know which one. If a number of differences is even, then they know that the agency is paying. 5.2 Translation example Let s trace the process of translation from a Promela specification to Intermediate Language of VerICS on the example of Dining Cryptographers protocol. Table 2 shows the Promela code (left column) and corresponding IL code (right column). Both columns have separately numbered lines which helps us to describe the key point of the translation. Declaration of the array of N active processes (line number 7 in Promela code) needs some explanation. It is handled by creating a N-element set of identical processes declarations. The line 8 of IL shows the declaration of only the last one of three processes. Each of these processes has the name with a common prefix and the unique suffix - an ordinal number which is an index in the array of processes. Each process requires the explicit definition of states (line 9). Because these processes are active, each of them is automatically added to the main section of IL (line 50). Lines 8 and 9 in Promela code show declarations of local variables. Intermediate Language only allows for defining local variables without assigning them the initial values. All operations on variables may occur only in transitions, so 225

8 Proc. CS&P '06 variables are declared in lines 10 and 11, but initial values are given on transition leading to the first state (namely state 0). Instead of the call to special function pid (Promela line 8) the appropriate process number (from the array of processes) is supplied. The references to an array elements are translated to corresponding variables. (Promela line 14 and IL line 18). Lines and in Promela code are simple conditional instructions that are translated into lines and Lines in Promela define a simple conditional loop and are translated into lines of IL code. The construction that contains two nested conditional instructions (lines 26-43) is translated (into lines 28-47) as it is depicted on figure 1 (states 3 and 4 correspond to the outer conditional instruction, whereas states 5,6 and 7,8 are nested conditional instructions). Fig. 1. Nested IF construction example. Table 2 does not contain never claim which (for sake of clarity) is presented in table 3. This never claim expresses the correctness of the Dining Cryptographers protocol. Intermediate Language does not support properties given in that way. Instead of, we must define a set of propositional variables which will become the components of the reachability formula.the never claim automaton is translated into IL as a new automaton we test for reachability of its last state, which stands for satisfiability of property in interest. The information about handling never claims was introduced in section 4.3. In our example one can see, that in state T0 of the never claim there is the loop with two outgoing transitions and one (always possible) transition leading back to the loop. If the state T1 (the ending state) is reached the formula holds in the model. Straightforward representation of this never claim consists of four states, but the application of some simple reductions could shrink it to two states only. The declaration of the local propositional variable and its redeclaration as the global one (used in further verification steps to build CTL formulas) ends the translation. 226

9 Part 2: Specification 1 #define N 3 1 crypto { 2 int finished = 0 2 define N 3; 3 byte coin[n] = N 3 var int finished = 0; 4 bool paid[n] = false 4 var int coin0 = N; var int coin1 = N; 5 bool notpaid = true 5 var int coin2 = N; var int paid0 = 0; 6 bool even = true 6 var int paid1 = 0; var int paid2 = 0; 7 var int notpaid = 1; var int even = 1; 7 active [N] proctype Cryptographer() { 8 process Cryptographer2 { 8 int nr = pid; 9 stateset state 0, state 1, state 2, 9 int neighbour = (nr +1)%N; state 3, state 4, state 5, state 6, 10 atomic { state 7, state 8; 11 if 10 var int nr; 12 ::notpaid == true > 11 var int neighbour; 13 notpaid = false; 12 to state 0: 14 paid[nr] = true; 13 { nr = 2; 15 ::skip; 14 neighbour = (nr +1)%N; } 16 fi 15 from state 0 to state 1: 17 } 16 when (notpaid == 1) 18 if 17 { notpaid = 0; 19 :: skip > coin[nr] = 1; 18 paid2 = 1; } 20 :: skip > coin[nr] = 0; 19 from state 0 to state 1: { } 21 fi; 20 from state 1 to state 2: 22 do 21 { coin2 = 1; } 23 :: coin[neighbour] == N > skip 22 from state 1 to state 2: 24 :: else -> break 23 { coin2 = 0; } 25 od; 24 from state 2 to state 2: 26 if 25 when (coin0 == N) { } 27 :: coin[nr] == coin[neighbour] > 26 from state 2 to state 3: 28 if 27 when (!(coin0 == N)) { } 29 :: paid[nr] == false > 28 from state 3 to state 5: 30 atomic { finished = finished+1 } 29 when (coin2 == coin0) { } 31 :: else > 30 from state 5 to state 6: 32 atomic { even =!even; 31 when (paid2 == 0) 33 finished = finished+1 } 32 { finished = finished + 1; } 34 fi; 33 from state 5 to state 6: 35 :: else > 34 when (!(paid2 == 0)) 36 if 35 { even = (even+1)%2; 37 :: paid[nr] == false > 36 finished = finished + 1; } 38 atomic { even =!even; 37 from state 6 to state 4: { } 39 finished = finished+1 } 38 from state 3 to state 7: 40 :: else > 39 when (!(coin2 == coin0)) { } 41 atomic { finished = finished+1 } 40 from state 7 to state 8: 42 fi; 41 when (paid2 == 0) 43 fi 42 { even = (even+1)%2; 44 } 43 finished = finished + 1; } 44 from state 7 to state 8: 45 when (!(paid2 == 0)) 46 { finished = finished + 1; } 47 from state 8 to state 4: { } 48 } 49 main { 50 Cryptographer0 Cryptographer1 Cryptographer2 } Table 2. Example of translation from Promela into IL language. 227

10 Proc. CS&P '06 1 never { 1 process never { 2 T0: 2 stateset state 0, state 1, state 2, state 3; 3 do 3 to state 0: 4 :: (finished==n) & even & 4 { }!(!paid[0] &!paid[1] &!paid[2]) 5 from state 0 to state 1: 5 > goto T1 6 when ((finished==n) && (even==1) &&!((paid0==0) && (paid1==0) && (paid2==0))); 7 { } 6 :: (finished==n) &!even & 8 from state 0 to state 2:!(paid[0] paid[1] paid[2]) > 9 when ((finished==n) && (even==0) && 7 goto T1!((paid0==1) (paid1==1) (paid2==1))); 10 { } 8 :: skip 11 from state 0 to state 0: 12 { } 9 od; 13 from state 1 to state 3: 10 accept: 14 { } 11 T1: 15 from state 2 to state 3: 12 skip 16 { } 17 prop { 18 end: in state 3; 19 } 13 } 20 } 21 prop { 22 never.end; 23 } Table 3. Example of translation never claim. 6 Experimental results We made several tests to examine the efficiency of verifying Promela models using VerICS and SPIN. The tests were performed on a machine equipped with Intel Xeon MP 2GHz, 4GB RAM and operating system RedHat AS3. These tests showed us that our system works, as for now, slower than SPIN. The verification procedure using VerICS requires following steps: 1. translation of a specification from Promela to IL 2. generation of a set of timed automata (one for each element of the system) 3. using BMC module to encode a symbolic path representing a fragment of the model combined with a verified property as a propositional formula 4. using ZCHAFF SAT-solver to check the satisfiability of that propositional formula As stated previously using BMC and ZCHAFF we test for reachability of the ending state of the automaton obtained from the never claim. Table 4 shows the experimental results for the first property that was tested. This property differs from the one of Table 3 in that we did not require that all cryptographers had to finish their protocol. The value N represents a number of cryptographers. Depth shows the size of the path of witness. Nodes, Edges and States correspond to the size of model. As we can see our method is not so efficient as SPIN, but the differences in time are not so huge and we think acceptable for the first attempt. 228

11 Part 2: Specification N Depth Nodes Edges BMC SAT Depth States States Spin time time Stored Matched time e e e Table 4. Experimental results for the first property The second tested property looks like the original never claim (in Table 3), but with even==0 replaced with even==1 in line 6 and symmetrically in line 9. Experimental results are given in Table 5. N Depth Nodes Edges BMC SAT Depth States States SPIN time time Stored Matched time e e e Table 5. Experimental results for the second property As we can see, the difference in the efficiency of SPIN and VerICS gets smaller with increasing the size of systems. The anomaly in results the time consumed for smaller system with 3 cryptographers is greater than that for 4 cryptographers goes from the fact, that although the symbolic path is shorter the part of the model that must be explored can be bigger. 7 Conclusions and future works Although the work on the translation from Promela into IL has not been completed yet, we are optimistic that the verification efficiency will be at least comparable which that of SPIN (in terms of both memory usage and CPU time) and in many cases even better. Our future research will focus on extending functionality and efficiency of the translator. At the moment, there is a lack of any mechanism of the optimization of the translation process and the subset of Promela language we support is relatively small. In further perspective, we also intend to extend the application by adding the time constructions. References 1. J. Bengtsson, K. G. Larsen, F. Larsson, P. Pettersson, W. Yi, and C. Weise. New generation of Uppaal. In Proc. of the Int. Workshop on Software Tools for Technology Transfer, J. Bengtsson and W. Yi. Timed automata: Semantics, algorithms and tools. In Lectures on Concurrency and Petri Nets: Advances in Petri Nets, volume 3098 of LNCS, pages Springer-Verlag,

12 Proc. CS&P '06 3. D. Bosnacki and D. Dams. Discrete-time Promela and Spin. In FTRTFT 98: Proceedings of the 5th International Symposium on Formal Techniques in Real- Time and Fault-Tolerant Systems, pages , London, UK, Springer- Verlag. 4. D. Chaum. The dining cryptographers problem: Unconditional sender and recipient untraceability. Journal of Cryptology, 1:65 75, A. Cimatti, E. M. Clarke, E. Giunchiglia, F. Giunchiglia, M. Pistore, M. Roveri, R. Sebastiani, and A. Tacchella. NuSMV2: An open-source tool for symbolic model checking. In Proc. of the 14th Int. Conf. on Computer Aided Verification (CAV 02), volume 2404 of LNCS, pages Springer-Verlag, S. Leue D. Bosnacki and A. Lluch Lafuente. Partial-order reduction for general state exploring algorithms. volume 3925 of LNCS. Springer-Verlag, March C. Daws, A. Olivero, S. Tripakis, and S. Yovine. The tool KRONOS. In Hybrid Systems III, volume 1066 of LNCS, pages Springer-Verlag, P. Dembiński, A. Janowska, P. Janowski, W. Penczek, A. Pó lrola, M. Szreter, B. Woźna, and A. Zbrzezny. VerICS: A tool for verifying timed automata and Estelle specifications. In Proc. of the 9th Int. Conf. on Tools and Algorithms for the Construction and Analysis of Systems (TACAS 03), volume 2619 of LNCS, pages Springer-Verlag, S. Evangelista and J.F. Pradat-Peyre. Memory effcient state space storage in explicit software model checking. volume 3639 of LNCS. Springer-Verlag, August G. J. Holzmann. SPIN Model Checker, The: Primer and Reference Manual. Addison Wesley, G. J. Holzmann and Margaret H. Smith. Automating software feature verification. Bell Labs Technical Journal, 5(2):72 87, A. Janowska and W. Penczek. Static path compression in timed systems. In Proc. of the Int. Workshop on Concurrency, Specification and Programming (CS&P 06). Humboldt University, K. McMillan. The SMV system. Technical Report CMU-CS , Carnegie- Mellon University, February I. Melatti, R. Palmer, G. Sawaya, Y. Yang, R. M. Kirby, and G. Gopalakrishnan. Parallel and distributed model checking in eddy. volume 3925 of LNCS. Springer- Verlag, March W. Nabia lek, A. Niewiadomski, W. Penczek, A. Pó lrola, and M. Szreter. VerICS 2004: A model checker for real time and multi-agent systems. In Proc. of the Int. Workshop on Concurrency, Specification and Programming (CS&P 04), volume 170(1) of Informatik-Berichte, pages Humboldt University, P. Pettersson and K. G. Larsen. Uppaal2k. Bulletin of the European Association for Theoretical Computer Science, 70:40 44, February W. Reisig. Petri Nets. An Introduction, volume 4 of EACTS Monographs on Theoretical Computer Science. Springer-Verlag, H. Song and K. J. Compton. Verifying Pi-calculus processes by Promela translation. 19. B. Victor and F. Moller. The Mobility Workbench a tool for the pi-calculus. In David Dill, editor, CAV 94: Computer Aided Verification, volume 818 of Lecture Notes in Computer Science, pages Springer-Verlag, S. Yovine. KRONOS: A verification tool for real-time systems. Springer International Journal of Software Tools for Technology Transfer, 1(1/2): ,