Method and apparatus for bounded model detection of rust programs

Abstract

The present application belongs to the technical field of computer technology and Rust program bound model detection technology, and relates to a Rust program bound model detection method and device. The method comprises the following steps: obtaining MIR intermediate representation of a Rust program, and preprocessing the MIR intermediate representation; performing ownership-sensitive static analysis on the preprocessed MIR intermediate representation to generate a verification condition; performing slice optimization on the verification condition to obtain a simplified verification condition; and solving the simplified verification condition by using an SMT solver, and generating a verification report according to the solving result. The present application performs bound model detection based on MIR, reduces information loss and potential errors in the conversion process, and improves the accuracy and efficiency of verification; the ownership-sensitive static analysis reduces the uncertainty of the abstract state, and improves the analysis accuracy; the ownership semantics is used to simplify the verification condition, which can significantly reduce the size of the logical formula to be solved, and improve the verification efficiency.

Description

Technical Field

[0001] This invention belongs to the field of computer technology and Rust program bounding model detection technology, specifically relating to a method and apparatus for detecting the bounding model of a Rust program. Background Technology

[0002] The technical terms involved in this invention are explained as follows: Intermediate representation: A representation between the source code and the target code during program compilation, used for code analysis and optimization.

[0003] Formula: In formal verification, a logical expression used to describe the properties and constraints of a program.

[0004] Encoding: The process of converting the semantics and properties of a program into a formal logical formula.

[0005] Solver: An automated reasoning tool used to solve logical formulas in formal verification.

[0006] Rust: A systems programming language known for its memory safety, concurrency safety, and high performance. Rust's core innovation lies in its ownership system, which performs compile-time checks to ensure memory safety.

[0007] Ownership: A core concept in the Rust programming language that defines a set of rules for managing memory. Ownership rules include: every value has a variable called its owner; a value can only have one owner at any given time; and a value is automatically released when the owner goes out of scope.

[0008] Safe Mode: In Rust programs, code written without the `unsafe` keyword will be strictly protected by the compiler in this mode, which will enforce ownership and borrowing rules to ensure memory safety.

[0009] Unsafe Mode: In Rust programs, code written using the `unsafe` keyword will not be subject to borrow checks by the compiler in this mode, requiring the programmer to manually ensure memory safety.

[0010] Traits: In Rust, a set of method interfaces is used to define shared behavior. Programmers can implement corresponding traits for different types. Through the trait mechanism, code can handle different types in a uniform way while maintaining the characteristics of static dispatch and zero-cost abstraction.

[0011] Lifetime: A compile-time concept in the Rust language used to ensure the validity of references. Lifetime describes the range of time a reference remains valid within its scope. The compiler uses lifetime analysis to prevent memory safety issues such as dangling references.

[0012] Borrowing Rules: Part of Rust's ownership system, these rules define how to access values ​​without acquiring ownership. Borrowing rules include: only one mutable reference or multiple immutable references can exist at a time, but mutable and immutable references cannot coexist; and references must always be valid.

[0013] MIR: Mid-level Intermediate Representation. An intermediate representation used internally by the Rust compiler, situated between the high-level abstract syntax tree and the low-level LLVM intermediate representation. MIR preserves important information such as Rust's type information and ownership semantics, making it an ideal representation for analyzing and verifying Rust programs. MIR employs a control flow graph structure, making it suitable for static analysis and verification.

[0014] GOTO-C: An intermediate representation format for C language used in formal verification.

[0015] LLVM: Low Level Virtual Machine. A widely used compiler infrastructure project that provides a set of intermediate representations and optimization toolchains. LLVM intermediate representations are typed, statically single-assignmented intermediate representations used by compilers for various programming languages.

[0016] Bounded Model Checking (BMC) is a formal verification technique that uses a Satisfiability Modular Theory (SMT) solver to check whether a program satisficing a specified property within a limited number of steps by converting the program into a logical formula and setting an upper limit on the number of execution steps. BMC enables in-depth verification of a program with reasonable computational resources.

[0017] Verification Condition (VC). The process of converting static analysis results into logical formulas solvable by the SMT solver. A verification condition represents the encoding of the property to be verified, and is usually a negation of that property encoding.

[0018] SMT Solver: Satisfiability Modulo Theories Solver. An automated reasoning tool used to determine the satisfiability of first-order logic formulas under specific theories (such as integers, arrays, bit vectors, etc.).

[0019] SAT: Satisfiable. In satisfiability theory and formal verification, SAT indicates that a logical formula has at least one solution. When the SMT solver returns SAT, it means that the verification condition is satisfied, i.e., there is a path in the program that violates the property (error found).

