Rust code memory security vulnerability detection tool

Abstract

The invention provides a Rust code memory security vulnerability detection tool, and relates to the technical field of software detection, and the tool comprises a mirror image packaging module which is used for packaging a detection unit and a running environment thereof into an independent container mirror image, and the detection unit is used for detecting a memory security vulnerability of a Rust code in a Rust project and outputting a corresponding detection result file; and the calling module is used for responding to the saving or opening operation for the Rust codes, obtaining a plurality of Rust items which are mutually dependent on the current Rust item, and calling the container mirror image to detect the memory security vulnerabilities of the Rust codes in each Rust item. According to the method, the use threshold of Rust code memory security detection is remarkably reduced, and even developers with relatively shallow programming experience can easily operate the method. By simplifying the configuration process and providing a friendly user experience, developers can focus more on the security of the code, rather than the use of tools.

Description

Technical Field

[0001] The present invention relates to the technical field of software detection, and in particular to a Rust code memory security vulnerability detection tool. Background Art

[0002] With the development of computer science, the diversity of programming languages ​​continues to increase. Rust, as an emerging system-level programming language, has gradually gained favor among developers due to its unique memory safety mechanism and high performance characteristics.

[0003] There are currently a variety of memory safety testing tools on the market. Different tools employ specific detection algorithms, such as alias analysis and data flow analysis, and perform testing in intermediate language stages such as HIR / MIR during the Rust compilation process. Furthermore, each tool has a different focus. Some focus on memory safety issues caused by improper resource management, such as Use After Free and Double Free, while others focus on various memory safety issues in high-risk operational scenarios, such as Panic Safety and Send / Sync trait safety. Typical examples include SafeDrop and Rudra, which can help developers identify potential vulnerabilities in Rust code. However, these tools generally suffer from limited adaptability. Specifically, these tools typically only support fixed versions of the Rust compiler, requiring developers to perform tedious manual configuration amidst frequent compiler updates. This not only increases the barrier to entry but also imposes a high learning curve and time-consuming effort on developers conducting memory safety testing. Furthermore, many testing tools require complex runtime configuration, requiring developers to deeply understand the tool's internal mechanisms and dependencies, making this particularly challenging for developers new to the Rust language or with limited programming experience. Therefore, the high threshold of usage experience makes many developers reluctant to use them in actual applications, and they are unable to fully utilize these detection tools to improve the security of their code. Summary of the Invention

[0004] The present invention provides a Rust code memory security vulnerability detection tool, aiming to solve the problems existing in the above background technology.

[0005] In order to solve the above-mentioned technical problems, the present invention is achieved as follows: The present invention provides a Rust code memory security vulnerability detection tool, comprising: An image encapsulation module, which is used to encapsulate the detection unit and its operating environment into an independent container image. The detection unit is used to detect memory security vulnerabilities in Rust code in Rust projects and output corresponding detection result files; A calling module is used to, in response to a save or open operation on the Rust code, obtain multiple Rust projects that are mutually dependent on the current Rust project in the same work area, and call the container image to detect memory safety vulnerabilities in the Rust code in each Rust project.

[0006] Optionally, the calling module includes a front-end submodule; The front-end submodule is used to determine the project root directory of the Rust project to be detected according to the file path of the Rust project to be detected through a path resolution algorithm; and copy the Rust project to be detected from the project root directory to the container image.

[0007] Optionally, the detection unit is configured with an input path and an output path, the input path is a path for obtaining the Rust project to be detected, the output path is a path for outputting the detection result file, and the input path is pointed to the detection unit by the container image.

[0008] Optionally, the calling module includes a back-end submodule; The back-end submodule is configured to parse the detection result file output by the detection unit and push the parsed detection result file to the front-end submodule via a network protocol; The front-end submodule is used to receive the parsed test result file and display the corresponding test result in a visual interface.

[0009] Optionally, the back-end submodule is used to extract key information from the detection result file, and the key information includes at least: vulnerability type, vulnerability location and repair suggestions; organize the key information into a data object in JSON format, and push it to the front-end submodule through a network protocol.

