Semi-automatic refinement relation verification method and system for firmware

Abstract

The invention relates to a semi-automatic refinement relation verification method and system for firmware, and the method comprises the steps: S1, form verification of a firmware abstract specification layer: firstly, modeling a firmware demand interface document, and carrying out attribute specification, namely form specification; thirdly, constraining the attribute specification by using a first-order theory, and generating an SMT expression file of an abstract specification layer; s2, performing form verification of a specification layer by a firmware program; s3, SMT-LIB theoretical unification: converting the SBI standard and the program behavior into an SMT expression in a semi-automatic manner, and performing theoretical conversion and grammar unification on the SBI standard and the program behavior which are converted into the SMT expression; s4, performing SMT solver form verification; S5, generating a verification report; and S6, visualizing the verification report. According to the method, whether the firmware meets the requirement specification or not can be effectively verified, and potential errors and security vulnerabilities can be found.

Description

Technical Field

[0001] The present invention relates to the technical field of formal verification methods, and particularly to a semi-automatic refinement relation verification method and system for firmware. Background Art

[0002] With the increasing complexity of software systems, ensuring program correctness and meeting requirement specifications have become important challenges in software engineering. In particular, firmware, as the connection bridge between the underlying hardware and the operating system, is responsible for performing key tasks such as kernel startup and underlying hardware initialization. Thus, it is very important to ensure the correctness of firmware.

[0003] Traditional testing methods are difficult to cover all possible execution paths and cannot guarantee the complete correctness of the system. Formal verification, as a verification technology based on mathematical methods, can provide higher verification assurance. However, existing dedicated program verification tools have certain limitations in expressive power and flexibility. Isabelle / HOL is a powerful interactive theorem prover that supports Higher-Order Logic and is suitable for formal modeling and verification of complex systems. Symbolic execution tools support first-order logic and automatically explore all possible execution paths of a program by symbolically inputting, generating path conditions, which helps to discover potential errors in the program. Summary of the Invention

[0004] Aiming at the deficiencies of the prior art, the present invention provides a semi-automatic refinement relation verification method for firmware;

[0005] Based on the advantages of Isabelle / HOL and symbolic execution tools, the present invention generates standard SMT (Satisfiability Modulo Theories) expressions based on a unified theoretical strategy, and then uses an SMT solver to verify the consistency between the program and the requirement specifications, thereby ensuring the integrity of the refinement relation verification between the SBI firmware at the abstract specification layer and the executable specification layer. This verification method conducts formal verification of the complete firmware from the aspects of requirements and program implementation, and through consistency, it ensures that the firmware program is written exactly according to the requirements, further ensuring the correctness and security of the firmware. Moreover, the semi-automatic verification method further reduces the requirements for researchers' basic knowledge of formal verification, helps to greatly improve the development efficiency of firmware forms, and has great significance for the research and development of the firmware security field of the operating system.

[0006] The present invention provides a semi-automatic refinement relation verification system for firmware.

[0007] Term Explanation:

[0008] 1. Isabelle / HOL: It is a powerful interactive theorem prover, where HOL stands for Higher-Order Logic. Isabelle / HOL allows users to formally define data types, functions, and logical rules within the framework of higher-order logic and construct rigorous mathematical proofs.

[0009] 2. Symbolic execution: It is a program analysis technique whose core idea is to treat the input of a program as symbolic variables rather than specific numerical values. By symbolically inputting, symbolic execution simulates the execution paths of the program and generates symbolic expressions and path conditions regarding the input and program states.

[0010] 3. Higher-order logic: It is a logical system that allows quantification over functions and predicates, i.e., functions can be passed as parameters or returned. Higher-order logic extends the expressive power of first-order logic and can describe more complex mathematical and computational concepts.

[0011] 4. SMT (Satisfiability Modulo Theories): It is a problem related to determining the satisfiability of logical formulas under specific theories. SMT extends the Boolean satisfiability problem (SAT) and introduces various rich theories such as integer arithmetic, arrays, bit vectors, floating-point numbers, etc.

[0012] 5. The symbolic analysis tool KLEE: It is an open-source symbolic execution tool used to automatically detect errors and vulnerabilities in programs. Based on symbolic execution technology, it can analyze different execution paths of C language programs and explore all possible paths of the program by generating symbolic inputs, thereby discovering potential errors such as memory overflows, null pointer references, deadlocks, etc.