[0020] UNSAT: Unsatisfiable. In satisfiability theory and formal verification, UNSAT indicates that the logical formula has no solution. When the SMT solver returns UNSAT, it means that the verification condition is unsatisfiable, i.e., the program satisfies the specified property within the given boundaries (no errors were found).

[0021] UNKNOWN: Unknown. In satisfiability theory and formal verification, UNKNOWN indicates that the solver cannot determine the satisfiability of a logical formula within given time and resource constraints. This typically occurs when the problem is too complex or times out.

[0022] Static analysis: A technique that infers program properties by analyzing program code without executing the program. Static analysis can be used to detect potential errors, verify the nature of a program, and optimize program performance.

[0023] Ownership-Sensitive Static Analysis (OSA) is a static analysis technique specifically designed for Rust programs. During static analysis, it explicitly distinguishes between safe and unsafe modes and tracks and maintains the ownership semantics of heap objects. By extending the range of values ​​for the allocation state function, OSA can accurately express the allocation state of heap objects under different modes.

[0024] Control Flow Graph (CFB): A graphical structure used to represent the execution flow of a program, where nodes represent basic blocks and edges represent control flow transitions. CFB is a crucial foundational structure for static analysis and optimization, and is widely used in formal verification tools such as compiler optimization and program analysis.

[0025] Virtual Function Table (VFC) is a data structure used in object-oriented programming to implement dynamic dispatch. It stores function pointers for object types, allowing the correct invocation of object methods at runtime. In bounded model checking, the VFC is used to handle dynamic dispatch and trait polymorphism.

[0026] Rust is a systems-level programming language characterized by memory safety guarantees and zero-cost abstractions. Its core innovation lies in its ownership type system, ensuring memory safety through compile-time checks, while providing both safe and unsafe programming modes to balance security and flexibility. Despite strong compile-time protection, memory safety risks still exist in practical applications due to the existence of unsafe code blocks. Bounded model checking is a mature program verification technique that encodes program semantics and properties to be verified into logical formulas, automating verification using constraint solvers. To improve verification efficiency, this technique is optimized in conjunction with a static analysis engine, including generating refined verification conditions and reducing the solver's burden. The static analysis engine plays a crucial role in the verification process, significantly improving overall verification performance through various optimization techniques.

[0027] Existing Rust program bounds model detection techniques mainly employ the following technical solutions: 1) Boundary Model Detection Technology Based on Goto-C Intermediate Representation. This technology first converts the Rust program into a Goto-C intermediate representation, and then uses an existing Goto-C-based C program boundary model detection framework for verification. The specific implementation process includes: generating a bounding reference (MIR) using the Rust compiler, and then translating the MIR into a Goto-C format program. During the translation process, Goto-C syntax structures are needed to represent Rust's complex type system, trait polymorphism, lifecycle, and other characteristics.

[0028] 2) Boundary model detection technology based on LLVM intermediate representation. This technology performs bounded model detection based on the LLVM intermediate representation in the Rust compilation chain. The specific implementation process includes: generating LLVM binary code using the Rust compiler, extracting the LLVM intermediate representation, and verifying it using an existing LLVM-based bounded model detection framework.

[0029] Based on a comprehensive analysis, existing Rust program bounds detection techniques have the following main shortcomings: 1) Loss of critical type information during translation. Existing technologies suffer from severe type information loss when translating Rust programs to other intermediate representations. GOTO-C, as an intermediate representation of the C language, cannot fully express Rust's complex type system, especially Rust's unique high-level type concepts such as ownership, lifecycle, and borrowing rules. While LLVM provides type support, it is primarily designed for general-purpose languages ​​and similarly fails to preserve Rust's high-level type information and ownership semantics. This lost type information and ownership semantics are crucial for program verification, preventing verification algorithms from utilizing the rich semantic constraints provided by the Rust compiler. This not only increases computational overhead but may also affect the accuracy of verification.

[0030] 2) Significantly low verification efficiency. Due to the lack of Rust type information and ownership semantics, existing bounded model detection algorithms employ traditional ownership-independent static analysis methods, which have significant limitations in verification efficiency. Traditional analysis methods treat all heap objects uniformly, ignoring the essential differences between safe and unsafe modes, generating a large amount of uncertainty in state representation and merging, resulting in a massive scale of generated verification conditions. The SMT solver needs to handle a large number of unnecessary verification conditions, facing a huge computational burden during the solution process, leading to a significant increase in verification time and overall low verification efficiency.