[0010] Optionally, the image packaging module is further used to mark the warehouse path and version number for the container image, and push the container image to the image warehouse specified in the image market based on the warehouse path, so that the calling module can download and call it; wherein, the warehouse path represents the location of the image warehouse specified by the container image in the image market, and the version number includes the version of the detection unit, the adapted Rust compiler version and the build date of the container image.

[0011] Optionally, the image encapsulation module is further used to specify environment variables of the container image; The detection unit is used to access resources and configuration files required for runtime according to the environment variables.

[0012] Optionally, the calling module is used to obtain log information recorded during the operation of the detection unit when the detection unit fails to detect; and restart the container image according to the log information after a preset time delay until a preset maximum number of retries is reached.

[0013] Optionally, the calling module is used to perform topological sorting on the multiple Rust projects to generate a sequential detection list; and call the container image in sequence according to the detection sequence list to detect memory safety vulnerabilities in the Rust code in each Rust project.

[0014] Optionally, the detection unit checks whether a logic change occurs inside the corresponding Rust C compiler, where the logic change includes syntax change, semantic change, API change, type system extension, and borrowing rule extension; if a logic change is detected inside the Rust C compiler, the analysis logic of the detection unit is modified accordingly.

[0015] The technical solution provided by the present invention brings at least the following beneficial effects: The detection tool provided by the present invention encapsulates the detection unit and its operating environment into an independent container image, so that developers can seamlessly run the detection tool in different environments, avoiding compatibility issues caused by improper environment configuration, and developers can easily perform memory safety detection in local or cloud environments. The tool can automatically respond to save or open operations on Rust code, and promptly obtain the current Rust project and multiple projects that depend on each other. It not only reduces the complexity of manual configuration, but also ensures the timeliness of detection, allowing developers to obtain security feedback immediately after code modification, thereby discovering and fixing potential memory safety vulnerabilities more quickly. Therefore, the present invention significantly lowers the threshold for using Rust code memory safety detection, and even developers with less programming experience can easily get started. By simplifying the configuration process and providing a friendly user experience, developers can focus more on the security of the code rather than the use of tools. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0017] Figure 1 This is a schematic diagram of the architecture of a Rust code memory security vulnerability detection tool provided by one embodiment of the present invention; Figure 2This is a schematic diagram of the application process of a Rust code memory security vulnerability detection tool according to an embodiment of the present invention. DETAILED DESCRIPTION

[0018] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making any creative efforts shall fall within the scope of protection of the present invention.

[0019] With the continuous advancement of software development, memory safety issues have become a key factor affecting program stability and security. Although the Rust language, with its unique ownership and lifecycle management mechanisms, demonstrates significant advantages in memory safety, a large number of potential memory safety vulnerabilities still exist in actual development. These vulnerabilities often stem from developers' unfamiliarity with the Rust language. In particular, when using Unsafe Rust, the compiler fails to provide sufficient safety guarantees, leading to frequent use-after-free and double-free issues. While a variety of memory safety detection tools are currently available on the market, such as SafeDrop and Rudra, they generally suffer from poor adaptability and high barriers to entry. To address these issues, the present invention proposes a Rust code memory safety vulnerability detection tool. Its core concept is to encapsulate the detection unit and its runtime environment into an independent container image through the integrated design of an image encapsulation module and a call module, thereby achieving environment independence and portability. The Rust code memory safety vulnerability detection tool provided in the embodiments of the present invention is a Rust code memory safety vulnerability detection device that not only simplifies the configuration process and lowers the barrier to entry, but also improves detection efficiency and accuracy, providing Rust developers with an efficient and easy-to-use memory safety detection solution. Through this invention, developers can more conveniently identify and fix potential memory safety vulnerabilities, further promoting the application of the Rust language in secure programming practices.

[0020] Figure 1 This is a schematic diagram of the architecture of a Rust code memory security vulnerability detection tool provided by an embodiment of the present invention. Figure 1 ,include: The image encapsulation module is used to encapsulate the detection unit and its operating environment into an independent container image. The detection unit is used to detect memory security vulnerabilities in Rust code in Rust projects and output corresponding detection result files.