[0013] 6. LLVM IR decompiler: It is a tool used to convert LLVM Intermediate Representation (IR) code back to high-level source code (such as C / C++). LLVM IR is the intermediate language in the LLVM compiler framework, which is used to represent information such as the control flow and data flow of a program during compilation and lies between the source code and the machine code.

[0014] The technical solution of the present invention is as follows:

[0015] A semi-automatic refinement relation hybrid verification method for firmware, based on Isabelle / HOL and a symbolic execution tool, includes:

[0016] S1. Formal verification of the firmware abstract specification layer: First, the firmware requirement interface document is modeled based on Isabelle / HOL, and attribute specification, i.e. formal specification, is performed; then, the attribute specification is constrained using first-order theory to generate the SMT expression file of the abstract specification layer, and the file type is SMT-LIB;

[0017] S2, Formal verification of the firmware program execution specification layer: Use multiple compilation tools to achieve a unified specification representation in different languages;

[0018] S3, SMT-LIB theory unification: Convert SBI standards and program behaviors into SMT expressions in a semi-automatic way, and perform theoretical conversion and grammatical unification on the SBI standards and program behaviors converted into SMT expressions;

[0019] S4, SMT solver formal verification: Use the SMT solver to verify the satisfiability of the unified SMT expression to determine whether the firmware program meets the required specifications;

[0020] S5. Generate verification report: output the verification result of the SMT solver; if the verification is successful, output the verification success and the execution path; if the verification fails, output the execution path and the counterexample that caused the verification to fail;

[0021] S6. Visualization of verification report.

[0022] Furthermore, in step S1, the firmware requirement interface document is modeled based on Isabelle / HOL, that is: Isabelle / HOL is used to formally specify the firmware requirement interface; the firmware requirement interface includes: input parameters, output regulations, and function behaviors of each function; the specification content includes security attributes; specifically: the description of the firmware requirement interface is converted into an operable logical expression.

[0023] Preferably, according to the present invention, in step S1, the Sleghammer parser provided by the Isabelle / HOL tool is used to constrain the attribute specification using the first-order theory to generate an SMT expression file of the abstract specification layer.

[0024] Preferably, according to the present invention, in step S2, formal verification of the specification layer is performed on the C language file of the firmware program; including:

[0025] First, the LLVM compiler is used to perform lexical analysis, syntax analysis, and semantic analysis on the C language source code to generate an abstract syntax tree (AST).

[0026] Then, the program representation is converted into an intermediate language IR in the form of three-address code;

[0027] Next, based on the intermediate language IR, write a formal specification using Lips for normalization description;

[0028] Finally, input the formal specification of the intermediate language IR into the symbolic analysis tool KLEE to perform symbolic execution on the intermediate language IR and explore all possible execution paths; for each execution path, KLEE automatically constructs the corresponding SMT expression, and the SMT expression includes the path condition and logical constraints.

[0029] Furthermore, during the symbolic execution process, KLEE uses an SMT solver to solve the SMT expression of the path to verify whether the program meets the expected properties or whether there are potential errors.

[0030] Furthermore, in step S2, perform formal verification at the specification layer for the assembly file of the firmware program; including:

[0031] Use the LLVM IR decompiler to decompile the assembly file of the firmware program and convert the assembly code into LLVM IR; after obtaining the LLVM IR, input it into the symbolic execution tool KLEE, and the symbolic execution tool KLEE explores all reachable states and generates corresponding SMT expressions for each path.

[0032] Furthermore, merge the SMT expressions under different paths obtained from the C language file of the firmware program and the SMT expressions under different paths obtained from the assembly file of the firmware program to obtain the abstract SMT expression corresponding to the firmware program.

[0033] Furthermore, the merging includes path merging, symbolic expression merging, and merging of conditional relationships between paths.

[0034] Furthermore, in step S3, syntax unification: standardize the variable naming of SMT-LIB, unify function and predicate symbols, and eliminate syntax differences.

[0035] Furthermore, in step S4, the verification condition for satisfiability verification is: combine the SMT expressions of the requirement specification and the program behavior to form the verification condition for satisfiability verification.

[0036] Furthermore, in step S4, use an SMT solver to verify: call the SMT solver to verify the satisfiability of the verification condition. If it is not satisfiable, it means that the program does not meet the requirement specification.