[0031] 3) Toolchain version compatibility issues. Existing verification technologies based on LLVM intermediate representations require extracting LLVM binary code from the Rust compilation chain and then performing intermediate representation conversion, involving multiple processing stages. The entire verification process is complex and prone to errors. Each stage may introduce information loss or conversion errors, increasing the uncertainty of the verification results. Furthermore, the LLVM intermediate representation is tightly coupled with the Rust compiler version; different versions of Rust compilers may generate different LLVM code, requiring verification tools to be adapted for specific versions, increasing maintenance costs and the barrier to entry. When Rust language features are updated, LLVM-based verification tools often lag behind and cannot support the new language features in a timely manner. Summary of the Invention

[0032] In view of the shortcomings of the existing technology, the specific technical problem to be solved by the present invention is as follows: 1) Addressing the issue of lost Rust type information during translation. To address the problem of lost Rust type information and ownership semantics during translation in existing technologies, this invention performs bounded model detection directly based on the Rust compiler's MIR intermediate representation. As an internal representation of the Rust compiler, the MIR fully preserves Rust's type system information, ownership semantics, borrowing rules, and other key content. This direct MIR-based analysis method avoids information loss during translation, providing rich type constraints and semantic information for subsequent static analysis and verification condition generation, significantly improving verification accuracy.

[0033] 2) Improved Verification Efficiency. Addressing the low verification efficiency of traditional ownership-independent static analysis, this invention significantly improves verification efficiency by introducing ownership-sensitive static analysis technology. Ownership-sensitive analysis, by expanding the value range of the allocation state function and the state merging strategy, can accurately express the allocation state of heap objects under different modes, reducing the uncertainty of state representation. This optimization strategy enables the identification and elimination of a large number of unnecessary verification conditions during the generation of verification conditions, significantly reducing the solution burden of the SMT solver and greatly improving verification efficiency.

[0034] 3) Addressing the technical issues of complex verification processes and poor version compatibility. To address the problems of existing verification techniques based on LLVM intermediate representations being complex, error-prone, and incompatible with Rust versions, this invention directly uses the Rust compiler's MIR intermediate representation for bounded model detection, avoiding the complex multi-stage process of extracting LLVM binary code from the Rust compilation chain and then converting it to an intermediate representation. This direct MIR-based approach simplifies the verification process, reduces potential information loss and conversion errors at each stage, and lowers the uncertainty of verification results. Furthermore, this invention directly interfaces with the Rust compiler's internal representation, no longer relying on LLVM intermediate representations, thus resolving the issue of tight coupling with Rust compiler versions. It can promptly support Rust language feature updates, improving maintenance costs and ease of use.

[0035] The technical solution adopted in this invention is as follows: A method for bounds model detection in Rust programs includes the following steps: Obtain the intermediate MIR representation of the Rust program and preprocess the intermediate MIR representation; Perform ownership-sensitive static analysis on the preprocessed MIR intermediate representation to generate validation conditions; The validation conditions are sliced ​​and optimized to obtain simplified validation conditions; The simplified verification conditions are solved using the SMT solver, and a verification report is generated based on the solution results.

[0036] Furthermore, the preprocessing includes: calculating the set of all functions reachable from the entry function and constructing a function table, identifying loop structures and recursive functions in the program, and constructing a virtual function table.

[0037] Furthermore, the ownership-sensitive static analysis includes: propagating the abstract state along the MIR control flow and updating the assignment function, pointer function, and state allocation function in the abstract state according to the MIR statements; performing finite expansion on the control flow graph and call graph according to the preset expansion boundaries based on the preprocessed loop structure and recursive function, and then generating verification conditions based on the abstract state of each program point.

[0038] Furthermore, the allocation state function is defined as the process from heap objects to a state set. Mapping, set of states strue indicates that the heap object was created by a safe Rust constructor and can be determined to be allocated at the current program point; sfalse indicates that the heap object has been freed in safe mode; utrue indicates that the heap object was created by an unsafe allocation operation and can be determined to be allocated at the current program point; ufalse indicates that the heap object has been freed in unsafe mode; and unknown indicates that it is impossible to determine whether the heap object is still in an allocated state based on the current control flow and pointer relationships.

[0039] Furthermore, the verification conditions include verification conditions encoded in the program and verification conditions encoded in the problem. When generating the verification conditions, the problems to be detected are divided into three categories: illegal dereference, illegal release, and memory leak, and the code is optimized for each category to reduce the size of the verification conditions corresponding to the three types of problems.