[0021] The image packaging module is used to package multiple detection units and their respective runtime environments into an independent, portable container image, ensuring consistent operation across different environments. The detection units are used to detect memory safety vulnerabilities in Rust projects, ensuring developers can identify and fix potential memory issues. The detection units can be SafeDrop and Rudra, which are optimized for the latest Rust compiler versions and run stably under the new compiler versions. Memory safety vulnerabilities (such as dangling pointers and memory leaks) detected during the detection process are flagged by the detection units and output as corresponding detection result files. Each detection unit is configured to accept Rust code as input and perform memory safety vulnerability detection. In addition to packaging the detection units themselves into the image, the runtime environment is also configured accordingly. To ensure that the detection units function properly under the latest Rust compiler version, the container image is configured with a runtime environment compatible with that compiler version. This includes installing the Rust toolchain, related libraries, and dependencies, and setting necessary environment variables (such as RUSTUP_HOME and CARGO_HOME) to ensure the proper operation of the Rust toolchain.

[0022] All runtime environments and detection units are encapsulated into Docker images. Users only need to pull the image and run it in any runtime environment that supports Docker. In other words, developers do not need to manually configure a complex development environment. They only need to run the container to complete the detection of memory safety vulnerabilities. Through containerization, the detection unit can be packaged into a standard, easy-to-distribute container image. Whether in a local development environment, an integrated environment, or a cloud environment, developers can quickly start the image and perform memory safety checks. By mounting the Rust project into a container image and running the container image in the background, the detection unit can automatically start analyzing the code in the project to find memory safety vulnerabilities.

[0023] SafeDrop is a tool for statically analyzing Rust code, primarily for identifying memory safety issues. SafeDrop initially supported older Rust compiler versions (such as 1.63.0), but as the Rust compiler has been updated, SafeDrop has been updated to support new features and optimizations introduced in these newer compiler versions. To ensure compatibility with the latest Rust versions, this paper has updated and optimized SafeDrop to work with the latest RustC compiler versions (such as nightly-2023-11-23). ​​Rudra is another Rust memory safety detection tool that focuses on statically analyzing memory safety vulnerabilities in Rust code. Similar to SafeDrop, earlier versions of Rudra only supported older versions of the Rust compiler (such as nightly-2020-08-26). To accommodate the rapidly evolving Rust ecosystem, Rudra has been adapted to support the latest versions of the Rust compiler. This allows Rudra to unleash even greater capabilities in the latest Rust compiler environments, ensuring accurate detection of memory issues. Developers or system administrators can optionally customize the configuration files of the detection units to use one or more detection units based on their needs. For example, the configuration file can choose to enable both Rudra and SafeDrop, or you can choose to enable Rudra or SafeDrop individually.

[0024] A calling module is used to, in response to a save or open operation on the Rust code, obtain multiple Rust projects that are mutually dependent on the current Rust project in the same work area, and call the container image to detect memory safety vulnerabilities in the Rust code in each Rust project.

[0025] The call module handles memory safety checks for Rust projects. The call module monitors user save and open operations on Rust code in an IDE (Integrated Development Environment), such as VSCode. When a user saves or opens Rust code, the call module is triggered, initiating the subsequent check process. Rust projects have complex dependencies between modules and libraries. The call module parses the dependency graph of the current Rust project within the same workspace and identifies multiple Rust projects that depend on the current project. Dependencies can be defined using a Cargo.toml file, which describes the metadata and dependencies of the Rust project. The call module reads this file, analyzes the libraries and modules that the Rust project depends on, and constructs a dependency graph. For example, consider a main project, MainProject, that depends on LibA and LibB within the same workspace. LibA, in turn, depends on LibC. In this case, the call module needs to identify the Rust projects, MainProject, LibA, LibB, and LibC, and include them in the check. If a library that the main project depends on does not exist in the workspace, the dependent library is not checked. The calling module calls the pre-configured container images in turn to detect memory safety vulnerabilities in the Rust code in each Rust project.

[0026] As you can understand, the Rust code memory safety vulnerability detection tool provided by this invention is embedded in the IDE as a plug-in. Developers can obtain real-time feedback on memory safety issues while writing code, reducing the time and cost of post-code testing. The integrated design of this invention makes it easy for even developers unfamiliar with the Rust programming language and various static analysis tools to use this tool, reducing both learning and usage costs.

