A semi-automatic firmware refinement relationship verification method and system

Abstract

This invention relates to a semi-automatic method and system for refining firmware relationships, comprising: S1, formal verification of the firmware abstract specification layer: First, modeling the firmware requirement interface document and performing attribute reduction, i.e., formal reduction; then, constraining the attribute reduction using first-order theory to generate an SMT expression file for the abstract specification layer; S2, formal verification of the firmware program execution specification layer; S3, SMT-LIB theory unification: through a semi-automatic method, converting both the SBI standard and program behavior into SMT expressions, and performing theoretical conversion and syntax unification on the converted SBI standard and program behavior; S4, formal verification of the SMT solver; S5, generating a verification report; S6, visualizing the verification report. This invention can effectively verify whether firmware meets requirement specifications and discover potential errors and security vulnerabilities.

Description

Technical Field

[0001] This invention relates to the field of formal verification methods, and in particular to a semi-automatic refinement relationship verification method and system for firmware. Background Technology

[0002] As software system complexity increases, ensuring program correctness and compliance with requirements specifications has become a significant challenge in software engineering. Firmware, in particular, serves as the bridge between the underlying hardware and the operating system, responsible for critical tasks such as kernel startup and low-level hardware initialization. Therefore, ensuring firmware correctness is extremely important.

[0003] Traditional testing methods struggle to cover all possible execution paths, failing to guarantee the complete correctness of the system. Formal verification, as a mathematically based verification technique, offers higher verification guarantees. However, existing dedicated program verification tools have limitations in expressiveness and flexibility. Isabelle / HOL is a powerful interactive theorem prover supporting higher-order logic, suitable for formal modeling and verification of complex systems. Symbolic execution tools support first-order logic, automatically exploring all possible execution paths of the program through symbolic input, generating path conditions, and helping to discover potential errors in the program. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides a semi-automatic method for refining and verifying firmware relationships.

[0005] Leveraging the advantages of Isabelle / HOL and symbolic execution tools, this invention generates standard SMT (Satisfiability Modulo Theories) expressions based on a unified theoretical strategy. Then, an SMT solver is used to verify the consistency between the program and the requirement specifications, thereby ensuring the completeness of the verification of the refined relationship between the abstract specification layer and the executable specification layer of the SBI firmware. This verification method performs complete formal verification of the firmware from both the requirement and program implementation perspectives. Consistency ensures that the firmware program is written entirely according to the requirements, further guaranteeing the firmware's correctness and security. Furthermore, the semi-automated verification method further reduces the formal verification knowledge requirements for researchers, significantly improving firmware formal development efficiency and having profound significance for research and development in the field of operating system firmware security.

[0006] This invention provides a semi-automatic firmware refinement relationship verification system.

[0007] Terminology Explanation:

[0008] 1. Isabelle / HOL: 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: This is a program analysis technique whose core idea is to treat program input as symbolic variables rather than specific numerical values. By symbolizing the input, symbolic execution simulates the program's execution path, generating symbolic expressions and path conditions related to the input and program state.

[0010] 3. Higher-order logic: This is a logic system that allows for the quantification of functions and predicates; that is, functions can be passed as parameters or returned. Higher-order logic extends the expressive power of first-order logic, enabling the description of more complex mathematical and computational concepts.

[0011] 4. SMT (Satisfiability Modulo Theories) is a problem involving determining the satisfiability of logical formulas under a specific theory. SMT extends the Boolean satisfiability problem (SAT) by introducing a variety of rich theories, such as integer arithmetic, arrays, bit vectors, and floating-point numbers.

[0012] 5. KLEE, a symbolic analysis tool: This 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 programs and explore all possible paths of the program by generating symbolic input, thereby discovering potential errors such as memory overflows, null pointer references, and deadlocks.

[0013] 6. LLVM IR Decompiler: This 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. During the compilation process, it is used to represent the program's control flow, data flow, and other information, existing between the source code and machine code.

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

[0015] A semi-automatic firmware refinement relationship hybrid verification method, based on Isabelle / HOL and symbolic execution tools, includes:

[0016] S1. Formal verification of the firmware abstract specification layer: First, model the firmware requirement interface document based on Isabelle / HOL and perform attribute reduction, i.e., formal reduction; then, use first-order theory to constrain the attribute reduction and generate the SMT expression file of the abstract specification layer, with the file type being SMT-LIB.

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