[0040] Furthermore, the step of slicing and optimizing the verification conditions includes: receiving the verification conditions output from the static analysis stage as input, and slicing the verification conditions of the program code; if the verification conditions of the problem code are empty, it means that there are no check items that need to be judged by the SMT solver, and the SMT solver is not called again; if the verification conditions of the problem code are not empty, the variables appearing in the verification conditions of the problem code are used as the initial correlation set, and the initial correlation set is used to perform reverse dependency analysis on the verification conditions of the program code, delete formulas that are not related to the verification conditions of the problem code, and obtain the sliced ​​verification conditions.

[0041] Furthermore, the step of generating a verification report based on the solution results includes: if the SMT solver returns SAT, it indicates that a program error has been found, and a detailed report containing error information and counterexample paths is generated; if the SMT solver returns UNSAT, it indicates that the program is safe within the given boundaries, and a safety confirmation report is generated; if the SMT solver returns UNKNOWN, an unknown state report is generated.

[0042] A bounds model detection device for Rust programs, comprising: The preprocessing module is used to obtain the intermediate MIR representation of the Rust program and preprocess the intermediate MIR representation. The static analysis module is used to perform ownership-sensitive static analysis on the preprocessed MIR intermediate representation and generate verification conditions. The validation condition slicing module is used to slice and optimize validation conditions to obtain simplified validation conditions. The SMT solver module is used to solve simplified verification conditions using the SMT solver. The report generation module is used to generate a verification report based on the solution results.

[0043] This invention introduces ownership-sensitive static analysis technology and performs boundary model detection based on MIR, which has the following significant advantages compared to existing technologies: 1) Bounded model detection based on MIR: This avoids the complex process of translating Rust programs to other intermediate representations, simplifying the verification process and reducing information loss and potential errors during conversion. Direct analysis based on MIR fully utilizes the internal components of the Rust compiler, improving the accuracy and efficiency of verification. Compared to verification techniques based on Goto-C or LLVM, this invention offers a simpler process and lower maintenance costs.

[0044] 2) Ownership-Sensitive Static Analysis: By distinguishing between safe and unsafe modes and tracking and maintaining ownership semantics during static analysis, ownership-sensitive analysis provides more accurate abstractions of program states. Compared to traditional static analysis, ownership-sensitive analysis leverages Rust's ownership rules to improve state merging, reducing uncertainty in abstract states and increasing analysis accuracy. This improvement makes the verification process more precise and reduces the possibility of false positives and false negatives.

[0045] 3) Simplified Verification Conditions Based on Ownership Semantics: Simplifying verification conditions using ownership semantics significantly reduces the size of the logical formulas that need to be solved. Based on ownership properties, some verification conditions can be directly determined as true or false, avoiding unnecessary SMT (Simplified Methods of Measuring and Analyzing) calculations. This simplification strategy greatly improves verification efficiency, especially when dealing with large programs. By reducing redundant verification conditions, the solution time and memory usage of the SMT solver are significantly improved. Attached Figure Description

[0046] Figure 1 This is a flowchart of the steps of a bounded model detection method for Rust programs according to the present invention.

[0047] Figure 2This is a module configuration diagram of a bounded model detection device for a Rust program according to the present invention.

[0048] Figure 3 This is a schematic diagram of the overall architecture of a bounded model detection method for Rust programs according to the present invention. Detailed Implementation

[0049] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to specific embodiments and accompanying drawings.

[0050] The boundary model detection method proposed in this invention is based on ownership-sensitive static analysis technology, and its core innovations include: 1) Direct analysis based on MIR intermediate representation: This invention directly uses the MIR intermediate representation inside the Rust compiler for bounded model detection, avoiding the complex process of translating Rust programs to other intermediate representations. MIR preserves key information such as Rust's type information and ownership semantics, providing rich semantic constraints for subsequent analysis.

[0051] 2) Ownership-Sensitive Static Analysis: This invention explicitly distinguishes between safe and unsafe modes during static analysis. By expanding the range of values ​​for the allocation state function, it can accurately express the allocation state of heap objects under different modes. An intelligent state merging strategy is employed, performing more precise state merging based on Rust's ownership rules.

[0052] 3) Optimization of verification conditions based on ownership semantics: This invention simplifies verification conditions by utilizing ownership semantics, which can identify and eliminate a large number of unnecessary verification conditions, significantly reduce the solution burden of the SMT solver, and greatly improve verification efficiency.