[0027] The detection tool provided by the present invention encapsulates the detection unit and its operating environment into an independent container image, allowing developers to seamlessly run the detection tool in different environments, avoiding compatibility issues caused by improper environment configuration. In addition, the tool can select one or more specified detection units to run through a configuration file, giving full play to the dynamic superposition advantages of multiple detection units, providing more comprehensive and diverse memory safety problem detection coverage, and developers can easily perform memory safety detection in local or cloud environments. The tool can automatically respond to save or open operations for Rust code, and promptly obtain the current Rust project and its multiple interdependent projects. It not only reduces the complexity of manual configuration, but also ensures the timeliness of detection, allowing developers to obtain security feedback immediately after code modification, thereby discovering and fixing potential memory safety vulnerabilities more quickly. Therefore, the present invention significantly lowers the threshold for using Rust code memory safety detection, and even developers with less programming experience can easily get started. By simplifying the configuration process and providing a friendly user experience, developers can focus more on the security of the code rather than the use of tools.

[0028] In an optional embodiment, the detection unit checks whether a logic change occurs inside the corresponding Rust C compiler, where the logic change includes syntax change, semantic change, API change, type system extension, and borrowing rule extension; if a logic change is detected inside the Rust C compiler, the analysis logic of the detection unit is modified accordingly.

[0029] The detection unit can establish an alias set based on the intermediate representation of the Rust compiler through path enumeration and alias analysis, which is used to record the memory areas pointed to by each variable and field. Based on this, it checks whether each resource allocation and release operation in the program is reasonable and determines whether there are potential memory safety issues.

[0030] As mentioned above, the detection unit can be SafeDrop. When adapting to the updated RustC compiler (such as the nightly-2023-11-23 version), some syntactic and semantic changes, API changes, and extensions of the type system and borrowing rules have occurred within the compiler. The detection unit needs to gradually modify the corresponding analysis logic based on the specific changes and update its algorithm to avoid detection omissions due to compiler optimization.

[0031] This example incorporates debugging and optimization across various aspects, including type system expansion, syntax changes, and internal compiler API changes, to upgrade the existing detection unit to adapt to the newer Rust C compiler. Specifically, in terms of the type system, the new version of Rust stabilizes Generic Associated Types (GATs), allowing them to be defined within traits. To correctly handle GATs during code analysis, we updated the syntax tree (AST) parsing logic and checked whether the specific types of GATs in trait implementations satisfy constraints (such as lifetime and ownership rules). Regarding syntax changes, the new version of Rust introduces changes to the let else syntax. When analyzing let else constructs (e.g., let Ok(x) = val else { return};), we updated the corresponding pattern matching and control flow analysis logic. Regarding API changes, internal interfaces of the Rust compiler (such as rustc_ast or rustc_middle) have changed, resulting in corresponding adjustments to dependent API calls.

[0032] In an optional embodiment, the calling module includes a front-end submodule; The front-end submodule is used to determine the project root directory of the Rust project to be detected according to the file path of the Rust project to be detected through a path resolution algorithm; and copy the Rust project to be detected from the project root directory to the container image.

[0033] The front-end submodule, as a submodule of the calling module, is used to handle tasks related to user interaction and Rust project file management. The path resolution algorithm is used to extract the project root directory from a given file path. The path resolution process includes the following steps: First, the front-end submodule responds to the user's save or open operation on the Rust code and obtains the file path of the Rust project to be tested in the current workbench. For example, the user opens a Rust project with the path C: / Users / User / Projects / RustProject / src / main.rs.

[0034] The front-end submodule then analyzes the path using a path resolution algorithm, searching upwards layer by layer until it finds the project's root directory, which is the directory containing the Cargo.toml file.

[0035] For example, the project root directory parsed from the path C: / Users / User / Projects / RustProject / src / main.rs is C: / Users / User / Projects / RustProject.