[0018] S3 and SMT-LIB Theoretical Consistency: Through a semi-automatic approach, both the SBI standard and program behavior are converted into SMT expressions, and the SBI standard and program behavior converted into SMT expressions are theoretically converted and syntactically unified.

[0019] S4, SMT Solver Formal Verification: Using the SMT solver, the satisfiability of the unified SMT expression is verified to determine whether the firmware program meets the requirements specifications.

[0020] S5. Generate Verification Report: Output the verification results of the SMT solver; if the verification is successful, output the verification success and execution path; if the verification fails, output the execution path and counterexamples that caused the verification failure.

[0021] S6. Visualize the verification report.

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

[0023] According to a preferred embodiment of the present invention, in step S1, the Sleghammer parser built into the Isabelle / HOL tool is used to constrain the attribute specification using first-order theory to generate an SMT expression file for the abstract specification layer.

[0024] According to a preferred embodiment of the present invention, in step S2, a formal verification at the specification level is performed on the C language file of the firmware program; including:

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

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

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

[0028] Finally, the formal reduction of the intermediate language IR is input 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, which includes path conditions and logical constraints.

[0029] Furthermore, during symbolic execution, KLEE uses the 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] Further, in step S2, a formal verification at the specification level is performed on the assembly file of the firmware program; including:

[0031] The assembly file of the firmware program is decompiled using the LLVM IR decompiler, converting the assembly code into LLVM IR. After obtaining the LLVM IR, it is input into the symbolic execution tool KLEE. KLEE explores all reachable states and generates the corresponding SMT expression for each path.

[0032] Furthermore, the SMT expressions obtained from the C language files of the firmware program under different paths are merged with the SMT expressions obtained from the assembly files of the firmware program under different paths to obtain the abstract SMT expression corresponding to the firmware program.

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

[0034] Furthermore, in step S3, syntax unification is achieved by standardizing variable naming in SMT-LIB, unifying function and predicate symbols, and eliminating syntax differences.

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

[0036] Furthermore, in step S4, the SMT solver is used for verification: the SMT solver is called to verify the feasibility of the verification conditions. If the conditions are not met, it indicates that the program does not meet the requirements specifications.

[0037] A computer device includes a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the steps of a semi-automatic refinement relationship hybrid verification method for firmware.

[0038] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of a semi-automatic refinement relationship hybrid verification method for firmware.

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

[0040] The firmware abstract specification layer formal verification module is configured as follows: First, it models the firmware requirement interface document based on Isabelle / HOL and performs attribute reduction, i.e., formal reduction; then, it uses first-order theory to constrain the attribute reduction and generates the SMT expression file of the abstract specification layer, with the file type being SMT-LIB.

[0041] 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;

[0042] The SMT-LIB theory unification module is configured to: convert SBI standards and program behaviors into SMT expressions in a semi-automatic manner, and perform theoretical conversion and syntax unification on the SBI standards and program behaviors converted into SMT expressions;

[0043] The SMT solver formal verification module is configured to: use the SMT solver to perform satisfiability verification on the unified SMT expression and determine whether the firmware program meets the requirements specification.

[0044] The verification report generation and visualization module is configured to: output the verification results of the SMT solver; if the verification is successful, output the verification success and execution path; if the verification fails, output the execution path and counterexamples that caused the verification failure; and visualize the verification report.

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

[0046] 1. This invention unifies and transforms the SMT expressions generated by Isabelle / HOL and symbolic execution tools to ensure compatibility, so that they can be verified in the SMT solver.

[0047] 2. This invention has high expressive power: By combining Isabelle / HOL's high-order logic and comprehensive path exploration of symbolic execution, it can accurately describe and verify complex firmware behavior and security attributes.

[0048] 3. This invention further improves verification efficiency: Semi-automated SMT expression generation and standardization reduce manual operations and improve verification efficiency. Simultaneously, using IR language for formal verification simplifies the logical complexity of the code and reduces the difficulty of formal specification.

[0049] 4. This invention can adapt to complex systems: it can handle firmware-specific features, such as privilege level management and hardware interaction, thus making up for the shortcomings of dedicated verification tools.

