Armv8-a assembly code oriented formalized verification method

Abstract

The invention discloses an Armv8-a assembly code-oriented formal verification method, which comprises the following steps of: analyzing an Armv8-a processor architecture and an instruction set system, extracting module components to be modeled, including an abnormal level, an execution state, a data value, a register block, a memory, an instruction set and an assembly code, and modeling each module component; determining a non-formalized requirement of the corresponding assembly instruction according to the function and the security specification of each assembly instruction in the assembly code, and then generating a formalized logic expression of each assembly instruction in combination with the defined model, so as to obtain a formalized specification; and finally, carrying out formalized verification by adopting a theorem prover. According to the method, modeling is carried out on each module component of a physical machine, then a formalized logic expression of each assembly instruction in an assembly code is generated based on a constructed model, and formalized verification of the Armv8-a assembly code is completed by using a theorem prover.

Description

Technical Field

[0001] The present invention belongs to the field of computer security technology, 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 loss of life and property. 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 situations and paths, and vulnerabilities may be hidden in edge cases or complex interactions. Therefore, although traditional testing methods are important means of quality assurance, they cannot completely eliminate errors and vulnerabilities in the system. With the expansion of system functions, the increase in code size, and the complexity of internal logic, ensuring the reliability and security of the system has become an important and challenging task. In the existing technology, formal methods are an effective way to address this challenge.

[0004] Formal methods are a technology based on mathematics and formal languages ​​that can improve the reliability and correctness of software and hardware systems. The core concept of this method is to eliminate ambiguity in software and hardware design and implementation and reduce the probability of errors and vulnerabilities through precise and rigorous specifications and verification processes. Formal methods include two main steps: formal specification and formal verification. Formal specification is a detailed, mathematical description of system behavior and properties, usually using formal languages. Such specifications eliminate ambiguous understanding of system specifications and provide accurate and consistent descriptions. Formal verification verifies the formal specification through mathematical analysis methods to ensure that the system meets the properties defined in the specification.

[0005] In recent years, there have been some efforts to verify operating system kernels: the seL4 project of the National Information and Communications Centre of 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 the deep specification and certification abstraction layer 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 key parts. Compared with high-level languages, assembly code can achieve direct access and control of hardware: it can directly operate 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 processing, assembly code can ensure minimal latency and maximum 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 a resource-constrained environment. Therefore, potential errors or vulnerabilities in assembly code may cause system crashes or security risks, so the verification of the operating system is inseparable from the security of assembly code. Summary of the invention

[0007] The purpose of the present invention is to overcome the shortcomings of the prior art and provide a formal verification method for Armv8-a assembly code, model each module component of a 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] In order to achieve the above-mentioned object of the invention, the formal verification method for Armv8-a assembly code of the present invention comprises the following steps:

[0009] S1: Analyze the processor architecture and instruction set system of Armv8-a, extract the various module components that need to be modeled, including exception level, execution status, data value, register group, memory, instruction set, assembly code, and model each module component. The specific method is as follows:

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

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

[0012] S1.3: define the register set including the general register greq, the special register sreg, and the processor status psbit; finally define the register group module, including mapping the register set instance to the data value type in step 1.2, and provide symbolic representation to operate the mapping, including accessing the mapping value and updating the mapping value;

[0013] S1.4: Memory data is defined based on basic data values, and each byte in the memory is mapped 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 read load and store operations; memory permission types include readable, writable, and readable and writable permissions; finally, Record is used to define the memory type to integrate the above contents;

[0014] S1.5: Define the types of Armv8-a instruction set, including data processing instructions, load and store instructions, flow control branch instructions, system control instructions, exception handling instructions, system register access instructions and pseudo instructions. 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 mode, including immediate addressing, register addressing, base addressing, and forward and backward index addressing, and define load and 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 system register access instructions MRS and MSR.

[0015] S1.6: Define the operation flow of each assembly instruction in the assembly code, including instruction fetching, parsing, and execution, and 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 status of registers and memory, thereby simulating the execution process of the assembly code;

[0016] S2: Determine the informal requirements of the corresponding assembly instructions according to the functions and safety specifications of each assembly instruction in the assembly code, and then generate the formal logic expression of each assembly instruction in combination with the model defined in step S1, so as to obtain the formal specification;

[0017] S3: Select a theorem prover according to actual needs, convert the recursive function of the simulated instruction executor and the formal logic expression 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.