[0036] After determining the project root directory, the front-end submodule copies the entire Rust project to be tested into an isolated container image. Using the Docker API, the front-end submodule creates a new Docker container instance as an isolated runtime environment. Using Docker's data volumes feature, it mounts all files in the project root directory into the container, ensuring that the entire Rust project is accessible within the container.

[0037] Finally, the front-end submodule copies all relevant files in the Rust project (such as source code, configuration files, etc.) into the container so that subsequent detection units can run in an isolated environment.

[0038] Through the above design, developers can quickly and effectively detect and fix potential memory safety issues without interfering with the local environment.

[0039] In an optional embodiment, the detection unit is configured with an input path and an output path, the input path is a path for obtaining the Rust project to be detected, the output path is a path for outputting the detection result file, and the input path is pointed to the detection unit by the container image.

[0040] The input path is the path to the Rust project to be tested, which serves as the entry point for the detection unit to obtain the project code. The input path is pointed to the detection unit by the container image. In other words, the detection unit runs in the container and can access the project files mounted in the container. For example, assuming that the Rust project to be tested is located in the path / app in the container, the input path will be configured to point to / app so that the detection unit can read the source code and related files of the project.

[0041] The output path is the storage location of the test result files generated by the test unit. The output path can be a specific directory within the container image, such as / app / results, or a directory on the host machine.

[0042] In an optional embodiment, the calling module includes a back-end submodule; the back-end submodule is used to parse the detection result file output by the detection unit and push the parsed detection result file to the front-end submodule through a network protocol.

[0043] As previously mentioned, after completing the memory safety check, the detection unit generates a corresponding test result file. The backend submodule reads the test result file and parses its contents. Specifically, the backend submodule first opens and reads the contents of the test result file. Using a parsing algorithm, it extracts key information from the test result file. This extracted information is organized into a structured data object; the parsed results are stored in a specified data structure, ready for network transmission. The backend submodule uses a network communication protocol (such as HTTP or WebSocket) to push the parsed test results to the frontend submodule.

[0044] The front-end submodule is used to receive the parsed test result file and display the corresponding test result in a visual interface.

[0045] The front-end submodule communicates with the back-end submodule via a network protocol, receiving parsed detection results pushed by the back-end submodule. Specifically, the front-end submodule sets up a listening mechanism to wait for parsing results from the back-end submodule. Once the back-end submodule sends the parsed detection results, the back-end submodule immediately receives them. The front-end submodule displays the received detection results in a user-friendly visual interface. Regarding interface design, the front-end submodule can optionally use a front-end framework (such as React or Vue.js) to build a dynamic user interface. Regarding display content, the front-end submodule can display all detected errors, warnings, and other information in a list format, allowing users to quickly browse all issues. For each error, the front-end submodule highlights the corresponding line of code in a code editor (such as VSCode) based on the file path and line number. This allows users to intuitively identify the location of the problematic code. When the user hovers over the highlighted code block, the front-end submodule pops up a detailed information box with a description of the error and possible fixes. Furthermore, the front-end submodule supports interactive features such as filtering and searching for errors and jumping to specific errors, enhancing user convenience.

[0046] In an optional embodiment, the back-end submodule is used to extract key information of the detection result file, and the key information includes at least: vulnerability type, vulnerability location and repair suggestions; organize the key information into a data object in JSON format, and push it to the front-end submodule through a network protocol.

[0047] Based on the detection result file, the backend submodule extracts the following key information: vulnerability type, which indicates the type of memory security issue detected, such as Use After Free (UAF) and Double Free (DF). or Out of Range Access (OOR); vulnerability location, which specifically indicates the code location where the problem occurs, including the file path and line number; repair suggestions, which provide possible suggestions or solutions for the detected vulnerability to help developers understand how to fix the problem.

[0048] The backend submodule organizes the extracted key information into a structured data object for subsequent transmission and processing. This embodiment uses the JSON (JavaScript Object Notation) format. JSON is a lightweight data exchange format that is easy for humans to read and write, and also easy for machines to parse and generate. For example: { "vulnerability_type": "Double Free", "location": { "file_path": "main.rs", "line_number": 20 }, "fix_suggestion": "Memory is released twice, please check the release logic"}; In this object: Vulnerability_type indicates the vulnerability type, location is a nested object containing file_path and line_number, and fix_suggestion indicates the recommended fix. The backend submodule selects the appropriate network protocol and pushes the compiled JSON data object to the frontend submodule's designated endpoint, which can be an API.

