Formal Verification Method for Armv8-a Assembly Code

Abstract

The present invention discloses a formal verification method for Armv8-a assembly code. The processor architecture and instruction set system of Armv8-a are analyzed, and each module component to be modeled is extracted, including exception levels, execution states, data values, register sets, memory, instruction sets, and assembly code. Each module component is modeled; according to the functions and security specifications of each assembly instruction in the assembly code, the informal requirements for the corresponding assembly instruction are determined, and then the formal logical expressions for each assembly instruction are generated in combination with the defined model, thereby obtaining a formal specification; finally, a theorem prover is used for formal verification. The present invention models each module component of the physical machine, then generates the formal logical expressions for each assembly instruction in the assembly code based on the constructed model, and uses the theorem prover to complete the formal verification of the Armv8-a assembly code.

Description

Technical Field

[0001] The present invention belongs to the technical field of computer security, and more specifically, relates to a formal verification method for Armv8-a assembly code. Background Art

[0002] As the basic platform for modern computer applications, the operating system supports the operation of various software and directly affects the stability and security of the computer system. Small vulnerabilities in the operating system may lead to serious system errors or security threats, and even cause life and property losses. Therefore, ensuring the security and reliability of the operating system is a key factor in maintaining the healthy operation of the computer software ecosystem.

[0003] Traditional software testing methods have limitations in discovering errors and vulnerabilities. Testing cannot cover all cases and paths, and vulnerabilities may be hidden in edge cases or complex interactions. Therefore, although traditional testing methods are important quality assurance means, they cannot completely eliminate errors and vulnerabilities in the system. With the expansion of system functions, the increase in code size, and the complication of internal logic, ensuring the reliability and security of the system has become an important and challenging task. In the prior art, the formal method is an effective way to address this challenge.

[0004] The formal method is a technology based on mathematics and formal languages, which can improve the reliability and correctness of software and hardware systems. The core idea of this method is to eliminate ambiguity in the design and implementation of software and hardware and reduce the probability of errors and vulnerabilities through precise and strict specifications and verification processes. The formal method includes two main steps: formal specification and formal verification. Formal specification is a detailed, mathematical description of the behavior and properties of the system, usually using a formal language. Such a specification eliminates the fuzzy understanding of the system specification and provides an accurate and consistent description. Formal verification then verifies the formal specification through mathematical analysis methods to ensure that the system meets the properties defined in the specification.

[0005] In recent years, for the verification of operating system kernels: the seL4 project of the National Information and Communications Technology Australia (NICTA) used the interactive theorem prover Isabelle / HOL to complete the formal verification of the microkernel through a three-layer verification framework. The CertiKOS framework developed by Yale University based on deep specifications and certified abstraction layers verified the concurrent operating system kernel mC2 through Coq. The University of Science and Technology of China developed an operating system kernel verification framework for a subset of the C language and verified the key modules of the preemptive operating system μC / OS-II.

[0006] Modern operating systems are mainly developed using high-level languages, but assembly code still plays an indispensable role in critical parts. Compared with high-level languages, assembly code can achieve direct access and control of hardware: it can directly operate on CPU registers, execute privileged instructions, and interact efficiently with hardware devices, which is crucial in many performance-sensitive scenarios. For example, during context switching and interrupt handling, assembly code can ensure minimal latency and the highest execution efficiency. In addition, assembly language also allows developers to achieve more refined control in memory management and system calls, ensuring the reliability and efficiency of the operating system when running in resource-constrained environments. Therefore, potential errors or vulnerabilities in assembly code can lead to system crashes or security risks, so the verification of operating systems is inseparable from the security of assembly code. Summary of the Invention

[0007] The purpose of the present invention is to overcome the deficiencies of the prior art and provide a formal verification method for Armv8-a assembly code. Model each module component of the physical machine, and then generate a formal logical expression for each assembly instruction in the assembly code based on the constructed model, and use a theorem prover to complete the formal verification of the Armv8-a assembly code.

[0008] To achieve the above invention purpose, the formal verification method for Armv8-a assembly code of the present invention includes the following steps:

[0009] S1: Analyze the processor architecture and instruction set system of Armv8-a, extract each module component that needs to be modeled, including exception levels, execution states, data values, register sets, memory, instruction sets, and assembly code, and model each module component. The specific method is as follows:

[0010] S1.1: Define the exception level types including EL0 to EL3. EL0 is used for the execution of ordinary user applications, EL1 is used for the execution of the operating system kernel privilege level, EL2 is used for the execution of the hypervisor, and EL3 is used for the execution of the secure world; define the execution state types including AArch64 and AArch32. When in the AArch64 state, the processor executes the A64 instruction set and uses 64-bit wide general-purpose registers; when in the AArch32 state, the processor executes the A32 or T32 instruction set and uses 32-bit wide general-purpose registers;

[0011] S1.2: Define the basic data value types including boolean type, natural number type, integer type, rational number type, and on this basis, expand and define 8-bit, 32-bit, 64-bit word lengths and the corresponding byte type, 32-bit integer type, 64-bit integer type according to the number of bits and range limitations;

[0012] S1.3: Define the register set to include general registers greq, special registers sreg, and processor status psbit; finally, define the register bank module, which includes mapping the register set instance to the data value types in Step 1.2 and providing a notation to operate on the mapping, including accessing and updating the mapped values;

[0013] S1.4: Define the memory data based on the basic data values, map each byte in the memory to the memval type, including the uninitialized type, the byte type mapped by unsigned 8-bit, and the pointer type mapped by block and offset; the memory operation types include load and store operations; the memory permission types include readable, writable, and read-write permissions; finally, use Record to define the memory type to integrate the above content into one;

[0014] S1.5: Define the Armv8-a instruction set types to include data processing instructions, load / store instructions, flow control branch instructions, system control instructions, exception handling instructions, system register access instructions, and pseudo-instructions. Among them, the data processing instruction types include arithmetic and logical operations, move and shift operations, sign and zero extension operations, and conditional comparison operations; model the addressing modes, including immediate addressing, register addressing, base addressing, pre- and post-index addressing, and define the load / store instructions based on this; the flow control branch instructions include unconditional branch B, conditional branch BC, subroutine call and return BL, RET, and exception return ERET; the system control instructions include the system register access instructions MRS, MSR;

[0015] S1.6: Define the operation process of each assembly instruction in the assembly code, including the fetch, parse, and execution processes, and then design a recursive function for simulating the instruction executor. This function gradually interprets the assembly instruction pointed to by the program counter, recursively executes a specified number of assembly instructions, and updates the states of the registers and memory, thereby simulating the execution process of the assembly code;

[0016] S2: Determine the informal requirements for the corresponding assembly instructions according to the functions and security specifications of each assembly instruction in the assembly code, and then generate the formal logical expressions for each assembly instruction by combining the model defined in Step S1, thereby obtaining the formal specification;

[0017] S3: Select a theorem prover according to the actual needs, convert the recursive function of the simulated instruction executor and the formal logical expressions of each assembly instruction into the format defined by the formal language in the theorem prover, and perform formal verification using the verification strategies provided in the theorem prover.

[0018] The formal verification method for Armv8-a assembly code of the present invention analyzes the processor architecture and instruction set system of Armv8-a, extracts various module components to be modeled, including exception levels, execution states, data values, register sets, memory, instruction sets, and assembly code, and models each module component; determines the informal requirements for each assembly instruction according to the function and security specifications of each assembly instruction in the assembly code, and then combines the defined model to generate the formal logical expression for each assembly instruction, thereby obtaining the formal specification; finally, uses a theorem prover for formal verification.

[0019] The present invention has the following beneficial effects:

[0020] 1) The present invention analyzes the characteristics of the Armv8-a hardware platform, designs and constructs a set of formal models that can be used to verify assembly code under the Armv8-a architecture, including the modeling design of data values, registers, memory, assembly instructions, and operational semantics; provides the formal description ability for the assembly module in the embedded operating system based on Armv8-a, so as to be able to perform subsequent specification and verification for the assembly code.

[0021] 2) The present invention designs a recursive function that simulates an assembly instruction executor. This function gradually interprets the instruction pointed to by the program counter, recursively executes a specified number of instructions, and updates the states of registers and memory, thereby simulating the execution process of the assembly program to achieve the formal verification of the assembly code. Description of the Drawings

[0022] Figure 1 is the flowchart of the specific implementation manner of the formal verification method for Armv8-a assembly code of the present invention;

[0023] Figure 2 is the flowchart of the formal model construction in the present invention;

[0024] Figure 3 is the schematic diagram of the process of the recursive function in this embodiment. Specific Implementation Manner