[0037] A computer device includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements the steps of a semi-automatic refinement relation hybrid verification method for firmware.

[0038] A computer-readable storage medium stores a computer program thereon, and when the computer program is executed by a processor, it implements the steps of a semi-automatic refinement relation hybrid verification method for firmware.

[0039] A semi-automatic refinement relation hybrid verification system for firmware includes:

[0040] A formal verification module for the firmware abstraction specification layer is configured to: First, model the firmware requirement interface document based on Isabelle / HOL and perform attribute specification, i.e., formal specification; Then, use a first-order theory to constrain the attribute specification to generate an SMT expression file for the abstraction specification layer, and the file type is SMT-LIB.

[0041] A formal verification module for the firmware program execution specification layer is configured to: Use multiple compilation tools to achieve unified specification representation in different languages.

[0042] An SMT-LIB theory unification module is configured to: In a semi-automatic manner, convert both the SBI standard and program behavior into SMT expressions, and perform theory conversion and syntax unification on the SBI standard and program behavior converted into SMT expressions.

[0043] An SMT solver formal verification module is configured to: Use an SMT solver to perform satisfiability verification on the unified SMT expressions to determine whether the firmware program meets the requirement specifications.

[0044] A verification report generation and visualization module is configured to: Output the verification result of the SMT solver; If the verification is successful, output the verification success and the execution path; If the verification fails, output the execution path and the counterexample that causes the verification to fail; And implement the visualization of the verification report.

[0045] The beneficial effects of the present invention are as follows:

[0046] 1. The present invention unifies and converts the SMT expressions generated by Isabelle / HOL and symbolic execution tools to ensure compatibility for verification in an SMT solver.

[0047] 2. The present invention has high expressive power: Combining the higher-order logic of Isabelle / HOL and the comprehensive path exploration of symbolic execution can accurately describe and verify complex firmware behaviors and security attributes.

[0048] 3. The present invention can further improve the verification efficiency: The semi-automatic generation and unification of SMT expressions reduce manual operations and improve the verification efficiency. At the same time, the formal verification using the IR language simplifies the logical complexity of the code and reduces the difficulty of formal specification.

[0049] 4. The present invention can adapt to complex systems: It can handle the unique characteristics of firmware, such as privilege level management, hardware interaction, etc., making up for the deficiencies of dedicated verification tools.

[0050] 5. The present invention can further discover potential vulnerabilities existing in firmware: Through formal verification, it can discover logical errors and security vulnerabilities that are difficult to detect by traditional testing methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the following-described drawings are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on the structures shown in these drawings.

[0052] Figure 1 It is a flowchart of a semi-automatic refinement relation hybrid verification method for firmware according to the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0053] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0054] Embodiment 1

[0055] A semi-automatic refinement relation hybrid verification method for firmware, based on Isabelle / HOL and a symbolic execution tool, such as Figure 1 as shown, includes:

[0056] S1. Formal verification of the firmware abstract specification layer: First, model the firmware requirement interface document based on Isabelle / HOL for property specification, i.e., formal specification; then, use first-order theory to constrain the property specification to generate an SMT expression file in the abstract specification layer, and the file type is SMT-LIB.

[0057] S2. Formal verification of the firmware program execution specification layer: Different from other software, firmware code interacts with hardware, so the code implementation includes: C language and assembly language; for this characteristic, this method uses multiple compilation tools (including LLVM IR) to achieve unified specification representation in different languages.

[0058] S3. SMT-LIB theory unification: In a semi-automatic manner, convert both the SBI standard and program behavior into SMT expressions, and perform theory conversion and syntax unification on the SBI standard and program behavior converted into SMT expressions to ensure compatibility.

[0059] Program behavior refers to the control flow, data flow, state changes, etc. of a program, which is implemented through program code. For example, the behavior of the SBI firmware program includes how to receive and process inputs, how to run under different hardware states, how to generate specific outputs, etc.

[0060] Program behavior is then transformed into SMT expressions by modeling the control flow, data flow, etc. of the program. This involves the input and output of the program, state changes, error detection, etc. For example, the "when the input is A, the program should output B" in program behavior can be transformed into the constraint condition "input = A → output = B".

[0061] S4. Formal verification using the SMT solver: Use the SMT solver to perform satisfiability verification on the unified SMT expressions to determine whether the firmware program meets the requirements specifications;