[0049] In an optional embodiment, the image packaging module is further used to mark the warehouse path and version number for the container image, and push the container image to the image warehouse specified in the image market based on the warehouse path, for download and calling by the calling module; wherein the warehouse path represents the location of the image warehouse specified by the container image in the image market, and the version number includes the version of the detection unit, the adapted Rust compiler version, and the build date of the container image.

[0050] The repository path refers to the storage location of the container image in the image market. The image market is an online platform that centrally stores and manages container images, where users can search, download, and use various images.

[0051] Image marketplaces include Docker Hub and Google Container Registry. A repository path consists of the username, repository name, and image name. For example, "myusername / myrepository / myimage." Labeling the repository path clearly identifies the user or team that owns the image, making it easy to find and manage within the image marketplace. The version number identifies the specific version of the container image, including the version of the detection unit, the compatible Rust compiler version, and the build date of the container image.

[0052] The image packaging module pushes the container image based on the repository path, uploading it to the specified image market for download and invocation by the calling module. The push operation can be performed using the Docker command-line tool. For example: docker push myusername / myrepository / myimage:v1.0.0-rustc-1.65.0-2023-11-23.

[0053] In an optional implementation, the image encapsulation module is further used to specify environment variables of the container image; and the detection unit is used to access resources and configuration files required for runtime according to the environment variables.

[0054] Environment variables are dynamic, named values ​​in the operating system that influence the behavior of programs. They can store configuration information, paths, user information, and more, making them accessible to running programs. In container environments, environment variables can be used to configure the application's runtime environment, ensuring that the application can find the resources and configuration files it needs.