[0050] 5. This invention can further discover potential vulnerabilities in firmware: through formal verification, it can discover logical errors and security vulnerabilities that are difficult to detect using traditional testing methods. Attached Figure Description

[0051] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the structures shown in these drawings without creative effort.

[0052] Figure 1 This is a flowchart of a semi-automatic firmware refinement relationship hybrid verification method according to the present invention. Detailed Implementation

[0053] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0054] Example 1

[0055] A semi-automatic firmware refinement relationship hybrid verification method, based on Isabelle / HOL and symbolic execution tools, such as... Figure 1 As shown, it includes:

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

[0057] S2. Formal verification of firmware execution specification layer: Unlike other software, firmware code interacts with hardware, therefore its implementation includes C language and assembly language; to address this characteristic, this method uses multiple compilation tools (including LLVMIR) to achieve a unified specification representation in different languages;

[0058] S3 and SMT-LIB Theoretical Consistency: Through semi-automatic methods, both the SBI standard and program behavior are converted into SMT expressions, and the SBI standard and program behavior converted into SMT expressions are theoretically transformed and syntactically unified to ensure compatibility;

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

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

[0061] S4, SMT Solver Formal Verification: Using the SMT solver, the satisfiability of the unified SMT expression is verified 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 execution path; if the verification fails, output the execution path and counterexamples that caused the verification failure; so as to guide developers to further modify the firmware system and improve development efficiency.

[0063] S6. Visualize the verification report.

[0064] Example 2

[0065] The semi-automatic refinement relationship hybrid verification method for firmware described in Example 1 differs in that:

[0066] In step S1, firmware requirement interface documents are modeled based on Isabelle / HOL. Specifically, Isabelle / HOL is used to formally specify the firmware requirement interfaces, transforming the firmware requirement specifications into a formal mathematical model. This formal specification describes and verifies the behavior of the firmware interfaces. The firmware requirement interfaces include: input parameters and output specifications for each function, as well as the function behavior defined by the interface standard. The specification content includes security attributes. In detail, the description of the firmware requirement interfaces (including function input parameters, output specifications, interface standard behavioral requirements, and security attributes) is transformed into operable logical expressions, enabling verification within the Isabelle / HOL environment.

[0067] Regarding the firmware requirement interface content mentioned in step S1, the following example is taken as an example of the SBI interface standard under the RISC-V architecture:

[0068] The SBI firmware's clock setting function, sbi_set_timer, is defined as follows:

[0069] struct sbiret sbi_set_timer(uint64_t stime_value)

[0070] This interface is configured to accept an input parameter of type unint64_t, named stime_value. The function sets the clock for the next time interval after stime_value, where stime_value is an absolute time. Furthermore, this function must clear any pending timer interrupt bits. The function returns a value of type sbiret, defined as follows:

[0071]

[0072] This structure defines a sbiret containing a long type error and a value, along with the error code and its value.

[0073] The definitions of error and value in the interface standard are shown in Table 1:

[0074] Table 1

[0075]

[0076]

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

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

[0079]

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

[0081] In Isabelle / HOL, "fun" represents a function definition: This method uses numerical values ​​to represent the order of privilege levels: 0 represents the user mode level; 1 represents the supervisor mode level; and 2 represents the machine mode level.

[0082]

[0083] To simulate the access control policy during RISC-V SBI execution, this method defines the privilege levels for each standard interface to access the `access_allowed` function. Simultaneously, to simulate real-world system operation and facilitate research on the SBI's access control policy, this method defines an independent `can_invoke` function to simulate whether the access control policy is truly secure under different privileged execution conditions.

[0084]

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

[0086]

[0087] In Isabelle / HOL, the theorem represents the theorem to be verified, which is also a specification of the verification attribute: This method verifies the correctness of the access control policy of the SBI standard. The access control policy specification is implemented 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 included in the Isabelle / HOL tool is used to constrain the attribute reduction using first-order theory, generating the SMT expression file for the abstract specification layer. Specifically, this includes:

[0089] Sledgehammer uses the objective theorems and constraints defined in Isabelle / HOL to parse and solve these constraints using external tools (such as Z3). Sledgehammer transforms 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, typically including variables, constraints, and propositional logic.