[0062] S5. Generate verification report: Output the verification results of the SMT solver; if the verification is successful, output the verification success and the execution path; if the verification fails, output the execution path and the counterexample that causes the verification to fail; to facilitate guiding developers to further modify the firmware system and improve development efficiency;

[0063] S6. Visualize the verification report.

[0064] Embodiment 2

[0065] A semi-automatic refinement relation hybrid verification method for firmware according to Embodiment 1, which is characterized in that:

[0066] In step S1, model the firmware requirement interface document based on Isabelle / HOL, that is: use Isabelle / HOL to perform formal specification on the firmware requirement interface, transform the requirement specifications of the firmware into a formal mathematical model, and describe and verify the behavior of the firmware interface through formal specification; the firmware requirement interface includes: input parameters of each function, output regulations, and function behaviors specified by the interface standard; the specification content includes security attributes; specifically: transform the description of the firmware requirement interface (including input parameters of functions, output regulations, behavior requirements of the interface standard, and security attributes, etc.) into an operable logical expression. So that it can be verified in the Isabelle / HOL environment.

[0067] An example of the content of the firmware requirement interface mentioned in step S1: Take the SBI interface standard under the RISC-V architecture as an example:

[0068] The interface definition of the sbi_set_timer interface of the clock setting function of the SBI firmware is as follows:

[0069] struct sbiret sbi_set_timer(uint64_t stime_value)

[0070] This interface sets the input parameter as stime_value of type uint64_t. The function's functionality is as follows: After stime_value, it sets the clock for the next time. Here, stime_value is the absolute time. In addition, this function must clear the pending timer interrupt bit. The return value of the function is of type sbiret, defined as follows:

[0071]

[0072] This structure defines that sbiret contains the error code and its value of type long named error and value.

[0073] Among them, error and value are defined in the interface standard as shown in Table 1:

[0074] Table 1

[0075]

[0076]

[0077] Regarding the formal specification of the firmware requirement interface document mentioned in step S1, for example, the access control policy in the security specification:

[0078] Taking the access policy of the SBI firmware as an example, in the SBI standard requirements, the firmware runs in different privilege level modes. These privilege level modes are: user mode level, supervisor mode level, and machine mode level. According to the SBI standard regulations, the order of privilege levels is as follows: user mode level < supervisor mode level < machine mode level. Therefore, taking the Isabelle / HOL formal specification as an example:

[0079]

[0080] datatype represents data type definition in Isabelle / HOL: In this method, the privilege level privilege_level is defined as User (user mode level) | Supervisor (supervisor mode level) | Machine (machine mode level).

[0081] fun represents function definition in Isabelle / HOL: In this method, the order of privilege levels is represented numerically: 0 represents the user mode level; 1 represents the supervisor mode level; 2 represents the machine mode level.

[0082]

[0083] In order to simulate the access control policy during the execution of RISC-V SBI, this method defines the access_allowed function to access the specified privilege level of each standard interface. At the same time, in order to simulate the actual operation of the system and facilitate the study of the access control policy of SBI, this method defines the can_invoke independent function to simulate whether the access control policy is truly secure under different privilege execution conditions.

[0084]

[0085] After the specification is completed, formal verification is performed using Isabelle / HOL's automatic theorem prover auto.

[0086]

[0087] theorem in Isabelle / HOL represents the theorem to be verified, and is also a specification of the verification attribute: This method verifies the correctness of the access control policy of the SBI standard and implements the access control policy specification through the theorem unauthorized_access_prevented, that is, when the interface function and the current execution environment of the system do not meet the requirements, the actual behavior of the system does not fully meet the requirements.

[0088] In step S1, the Sleghammer parser provided by the Isabelle / HOL tool is used to constrain the attribute specification using the first-order theory to generate the SMT expression file of the abstract specification layer. Specifically, it includes:

[0089] Sledgehammer uses the target theorems and constraints defined in Isabelle / HOL, and parses and solves these constraints through external tools (such as Z3). Sledgehammer converts the types, theorems, and constraints defined in Isabelle / HOL into first-order logic expressions and generates corresponding SMT-LIB format files. These files record the required logical constraints and related mathematical expressions, usually including variables, constraints, propositional logic, etc.