[0055] When building a container image, the image packaging module sets a series of environment variables according to the needs of the detection unit, including: RUSTUP_HOME, which specifies the installation directory of the Rust toolchain to ensure that the Rust compiler can find the required tools and libraries; CARGO_HOME, which specifies the working directory of Cargo (Rust's package manager) for storing dependent packages and build outputs; other configuration variables, such as log level, input path, and output path, ensure that the detection unit can read and write data correctly.

[0056] For example, in a Dockerfile or build script, the environment variables can be set as follows: ENV RUSTUP_HOME= / usr / local / rustup; ENV CARGO_HOME= / usr / local / cargo; ENV LOG_LEVEL=info.

[0057] At runtime, the instrumentation unit accesses required resources and configuration files based on the specified environment variables. When the instrumentation unit starts, it checks the environment variables and configures its runtime environment accordingly. For example, the instrumentation unit can determine the location of dependent libraries by reading the CARGO_HOME variable, ensuring that these libraries are correctly accessed during analysis.

[0058] In an optional embodiment, the calling module is used to obtain the log information recorded during the operation of the detection unit when the detection unit fails to detect; and restart the container image according to the log information after a preset time delay until a preset maximum number of retries is reached.

[0059] The detection unit may fail to complete the detection successfully due to various reasons, such as insufficient resources (such as memory or CPU) or temporary network problems. When the detection unit fails, the calling module captures this status and starts the subsequent processing process. The detection unit will record detailed log information during operation. The calling module will access the runtime log of the detection unit, which can be obtained through the Docker API or the log file in the container. For example, you can use the following command to get the container log: docker logs<container_id> .

[0060] After receiving the log information, the calling module delays for a preset period of time (e.g., a few seconds) before attempting to restart the container. This allows the system time to recover and avoids repeated failures due to transient resource contention or excessive load. The calling module analyzes the cause of the failure based on the log information and decides whether to restart the container. If a restart is required, the calling module stops the currently running container and restarts the container image. You can use the Docker command: docker restart<container_id> .

[0061] To prevent the system from falling into an infinite retry state, the calling module sets a maximum number of retries (for example, 3, 5, etc.). After each restart, the calling module checks the current retry count. If the detection fails again after the restart, the calling module will continue to obtain log information and delay restarts until the preset maximum number of retries is reached. If the retry count reaches the upper limit, the calling module will stop retrying and provide failure feedback to the user or log it in the system log.

[0062] In an optional embodiment, the calling module is used to perform topological sorting on the multiple Rust projects and generate a sequential detection list; and according to the detection sequence list, the container image is called in sequence to detect memory safety vulnerabilities in the Rust code in each Rust project.

[0063] The calling module sorts Rust projects using topological sorting, generating a sequential detection list. These projects are then tested sequentially, ultimately providing the test results. Large Rust projects often contain multiple subprojects or modules, which may have dependencies. For example, the code in one submodule may depend on the implementation of another submodule. Therefore, when testing these projects, a specific order must be followed to ensure that projects that do not depend on other modules are tested first, followed by those that do. Topological sorting is a method for sorting directed acyclic graphs (DAGs). In Rust projects, the dependencies between projects can be represented as a graph, with each node representing a Rust project or module and edges representing dependencies between modules. The goal of topological sorting is to produce a sorted list, or detection order list, such that each project or module appears before the modules it depends on. This allows testing to prioritize projects without dependencies over those that depend on other projects. Suppose there are three Rust projects: ProjectA, which does not depend on other projects; ProjectB, which depends on ProjectA; and ProjectC, which depends on ProjectB. The result of topological sorting should be: ProjectA → ProjectB → ProjectC. In other words, the calling module will first check ProjectA, then ProjectB, and finally ProjectC. After the topological sort is complete, the calling module generates a sequential check list based on the sorted results. Each item in the sequential check list represents a Rust project. This sequential check list ensures that checks are performed according to the dependencies between projects, preventing check failures due to dependencies on unchecked modules.

[0064] The calling module checks the projects in the list sequentially, calling the container image one by one to check the code in each Rust project for memory safety vulnerabilities. Before checking the first Rust project, the calling module first starts a new container instance. The target Rust project's code is then passed to the detection unit within the container for analysis. This is accomplished by mounting the project's code directory into the container. The detection unit in the container then performs memory safety vulnerability analysis, checking for memory safety vulnerabilities in the Rust code.

[0065] Figure 2 This is a schematic diagram of the application process of a Rust code memory security vulnerability detection tool according to an embodiment of the present invention. Figure 2As shown, when a user saves or opens Rust code, the front-end submodule in the calling module responds to this action. The front-end submodule uses a path resolution algorithm to resolve the file path of the Rust project to be tested and determine its project root directory. When multiple Rust projects are interdependent, the calling module topologically sorts these projects to generate a sequential detection list. Following this order, the container image performs memory safety vulnerability detection on the code in each Rust project. The front-end submodule in the calling module copies the Rust project to be tested from the root directory to the container image for subsequent memory safety vulnerability detection. The Rust project copied to the container image is then tested for memory safety vulnerabilities by the detection unit. Based on the memory lifecycle annotations in the Rust code, the detection unit detects potential memory safety vulnerabilities at each memory allocation and deallocation point. The detection unit outputs the detection result file to an output path. The back-end submodule captures the detection result file and parses the key information. The parsed key information is organized into a JSON-formatted data object and pushed to the front-end submodule via a network protocol. After receiving the parsed test result file, the front-end submodule displays the memory safety test results of each Rust project in a visual interface for users to view and analyze.

[0066] Through the above process, the Rust code memory safety vulnerability detection tool provided by the present invention can efficiently detect memory safety vulnerabilities in Rust code and present the detection results through a visual interface, helping developers to better locate and fix potential memory safety issues, thereby improving the code quality and security of Rust projects.

[0067] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, apparatuses, electronic devices, and storage media. Accordingly, embodiments of the present invention may take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of the present invention may take the form of a computer program product implemented on one or more computer-readable storage media (including but not limited to magnetic disk storage, CD-ROMs, optical storage, etc.) containing computer-usable program code.

[0068] The embodiments of the present invention are described with reference to the flowcharts and / or block diagrams of the methods and apparatus according to the embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as the combination of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminal device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1a process or multiple processes and / or boxes Figure 1 These computer program instructions can also be stored in a computer readable memory that can guide a computer or other programmable data processing terminal device to work in a specific way, so that the instructions stored in the computer readable memory produce a product including an instruction device, which implements the functions specified in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device, so that a series of operation steps are executed on the computer or other programmable terminal device to produce a computer-implemented process, thereby providing instructions for implementing the process in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0069] Although the preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they are aware of the basic creative concepts. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present invention.