[0018] The present invention is 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 that needs to be modeled is extracted, including exception level, execution state, data value, register group, memory, instruction set, and assembly code, and each module component is modeled; the informal requirements of the corresponding assembly instruction are determined according to the function and safety specification of each assembly instruction in the assembly code, and then the formal logical expression of each assembly instruction is generated in combination with the defined model, so as to obtain a formal specification; finally, a theorem prover is used 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 modeling and design of data values, registers, memory, assembly instructions, and operational semantics; and provides the formal description capability of assembly modules in an embedded operating system based on Armv8-a, so that subsequent specification and verification of assembly code can be performed.

[0021] 2) The present invention designs a recursive function that simulates an assembly instruction executor, which gradually interprets the instructions pointed to by the program counter, recursively executes a specified number of instructions, and updates the status of registers and memory, thereby simulating the execution process of the assembler program to achieve formal verification of the assembly code. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0024] Figure 3 It is a schematic diagram of the flow chart of the recursive function in this embodiment. DETAILED DESCRIPTION

[0025] The specific implementation of the present invention is described below in conjunction with the accompanying drawings so that those skilled in the art can better understand the present invention. It should be 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] Example

[0027] Figure 1 This is a flow chart of a specific implementation method of the formal verification method for Armv8-a assembly code of the present invention. Figure 1As shown, the specific steps of the formal verification method for Armv8-a assembly code of the present invention include:

[0028] S101: Formal model construction:

[0029] In order to implement formal verification for Armv8-a assembly code, we first need to analyze the processor hardware characteristics and instruction set of the Armv8-a architecture, and formally describe and model 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 groups; 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, the present invention analyzes the processor architecture and instruction set system of Armv8-a, and extracts the various module components that need to be modeled, including exception level, execution state, data value, register group, memory, instruction set, and assembly code. Figure 2 is a flowchart of the formal model construction in the present invention. Figure 2 As shown, the specific steps of constructing the formalized model in the present invention include:

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

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

[0036] S202: Data Value Modeling:

[0037] In the Armv8-a assembly model, it is necessary to consider how to represent and process values, as well as register values, memory values, etc. that extend from this. For data values, the basic types are defined, including Boolean (bool) type, natural number (nat) type, integer (Z) type, and rational number (Q) type. On this basis, the word lengths of 8 bits, 32 bits, and 64 bits and the corresponding byte type, 32-bit integer type, and 64-bit integer type are defined based on the number of bits and range restrictions. In addition, the pointer ptr type is represented by a mapping of a two-tuple block block and an offset offset. Therefore, register values ​​or memory values ​​can be mapped or encapsulated based on the above data types.

[0038] S203: Register group modeling:

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

[0040] The register set is defined to include the general register greq, the special register sreg, and the processor status psbit. Finally, the register group module is defined, which maps the register set instance to the data value type in step S102, and provides a symbolic representation to operate the mapping, including accessing the mapping value and updating the mapping 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 of memory modeling in the present invention is:

[0043] Memory data is defined based on basic data values, and each byte in the memory is mapped 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 read load and store operations. Memory permission types include readable, writable, and readable and writable permissions. Finally, Record is used to define the memory type to integrate the above content.

[0044] S205: Instruction set and instruction operation semantics modeling:

[0045] The definition of the Armv8-a instruction set types includes data processing instructions, load and store instructions, flow control branch instructions, system control instructions, exception handling instructions, system register access instructions and pseudo instructions. The data processing instruction types include arithmetic and logical operations, move and displacement 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 displacement operation instruction types include LSL, LSR, MOV, etc., the sign and zero extension instruction types include SXTB, UXTB, etc., and the conditional comparison instruction types include four status flags: zero (Z), negative (N), Carry (C), and overflow (V). Because the Armv8-a architecture is a load / store architecture, there is no data processing instruction that directly operates on the data in the memory. The data must first be loaded into the register, modified, and then stored in the memory. Therefore, it is necessary to model the addressing mode, including immediate addressing, register addressing, base addressing, and front and back index addressing, and based on this, define load and store instructions, such as LDR, STR, LDP, STP, etc. 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 system register access instructions MRS (Move to Register from State register) and MSR (Move to State register from Register).

[0046] S206: Assembly code modeling:

[0047] The assembly code is composed of assembly instructions. In order to realize the state transition deduction process of the assembly program line by line, it is necessary to define the operation flow of each assembly instruction in the assembly code, including instruction fetching, parsing and execution. Then a recursive function is designed to simulate the instruction executor. This function gradually interprets the assembly instructions pointed to by the program counter, recursively executes the specified number of assembly instructions, and updates the status of registers and memory, thereby simulating the execution process of the assembly code.

[0048] Figure 3It is a schematic diagram of the flow chart of the recursive function in this embodiment. Figure 3 As shown, the specific steps of simulating the recursive function of the instruction executor in this embodiment include:

[0049] S301: Determine assembly code parameters:

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

[0051] S302: Determine whether the number of remaining assembly instructions is 0, if so, the execution ends, otherwise proceeds to step S303.

[0052] S303: Determine whether the PC (Program Counter) register value is legal. If it is illegal, the execution ends, otherwise it goes to step S304.

[0053] S304: Determine whether the assembly instruction block exists. If not, the execution ends; otherwise, proceed to step S305.

[0054] S305: Determine whether the assembly instruction exists. If not, the execution ends; otherwise, proceed to step S306.

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

[0056] The assembly instruction execution function is called to execute the current assembly instruction, and then the process returns to step S302.

[0057] It can be seen that the recursive function simulating the instruction executor interprets the instructions pointed to by the program counter (PC) step by step, recursively executes a specified number of instructions, and updates the register set and memory status, thereby simulating the execution process of the assembly program.

[0058] S102: Determine the formal specification:

[0059] According to the function and safety specification of each assembly instruction in the assembly code, the informal requirements of the corresponding assembly instruction are determined, and then the formal logical expression of each assembly instruction is generated in combination with the model defined in step S101, so as to obtain the formal specification.

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

[0061] Most of the formal verification based on theorem proof uses program logic as the theoretical basis to deduce the proposition that "the system satisfies the specification". Hoare logic is a classic program logic used for theorem proof, and the verification object is a sequential program. In Hoare logic, each command C has a precondition P and a postcondition Q associated with it. The precondition P describes the state before the program is executed, and the postcondition Q describes the state after the program is executed. Hoare logic provides a set of inference rules that allow the proof of program correctness to be derived by combining these triples. In state S0, the precondition Q0 is true, and after executing instruction C1, state S1 is reached, satisfying postcondition Q1; in state S1, the precondition Q1 is true, and after executing instruction C2, state S2 is reached. 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 the Hall logic, the Hall ternary formal assertion of the assembly instruction can be constructed, including the physical machine precondition, the state transition function of the assembly instruction and the physical machine postcondition. Next, the method of determining the formal specification is explained by taking the task context switching assembly code as an example. The specific method is:

[0064] Combined with the assembly code modeling in step S101, the precondition of the assembly code is given: the machine state W is a two-tuple of register group R and memory M. Then, the specific function of the assembly code to be verified is analyzed, and the machine state transition process is derived in combination with the instruction set and instruction semantics defined in the assembly code modeling in step S101, thereby giving the postcondition W' of the assembly code, which is a two-tuple of register group R' and memory M'.

[0065] For example, the task context switching assembly code has two functions: saving the current task context and restoring the new task context. It is necessary to push and pop the general registers and some special registers. Therefore, it is necessary to pay attention to the general register GR in the system modeling register group R, the elr in the special register SR el1 , sp el0 , sp el1 ,spsr el1 , the initial and final values ​​of pc, and the initial and final states of memory M.

[0066] Then the programming instructions for saving the task context need to satisfy the initial state and target state of the physical machine state in accordance with the specification, including:

[0067] Save the old task context context_save:

[0068] The preconditions are: the initial state of the register group is R: the initial value of the special register is 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] Postcondition: the register group end state is R': special register sp el1 and the value of general register x0 is sp old -272, the value of the program counter pc is pc old +21. The memory end state is M': the value of memory address 248+8*i is the value of general register x i (where 0≤i≤30). Memory address sp old -256 is the value of the special register elr old . Memory address sp old -264 is the value of the special register sp el0_old , memory address sp old -272 is the value of the special register spsr old .

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

[0071]

[0072] Context_save

[0073]

[0074] Restore the new task context context_restore:

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