[0090] SMT-LIB files are standardized representation file formats used to describe SMT problems. They typically include the following: Variable declarations: Symbolic variables are defined in the file (e.g., firmware inputs, outputs, state variables, etc.). Logical constraints: Mathematical constraints describing the behavioral requirements and properties of the firmware model, such as constraints on certain state changes, input-output relationships, etc. Solution objectives: During verification, the solver will attempt to prove whether these constraints are consistent or whether any property violations exist.

[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 attributes.

[0092] In step S2, a formal verification at the specification level is performed on the C language file of the firmware program; this includes:

[0093] First, the C language source code is subjected to lexical analysis, syntax analysis, and semantic analysis using the LLVM compiler to generate an abstract syntax tree (AST). The lexical analysis phase uses a lexical analyzer to decompose the source code into tokens, identifying basic syntactic units such as keywords, operators, and identifiers. The syntax analysis phase uses a parser to check whether the token stream conforms to grammatical rules and constructs the abstract syntax tree, where each node represents the program's syntactic structure. The semantic analysis phase verifies the logical correctness of the code using a symbol table and a type checker, ensuring, for example, the correct use of variables and functions and type matching.

[0094] Then, the program representation is transformed into an intermediate language (IR) in three-address code form. This process involves progressively breaking down the nodes of the AST into triplet operations, such as transforming the assignment statement a = b + c into t1 = b + c; a = t1, and representing it in three-address code form. Complex control and data flows (such as conditional statements and loops) are also decomposed into basic operation sequences, making the intermediate representation easier to optimize and verify.

[0095] Next, formal specifications are written using Lips based on the intermediate language IR for normalization. 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, the formal reduction of the intermediate language (IR) is input into the symbolic analysis tool KLEE to perform symbolic execution on the IR, exploring all possible execution paths. Specifically, KLEE symbolizes execution variables starting from the program entry point, generates different paths for conditional statements and branch structures, and dynamically calculates symbolic expressions along 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 utilizes an SMT solver (such as Z3) to solve the SMT expressions of the paths to verify whether the program meets expected properties or whether there are potential errors. Through this process, the logical correctness, security properties, and functional behavior of firmware programs can be systematically verified, ensuring that their design and implementation meet the requirements specifications. Symbolic execution covers all possible execution paths, providing robust formal verification support.

[0098] In step S2, a specification-level formal verification is performed on the assembly file of the firmware program; including:

[0099] The LLVM IR decompiler is used to decompile the assembly files of the firmware program, converting the assembly code into LLVM IR (intermediate representation). The decompilation process involves parsing assembly instructions and transforming them into a more abstract intermediate language (LLVM IR), which is easier to analyze, optimize, and verify. The decompiled intermediate language IR still contains the basic structure and control flow of the program, but it is not dependent on specific hardware architectures, allowing symbolic execution tools (such as KLEE) to perform subsequent analysis more efficiently.

[0100] After obtaining the LLVM IR, it is input into the symbolic execution tool KLEE. KLEE explores all reachable states and generates corresponding SMT expressions for each path. KLEE uses symbolic execution to simulate the program's execution process. For each control flow path, KLEE generates SMT constraints representing the conditions of that path. These SMT expressions reflect the constraints of the program under different execution paths, such as variable values, branch conditions, and the choice of execution path. 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] The SMT expressions obtained from different paths of the C language files of the firmware program and the SMT expressions obtained from different paths of the assembly files of the firmware program are merged to obtain the abstract SMT expression corresponding to the firmware program.

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

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

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

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

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

[0107] The final merged result is an abstract SMT expression that incorporates the behavior of C language and assembly code, and can fully reflect the control flow and data flow characteristics of the program.

[0108] In step S3, it is crucial to ensure that Isabelle / HOL and the SMT expressions generated by symbolic execution tools (such as KLEE) use the same logical theory. Typically, SMT expressions use integer arithmetic theory and array theory to describe program behavior, and Isabelle / HOL also has corresponding theoretical support. Therefore, this invention needs to ensure that the SMT expressions generated by Isabelle / HOL and symbolic execution tools use the same logical theory: integer arithmetic and array theory. Theoretical conversion includes:

[0109] 1) Integer Arithmetic: Expressions involving integer variables (such as addition, subtraction, comparisons, etc.) require ensuring that the same integer arithmetic theory is used in both Isabelle / HOL and the SMT solver. In Isabelle / HOL, integer arithmetic can be modeled using HOL-Integer theory, while in SMT expressions, integer types and basic operators (such as +, -, <, =, etc.) are typically used for description.