[0070] Finally, it should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "comprises" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article, or terminal device that includes a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article, or terminal device. In the absence of further limitations, the elements defined by the sentence "comprises..." do not exclude the presence of other identical elements in the process, method, article, or terminal device that includes the elements.

[0071] The above is a detailed introduction to a Rust code memory security vulnerability detection tool provided by the present invention. Specific examples are used herein to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core ideas. At the same time, for those skilled in the art, according to the ideas of the present invention, there may be changes in the specific implementation methods and application scopes. In summary, the content of this specification should not be understood as limiting the present invention.

Claims

1. A Rust code memory security vulnerability detection tool, characterized by: include: An image encapsulation module, which is used to encapsulate the detection unit and its operating environment into an independent container image. The detection unit is used to detect memory security vulnerabilities in Rust code in Rust projects and output corresponding detection result files; A calling module is used to, in response to a save or open operation on the Rust code, obtain multiple Rust projects that are mutually dependent on the current Rust project in the same work area, and call the container image to detect memory safety vulnerabilities in the Rust code in each Rust project.

2. A Rust code memory security vulnerability detection tool according to claim 1, characterized in that: The calling module includes a front-end submodule; The front-end submodule is used to determine the project root directory of the Rust project to be detected according to the file path of the Rust project to be detected through a path resolution algorithm; and copy the Rust project to be detected from the project root directory to the container image.

3. A Rust code memory security vulnerability detection tool according to claim 2, characterized in that: The detection unit is configured with an input path and an output path, the input path is a path for obtaining the Rust project to be detected, the output path is a path for outputting the detection result file, and the input path is pointed to the detection unit by the container image.

4. A Rust code memory security vulnerability detection tool according to claim 2, characterized in that: The calling module includes a back-end submodule; The back-end submodule is configured to parse the detection result file output by the detection unit and push the parsed detection result file to the front-end submodule via a network protocol; The front-end submodule is used to receive the parsed test result file and display the corresponding test result in a visual interface.

5. A Rust code memory security vulnerability detection tool according to claim 4, characterized in that: The back-end submodule is used to extract key information from the detection result file, where the key information includes at least: vulnerability type, vulnerability location and repair suggestions; organize the key information into a data object in JSON format and push it to the front-end submodule via a network protocol.

6. A Rust code memory security vulnerability detection tool according to claim 1, characterized in that: The image packaging module is further used to mark the warehouse path and version number for the container image, and push the container image to the image warehouse specified in the image market based on the warehouse path for download and calling by the calling module; wherein the warehouse path represents the location of the image warehouse specified by the container image in the image market, and the version number includes the version of the detection unit, the adapted Rust compiler version, and the build date of the container image.

7. A Rust code memory security vulnerability detection tool according to any one of claims 1 to 6, characterized in that: The image encapsulation module is further used to specify the environment variables of the container image; The detection unit is used to access resources and configuration files required for runtime according to the environment variables.

8. A Rust code memory security vulnerability detection tool according to any one of claims 1 to 6, characterized in that: The calling module is used to obtain the log information recorded when the detection unit is running if the detection unit fails; and restart the container image according to the log information after a preset time delay until a preset maximum number of retries is reached.

9. A Rust code memory security vulnerability detection tool according to any one of claims 1 to 6, characterized in that: The calling module is used to topologically sort the multiple Rust projects and generate a sequential detection list; according to the detection sequence list, the container image is called in sequence to detect memory security vulnerabilities in the Rust code in each Rust project.

10. A Rust code memory security vulnerability detection tool according to claim 1, characterized in that: Checking, for the detection unit, whether logic changes occur within the corresponding RustC compiler, where the logic changes include syntax changes, semantic changes, API changes, type system extensions, and borrowing rule extensions; When a logic change is detected inside the RustC compiler, the analysis logic of the detection unit is modified accordingly.

Images