[0090] The SMT-LIB file is a standardized expression file format used to describe SMT problems. It usually includes the following: Variable declaration: Symbolic variables are defined in the file (for example, firmware inputs, outputs, state variables, etc.). Logical constraints: Mathematical constraints that describe the behavioral requirements and properties of the firmware model, such as constraining certain state changes, input-output relationships, etc. Solution goal: During the verification process, the solver will try to prove whether these constraints are consistent or whether there are violations of the properties.

[0091] In this way, the formal verification of the abstract specification layer can be transformed into an SMT problem and verified by an efficient SMT solver (such as Z3, CVC4, etc.), further ensuring that the firmware design meets the predetermined requirements and security properties.

[0092] In step S2, for the C language files of the firmware program, perform the formal verification of the specification layer, including:

[0093] First, perform lexical analysis, syntax analysis, and semantic analysis on the C language source code based on the LLVM compiler to generate an Abstract Syntax Tree (AST). In the lexical analysis stage, the source code is decomposed into tokens by the Lexical Analyzer to identify basic syntax units such as keywords, operators, and identifiers. In the syntax analysis stage, the Parser checks whether the token stream conforms to the syntax rules and constructs an abstract syntax tree, where each node of the tree represents the syntax structure of the program. In the semantic analysis stage, the symbol table and type checker are used to verify the logical correctness of the code, such as ensuring the correct use of variables and functions and type matching.

[0094] Then, transform the program representation into an intermediate language IR in the form of three-address code. This process is achieved by gradually disassembling the nodes of the AST into triple operations. For example, the assignment statement a = b + c is transformed into t1 = b + c; a = t1 and represented in the form of three-address code. Complex control flows and data flows (such as conditional judgments and loops) are also decomposed into basic operation sequences to make the intermediate representation easy to optimize and verify.

[0095] Next, write a formal specification using Lips based on the intermediate language IR for normalized description. Lips is a formal language used to define the syntax and semantics of IR. By logically modeling the variables, operations, and constraints of the intermediate language, it is made suitable for further processing by formal verification tools. For example, variable type constraints, input-output relationships, and logical rules can be defined for the operations of IR.

[0096] Finally, input the formal specification of the intermediate language IR into the symbolic analysis tool KLEE to perform symbolic execution on the intermediate language IR and explore all possible execution paths. Specifically, KLEE starts symbolic execution of variables from the program entry point, generates different paths for conditional judgments and branch structures, and dynamically calculates symbolic expressions on the paths. For each execution path, KLEE automatically constructs the corresponding SMT expression, which includes path conditions (such as variable relationships and branch conditions) and logical constraints.

[0097] During symbolic execution, KLEE uses an SMT solver (such as Z3) to solve the SMT expressions of paths to verify whether the program meets the expected properties or whether there are potential errors. Through this process, the logical correctness, security properties, and functional behavior of the firmware program can be systematically verified to ensure that its design and implementation meet the requirements specifications, cover all possible execution paths during symbolic execution, and provide strong formal verification support.

[0098] In step S2, perform formal verification at the specification layer for the assembly file of the firmware program, including:

[0099] Use an LLVM IR decompiler to decompile the assembly file of the firmware program and convert the assembly code into LLVM IR (intermediate representation). The decompilation process involves parsing assembly instructions and converting them into a more abstract intermediate language (LLVM IR), which is more convenient for analysis, optimization, and verification. Among them, the decompiled intermediate language IR still contains the basic structure and control flow of the program but does not depend on a specific hardware architecture, enabling a symbolic execution tool (such as KLEE) to perform subsequent analysis more efficiently.

[0100] After obtaining the LLVM IR, input it to the symbolic execution tool KLEE. The symbolic execution tool KLEE explores all reachable states and generates corresponding SMT expressions for each path. KLEE uses symbolic execution to simulate the execution process of the program. For each control flow path, KLEE generates SMT constraints representing the conditions of that path. These SMT expressions reflect the constraint conditions of the program under different execution paths, such as variable values, branch conditions, and the selection of execution paths. Each path corresponds to a set of conditions, and the KLEE tool explores the possible behaviors and states of the program by solving these constraints.

[0101] Merge the SMT expressions under different paths obtained from the C language file of the firmware program and the SMT expressions under different paths obtained from the assembly file of the firmware program to obtain the abstract SMT expression corresponding to the firmware program.