[0025] The following describes the specific implementation manner of the present invention in conjunction with the drawings, so that those skilled in the art can better understand the present invention. It should be particularly noted that in the following description, when the detailed description of known functions and designs may dilute the main content of the present invention, these descriptions will be omitted here.

[0026] Embodiment

[0027] Figure 1 is the flowchart of the specific implementation manner of the formal verification method for Armv8-a assembly code of the present invention. As Figure 1As shown in the figure, the specific steps of the formal verification method for Armv8-a assembly code according to the present invention are as follows:

[0028] S101: Formal model construction:

[0029] To achieve formal verification of Armv8-a assembly code, it is first necessary to analyze the processor hardware characteristics and instruction set of the Armv8-a architecture, and perform formal description and modeling for the physical machine state, assembly instructions, and assembly code. Table 1 is the Armv8-a machine state model information table.

[0030]

[0031]

[0032] Table 1

[0033] As shown in Table 1, the physical machine state of the Armv8-a processor involves the modeling of memory and register sets; the assembly instructions involve the semantic modeling of data transfer, arithmetic operations, logical operations, and program transfer type instructions, as well as the fetching, parsing, and execution logic modeling of different instruction operations; the assembly code composed of multiple instructions involves the definition and execution modeling of code blocks. Therefore, in the present invention, the processor architecture and instruction set system of Armv8-a are analyzed, and each module component to be modeled is extracted, including exception levels, execution states, data values, register sets, memory, instruction sets, and assembly code. Figure 2 is the flowchart of formal model construction in the present invention. As Figure 2 shown, the specific steps of formal model construction in the present invention are as follows:

[0034] S201: Exception level and execution state modeling:

[0035] As shown in Table 1, the Armv8-a processor architecture has four exception levels. Therefore, the exception level types are defined as EL0 to EL3. EL0 is used for the execution of ordinary user applications, EL1 is used for the execution of the operating system kernel privilege level, EL2 is used for the execution of the hypervisor, and EL3 is used for the execution of the secure world. The execution state types are defined as AArch64 and AArch32. When in the AArch64 state, the processor executes the A64 instruction set and uses 64-bit wide general-purpose registers; when in the AArch32 state, the processor executes the A32 or T32 instruction set and uses 32-bit wide general-purpose registers.

[0036] S202: Data value modeling:

[0037] In the Armv8-a assembly model, it is necessary to consider how to represent and process values, and the register values, memory values, etc. derived therefrom. For data values, its basic types are defined to include the boolean (bool) type, the natural number (nat) type, the integer (Z) type, and the rational number (Q) type. On this basis, 8-bit, 32-bit, and 64-bit word lengths and the corresponding byte type, 32-bit integer type, and 64-bit integer type are defined according to the bit number and range limitations. In addition, the pointer ptr type is represented by the mapping of the binary tuple block and the offset. Therefore, the register value or memory value can be mapped or encapsulated on the basis of the above data types.

[0038] S203: Register set modeling:

[0039] In the Armv8-a assembly model, it is necessary to perform abstract modeling on registers, involving general-purpose registers and special registers. Specifically, it includes the definition of 64-bit general-purpose registers: X0 to X30, the special register zero register, the PC program counter, and the SP stack pointer. Special registers include the SPSR program status save register, the ELR exception link register, and the PSTATE processor status bit. At all exception levels of Armv8-a, the general-purpose register set and the PC program counter are the same and can be accessed at all exception levels. However, there are also some specific registers at each exception level. For example, the SP stack pointer has corresponding registers at EL0 to EL3, and the SPSR and ELR have corresponding registers at EL1 to EL3. Therefore, the relative impacts also need to be considered during modeling. The specific method for register set modeling in the present invention is:

[0040] Define the register set to include general-purpose registers greq, special registers sreg, and the processor status psbit. Finally, define the register set module, which maps the register set instance to the data value type in step S102 and provides a symbolic notation to operate the mapping, including accessing the mapped value and updating the mapped value.

[0041] S204: Memory modeling:

[0042] The memory model in the Armv8-a assembly model involves multiple aspects, including memory data representation, memory operations, and memory permissions. Therefore, the specific method for memory modeling in the present invention is:

[0043] The memory data is defined based on the basic data values. Each byte in the memory is mapped to the memval type, including the uninitialized type, the byte type mapped by unsigned 8-bit, and the pointer type mapped by block and offset. The memory operation types include load and store operations. The memory permission types include readable, writable, and read-write permissions. Finally, the memory type is defined using Record to integrate the above content into one.

