Abstract: Formal verification is a method to prove the correctness of software, hardware or systems, and has received more and more attention in recent years. This article provides a review of research on formal verification. First, the basic concepts of formal verification are introduced, and then the three techniques of formal verification are introduced, including model checking, theorem proving, and equivalence verification. In addition, two papers introduce the application and implementation of formal verification in the development of software and hardware systems, and the development and use of formal verification tools. Finally, the future development of formal verification is prospected, and it is believed that people should continue to explore new theories and tools to improve the efficiency and usability of formal verification.
Keywords: formal verification; formal methods; software development; research review
I. Introduction
Nowadays, the performance of computer hardware is getting higher and higher, the computing speed is getting faster and faster, the architecture is becoming more and more complex, and the functions of software are becoming more and more powerful and complex. How to develop reliable software and hardware? Systems have become a huge challenge for the development of computer science, especially now that computer systems have been widely used in many safety-critical systems related to the national economy and people's livelihood, such as high-speed train control systems, aerospace control systems, nuclear reactor control systems, medical equipment systems, etc. Any errors in these systems can have catastrophic consequences.
The design and development of computer systems requires analysis, processing, and proof of the properties of computer hardware and software systems. Formal methods are based on formal (logical) systems and support strict specification, modeling and verification of computer systems, and for this purpose algorithms are designed to establish computer-aided tools. In the development process of modern computer systems, formal methods are applied at different stages, in different forms and degrees. For example: in model-based software development, modeling, model refinement and model-based testing are all based on The ideas and technologies of formal methods were developed; the type design of programming languages and the algorithms of program analysis are the basic technologies in formal methods [1].
The most significant role of formal methods is to verify formal specifications. There are two common forms of formal verification: one is reasoning about "whether the system model specification satisfies its property specification". At this time, the model specification tends to be operational and the properties are often descriptive; the other is reasoning about "a model specification of the system." Whether there is a refinement or equivalence relationship with another model specification." These reasoning processes provide a set of static methods to predict the behavior of the system: users can describe the desired properties of the system's behavior or conjectures about the relationships between different abstractions during the development process. Formal verification verifies or falsifies this property in a mechanized way. Or guess, thereby improving users' trust in the protocol and system.
2. Formal verification method
Formal verification methods mainly include theorem proving, model testing and model equivalence verification. The author will introduce the above three methods in detail below.
2.1 Proof of theorem
Formal verification based on theorem proof takes the assertion that "the system satisfies its specification" as a logical proposition, and proves this proposition in the form of deductive reasoning through a set of inference rules. Most of the verification based on theorem proof is based on program logic, but program logic is not the only verification method. For example, we can directly express the safety, correctness and other properties of program execution based on the operational semantics of the program and prove the relevant Theorem [2].
According to the different proof methods and degree of automation, verification based on theorem proof can be divided into two categories, namely automatic verification based on automatic theorem prover and semi-automatic verification based on human-computer interaction.
2.1.1 Automatic verification based on automatic theorem prover
With the development of automatic proof theory and the substantial enhancement of computer processor capabilities, the capabilities of automatic theorem provers have been greatly improved, and verification based on automatic theorem proof has also been greatly developed. Currently common program provers include Dafny, Why3, VeriFast, Smallfoot, etc. Most of these program provers are based on some specific program logic. Given a program and its specification, the prover can automatically decide which axioms or rules in the program logic to use for each statement of the program, and generate corresponding verification conditions as proof obligations. The finally generated verification conditions are sent to the automatic theorem prover, and the theorem prover completes the proof of the verification conditions. The most widely used theorem prover at present is Z3 developed by Microsoft. Other common provers include CVC4, Yices2, etc. Using various theorem provers and automated program verification techniques, people have achieved verification of some relatively practical and large-scale specific systems.
The advantage of verification work based on automatic theorem proving is that the verification efficiency is high and does not require manual writing of proofs. However, since many problems in automatic theorem proving are undecidable, and each theorem prover has its own capacity limitations, the properties that can be expressed and proved are limited. In order to realize automatic proof, it is often necessary to rewrite the properties to be proved and the code itself to be verified, or even sacrifice the properties to be verified and the functions of the code in order to accommodate the automation of verification.
2.1.2 Semi-automatic verification based on human-computer interaction
Another type of verification work based on theorem proof does not emphasize the use of computers to automate verification. Instead, it uses computers to solve the problem of representing the proof in the computer and automatically checking the correctness of the proof. The construction of the proof is done manually. Interacting with machines is done in a semi-automated manner. Many auxiliary theorem proving tools, such as Coq[3] and Isabelle/HOL, are developed for this purpose. Such tools often take advantage of the Curry-Howard isomorphism relationship between type systems and logic [4] to transform the process of constructing a proof into a process of writing a program, and the correctness check of the proof also becomes a type checking problem.
This kind of semi-automated verification work of human-computer interaction often requires a lot of manual labor to construct proofs. Although some basic proof strategies and lemma libraries are provided in auxiliary theorem proving tools to reduce the burden of proof, in the verification of actual code , often an average of 20 to 30 lines of proof scripts are required to be written manually for one line of program. However, the advantage of this approach is that there is no need to sacrifice the expressiveness of the specification and code. In particular, the program specification can be expressed by highly expressive logic (such as the high-order logic used in Coq [3] and Isabelle/HOL). Moreover, the proof itself is explicitly represented in the machine, and its correctness can be automatically checked. Therefore, we do not need to rely on automatic theorems to prove the correctness of the algorithm, and the verification conclusion is more credible.
2.2 Model testing
In theorem proving, formal verification directly proves the property to be proved as a mathematical theorem, which is also called deductive verification. A counterpart to deductive reasoning is model testing. The basic idea of model testing is that it is much easier to test whether a structure satisfies a formula than to prove that the formula is satisfied under all structures. Therefore, a new verification method for testing the satisfiability of formulas on finite state models was created for concurrent systems. form[5].
Figure 1[6] is a schematic diagram of the model detection and verification method. First, build a formal verification model based on the design, then write assertion attributes and related constraints based on the design requirements, and then merge the model and constraints into a formal verification model that meets the verification requirements. Then add the design that needs to be verified and use the formal verification tool to verify it. At this time, the formal verification tool will automatically traverse all the states that need to be verified according to the constraints. If all assertions are true, the design is correct. Otherwise, the design is wrong. When the tool finds the error, it can Provide error scenarios to help verifiers analyze errors. Analyze the coverage status based on the formal verification results, and optimize the formal verification environment through the analyzed results to improve the formal verification coverage.
Figure 2[6] is a schematic diagram of model detection and error checking. During model detection, the state range that can be searched is first defined according to the design requirements. During the state search process, the tool will first establish an initial state and expand to the next state. Unless there are explicit state constraints, expansion will always proceed. Duplication of states may occur during the search process, but no matter what the process is, the tool will traverse all state spaces, and then the tool will compare and check the output values of all states with the standard values in model checking. During assertion checking During the process, if the output value does not meet the assertion attribute, the model checking tool will run in the opposite direction and deduce the input state when the error occurred. This is the principle behind the counterexample given by the tool mentioned above.
Design modeling and formal specification are important links in building a formal verification environment for model checking methods. In model checking, in order to verify the design, you first need to understand the design specifications and verification requirements, and then write the design equivalent reference model on this basis. Often the reference model will be more abstract than the design, and the model is simply to describe the expected results. During the verification process, the design module can be decomposed into small modules that are convenient for verification, but at the same time, the state logic and state space between any decomposed modules must be consistent [7]. Therefore, in order to prevent state explosion during verification, the state space can be divided while ensuring the rationality of verification, making verification simpler and faster. During model checking, the formal verification tool will judge the correctness of the relevant attributes based on the formal specification. Formal specification uses a formal language with precise semantics to describe design properties. The status of formal specification will affect the consistency and completeness of model testing. Consistency refers to the lack of contradiction with the verification goal, and completeness refers to whether the target attributes are completely and without omissions.
2.3 Equivalence test
Equivalence verification is currently the most commonly used verification technology in formal verification methods. Equivalence verification not only has the characteristics of full formal verification traversal and fast verification speed, but also has a high degree of automation of equivalence verification, and the verification tool is easy to operate. Although equivalence verification has many advantages, this verification method cannot be used to verify the functional correctness of the design, because the principle of the equivalence verification method is to achieve the purpose of verification by comparing the equivalence between designs at different stages. . In formal verification, since the method of mathematical logic analysis is abstract, verification will not be restricted by different description languages, and the equivalence of designs between different description methods can be verified [8]. That is, equivalence verification can only detect whether errors occur between different design stages of the chip, but cannot detect common errors in designs at different stages. Equivalence verification is usually used in the chip design process for error analysis between RTL and RTL, gate level and RTL, gate level and gate level, and layout and gate level [9].
3. Research on related papers
This chapter will briefly introduce two papers on formal verification that the author has read, and focus on specific case analysis in the literature during the introduction process.
3.1 Ptolemy discrete event model formal verification method[10]
3.1.1 Basic idea
Ptolemy is a modeling and simulation toolkit that is widely used in cyber-physical fusion systems. It mainly uses simulation to ensure the correctness of the built model. This paper proposes a method based on formal model transformation to verify the correctness of the discrete event model. The discrete event model triggers components based on the timestamps of different events. The timed automaton model can express this feature, so Uppaal was selected as the verification tool. First, the formal semantics of the discrete event model are defined; secondly, a set of mapping rules from the discrete event model to the timed automaton is designed; then a plug-in is implemented in the Ptolemy environment, which can automatically convert the discrete event model into a timed automaton model. And the verification is completed by calling the Uppaal verification kernel. Compared with existing research work, this method defines more complete Ptolemy component conversion rules and can support more components; it retains the hierarchical characteristics of the model and effectively avoids state space explosion; it avoids the use of tick timing and reduces verification complexity; a plug-in for automatic conversion verification was designed and implemented in the Ptolemy environment, which improved the tool chain for model-driven development using Ptolemy.
The overall framework of Ptolemy DE model verification is shown in Figure 3 [10], which can be divided into two parts: conversion model and formal verification: (1)
In the automatic conversion stage of the model, the Ptolemy DE model and the attribute verification formula extracted according to the model are As input, first parse the Ptolemy DE model to obtain the structural information of each component; then convert each component into a corresponding timed automaton according to the defined mapping rules; finally, the timed automaton and the attribute verification formula are combined to form a Verified timed automaton network structures.
(2) Output the timed automaton network structure in the memory to a file, and then call the Uppaal verification engine for verification.
3.1.2 Traffic light case analysis
In a traffic light system, there are three types of lights indicating the movement of vehicles: red, yellow, and green. There are two types of lights indicating the movement of pedestrians: red and green. When the system is working normally: the car indicator light changes in the order of red, yellow, green and yellow, staying for 3, 1, 2 and 1 time units respectively; the pedestrian indicator light changes according to the change of the car indicator light: when the car indicator light When the car indicator light changes from yellow to red, the pedestrian indicator light turns red; when the car indicator light changes from yellow to red, the pedestrian indicator light turns green. Sometimes the system will malfunction. At this time, only the yellow light indicating that the car is paused flashes, and all other indicator lights are off.
As shown in Figure 4 [10], five parameters are defined in the Ptolemy DE model: Pred, Pgrn, Cred, Cyel and Cgrn, which represent different traffic lights respectively: when the value is 1, it means that the corresponding traffic light is on; When it is 0, it means that the corresponding traffic light is off. As shown in the figure, the values of parameters Pred and Cyel are 1, then the red light for pedestrians and the yellow light for vehicles are on. DiscreteClock is an event source component that generates an output signal with a period of 1, Decision is an exception generator, TrafficLight is a traffic light controller, and SetVariable component is used to update parameter values. Among them, the component TrafficLight traffic light controller is a modal model with two states, normal and error, and each state normal and error has a refined model. TrafficLight normal is a detailed model of the normal state in TrafficLight, which represents the detailed model of the traffic light controller under normal conditions of the system, including two controllers: the vehicle traffic light controller CarLightNormal and the pedestrian traffic light controller PedestrianLightNormal.
By extracting the attribute features in the Ptolemy DE model and formally describing them as CTL formulas, the Uppaal verification engine is then used to formally verify the reliability, security, and deadlock of the model. Table 1[10] is the detailed verification situation of the above verification formula. When there are unsatisfied attributes in the timed automaton model, the Uppaal verification engine can return an abnormal path.
3.2 Formal verification of smart contracts for MSVL[11]
3.2.1 Basic idea
Smart contracts are computer protocols that run on the blockchain and are widely used in various fields. However, security issues arise one after another. Therefore, before smart contracts are deployed on the blockchain, they need to be security audited. However, traditional testing methods cannot guarantee the high reliability and correctness required for smart contracts. The article proposes a model detection method for smart contract security based on Sequential Logic Language (MSVL): First, MSVL is used to model the smart contract program. In order to reduce a large number of manual operations during modeling, a smart contract language Solidity conversion method is developed. For MSVL's converter tool SOL2M, the automatic generation of smart contract modeling programs is realized; then the propositional projected temporal logic (PPTL) formula is used to describe the security properties of the smart contract; and finally it is automated in the Unified Model Checker (UMC4M for short) Verify whether the modeling program meets the given security properties, and illustrate the feasibility and practicability of this method in smart contract verification through examples.
Among them, the specific structure and workflow of the converter tool SOL2M are shown in Figure 5 [11]. The SOL2M converter is mainly divided into 4 parts:
(1) Preprocessing: Processing the version identification statements in the Solidity source program and importing other source file statements;
(2) Lexical analysis: Generating a lexical analyzer through the JavaCC tool to analyze the Solidity program Lexical analysis identifies the source program as a specific word stream;
(3) Syntax analysis: generates a syntax analyzer through the JavaCC tool, performs syntax analysis on the Solidity program, and identifies the word stream generated by lexical analysis as program statements; (4)
Program Conversion: By analyzing the lexical and syntactic similarities and differences between Solidity and MSVL, the conversion rules from Solidity to MSVL are formulated, and the conversion code is nested in the BNF paradigm of syntax analysis to achieve dynamic conversion from Solidity programs to MSVL programs.
3.2.2 Bank transfer contract case analysis
Taking a specific bank transfer smart contract and common reentrancy attack vulnerabilities as examples, the detailed process and verification process of SOL2M's modeling of transfer contracts and reentrancy attacks are given. When modeling, the reentrancy attack operation was abstracted into the bank transfer contract, that is, the transfer contract and the reentrancy attack code were abstracted into contracts. As shown in Figure 6 [11], the function of the deposit function is for the user to deposit money into the bank, and the withDraw function implements the transfer function. The user withdraws money from the bank through the withDraw function and the send function. The Attack function implements the reentrancy attack function. The specific steps are: first, the attacker calls the Attack function and deposits some ether coins into the bank transfer contract through the deposit function; then calls the withDraw function to withdraw money from the bank transfer contract, using The require statement determines whether the user's balance and the total bank balance are sufficient; finally, the send function is called to transfer money to the user's address.
Model the contract, merge the bank transfer contract and the reentrancy attack into one contract and use it as the input of the SOL2M converter. The conversion result is shown in Figure 7 [11]. The PPTL formula is used to describe the properties that a bank transfer contract should satisfy from the three levels of functional consistency, logical correctness and contract completeness, which will not be elaborated here.
4. Summary
Formal verification is a technique that uses mathematical methods to prove the correctness of software, hardware, or systems. It uses formal language, logic and proof technology to achieve the purpose of proving whether the system behavior meets the given specified purpose by modeling, specifying and verifying the system.
The advantage of formal verification is that it can conduct comprehensive, automatic, formal testing and verification of the system, thereby discovering and correcting system design defects. Its results can lead to precise and certain conclusions, which can help developers reduce the time and cost of iterative design and testing. Therefore, formal verification has been widely used in the development process of modern software and hardware systems.
Although formal verification has powerful verification capabilities, it also has some challenges in practical applications. Formal verification requires professional provers and high-level knowledge of mathematics and computer science, so it is more expensive. Furthermore, the scale of formal verification is often limited at the scale of the actual system due to complexity issues.
To sum up, formal verification is a very valuable technology, and its role in improving the quality of software and hardware systems cannot be ignored. However, in order to make it more widely used in actual development processes, the efficiency and usability of formal verification need to be continuously improved.
references