[0076] Postconditions: The register group ends in R'; the initial value of the special register is SR new , where SR includes elr el1 , sp el0 ,spsr el1 The value of the program counter pc is pc new , EL1 stack pointer register sp at exception level el1 The value of 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] A theorem prover is selected according to actual needs, and the recursive function of the simulated instruction executor and the formal logic expression of each assembly instruction are converted into the format defined by the formal language in the theorem prover, and formal verification is performed using the verification strategy 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 program specification and mathematical high-level language called Gallina, which is based on an expression language called Calculus of Inductive Constructions (CIC), which itself combines high-order logic and richly typed functional programming languages. Taking the Hall logic in this embodiment as an example, the formal verification method based on the Coq theorem prover is:

[0084] Convert the recursive function of the simulated instruction executor of the assembly code to be verified into the format defined by the formal language in Coq, and then use the Coq theorem prover to write the preconditions and postconditions in the Hall logic expression of each assembly instruction as a formal correctness lemma. Finally, use the verification strategy provided in the Coq theorem prover to perform formal verification to determine whether the executed assembly program satisfies the formal correctness lemma, thereby verifying the functional correctness and memory safety of the assembly program.

[0085] Although the above describes the illustrative specific embodiments of the present invention to facilitate 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 as defined and determined by the attached claims, these changes are obvious, and all inventions and creations using the concept of the present invention are protected.

Claims

1. A formal verification method for Armv8-a assembly code, characterized in that: The following steps are involved: S1: Analyze the processor architecture and instruction set system of Armv8-a, extract the various module components that need to be modeled, including exception level, execution status, data value, register group, memory, instruction set, 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 ordinary user application execution, EL1 is used for operating system kernel privilege level execution, EL2 is used for virtual machine hypervisor execution, and EL3 is used for secure world execution; define execution state types including AArch64 and AArch32. When in AArch64 state, the processor executes the A64 instruction set and uses 64-bit wide general registers; when in AArch32 state, the processor executes the A32 or T32 instruction set and uses 32-bit wide general registers; S1.2: Define the basic data value types including Boolean type, natural number type, integer type, rational number type, and expand on this to define 8-bit, 32-bit, 64-bit word lengths and corresponding byte types, 32-bit integer types, and 64-bit integer types based on the number of bits and range restrictions; S1.3: define the register set including the general register greq, the special register sreg, and the processor status psbit; finally define the register group module, including mapping the register set instance to the data value type in step 1.2, and provide symbolic representation to operate the mapping, including accessing the mapping value and updating the mapping value; S1.4: Memory data is defined based on basic data values, and each byte in the memory is mapped 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 read load and store operations; memory permission types include readable, writable, and readable and writable permissions; finally, Record is used to define the memory type to integrate the above contents; S1.5: Define the Armv8-a instruction set types to include data processing instructions, load and store instructions, flow control branch instructions, system control instructions, exception handling instructions, system register access instructions and pseudo instructions. 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 mode, including immediate addressing, register addressing, base addressing, front and back index addressing, and define load and store instructions based on this; flow control branch instructions include unconditional branch B, conditional branch BC, subroutine call and return BL, RET, exception return ERET; system control instructions include system register access instructions MRS, MSR; S1.6: Define the operation flow of each assembly instruction in the assembly code, including instruction fetching, parsing, and execution, and 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 status of registers and memory, thereby simulating the execution process of the assembly code; S2: Determine the informal requirements of the corresponding assembly instructions according to the functions and safety specifications of each assembly instruction in the assembly code, and then generate the formal logic expression of each assembly instruction in combination with the model defined in step S1, so as to obtain the formal specification; S3: Select a theorem prover according to actual needs, convert the recursive function of the simulated instruction executor and the formal logic expression 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, characterized in that: The specific steps of simulating the recursive function of the instruction executor in step S1.6 include: 1) Determine the number of assembly instructions, register sets, and memory status in the assembly code; 2) Determine whether the number of remaining assembly instructions is 0, if so, the execution ends, otherwise proceed to step 3); 3) Determine whether the PC register value is legal. If not, the execution ends, otherwise proceed to step 4); 4) Determine whether the assembly instruction block exists. If not, the execution ends, otherwise proceed to step S5); 5) Determine whether the assembly instruction exists. If not, the execution ends, otherwise go to step 6); 6) Call the assembly instruction execution function, execute the current assembly instruction, and then return to step 2).

3. The formal verification method according to claim 1, characterized in that: The logic expression in step S2 adopts the Hall 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: The theorem prover in step S3 adopts the Coq theorem prover.

Images