[0110] 2) Array Theory: If array operations (such as indexing, assignment, etc.) are involved in the program, array theory should be used consistently in Isabelle / HOL and SMT expressions. In Isabelle / HOL, arrays can be modeled using the Array module, while SMT expressions use operations similar to select and store to represent array reading and updating.

[0111] 3) Conversion Process: The conversion between Isabelle / HOL and SMT expressions in terms of integer arithmetic and array operations is accomplished by mapping the arithmetic and array operations in SMT-LIB expressions to their corresponding operations in Isabelle / HOL. This ensures that both are verified within the same theoretical framework.

[0112] In step S3, syntax unification involves standardizing variable naming in SMT-LIB, unifying function and predicate symbols, and eliminating syntactic differences. The goal of syntax unification is to eliminate syntactic differences between SMT expressions and Isabelle / HOL expressions, ensuring compatibility and comparability. Specifically, this includes:

[0113] 1) Standardize variable naming: Variable naming in SMT-LIB and Isabelle / HOL is inconsistent, therefore standardization is necessary. Unify the variable names in all SMT expressions to match those in Isabelle / HOL, avoiding matching issues caused by naming differences.

[0114] 2) Unified Function and Predicate Symbols: Function and predicate symbols (such as <=, +, etc.) in SMT-LIB and Isabelle / HOL may have different representations, requiring unified processing. Predefined mapping rules can be used to convert symbols in SMT-LIB to their corresponding symbols in Isabelle / HOL, ensuring symbol matching.

[0115] 3) Eliminating Syntactic Differences: SMT-LIB and Isabelle / HOL differ in their syntactic structures. For example, SMT expressions use parentheses, while Isabelle / HOL may use different structures. Therefore, syntactic unification converts SMT expressions into a form recognizable by Isabelle / HOL.

[0116] In step S4, the verification conditions for satisfiability verification are: combining the SMT expressions of the requirement specification and program behavior to form the verification conditions for satisfiability verification (such as logical implication relationships). The specific combination method is as follows:

[0117] 1) Requirements Specification SMT Expression: First, the requirements specification is formalized into an SMT expression, describing the expected program behavior. For example, it can be expressed as a security requirement under a certain condition, such as x>5.

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

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

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

[0121] 1) Logical Implication Relationship: This involves checking whether the SMT expression representing program behavior satisfies the SMT expression in the requirements specification. In other words, it checks whether the program behavior meets expected security, functionality, and other attributes. This can be represented by a logical implication relationship: Requirements Specification Program behavior, that is, whether the program behavior can meet the requirements specification.

[0122] 2) Satisfaction Verification: Finally, the SMT solver is used to verify the satisfiesness of the combined SMT expression, checking whether there is a solution that satisfies all constraints. If the solver returns "Satisfiable", it means that the program behavior meets the requirements specification; if it returns "Unsatisfiable", it means that the program behavior fails to meet the requirements specification.

[0123] This step ensures that the SBI firmware meets the predetermined requirements specifications during design and implementation, and covers all possible execution paths during symbolic execution, thus performing comprehensive satisfiability verification.

[0124] In step S4, the SMT solver is used for verification: the SMT solver is called to verify the feasibility of the verification conditions. If the conditions are not met, it indicates that the program does not meet the requirements specifications.

[0125] Example 3

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

[0127] Example 4

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

[0129] Example 5

[0130] A semi-automatic firmware refinement relationship hybrid verification system includes:

[0131] The firmware abstract specification layer formal verification module is configured as follows: First, it models the firmware requirement interface document based on Isabelle / HOL and performs attribute reduction, i.e., formal reduction; then, it uses first-order theory to constrain the attribute reduction and generates the SMT expression file of the abstract specification layer, with the file type being SMT-LIB.

[0132] 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;

[0133] The SMT-LIB theory unification module is configured to: convert SBI standards and program behaviors into SMT expressions in a semi-automatic manner, and perform theoretical conversion and syntax unification on the SBI standards and program behaviors converted into SMT expressions;

