Dec 15, 2013 - system for flash memory. Since it has been ... serve as the basis for software that has very few errors once the customer .... power loss recovery.
International Journal of Advanced Computer Science, Vol. 3, No. 12, Pp. 602-606, Dec., 2013.
File System Formalization: Revisited Ikram Ullah Lali
Manuscript Received: 31, Jan., 2013 Revised: 11, Oct., 2013 Accepted: 27, Oct., 2013 Published: 15, Dec., 2013
Keywords Verified File System; Specification; Verification; Software Verifications; Formal Verification of File System
Abstract In this article, we give a literature survey of the current state of the art regarding building a verifiable file system. The 15 year old grand challenge in software verification proposed by Hoare. Later on it was refined by Joshi and Holzmann to a mini-challenge to build a small verifiable file system for flash memory. Since it has been around 5 years after defining this mini-challenge, therefore, it is important to revisit its success or failure status through the present literature survey.
1
1.
Introduction
A formal specification is simply a description of a system using a mathematical notation. These mathematical notations are used through a language called formal specification language. These specification languages have a formal semantics, which makes it possible to unambiguously denote the meaning of a specification expressed in that language [1]. Formal specification is part of most of the formal method tools. The use of mathematics makes it precise, unlike the more ambiguous natural language and diagrams mostly used for specifications. A specification language could be used as a design tool and, some times as a documentation tool [2]. Formal specifications are applied in the early phases of software development. They reduce the errors in requirements by conduction of detailed analysis in the beginning. There are different types of specifications such as algebraic specification and model based specifications etc. Simply using the formal notations does not ensure that the specifications will be correct. Moreover, writing a correct formal specifications is not an easy job. A unique feature of formal specifications is the support for formal deduction. For mechanized analysis, a specification language is needed with a powerful theorem prover. Other other hand, through the years, Testing and simulation are traditional techniques which are used to check that the software written is correct with respect to its functionality [3]. Many testing techniques are available which help in eliminating coding errors. However, there are very few defects in the end product due to coding errors. For example, in 197 critical faults detected
during the testing phase of the Voyager and Galileo spacecraft, just 3 were coding errors. About 50% of the faults were traced to requirements and 25% to design and the rest due to other errors. This is a typical example of a prevalent problem that the majority of faults in software arise in requirements and design and very few occur due to coding. Furthermore, such techniques do not cover all possible behaviors of the system [4]. Formal verification uses the mathematical techniques for ensuring the design to conform to the functional correctness. It is a technique for proving or disproving the correctness of algorithms according to their formal specifications using formal methods of mathematics. It is used in proving that a property holds for a design. Von Neumann and Goldstine did the earliest work [5], on program verification. It was further continued by Turing in mid-1940s, as soon as the electronic digital computer became a practical possibility. These pioneers acknowledged immediately what generations of programmers after them discovered by humbling practical experience: Writing programs is easy; writing correct programs is difficult [6]. Writing a formal proof of correctness for software is even more difficult. It is applied to designs described at many different levels of abstraction [7]. Formal verification helps in eliminating errors in the design which can cause disastrous at later stages. Practically, formal verification assumes the use of mechanized automatic or semi-automatic techniques.
2.
Why File Systems need Formalism?
In safety critical systems, failure can have a high price. In most of the cases, loss of information was due to specification and design errors in the software. Severe economic consequences can arise when computer software fails. In such situations, it is essential that errors are uncovered before software is put into operation. Files in computer are managed by the file system software, therefore they must be error free and reliable. AS file systems are at the core of the operating system kernel, even a simple error can cause a crash of the system, possibly resulting in loss of stored data [8]. File system errors are among the most dangerous errors because they can cause loss of persistent data stored on the disk. The growing size and complexity of file systems indicates the need of verification of such systems for ensuring reliability. It is very difficult to ensure reliability by testing techniques. Formal verification uses the mathematical techniques for ensuring the design to conform to the functional correctness. It can be applied to designs described for many different levels of abstraction [7]. It helps in eliminating errors in the design which can cause disaster at later stages. Formal methods reduce
Ikram Ullah Lali: File System Formalization: Revisited.
specification errors dramatically and, as a consequence, serve as the basis for software that has very few errors once the customer begins using it [9].
3.
Challenge in Software Verification
Software has been the subject of academic research for 75 years by now. Theoretical computer science been studied and evolved to be widely used for its benefits in software development theories such as formal methods of software engineering. Formal methods have been used in development of many safety critical computing domains [10]. Formal specification and verification are important methodologies for producing quality software products. Formal methods are techniques used to build formally verified software systems. On the other hand, it is challenging to apply these techniques as they need extra technical expertise. Hoare in [11] proposed a grand challenge in software verification. The challenge was to construct and apply a verified compiler that guarantees the correctness of a program before using it. Moreover, justifying the grand challenge, [11] explains that in the history of science, the need for a grand challenge arises only exceptionally. As a prerequisite, the branch of study first must be at an ample level of maturity to predict and plan the direction of future progress. It is put forward to let the researchers come together rather addressing the problem individually in relative isolation or in small teams. The grand challenge was further refined by Joshi and Holzmann in [12] to a mini- challenge to build a small verifiable file system for flash memory. It was an ideal project for the computing researchers due to its complexity, size and importance. Verifiable file system is complex that customary methods such as testing and code reviews are deficient to establish its correctness. It is important as positive completion of this project would have an influence beyond the verification community. Specifically, Joshi and Holzmann were interested in the problem of how to write a filesystem whose correctness can be checked using automated verification tools. In [13], Freitas et al. suggested a road map towards solving the this challenge. They describe the state of the art about the mini-challenge i.e. verifiable file system. The current status of the challenge is discussed in [14]. They illustrate that it would be interesting aspect of file systems correctness to find whether the file systems data structures and code can store and retrieve data without running into logical flaws. They elaborate that the physical nature of the storage media must be considered while specifying a file system. Earlier, in [15], C. Morgan and B. Sufrin proposed abstract specifications of some of the data structures in the UNIX file system. They used Z notation to describe some aspects of the UNIX filing system. There are two approaches to build formally verified software systems i.e. (i) Using model checkers and (ii) Using theorem provers. A. Model Checking Model checking was invented in the early 80ties by E. Clarke and A. Emerson [16] and independently by J.
603
Queille and J. Sifakis [17]. It is a systematic approach of exhaustive exploration of the mathematical model. A state of the system is modeled as a snapshot of the system at some point in time, given by the set of the values of the variables of that system at that time. This is only possible for finite models. Normally, all the states and transitions in the model are explored by using smart and domain specific abstraction techniques. The implementation techniques include state space enumeration, abstract interpretation, symbolic simulation, symbolic state space enumeration, abstraction refinement. The properties needed to be verified are described in temporal logics, as linear temporal logic (LTL) or computational tree logic (CTL) [18]. Model checking is further classified as global temporal model checking, local temporal model checking [19], automata theoretic model checking [20], refinement based model checking [21], bounded model checking [22] and symbolic trajectory evaluation [23]. Different tools have been developed for each of these model checking technique. B. Theorem Proving It uses a formal method of mathematical reasoning about the given system. Most of the search strategies used by automated deduction systems are either directly based on or can be derived from the sequent calculus. We can mainly classify procedures as either working backwards from the proposed theorem to the axioms, or forward from the axioms to the theorem [24]. A logical language can be used as a deduction system (proof system) called proof theory. The proof of the correctness is mechanically checked by a theorem prover, such as Prototype Verification System (PVS) [25], HOL theorem prover [26], the ACL2 [59], Isabelle [27], or Coq [28] etc. This is normally partially automated and for validation, it is driven by the users understanding of the system. Refinement technique is popular which originated in [29].
4.
File System Formalism using Model Checkers
Model checking techniques to verify the file system implementation have been used in [30, 31, 8]. Galloway et al. [30] verify the existing Linux Virtual File System (VFS) by extracting and validating a model from an available implementation of VFS. They used analytical approach for verifying the implementation of VFS. Moreover, they validated their model using simulations in SPIN [32]. They analyzed how an appropriate model of the VFS implementation can be constructed and whether meaningful verification results can be obtained or not. They extract a model from VFS data structures and algorithms. They state that current automated techniques for extracting models from C source code cannot deal with important aspects of operating systems code such as macros, architecture, dynamic memory allocation etc. Therefore, they extracted a model by hand. They used SMART model checker [33] for analyzing the data integrity constraints and for the proof of deadlock freedom. They conclude that it is feasible to apply International Journal Publishers Group (IJPG) ©
International Journal of Advanced Computer Science, Vol. 3, No. 12, Pp. 602-606, Dec., 2013.
604
model checkers to complex file system data structures and algorithms but automated extraction of faithful models is not viable to do. Yang et al. [8] build their own model checker FiSC to find serious file system errors. The [8] shows that even the most popular file systems contain serious bugs which can cause damage to the stored data. They used FiSC for three most important file systems including ext3 [34], JFS [35], and ReiserFS [36]. They found 32 serious errors in popular file systems implementations and 10 of which could were even more crucial as they could result in meta data including the file system root directory. They reported the found bugs to relevant. Therefore, it is important to consider correctness proofs even of existing file system implementations. Yang et al. [8] conclude that model checking can be well applied to find the errors in real file systems. P. Taverne et al. [31], designed a simple robust file store and implemented it in the form of a Promela model. They used model checking to verify the correctness of their implementation and did bounded exhaustive verification of power loss recovery. The construction of an abstract model in Promela has proven to be very useful to test a design concept on a reduced scale and the model proved to be truly effective in verifying the software systems.
5.
File System Formalism Using theorem provers
Many researchers have used automated theorem provers for the specification and verification of file system. Most of them used refinement techniques. [37, 38] specified POSIX file store using Z/Eves. Their work is based the refinement techniques described by [15]. They formally verified specification of a POSIX compliant file systems. The major objective was to build a verified file store for space flight missions. In [37], for refinement [39], they divided in three parts as basic file creation and data manipulation, file descriptors to access created files and their data and directories and links. They tried to develop an implementation level refinement specification for the operations of the system based on the modeling of Java hash code system. They used java HashMaps to build concrete implementations from an abstract specification in [37] taken from JML annotations given in [40]. Using refinement techniques, different aspects of UNIX file system security have been verified by Wenzel [41]. They used the proof assistant Isabelle/HOL i.e. a generic proof assistant. They used typed classical set theory provided by Isabelle/HOL. The structured proof language of Isabelle/Isar [27] is intended to support semiautomated reasoning over a range of different application domains. In their model of Unix, they used a fixed data type operation for the system calls with an inductive definition of state transitions in the file systems for the operational semantics. In [42], Kang and Jackson presented an elaborated work on flash memory formalism using Alloy. They modeled the basic operations
of a filesystem along with the features necessary to the NAND flash hardware, such as wear leveling and erase unit reclamation. An interesting aspect of their work is addressing the fault tolerance through modeling a procedure for recovery from interrupted filesystem operations due to unexpected power loss. The model described [42], addresses three primary aspects of a flash file system including underlying flash hardware, basic operations (i.e. read and write) of POSIX file system software and a fault tolerance mechanism. Recognizing the importance of flash file system due to robust nature of the underlying medium, Andreas et al. [43] contemplated the formalization of flash memory with reference to UBIFS implementation for Linux. They used bottom up approach for modeling i.e. implementation to abstraction. For their work, they use interactive verification system KIV [58]. The authors in [43] have specified the four central data structures of UBIFS implementation as file store which stores node structured data, the flash index, its cached copy in the RAM and the journal. Moreover, a correctness proof of operations like reading and writing in a Unix based file system is presented in [44] using Athena, an interactive theorem-proving environment. In [45], they model and verify an abstract file systematic using different formal methods and tools. They use a tool chain to combine manual specification and proofs of mechanical verification tools such as HOL, VDM++ and Alloy. A. Formalism of Fault-Tolerant File Systems They produced TLA+ specifications [46] to formally specify the fault tolerant file systems in [47]. In their work, they have formally specified the parts of fault-tolerant file systems such as Google File System(GFS) [48], Niobe [49] and Dynamo [50] and used them to illustrate the design similarities and differences, clarify and mechanically verified consistency properties and evaluate design alternatives. They only specify the system at high level and in-depth specification is left for the future researchers. They used refinement techniques to map abstract to the concrete specifications. B. Hierarchical File System’s Formalism In 2008, inspired by Hughes specification [51] of a visual file system in Z, Damchoom, Butler, and Abrial [52] have modeled a tree structured file system in Event-B and Rodin. The [52] gives one of the first specifications of a hierarchical file system in which the tree structure can be modified. In [53, 54], they specify flash file system at eight levels as tree structure, files and directories, file content, permission control, other missing properties (name, creation date, etc.), decomposing file write, decomposing file read and replacing by the flash specification. Furthermore they give the implementation of their verified model using Java. Their model is close to a practical verifable flash file system. Another effort to specify and verify hierarchical file system is given in [55]. The cenetral concept in their specification is file names and paths. In [55], they use top International Journal Publishers Group (IJPG) ©
Ikram Ullah Lali: File System Formalization: Revisited.
down approach for a deep understanding of system functions. They describe the file system from user’s point of view. They used refinement techniques for defining abstract system to concrete file system. They used PVS i.e. general purpose, higher order interactive theorem prover. Their work consist of proving more than 200 lemmas. Furthermore, they described the UNIX security model and proved the properties using PVS theorem prover. In [56], they claim a practical methodology for complete functional verification of a file system. They decompose a specification by functionality at two levels of refinement. Gidon Ernst et al in [57] use a modular approach towards formalization of linux virtual file system switch.
6.
Conclusions and Research Directions
The proposed mini-challenge [12] is to build a complete working formally verifiable file system. Several individual research efforts have been done on this front. A lot of work is done in this regard. Some of the researchers have tried to verify the existing file systems. Others have tried to verify the structure of the file systems. Different tools both in model checking and theorem proving have been used in different aspects. One of the major issues is the power failure and recoverly from unwanted power shut down. Although, several efforts have been made towards building a verifiable file system to meet the mini-challenge proposed in [12]. But yet there is not even a single complete build available which is known to be formally verified in all aspects. There is still space for more research work to build a complete working verifiable file system.
605
[9]
[10]
[11] [12]
[13]
[14]
[15]
[16]
[17]
[18] [19]
[20]
References [1]
[2] [3]
[4]
[5]
[6]
[7]
[8]
Nico Plat, Jan van Katwijk, and Hans Toetenel. Application and benefits of formal methods in software development. Softw. Eng. J., 7(5):335–346, sep 1992. Jonathan P. Bowen. Formal specification and documentation using z: A case study approach, 2003. Michael Huth and Mark Ryan. Logic in Computer Science: Modelling and Reasoning about Systems. Cambridge University Press, New York, NY, USA, 2004. R. Lutz. Analyzing software requirements errors in safety-critical embedded systems. In IEEE International Symposium on Requirements Engineering, pages 126–133, CA, January 1993. C. B. Jones. The early search for tractable ways of reasoning about programs. IEEE Annals of the History of Computing, 25:2003, 2003. Paul P. Boca, J. P. Bowen, and J. I. Siddiqi, editors. Formal methods : state of the art and new directions. Springer, London (Dordrecht) New York, 2010. C. Pecheur. Advanced modelling and verification techniques applied to a cluster file system. In Proceedings of the 14th IEEE international conference on Automated software engineering, pages 119–126, Washington, DC, USA, 1999. IEEE Computer Society. J. Yang, P. Twohey, D. Engler, and M. Musuvathi. Using model checking to find serious file system errors. ACM Transactions on Computer Systems, 24(4):393–423, 2006.
[21]
[22] [23]
[24] [25]
[26] [27]
[28]
Roger S. Pressman. Software Engineering: A Practitioner’s Approach. McGraw-Hill Higher Education, 5th edition, 2009. Cliff B. Jones, Peter W. O’Hearn, and Jim Woodcock. Verified software: A grand challenge. IEEE Computer, 39(4):93–95, 2006. C.A.R. Hoare. The verifying compiler: A grand challenge for computing research. Journal of the ACM, 50:63–69, 2003. R. Joshi and G.J. Holzmann. A Mini Challenge: Build a verifiable filesystem. Formal Aspects of Computing, 19:4, 2007. Leo Freitas, Jim Woodcock, and Andrew Butterfield. POSIX and the verification Grand Challenge: A roadmap. In ICECCS ’08: Proceedings of the 13th IEEE International Conference on Engineering of Complex Computer Systems, pages 153–162, Washington, DC, USA, 2008. IEEE Computer Society. J. Woodcock and R. Banach. The verification grand challenge. Computer Society of India Communications, pages 661–668, 2007. C. Morgan and B. Sufrin. Specification of the UNIX filing System. IEEE Transactions on Software Engineering, SE-10:128–142, 1984. Edmund M. Clarke and E. Allen Emerson. Design and synthesis of synchronization skeletons using branching-time temporal logic. In Logic of Programs, Workshop, pages 52– 71, London, UK, 1982. Springer-Verlag. J. Quielle and J. Sifakis. Specification and verification of conurrent systems in cesar. In In Intl. Symp. on Programming, volume 137. Springer-Verlag, 1982. Edmund M. Clarke. Model checking. Lecture Notes in Computer Science, 1346, 1997. Armin Biere, Edmund M. Clarke, and Yunshan Zhu. Combining local and global model checking. Electr. Notes Theor. Comput. Sci., 23(2):34–45, 1999. Byron Cook and Andreas Podelski, editors. Verification, Model Checking, and Abstract Interpretation, 8th International Conference, VMCAI 2007, Nice, France, January 14-16, 2007, Proceedings, volume 4349 of Lecture Notes in Computer Science. Springer, 2007. Edd Turner, Michael Butler, and Michael Leuschel. A refinement-based correctness proof of symmetry reduced model checking. In Proceedings of the Second international conference on Abstract State Machines, Alloy, B and Z, ABZ’10, pages 231–244, Berlin, Heidelberg, 2010. Springer-Verlag. Armin Biere, Alessandro Cimatti, Edmund Clarke, and Yunshan Zhu. Symbolic model checking without bdds, 1999. Mark D. Aagaard, Thomas F. Melham, and John W. O’leary. Xs are for trajectory evaluation, booleans are for theorem proving (extended version), 2000. F. Pfenning. Automated Theorem Proving. Carnegie Mellon University, Introduction, etc., 2004. S. Owre, N. Shankar, J.M. Rushby, and D.W.J. Stringer-Calvert. PVS Version 2.4, System Guide, Prover Guide, PVS Language Reference, 2001. http://pvs.csl.sri.com HOL. Hol theorem proving system. [Online], 2013. Lawrence C. Paulson, C. Paulson, Tobias Nipkow, and Tobias Nipkow. Isabelle tutorial and user’s manual. Technical report, 1990. Available at : http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-189.pdf Cristina Cornes, Judicael Courant, Jean-Christophe Fillitre, Grard Huet, Chetan Murthy, Csar Munoz, Catherine Parent, Amokrane Saibi Benjamin Werner, Calcul Symbolique, Pascal Manoury, Pascal Manoury, Amokrane Saibi, International Journal Publishers Group (IJPG) ©
606
[29] [30]
[31]
[32] [33]
[34] [35] [36] [37]
[38] [39]
[40]
[41] [42]
[43]
[44]
[45]
[46]
[47]
International Journal of Advanced Computer Science, Vol. 3, No. 12, Pp. 602-606, Dec., 2013.
Benjamin Werner, and Projet Coq. The coq proof assistant reference manual v 8.0, 2008. Available at : http://coq.inria.fr/coq/refman/Reference-Manual002.html. Wirth and Niklaus. Program development by stepwise refinement. Commun. ACM, 14(4):221–227, 1971. A. Galloway, G. Luttgen, J.T. Muhlberg, and R. Siminiceanu. Model-checking the Linux virtual file system. In VMCAI, pages 74–88, 2009. P. Taverne and C. Pronk. Raffs: Model checking a robust abstract flash file store. In K. Breitman and A. Cavalcanti, editors, Formal Methods and Software Engineering, 11th International Conference on Formal Engineering Methods, volume 5885 of LNCS, page 226 .. 245, Berlin, December 2009. ICFEM 2009, Springer Verlag, Berlin Heidelberg New York. Gerard J. Holzmann. The model checker SPIN. Software Engineering, 23(5):279–295, 1997. Gianfranco Ciardo, Ming ying Chung, Andrew S. Miner, Gianfranco Ciardo, Robert L. Jones, Robert M. Marmorstein, Andrew S. Miner, Radu I. Siminiceanu, and Andy Yu. Smart: The stochastic model checking analyzer for reliability and timing. In In International Conference on Quantitative Evaluation of Systems (QEST, pages 338–339. IEEE Computer Society, 2004. EXT2. The ext2/ext3 file systems. [Online], 2013. JFS. The ibm journaling file system for linux. [Online], 2013. ReiserFS. Reiserfs. [Online], 2011. L. Freitas, J. Woodcock, and Z. Fu. POSIX file store in Z/Eves: An experiment in the verified software repository. Sci. Comput. Program., 74(4):238–257, 2009. Z. Fu. A refinement of the UNIX filing system using Z/Eves. Master’s thesis, University of York, October 2006. Jim Woodcock, Peter Gorm Larsen, Juan Bicarregui, and John Fitzgerald. Formal methods: Practice and experience. ACM Comput. Surv., 41(4):19:1–19:36, oct 2009. L. Burdy, Y. Cheon, D.R. Cok, M.D. Ernst, J.R. Kiniry, G.T, K.R.M. Leino, and E. Poll. An overview of jml tools and applications. International Journal on Software Tools for Technology Transfer, pages 73–89, 2003. M. Wenzel. Some aspects of Unix file-system security. Isabelle/Isar proof document. T.U. Munchen, 2001. Eunsuk Kang and Daniel Jackson. Formal Modeling and Analysis of a Flash Filesystem in Alloy. pages 294–308. 2008. Andreas Schierl, Gerhard Schellhorn, Dominik Haneberg, and Wolfgang Reif. Abstract specification of the ubifs file system for flash memory. In Proceedings of the 2nd World Congress on Formal Methods, FM ’09, pages 190–206, Berlin, Heidelberg, 2009. Springer-Verlag. K. Arkoudas, K. Zee, V.Kuncak, and M.Rinard. Verifying a file system implementation. In Sixth International Conference on Formal Engineering Methods (ICFEM04), volume 3308 of LNCS, pages 8–12, 2004. Miguel Alexandre Ferreira and José Nuno Oliveira. An integrated formal methods tool-chain and its application to verifying a file system model. In SBMF, pages 153–169, 2009. Leslie Lamport. Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2002. Roxana Geambasu, Andrew Birrell, and John MacCormick. Experiences with formal specification of fault-tolerant file systems. In DSN, pages 96–101, 2008.
[48] Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung. The google file system. SIGOPS Oper. Syst. Rev., 37(5):29– 43, oct 2003. [49] John Maccormick, Chandramohan A. Thekkath, Marcus Jager, Kristof Roomp, Lidong Zhou, and Ryan Peterson. Niobe: A practical replication protocol. Trans. Storage, 3(4):1:1–1:43, feb 2008. [50] Giuseppe DeCandia, Deniz Hastorun, Madan Jampani, Gunavardhan Kakulapati, Avinash Lakshman, Alex Pilchin, Swaminathan Sivasubramanian, Peter Vosshall, and Werner Vogels. Dynamo: amazon’s highly available key-value store. SIGOPS Oper. Syst. Rev., 41(6):205–220, oct 2007. [51] J. Hughes. Specifying a visual file system in Z. Technical report, Department of Computing Science, University of Glasgow, 3 pages, 1989. [52] K. Damchoom, M.J. Butler, and J.-R. Abrial. Modelling and proof of a tree-structured file system in Event-B and Rodin. In ICFEM, pages 25–44, 2008. [53] K. Damchoom and M. Butler. An experiment in applying event-b and rodin to a flash-based filestore. In Rodin User and Developer Workshop, 1346, 2009. [54] K. Damchoom and M. Butler. Applying event and machine decomposition to a flash-based filestore in event-b. Lecture Notes in Computer Science, 5902, 2009. [55] Wim H. Hesselink and M. Ikramullah Lali. Formalizing a hierarchical file system. Formal Aspects of Computing, 24(1), 2012. [56] Leonid Ryzhyk Sidney Amani and Toby Murray. Towards a fully verified file system. In EuroSys Doctoral Workshop 2012, Bern, Switzerland., 2012. [57] Gidon Ernst, Gerhard Schellhorn, Dominik Haneberg, Jörg Pfähler, and Wolfgang Reif. A formal model of a virtual filesystem switch. In SSV, pages 33–45, 2012. [58] KIV. Kiv (karlsruhe interactive verifier) theorem prover. http://www.informatik.uni-augsburg.de/lehrstuehle/swt/se/ki v/. [59] Matt Kaufmann and J Strother Moore. Acl2-tutorial. Available at: http://www.cs.utexas.edu/users/moore/acl2/v3-6/ACL2-TUT ORIAL.html.
International Journal Publishers Group (IJPG) ©