[0102] The merging includes path merging, symbolic expression merging, and merging of conditional relationships between paths.

[0103] The purpose of merging these two sources of SMT expressions is to obtain a comprehensive abstract SMT expression representing all possible behaviors of the firmware program, specifically including:

[0104] 1) Path merging: Combine the path conditions generated by C language and assembly to form a comprehensive path constraint. For example, if a path constraint in C language code is x > 5 and a path constraint in assembly code is y < 10, the merged path constraint is x > 5 AND y < 10.

[0105] 2) Symbolic expression merging: Merge the SMT expressions generated by C language and assembly to construct a comprehensive expression. For the same variable, if there are constraints in both the C language path and the assembly path, it needs to be uniformly processed during merging to ensure the consistency of the constraints.

[0106] 3) Merging of conditional relationships between paths: By merging the two types of expressions, the symbolic execution paths of the firmware program can be unified to ensure that a complete symbolic constraint analysis is performed on each path.

[0107] The final merging result is an abstract SMT expression that includes the behaviors of C language and assembly code, and can comprehensively reflect the control flow and data flow characteristics of the program.

[0108] In step S3, it is very important to ensure that the SMT expressions generated by Isabelle / HOL and the symbolic execution tool (such as KLEE) use the same logical theory. Usually, SMT expressions use the integer arithmetic theory and the array theory to describe program behaviors, and Isabelle / HOL also has corresponding theoretical support. Therefore, the present invention needs to ensure that the SMT expressions generated by Isabelle / HOL and the symbolic execution tool use the same logical theory: integer arithmetic and array theory. Theory conversion; including:

[0109] 1) Integer arithmetic: For expressions involving integer variables (such as addition, subtraction, comparison, etc.), it is necessary to ensure that the same integer arithmetic theory is used in Isabelle / HOL and the SMT solver. In Isabelle / HOL, integer arithmetic can be modeled through the HOL-Integer theory, while in SMT expressions, integer types and basic operators (such as +, -, <, =, etc.) are usually used to describe.

[0110] 2) Array theory: If the program involves array operations (such as indexing, assignment, etc.), it is necessary to uniformly use the array theory in Isabelle / HOL and SMT expressions. In Isabelle / HOL, arrays can be modeled through the Array module, while SMT expressions represent array reading and updating through operations similar to select and store.

[0111] 3) Conversion process: The conversion between Isabelle / HOL and SMT expressions in aspects such as integer arithmetic and array operations is achieved by mapping the arithmetic and array operations in SMT-LIB expressions to the corresponding operations in Isabelle / HOL. This ensures that the verification is carried out within the same theoretical framework for both.

[0112] In step S3, syntax unification: Standardize the variable naming in SMT-LIB, unify function and predicate symbols, and eliminate syntax differences. The goal of syntax unification is to eliminate the syntax differences between SMT expressions and Isabelle / HOL expressions, ensuring that they are compatible and can be compared for verification. Specifically, it includes:

[0113] 1) Unify variable naming: The variable naming in SMT-LIB and Isabelle / HOL is inconsistent, so it is necessary to standardize the variable naming. Unify the variable names in all SMT expressions to be the same as those in Isabelle / HOL to avoid matching problems caused by naming differences.

[0114] 2) Unify function and predicate symbols: The function and predicate symbols (such as <=, +, etc.) in SMT-LIB and Isabelle / HOL may have different representations, and these symbols need to be unified. The symbols in SMT-LIB can be converted to the corresponding symbols in Isabelle / HOL through predefined mapping rules to ensure symbol matching.

[0115] 3) Eliminate syntax differences: There are differences in the syntax structures between SMT-LIB and Isabelle / HOL. For example, parentheses are used to represent expressions in SMT expressions, while Isabelle / HOL may use different structures to express. Therefore, syntax unification converts SMT expressions into a form recognizable by Isabelle / HOL.

[0116] In step S4, the verification condition for satisfiability verification is: Combine the SMT expressions of the requirements specification and the program behavior to form the verification condition for satisfiability verification (such as logical implication relationship). The specific combination method is as follows:

[0117] 1) SMT expression of requirements specification: First, the requirements specification is formalized as an SMT expression to describe the expected program behavior. For example, it can be expressed as a security requirement under certain conditions, such as x > 5.