[0053] 4) Verification condition generation and solution: This invention converts static analysis results into logical formulas that can be solved by the SMT solver. By calling the solver, it automatically determines whether there are errors in the program and generates a detailed verification report.

[0054] This invention provides a method for detecting the bounds model in a Rust program, such as... Figure 1 As shown, the main steps include: Preprocessing step: Responsible for obtaining the intermediate MIR representation of the Rust program and preprocessing the intermediate MIR representation. This step includes calculating the set of reachable functions, identifying loop structures, and constructing a virtual function table, preparing program structure information for subsequent analysis.

[0055] Static analysis step: Responsible for performing ownership-sensitive static analysis based on the preprocessed MIR and generating verification conditions. This step tracks and maintains ownership semantics during the analysis process, performs semantic analysis on each instruction in the MIR, and generates verification conditions.

[0056] The validation condition slicing step is responsible for slicing and optimizing the validation conditions generated by static analysis to obtain simplified validation conditions. This step identifies and removes formula parts irrelevant to memory safety checks through correlation analysis, thus reducing the size of the validation conditions.

[0057] SMT Solving Steps: The responsible steps are to use the SMT solver to encode the simplified verification conditions into a format supported by the solver, and then call the solver to solve the verification conditions.

[0058] Report generation steps: Responsible for generating a detailed verification report based on the results of the SMT solver. Provide counterexamples when errors are found, and generate a safety confirmation report when no errors are found.

[0059] This invention provides a bounds model detection device for Rust programs, offering a complete device architecture, such as... Figure 2 As shown, it mainly includes the following functional modules: The preprocessing module is responsible for obtaining the intermediate MIR representation of the Rust program and preprocessing the intermediate MIR representation, including calculating the set of reachable functions, identifying loop structures, and constructing a virtual function table, in order to prepare program structure information for subsequent analysis.

[0060] Static Analysis Module: Responsible for performing ownership-sensitive static analysis based on the preprocessed MIR, tracking and maintaining ownership semantics during the analysis process, performing semantic analysis on each instruction in the MIR, and generating verification conditions.

[0061] Verification condition slicing module: responsible for slicing and optimizing the verification conditions generated by static analysis, identifying and removing formula parts that are not related to memory safety checks through correlation analysis, and simplifying the scale of verification conditions.

[0062] SMT Solver Module: Responsible for interacting with the SMT solver, encoding the simplified verification conditions into a format supported by the solver, and calling the solver to solve the verification conditions.

[0063] Report generation module: Responsible for generating detailed verification reports based on the results of the SMT solver, providing counterexample information when errors are found, and generating safety confirmation reports when no errors are found.

[0064] The overall architecture of the technical solution of this invention is as follows: Figure 3 As shown, the relevant technologies are mainly achieved through the collaborative work of the above five core modules, including: 1. Preprocessing Stage: The preprocessing module obtains the intermediate MIR representation of the program through the Rust compiler interface and performs structural processing. The main tasks of the preprocessing stage include: calculating the set of all functions reachable from the entry function and constructing a function table; identifying loop structures and recursive functions in the program and constructing a virtual function table. The preprocessing module outputs the processed MIR, preparing complete program structure information for the static analysis stage.

[0065] 2. Static Analysis Phase: The static analysis module analyzes the preprocessed MIR. It obtains ownership information through Rust type information and performs ownership-sensitive analysis during the analysis process, maintaining and updating the ownership state of each memory allocation. Based on the maintained ownership state, it optimizes the generation of verification conditions. Other key tasks include: semantic analysis of each instruction in the MIR, updating assignment functions, pointer functions, and allocation state functions in the abstract state; expanding loop structures and recursive functions to predetermined boundaries, generating and optimizing verification conditions, etc. The result of static analysis is a set of verification conditions.

[0066] The assignment function records the symbolic values ​​of variables, temporary variables, pointer variables, and object fields at the current program point; the pointer function records the heap objects that pointers or references may point to and their offsets relative to the object's starting address; and the allocation status function records the allocation status of each heap object at the current program point and distinguishes whether the status originates from safe mode or unsafe mode.

[0067] The static analysis module of this invention propagates the abstract state along the MIR control flow and updates the assignment function, pointer function and state allocation function in the abstract state according to the MIR statement.