[0044] S205: Instruction Set and Instruction Operation Semantics Modeling:

[0045] Define the Armv8-a instruction set types including data processing instructions, load / store instructions, flow control branch instructions, system control instructions, exception handling instructions, system register access instructions, and pseudo-instructions. Among them, the data processing instruction types include arithmetic and logical operations, move and shift operations, sign and zero extension operations, and conditional comparison operations. The arithmetic and logical operation instruction types include ADD, SUB, CMP, CMN, etc. The move and shift operation instruction types include LSL, LSR, MOV, etc. The sign and zero extension instruction types include SXTB, UXTB, etc. The conditional comparison instruction types include four status flags: zero (Z), negative (N), Carry (C), and overflow (V). Since the Armv8-a architecture is a load / store architecture, there are no data processing instructions that directly operate on the data in the memory. The data must first be loaded into the register, modified, and then stored into the memory. Therefore, it is necessary to model the addressing modes, including immediate addressing, register addressing, base addressing, pre / post-index addressing, and define the load / store instructions based on this, such as LDR, STR, LDP, STP, etc. The flow control branch instructions include unconditional branch B, conditional branch BC, subroutine call and return BL, RET, and exception return ERET. The system control instructions include the instructions for accessing system registers MRS (Move to Register from State register), MSR (Move to State register from Register).

[0046] S206: Assembly Code Modeling:

[0047] The assembly code is composed of assembly instructions. In order to implement the derivation process of the step-by-step state transition of the assembly program, it is necessary to define the operation process of each assembly instruction in the assembly code, including the fetch, parse, and execution processes. Then a recursive function is designed to simulate the instruction executor. This function gradually interprets the assembly instruction pointed to by the program counter, recursively executes a specified number of assembly instructions, and updates the states of the registers and memory, thereby simulating the execution process of the assembly code.

[0048] Figure 3It is a flowchart of the recursive function in this embodiment. As Figure 3 shown, the specific steps of the recursive function of the simulation instruction executor in this embodiment include:

[0049] S301: Determine the assembly code parameters:

[0050] Determine the number of assembly instructions, register set, and memory state in the assembly code.

[0051] S302: Judge whether the number of remaining assembly instructions is 0. If so, end the execution; otherwise, go to step S303.

[0052] S303: Judge whether the value of the PC (Program Counter) register is legal. If not, end the execution; otherwise, go to step S304.

[0053] S304: Judge whether the assembly instruction block exists. If not, end the execution; otherwise, go to step S305.

[0054] S305: Judge whether the assembly instruction exists. If not, end the execution; otherwise, go to step S306.

[0055] S306: Call the assembly instruction execution function:

[0056] Call the assembly instruction execution function to execute the current assembly instruction, and then return to step S302.

[0057] It can be seen that the recursive function of the simulation instruction executor recursively executes a specified number of instructions by gradually interpreting the instructions pointed to by the program counter (PC), updates the register set and memory state, so as to simulate the execution process of the assembly program.

[0058] S102: Determine the formal specification:

[0059] Determine the informal requirements of the corresponding assembly instruction according to the function and security specification of each assembly instruction in the assembly code, and then generate the formal logical expression of each assembly instruction in combination with the model defined in step S101, so as to obtain the formal specification.

[0060] The assembly code consists of a series of assembly instructions, and each instruction may affect the program state. By gradually decomposing and verifying the correctness of each instruction sequence, a formal proof chain can be established, so as to ensure that the program meets the specified functions and properties and deduce the correctness of the whole program.

[0061] Most of the formal verification based on theorem proving takes program logic as the theoretical basis to deduce and reason about the proposition that "the system meets the specification". Hoare logic is a classical program logic for theorem proving, and the verification object is sequential programs. In Hoare logic, each command C has a related precondition P and postcondition Q. The precondition P describes the state before the program execution, and the postcondition Q describes the state after the program execution. Hoare logic provides a set of inference rules, making it possible to derive a proof of program correctness by combining these triples. The precondition Q0 is true in the state S0, and after executing the instruction C1, it reaches the state S1, satisfying the postcondition Q1; the precondition Q1 is true in the state S1, and after executing the instruction C2, it reaches the state S2. Then, according to the combination rules of Hoare logic, it can be deduced that:

[0062] ({Q0(S0)}C1{Q1(S1)}, {Q1(S1)C2{Q2(S2)}) / ({Q0(S0)}C1; C2{Q1(S1)})

[0063] According to Hoare logic, the Hoare triple formal assertion of assembly instructions can be constructed, including the physical machine precondition, the state transition function of assembly instructions, and the physical machine postcondition. Next, take the assembly code of task context switching as an example to illustrate the determination method of formal specification. The specific method is as follows:

[0064] Combined with the assembly code modeling in step S101, the precondition of the assembly code is given: the machine state W, which is a binary tuple of the register set R and the memory M. Then analyze the specific function of the assembly code to be verified, and combine the instruction set and instruction semantics defined in the assembly code modeling in step S101 to deduce the machine state transition process, so as to give the postcondition W' of the assembly code, which is a binary tuple of the register set R' and the memory M'.

[0065] For example, the assembly code of task context switching, its function is divided into saving the current task context and restoring the new task context, and it is necessary to perform push and pop operations on the general registers and some special registers. Therefore, it is necessary to pay attention to the general register GR in the system modeling register set R, the elr in the special register SR el1 , sp el0 , sp el1 , spsr el1 , the initial and end values of pc, as well as the initial state and end state of the memory M.

[0066] Then the programming instructions for saving the task context need to meet the specification that the initial state and target state of the physical machine state conform, specifically including:

[0067] Saving the old task context context_save:

[0068] The precondition is: the initial state of the register bank is R, and the initial values of the special registers are SR old , where SR includes elr el1 , sp el0 , sp el1 , spsr el1 , pc. The initial value of the general register GR is x i (where 0 ≤ i ≤ 30). The initial state of the memory is M

[0069] The postcondition is: the final state of the register bank is R′, the values of the special register sp el1 and the general register x0 are sp old - 272, and the value of the program counter pc is pc old + 21. The final state of the memory is M′: the value of the memory address 248 + 8 * i is the value of the general register x i (where 0 ≤ i ≤ 30). The memory address sp old - 256 is the value of the special register elr old . The memory address sp old - 264 is the value of the special register sp el0_old , and the memory address sp old - 272 is the value of the special register spsr old .

[0070] According to the above process, the Hoare logic expression of the programming instruction for saving the task context in this embodiment is as follows:

[0071]

[0072] Context_save

[0073]

[0074] Restoring the new task context context_restore:

[0075] The precondition is: the initial state of the register bank is R, and the special register sp el1 and the general register x0 have the value sp new , and the value of the program counter pc is pc new . The initial state of the memory is M: the value of the memory address sp new + 24 + 8 * i is the value of the general register x i_new (where 0 ≤ i ≤ 30). The memory address sp new + 16 is the value of the special register elr new . The memory address sp newThe value of +8 is the value of the special register sp_el0 new , the memory address sp new The value of is the value of the special register spsr new .

[0076] The postcondition is: the end state of the register bank is R': the initial values of the special registers are SR new , where SR includes elr el1 , sp el0 , spsr el1 . The value of the program counter pc is pc new , the stack pointer register sp at exception level EL1 el1 The value of is sp new +272, the initial value of the general register GR is x i_new (where 0 ≤ i ≤ 30). The end state of the memory is M'.

[0077]

[0078]

[0079] Context_restore

[0080]

[0081] S103: Formal verification:

[0082] Select a theorem prover according to actual needs, convert the recursive function simulating the instruction executor and the formal logical expressions of each assembly instruction into the format defined by the formal language in the theorem prover, and perform formal verification using the verification strategies provided in the theorem prover.

[0083] In this embodiment, the Coq theorem prover is selected for formal verification. Coq is an interactive theorem proving tool that implements a high-level programming and mathematical language called Gallina, which is based on an expressive formal language called the Calculus of Inductive Constructions (CIC), and this formal language itself combines higher-order logic and a richly typed functional programming language. Taking the Hoare logic in this embodiment as an example, the formal verification method based on the Coq theorem prover is as follows:

[0084] Convert the recursive function of the simulation instruction executor of the assembly code to be verified into the format defined by the formal language in Coq, then use the Coq theorem prover to write the preconditions and postconditions in the Hoare logic expressions of each assembly instruction as formal correctness lemmas, and finally use the verification strategies provided in the Coq theorem prover to perform formal verification to determine whether the execution of the assembly program satisfies the formal correctness lemmas, thereby verifying the functional correctness and memory safety of the assembly program

[0085] Although the illustrative specific embodiments of the present invention have been described above for the convenience of those skilled in the art to understand the present invention, it should be clear that the present invention is not limited to the scope of the specific embodiments. For those of ordinary skill in the art, as long as various changes are within the spirit and scope of the present invention defined and determined by the appended claims, these changes are obvious, and all inventions and creations using the concept of the present invention are within the scope of protection.

Claims

1. A formal verification method for Armv8-a assembly code, characterized in that, The steps include: S1: Analyze the processor architecture and instruction set system of Armv8-a, extract each module component that needs to be modeled, including exception levels, execution states, data values, register sets, memory, instruction sets, and assembly code, and model each module component. The specific method is as follows: S1.1: Define exception level types including EL0 to EL3. EL0 is used for the execution of ordinary user applications, EL1 is used for the execution of the operating system kernel privilege level, EL2 is used for the execution of the hypervisor, and EL3 is used for the execution of the secure world; define execution state types including AArch64 and AArch32. When in the AArch64 state, the processor executes the A64 instruction set and uses 64-bit wide general-purpose registers; when in the AArch32 state, the processor executes the A32 or T32 instruction set and uses 32-bit wide general-purpose registers. S1.2: Define the basic data value types including boolean type, natural number type, integer type, rational number type, and on this basis, expand and define 8-bit, 32-bit, and 64-bit word lengths and the corresponding byte types, 32-bit integer types, and 64-bit integer types according to bit number and range limitations. S1.3: Define the register set including general registers greq, special registers sreg, and processor status psbit; finally, define the register set module, including mapping the register set instance to the data value types in step 1.2, and providing symbolic notations to operate the mapping, including accessing the mapped value and updating the mapped value. S1.4: Define the memory data based on the basic data values, map each byte in the memory to the memval type, including uninitialized types, byte types mapped by unsigned 8 bits, and pointer types mapped by blocks and offsets; memory operation types include load and store operations; memory permission types include readable, writable, and read-write permissions; finally, use Record to define the memory type to integrate the above content into one. S1.5: Define the Armv8-a instruction set types including data processing instructions, load / store instructions, flow control branch instructions, system control instructions, exception handling instructions, system register access instructions, and pseudo-instructions. Among them, data processing instruction types include arithmetic and logical operations, move and shift operations, sign and zero extension operations, and conditional comparison operations. Model the addressing modes, including immediate addressing, register addressing, base addressing, pre-indexed and post-indexed addressing, and define the load / store instructions based on this; flow control branch instructions include unconditional branch B, conditional branch BC, subroutine call and return BL, RET, and exception return ERET; system control instructions include access system register instructions MRS, MSR. S1.6: Define the operation process of each assembly instruction in the assembly code, including the instruction fetching, parsing, and execution processes. Then, design a recursive function for simulating the instruction executor, which gradually interprets the assembly instruction pointed to by the program counter, recursively executes a specified number of assembly instructions, and updates the states of registers and memory, thereby simulating the execution process of the assembly code; S2: Determine the informal requirements for each assembly instruction according to the function and security specifications of the assembly instruction in the assembly code. Then, combine with the model defined in step S1 to generate the formal logical expressions for each assembly instruction, thereby obtaining the formal specification; S3: Select a theorem prover according to actual needs, convert the recursive function for simulating the instruction executor and the formal logical expressions of each assembly instruction into the format defined by the formal language in the theorem prover, and perform formal verification using the verification strategy provided in the theorem prover.

2. The formal verification method according to claim 1, wherein The specific steps of the recursive function for simulating the instruction executor in step S1.6 include: 1) Determine the number of assembly instructions, the register set, and the memory state in the assembly code; 2) Judge whether the number of remaining assembly instructions is 0. If so, the execution ends; otherwise, go to step 3); 3) Judge whether the value of the PC register is legal. If not, the execution ends; otherwise, go to step 4); 4) Judge whether the assembly instruction block exists. If not, the execution ends; otherwise, go to step S5); 5) Judge whether the assembly instruction exists. If not, the execution ends; otherwise, go to step 6); 6) Call the assembly instruction execution function to execute the current assembly instruction, and then return to step 2).

3. The formal verification method according to claim 1, characterized in that In step S2, the logical expressions adopt the Hoare logic form, including the physical machine precondition, the state transition function of the assembly instruction, and the physical machine postcondition.

4. The formal verification method according to claim 1, characterized in that, In step S3, the theorem prover adopts the Coq theorem prover.

Images