[0118] 2) SMT expression of program behavior: The actual behavior of the program is described by the SMT expression generated by a symbolic execution tool (such as KLEE), reflecting the state constraints during the actual operation of the program.

[0119] Specific combination method: Combine the SMT expressions of the requirements specification and the program behavior to form comprehensive verification conditions. When combining, use logical operators (such as AND, OR) to connect the two SMT expressions. For example, if the requirements specification requires x > 5 and the program behavior constraint is x <= 10, the combined verification condition is: (x > 5) AND (x <= 10).

[0120] The combined verification conditions form the core of the satisfiability verification. By checking these verification conditions, it can be verified whether the requirements specification can be derived from the behavior of the program. The specific process of checking the verification conditions is as follows:

[0121] 1) Logical implication relationship: It is necessary to check whether the SMT expression of the program behavior satisfies the SMT expression of the requirements specification. That is, check whether the program behavior meets the expected properties such as security and functionality. It can be represented by the logical implication relationship: requirements specification program behavior, that is, whether the program behavior can meet the requirements specification.

[0122] 2) Satisfiability verification: Finally, use the SMT solver to perform satisfiability verification on the combined SMT expression to check whether there is a solution that satisfies all constraints. If the solver returns "satisfiable", it means that the program behavior conforms to the requirements specification; if it returns "unsatisfiable", it means that the program behavior fails to meet the requirements specification.

[0123] Through this step, it can be ensured that the SBI firmware program meets the predetermined requirements specification during design and implementation, and covers all possible execution paths during symbolic execution for comprehensive satisfiability verification.

[0124] In step S4, use the SMT solver to verify: Call the SMT solver to verify the satisfiability of the verification conditions. If it is unsatisfiable, it means that there is a situation where the program does not meet the requirements specification.

[0125] Embodiment 3

[0126] A computer device, including a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements the steps of a semi-automatic refinement relationship hybrid verification method for firmware described in Embodiment 1 or 2.

[0127] Embodiment 4

[0128] A computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it implements the steps of a semi-automatic refinement relationship hybrid verification for firmware described in Embodiment 1 or 2.

[0129] Embodiment 5

[0130] A semi-automatic refined relationship hybrid verification system for firmware, comprising:

[0131] A formal verification module for the firmware abstraction specification layer, configured to: First, model the firmware requirement interface document based on Isabelle / HOL, and perform property specification, i.e., formal specification; Then, use first-order theory to constrain the property specification to generate an SMT expression file in the abstract specification layer, and the file type is SMT-LIB;

[0132] A formal verification module for the firmware program execution specification layer, configured to: Use a variety of compilation tools to achieve unified specification representation in different languages;

[0133] An SMT-LIB theory unification module, configured to: Convert both the SBI standard and program behavior into SMT expressions in a semi-automated manner, and perform theory conversion and syntax unification on the SBI standard and program behavior converted into SMT expressions;

[0134] An SMT solver formal verification module, configured to: Use an SMT solver to perform satisfiability verification on the unified SMT expressions to determine whether the firmware program meets the requirement specifications;

[0135] A verification report generation and visualization module, configured to: Output the verification results of the SMT solver; If the verification is successful, output the verification success and the execution path; If the verification fails, output the execution path and the counterexample that causes the verification to fail; And realize the visualization of the verification report.

Claims

1. A semi-automatic refined relation hybrid verification method for firmware, characterized in that: Based on Isabelle / HOL and symbolic execution tools, including: S1. Formal verification of the firmware abstract specification layer: First, the firmware requirement interface document is modeled based on Isabelle / HOL, and attribute specification, i.e. formal specification, is performed; then, the attribute specification is constrained using first-order theory to generate the SMT expression file of the abstract specification layer, and the file type is SMT-LIB; S2, Formal verification of the firmware program execution specification layer: Use multiple compilation tools to achieve a unified specification representation in different languages; S3, SMT-LIB theory unification: Convert SBI standards and program behaviors into SMT expressions in a semi-automatic way, and perform theoretical conversion and grammatical unification on the SBI standards and program behaviors converted into SMT expressions; S4, SMT solver formal verification: Use the SMT solver to verify the satisfiability of the unified SMT expression to determine whether the firmware program meets the required specifications; S5. Generate verification report: output the verification result of the SMT solver; if the verification is successful, output the verification success and the execution path; if the verification fails, output the execution path and the counterexample that caused the verification to fail; S6. Visualization of verification report.