[0068] Traditional ownership-independent static analysis's allocation state function typically only distinguishes between three states: allocated, released, and unknown, failing to express whether the object's state originates from safe or unsafe Rust code. To leverage Rust's ownership semantics, this invention extends the range of values ​​for the allocation state function, making the allocation state function... Defined as a collection of state objects from heap objects The mapping, where Here, strue indicates that the heap object was created by a safe Rust constructor and can be determined to be allocated at the current program point; sfalse indicates that the heap object has been freed in safe mode; utrue indicates that the heap object was created by an unsafe allocation operation and can be determined to be allocated at the current program point; ufalse indicates that the heap object has been freed in unsafe mode; and unknown indicates that it is impossible to determine whether the heap object is still in an allocated state based on the current control flow and pointer relationships.

[0069] The update rules for allocation state functions include: when the MIR statement is a safe allocation function such as Box::new(...), the allocation state of the newly created object is strue; when the MIR statement is a non-safe allocation function such as __rust_alloc(...), the allocation state of the newly created object is utrue; when the MIR statement is Drop(b), the heap object that b may point to is determined according to the pointer function, and the state of the corresponding heap object is updated to sfalse; when the MIR statement is __rust_dealloc(p), the heap object that p may point to is determined according to the pointer function, and the state of the corresponding heap object is updated to ufalse. If the pointer to be released may point to multiple heap objects, the state is updated for each possible object separately, and when the target object cannot be uniquely determined, a state merging rule is used to obtain the conservative result unknown.

[0070] At the control flow convergence point, the state allocation function is merged using an ownership-sensitive merge function. The merge rules are as follows: if two states to be merged are identical, the merged result is that state; if the two states to be merged are strue and sfalse, or sfalse and strue, the merged result is strue; if the two states to be merged are utrue and strue, or strue and utrue, the merged result is utrue; if the two states to be merged are ufalse and sfalse, or sfalse and ufalse, the merged result is ufalse; the merged result for other combinations of states to be merged is unknown.

[0071] Then, the static analysis module performs finite expansion on the control flow graph and call graph according to preset expansion boundaries, based on the loop structures and recursive functions identified in the preprocessing stage. For loop structures, the static analysis module copies the loop body control flow and connects the loop entry, loop body, and loop exit edges according to the boundary number; paths exceeding the boundary and reaching the loop expansion upper limit are no longer expanded. For recursive functions, the static analysis module inlines or expands recursive calls according to the call depth boundary; recursive calls exceeding the boundary stop expansion or generate boundary constraints. After expansion, the static analysis module generates verification conditions based on the abstract state of each program point. Verification conditions include verification conditions for the program code. Validation conditions for the problem code The overall form is .

[0072] Based on the aforementioned allocation state function, the static analysis module, when generating memory safety verification conditions, categorizes the problems to be detected into three types: illegal dereferences, illegal releases, and memory leaks, and performs coding optimization for each. A Boolean function for the state of a memory object.

[0073] 1) For illegal dereferences, the static analysis module checks MIR statements containing pointer or reference dereference operations, such as those for... p is a statement for reading and writing, where p indicates dereferencing the pointer p. If it points to a function, it means p might point to a collection of heap objects. Then check the allocation status of each object separately.

[0074] for or Then the dereference is valid, let's call it. ; for or If the dereference is illegal, then dereference is invalid. ; for If the validity of the dereference cannot be determined, the `alloc` function is used to generate check items to be solved, denoted as... ,in Represents heap objects The current program point is in an allocated state.

[0075] Finally, Extracted into φ_issues. This indicates the formula for checking for illegal dereferences.

[0076] 2) For illegal releases, the static analysis module checks release-related MIR statements such as `drop(p)` and `__rust_dealloc(p)`. If the pointer function indicates that `p` may point to a collection of heap objects... Then check the allocation status of each object separately.

[0077] for or Then the release is legal, record. ; for or If so, release illegally, record. ; for If the release is invalid, the legality of the release cannot be determined. The `alloc` function is used to generate check items to be solved, denoted as... ,in Represents heap objects The current program point is in an allocated state.

[0078] Finally, Extracted Inside. Among them. This represents the check formula for illegal releases. After analyzing the release statement, if the current statement is drop(p), the allocation status of the corresponding object is updated to sfalse; if the current statement is __rust_dealloc(p), the allocation status of the corresponding object is updated to ufalse.

[0079] 3) For memory leaks, the static analysis module checks the set of heap objects at the termination point where the program exits a basic block or a given boundary. Does the database contain any objects that are still in the allocated state?

[0080] for This indicates that ownership of the object has not been lost and there is no memory leak. ; for or If the object has been released, it does not constitute a memory leak. ; for If the object remains in an allocated state, it constitutes a memory leak. ; for If the object is not allocated, it cannot be determined whether it has been allocated. The `alloc` function is used to generate check items to be solved. ,in Represents heap objects The program is still in the allocated state at the termination point.