[0134] The SMT solver formal verification module is configured to: use the SMT solver to perform satisfiability verification on the unified SMT expression and determine whether the firmware program meets the requirements specification.

[0135] The verification report generation and visualization module is configured to: output the verification results of the SMT solver; if the verification is successful, output the verification success and execution path; if the verification fails, output the execution path and counterexamples that caused the verification failure; and visualize the verification report.

Claims

1. A semi-automatic refinement relationship 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, model the firmware requirement interface document based on Isabelle / HOL and perform attribute reduction, i.e., formal reduction; then, use first-order theory to constrain the attribute reduction and generate the SMT expression file of the abstract specification layer, with the file type being SMT-LIB. S2. Formal verification of firmware program execution specification layer: using multiple compilation tools to achieve a unified specification representation in different languages; S3 and SMT-LIB Theoretical Consistency: Through a semi-automatic approach, both the SBI standard and program behavior are converted into SMT expressions, and the SBI standard and program behavior converted into SMT expressions are theoretically converted and syntactically unified. S4. SMT Solver Formal Verification: Using the SMT solver, the satisfiability of the unified SMT expression is verified to determine whether the firmware program meets the requirements specifications. S5. Generate Verification Report: Output the verification results of the SMT solver; if the verification is successful, output the verification success and execution path; if the verification fails, output the execution path and counterexamples that caused the verification failure. S6. Visualize the verification report.

2. The semi-automatic refined relationship 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: the firmware requirement interface is formally specified using Isabelle / HOL. The firmware requirement interface includes: the input parameters, output specifications, and function behavior of each function; the specification content includes security attributes; specifically, it transforms the description of the firmware requirement interface into an operable logical expression.

3. The semi-automatic refinement relationship hybrid verification method for firmware according to claim 1, characterized in that, In step S1, the Sledgehammer parser built into the Isabelle / HOL tool is used to constrain the attribute reduction using first-order theory, generating the SMT expression file for the abstract specification layer.

4. The semi-automatic refined relationship hybrid verification method for firmware according to claim 1, characterized in that, In step S2, a formal verification at the specification level is performed on the C language file of the firmware program; this includes: First, lexical analysis, syntax analysis, and semantic analysis are performed on the C language source code using the LLVM compiler to generate an abstract syntax tree (AST). Then, the program representation is converted into an intermediate language (IR) in three-address code form; Next, based on the intermediate language IR, a formal specification is written using Lips for normalization description; Finally, the formal reduction of the intermediate language IR is input 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, which includes path conditions and logical constraints.

5. The semi-automatic refinement relationship hybrid verification method for firmware according to claim 1, characterized in that, During symbolic execution, KLEE uses the 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. In step S2, a formal verification at the specification level is performed on the assembly file of the firmware program; this includes: Use the LLVM IR decompiler to decompile the assembly files 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. KLEE explores all reachable states and generates the corresponding SMT expression for each path.

6. The semi-automatic refinement relationship hybrid verification method for firmware according to claim 1, characterized in that, The SMT expressions obtained from different paths of the C language files of the firmware program and the SMT expressions obtained from different paths of the assembly files of the firmware program are merged to obtain the abstract SMT expression corresponding to the firmware program. Merging includes path merging, symbolic expression merging, and merging of conditional relationships between paths.

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

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the semi-automatic refinement relationship hybrid verification method for firmware as described in any one of claims 1-7.

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

10. A semi-automatic firmware refinement and hybrid verification system, characterized in that, include: The firmware abstract specification layer formal verification module is configured as follows: First, it models the firmware requirement interface document based on Isabelle / HOL and performs attribute reduction, i.e., formal reduction; then, it uses first-order theory to constrain the attribute reduction and generates the SMT expression file of the abstract specification layer, with the file type being 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 SBI standards and program behaviors into SMT expressions in a semi-automatic manner, and perform theoretical conversion and syntax unification on the SBI standards and program behaviors converted into SMT expressions; The SMT solver formal verification module is configured to: use the SMT solver to perform satisfiability verification on the unified SMT expression and determine whether the firmware program meets the requirements specifications. The verification report generation and visualization module is configured to output the verification results of the SMT solver. If the verification is successful, output the verification success and execution path; if the verification fails, output the execution path and a counterexample that caused the verification to fail; and visualize the verification report.

Images