2. A semi-automatic refined relation hybrid verification method for firmware according to claim 1, characterized in that: In step S1, the firmware requirement interface document is modeled based on Isabelle / HOL, that is, Isabelle / HOL is used to formally specify the firmware requirement interface; The firmware requirement interface includes: input parameters, output specifications, and function behaviors of each function; the specification content includes security attributes; specifically: converting the description of the firmware requirement interface into an operable logical expression.

3. A semi-automatic refined relation hybrid verification method for firmware according to claim 1, characterized in that: In step S1, the Sleghammer parser provided by the Isabelle / HOL tool is used to constrain the attribute specification using the first-order theory to generate an SMT expression file of the abstract specification layer.

4. A semi-automatic refined relation hybrid verification method for firmware according to claim 1, characterized in that: In step S2, formal verification of the specification layer is performed on the C language file of the firmware program, including: First, the LLVM compiler is used to perform lexical analysis, syntax analysis, and semantic analysis on the C language source code to generate an abstract syntax tree (AST). Then, the program representation is converted into an intermediate language IR in the form of three-address code; Next, a formal specification is written using Lips based on the intermediate language IR for standardized description; Finally, the formal specification of the intermediate language IR is input into the symbolic analysis tool KLEE, and symbolic execution is performed on the intermediate language IR to explore all possible execution paths; for each execution path, KLEE automatically constructs the corresponding SMT expression, which includes path conditions and logical constraints.

5. A semi-automatic refined relation hybrid verification method for firmware according to claim 1, characterized in that: During the symbolic execution process, KLEE uses an SMT solver to solve the SMT expression of the path to verify whether the program meets the expected properties or whether there are potential errors; Further preferably, in step S2, formal verification of the specification layer is performed on the assembly file of the firmware program; including: Use LLVM IR decompiler to decompile the assembly file of the firmware program and convert the assembly code into LLVMIR; After obtaining the LLVM IR, it is input into the symbolic execution tool KLEE. The symbolic execution tool KLEE explores all reachable states and generates corresponding SMT expressions for each path.

6. A semi-automatic refined relation hybrid verification method for firmware according to claim 1, characterized in that: Merge the SMT expressions under different paths obtained for the C language files of the firmware program and the SMT expressions under different paths obtained for the assembly files of the firmware program to obtain an abstract SMT expression corresponding to the firmware program; Further preferably, the merging includes path merging, symbolic expression merging and conditional relationship merging between paths.

7. A semi-automatic refined relation hybrid verification method for firmware according to claim 1, characterized in that: In step S3, syntax unification: standardize the variable naming of SMT-LIB, unify the function and predicate symbols, and eliminate syntax differences; In step S4, the verification condition of the satisfiability verification is: combining the requirement specification and the SMT expression of the program behavior to form the verification condition of the satisfiability verification; In step S4, the SMT solver is used for verification: the SMT solver is called to verify the satisfiability of the verification conditions. If the conditions are not satisfied, it means that the program does not meet the requirement specifications.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of a semi-automatic refined relation hybrid verification method for firmware as described in any one of claims 1-7 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of a semi-automatic refined relation hybrid verification method for firmware as described in any one of claims 1-7 are implemented.

10. A semi-automatic refined relation hybrid verification system for firmware, characterized in that: include: The firmware abstract specification layer formal verification module is configured as follows: first, the firmware requirement interface document is modeled based on Isabelle / HOL, and attribute specification is performed, i.e., formal specification; then, the attribute specification is constrained using first-order theory to generate an SMT expression file of the abstract specification layer, and the file type is SMT-LIB; The firmware program execution specification layer formal verification module is configured to: use multiple compilation tools to achieve a unified specification representation in different languages; The SMT-LIB theory unification module is configured to: convert both SBI standards and program behaviors into SMT expressions in a semi-automatic way, and perform theory conversion and syntax unification on the SBI standards and program behaviors converted into SMT expressions; The SMT solver formal verification module is configured to: utilize the SMT solver to perform satisfiability verification on the unified SMT expression to determine whether the firmware program meets the requirement specifications; The verification report generation and visualization module is configured to: output the verification results of the SMT solver; If the verification succeeds, the verification success and execution path are output; if the verification fails, the execution path and the counterexample that caused the verification to fail are output; and the verification report is visualized.

Images