[0081] Finally, Extracted This indicates the presence of at least one potentially leaky heap object. The formula for checking memory leaks is as follows: For objects in safe mode that can be determined by ownership rules to be released when the owner leaves the scope, they can be marked as sfalse during state updates, thus avoiding the generation of unnecessary memory leak checks; for objects that are not safely allocated or whose state is unknown, leak checks are conservatively retained.

[0082] Through the above classification and coding, the static analysis module optimizes based on the coding result of each check item: when a check item is encoded as false, it indicates that the illegal dereference, illegal release, or memory leak problem corresponding to the object is determined to be non-existent, and can be directly resolved from the code. Delete it; no need to submit to the SMT solver. When a check item is encoded as true, it means that the problem corresponding to the object can be identified as an error candidate by the allocation state function. If the current path reachability has been determined by the path constraints, the corresponding error report can be generated directly. If path reachability still needs to be confirmed, the path constraints related to the check item are retained and submitted to subsequent solvers for confirmation. Check items are only retained when they are encoded as non-Boolean constant formulas. The process is then handed over to the subsequent slicing module and SMT solver. Therefore, this invention pre-processes both safe and error-prone scenarios during the static analysis phase, generating formulas only for cases with uncertain states. This reduces the scale of verification conditions for illegal dereferences, illegal releases, and memory leaks, thereby lowering the solver's workload.

[0083] The generated "verification conditions" are as follows: Suppose that pointer analysis results indicate that the set of heap objects that pointer p may point to is... If the program statements contain dereferences p, and the allocation state function For Since it is in a safe mode and has been allocated, no illegal dereference check is generated; for Since its allocation state is unknown, an illegal solution reference check item is generated for ho2. .

[0084] 3. Slicing Module: The slicing module receives the verification conditions output from the static analysis phase. As input, and for the program semantic formulas therein Slice the material. If... If empty, it means there are no checks that require further evaluation by the SMT solver, and the slicing module will not call the SMT solver again; if If not empty, the slice module uses The "variables" appearing in the text refer to the initial relevant set, for Perform reverse dependency analysis and delete dependencies related to... Irrelevant formulas, resulting in verification conditions after slicing. The verification conditions after slicing are passed to the SMT solver.

[0085] The specific steps of the slicing process include: the slicing module first... The formulas in the code are organized into a formula sequence according to the order generated during the static analysis phase. Each formula represents a variable assignment, memory array update, allocation state array update, or path condition constraint. Subsequently, the slicing module... right The correlation analysis results mark the formulas that should be retained and delete the unmarked formulas. The retained formulas constitute... , and the original Verification conditions after composing the slice This slicing process only deletes and does not affect... The program semantic formula does not change the formula of the problem to be verified.

[0086] The specific method for "correlation analysis" is inverse dependency analysis. The slicing module first starts from... Extract relevant symbols to form an initial relevant set R. The relevant symbols include... The variables, object addresses, heap object identifiers, memory arrays, allocation state arrays, and indexes in array selection expressions that appear in the data are then processed by the slicing module according to... The formulas are generated in reverse order. For each formula in the set, if the target symbol defined or updated by the formula belongs to the current relevant set R, or if the result of the formula is dependent on symbols in the current relevant set R, then the formula is marked as a relevant formula and retained; at the same time, the variables appearing in the expression on the right side of the formula are added to the relevant set R. If the target symbol defined or updated by a formula does not belong to the relevant set R, and its expression on the right side does not affect the symbols in the relevant set R, then the formula is determined to be an irrelevant formula and deleted.

[0087] 4. SMT Solving and Report Generation: The SMT solving module receives the verification conditions after slicing as input, translates the verification conditions into a format supported by the solver, and calls the SMT solver to solve. The report generation module generates the final verification report based on the solution results: if the solver returns SAT, it indicates that a program error has been found, and a detailed report containing error information and counterexample paths is generated; if the solver returns UNSAT, it indicates that the program is safe within the given boundaries, and a safety confirmation report is generated; if the solver returns UNKNOWN, an unknown state report is generated.

[0088] It should be understood that the methods and apparatus disclosed in the above embodiments of the present invention can be implemented in other ways. For example, the above module division can be implemented in other ways, multiple modules can be combined or integrated into another device or system, or some features can be ignored or not executed. Each step and module in the present invention can be implemented in the form of software functional units and can be stored in a computer-readable storage medium, including several instructions to cause a computer device to execute some or all of the steps of the method described in the present invention. For example, one embodiment of the present invention provides a computer device (computer, server, etc.) including a memory and a processor, the memory storing a computer program configured to be executed by the processor, the computer program including instructions for executing each step of the method of the present invention. For example, another embodiment of the present invention provides a computer-readable storage medium (such as ROM / RAM, disk, optical disk, etc.) storing a computer program, which, when executed by a computer, implements each step of the method of the present invention. For example, another embodiment of the present invention provides a computer program product including a computer program, which, when executed by a computer, implements the steps of the method of the present invention.

[0089] The specific embodiments of the present invention disclosed above are intended to help understand the content of the present invention and to implement it accordingly. Those skilled in the art will understand that various substitutions, changes, and modifications are possible without departing from the spirit and scope of the present invention. The present invention should not be limited to the content disclosed in the embodiments of this specification; the scope of protection of the present invention is defined by the claims.

Claims

1. A method for detecting the bounds model of a Rust program, characterized in that, Includes the following steps: Obtain the intermediate MIR representation of the Rust program and preprocess the intermediate MIR representation; Perform ownership-sensitive static analysis on the preprocessed MIR intermediate representation to generate validation conditions; The validation conditions are sliced ​​and optimized to obtain simplified validation conditions; The simplified verification conditions are solved using the SMT solver, and a verification report is generated based on the solution results.

2. The method according to claim 1, characterized in that, The preprocessing includes: calculating the set of all functions reachable from the entry function and constructing a function table; identifying loop structures and recursive functions in the program; and constructing a virtual function table.

3. The method according to claim 2, characterized in that, The ownership-sensitive static analysis includes: propagating the abstract state along the MIR control flow and updating the assignment function, pointer function and state allocation function in the abstract state according to the MIR statements; performing finite expansion on the control flow graph and call graph according to the preset expansion boundaries based on the preprocessed loop structure and recursive function, and then generating verification conditions based on the abstract state of each program point.

4. The method according to claim 3, characterized in that, The allocation state function is defined as a process from heap objects to a state set. Mapping, set of states strue indicates that the heap object was created by a safe Rust constructor and can be determined to be allocated at the current program point; sfalse indicates that the heap object has been freed in safe mode; utrue indicates that the heap object was created by an unsafe allocation operation and can be determined to be allocated at the current program point; ufalse indicates that the heap object has been freed in unsafe mode; and unknown indicates that it is impossible to determine whether the heap object is still in an allocated state based on the current control flow and pointer relationships.

5. The method according to claim 3, characterized in that, The verification conditions include verification conditions for program code and verification conditions for problem code. When generating verification conditions, the problems to be detected are divided into three categories: illegal dereference, illegal release, and memory leak, and the code is optimized for each category to reduce the size of the verification conditions for each category.

6. The method according to claim 5, characterized in that, The step of slicing and optimizing the verification conditions includes: receiving the verification conditions output from the static analysis stage as input and slicing the verification conditions of the program code; if the verification conditions of the problem code are empty, it means that there are no check items that need to be judged by the SMT solver, so the SMT solver is not called; if the verification conditions of the problem code are not empty, the variables appearing in the verification conditions of the problem code are used as the initial correlation set, and the initial correlation set is used to perform reverse dependency analysis on the verification conditions of the program code, delete formulas that are irrelevant to the verification conditions of the problem code, and obtain the sliced ​​verification conditions.

7. The method according to claim 1, characterized in that, The step of generating a verification report based on the solution results includes: if the SMT solver returns SAT, it indicates that a program error has been found, and a detailed report containing error information and counterexample paths is generated; if the SMT solver returns UNSAT, it indicates that the program is safe within the given boundaries, and a safety confirmation report is generated; if the SMT solver returns UNKNOWN, an unknown state report is generated.

8. A bounds model detection device for Rust programs, characterized in that, include: The preprocessing module is used to obtain the intermediate MIR representation of the Rust program and preprocess the intermediate MIR representation. The static analysis module is used to perform ownership-sensitive static analysis on the preprocessed MIR intermediate representation and generate verification conditions. The validation condition slicing module is used to slice and optimize validation conditions to obtain simplified validation conditions. The SMT solver module is used to solve simplified verification conditions using the SMT solver. The report generation module is used to generate a verification report based on the solution results.

9. A computer device, characterized in that, It includes a memory and a processor, the memory storing a computer program configured to be executed by the processor, the computer program including instructions for performing the method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a computer, implements the method according to any one of claims 1 to 7.

Images