Test method and device for operating system kernel based on Rust language

Abstract

The embodiment of the invention provides a test method and device for an operating system kernel based on a Rust language, and the method comprises the steps: obtaining a source code of the operating system kernel based on the Rust language, compiling the source code into an intermediate representation, and generating a function call graph among functions contained in the operating system kernel according to the intermediate representation; determining a target position corresponding to a preset potential anomaly in the intermediate representation and a target variable corresponding to the potential anomaly in the target position through a preset recognition rule; performing backward tracking analysis on the target variable according to the function call graph and the target position, and determining a system call interface associated with the target position in an operating system kernel and a call variable associated with the target variable in the system call interface; and according to the system call interface and the call variable, generating a test case for the operating system kernel.

Description

Technical Field

[0001] This specification relates to one or more embodiments in the fields of operating systems and Rust language technology, and more particularly to a testing method and apparatus for a Rust-based operating system kernel. Background Technology

[0002] Rust, as a memory-safe programming language, is frequently used as the kernel development language for highly secure operating systems. Code written in Rust can prevent certain types of exceptions at compile time through Rust's ownership and borrow checker mechanisms, such as buffer overflows, double frees, and use-after-free exceptions, thus improving code safety and reliability. However, other types of exceptions, if not specifically caught and handled by the developer, can still cause programs developed in Rust to crash, especially in the operating system kernel, where a crash can often result in significant losses for the user. Summary of the Invention

[0003] The embodiments in this specification aim to provide a testing method and apparatus for operating system kernels based on the Rust language. By compiling the source code of the Rust-based operating system kernel into an intermediate representation, the location of preset potential exceptions and the variables associated with these exceptions can be easily identified from the intermediate representation. Furthermore, backward tracing analysis based on control flow and data flow can be performed on these variables to accurately determine the system call interfaces in the operating system kernel associated with the variables, as well as the call variables associated with those variables within the system call interfaces—that is, to accurately determine the system call interfaces and call variables related to potential exceptions. By generating and running test cases for these system call interfaces and call variables, the probability of triggering exceptions in the Rust-based operating system kernel through testing can be greatly increased, thereby effectively improving the efficiency of discovering operating system kernel vulnerabilities and overcoming the shortcomings of existing technologies.

[0004] Based on the first aspect, a testing method for operating system kernels based on the Rust language is provided, including:

[0005] Obtain the source code of the operating system kernel based on the Rust language, compile the source code into an intermediate representation, and generate a function call graph between functions contained in the operating system kernel based on the intermediate representation;

[0006] By using preset identification rules, the target location corresponding to the preset potential anomaly in the intermediate representation and the target variable corresponding to the potential anomaly in the target location are determined; based on the function call graph and the target location, a backward tracing analysis is performed on the target variable to determine the system call interface in the operating system kernel associated with the target variable and the call variable in the system call interface associated with the target variable;

[0007] Based on the system call interface and the call variables, test cases are generated for the operating system kernel.

[0008] In one possible implementation, the method further includes:

[0009] Run the test cases, and determine the vulnerabilities existing in the operating system kernel based on the results of the test cases.

[0010] In one possible implementation, test cases for the operating system kernel are generated based on the system call interface and the call variables, including:

[0011] The value of the calling variable is mutated to obtain the mutated value corresponding to the calling variable;

[0012] Based on the system call interface and the mutation value, test cases are generated for the operating system kernel.

[0013] In one possible implementation, backward tracing analysis based on the function call graph and the target location includes: performing backward tracing analysis based on data flow and control flow based on the function call graph and the target location.

[0014] In one possible implementation, the method further includes:

[0015] After determining the system call interface in the operating system kernel associated with the target variable, and the call variable in the system call interface associated with the target variable, the mapping relationship between the system call interface and the call variable is added to a preset dictionary;

[0016] Based on the system call interface and the call variables, generate test cases for the operating system kernel;

[0017] The test cases are generated based on the mapping relationships stored in the dictionary.

[0018] In one possible implementation, the potential exceptions include one or more of the following: unwrap exception, array out-of-bounds exception, numerical overflow exception, negative value inversion exception, division by zero error exception, and remainder error exception.

[0019] In one possible implementation, the intermediate representation is a mid-level intermediate representation (MIR); the identification rules include any one or more of the following:

[0020] If the potential exception is an unpacking exception, the target location is the location of the unpacking call in the intermediate representation, and the target variable is the call parameter of the unpacking call;

[0021] If the potential exception is an array out-of-bounds exception, the target position is the position where the boundary check instruction is located in the intermediate representation, and the target variable is the length parameter and index parameter of the boundary check instruction;

[0022] If the potential exception is a numerical overflow exception, the target position is the position of the overflow check statement in the intermediate representation, and the target variables are the left operand and right operand of the overflow check statement.

[0023] If the potential exception is a negative value negation exception, the target position is the position of the negation overflow check statement in the intermediate representation, and the target variables are the left operand and right operand of the negation overflow check statement.

[0024] If the potential exception is a division-by-zero error exception, the target position is the position of the division-by-zero check statement in the intermediate representation, and the target variable is the divisor parameter of the division-by-zero check statement;

[0025] If the potential exception is a remainder-zero error exception, the target position is the position of the remainder-zero check statement in the intermediate representation, and the target variable is the modulus parameter of the division-by-zero check statement.

[0026] According to the second aspect, a testing device for an operating system kernel based on the Rust language is provided, comprising:

[0027] The acquisition unit is configured to acquire the source code of an operating system kernel based on the Rust language, compile the source code into an intermediate representation, and generate a function call graph between functions contained in the operating system kernel based on the intermediate representation;

[0028] The determination unit is configured to, through preset identification rules, determine the target location in the intermediate representation corresponding to a preset potential anomaly and the target variable in the target location corresponding to the potential anomaly; perform backward tracing analysis on the target variable based on the function call graph and the target location to determine the system call interface in the operating system kernel associated with the target variable and the call variable in the system call interface associated with the target variable;

[0029] The test unit is configured to generate test cases for the operating system kernel based on the system call interface and the call variables.

[0030] According to a third aspect, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method described in the first aspect.

[0031] According to a fourth aspect, a computing device is provided, including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method described in the first aspect.

[0032] By utilizing one or more of the methods, devices, computing equipment, and storage media mentioned above, the probability of triggering exceptions in the Rust-based operating system kernel through testing can be greatly increased, thereby effectively improving the efficiency of discovering vulnerabilities in the operating system kernel through testing. Attached Figure Description

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

[0034] Figure 1 This diagram illustrates a testing method for a Rust-based operating system kernel according to an embodiment of this specification.

[0035] Figure 2 A flowchart illustrating a testing method for a Rust-based operating system kernel according to an embodiment of this specification is shown.

[0036] Figure 3 A schematic diagram illustrating the types of potential anomalies according to embodiments of this specification;

[0037] Figure 4 This diagram illustrates a structural diagram of a test apparatus for a Rust-based operating system kernel according to an embodiment of this specification. Detailed Implementation

[0038] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0039] As mentioned earlier, Rust, as a memory-safe programming language, is currently frequently used as the kernel development language for highly secure operating systems. Code written in Rust can undergo static code analysis at compile time through Rust's ownership and borrow checker mechanisms, preventing certain types of exceptions, such as buffer overflows, double-free, and use-after-free, thus improving code security and reliability. However, other types of exceptions, if not specifically caught and handled by the developer, can still cause programs developed in Rust to crash.

[0040] For example, in Rust, the `unwrap` function is used to directly retrieve an internal value from an optional or result type. When this function is called, if the value does not exist (None) or the operation fails, a panic is immediately triggered. While `unwrap` serves as a convenient proxy, developers often assume "nothing will go wrong here." However, if the input to this function during actual runtime results in a missing value or a failed operation, the program will still crash. Furthermore, whether an exception occurs during the call to the `unwrap` function itself depends on the runtime input parameters, making it difficult to detect exceptions through compile-time static checking mechanisms (e.g., static checks based on ownership and borrowing mechanisms). Additionally, although Rust automatically inserts checks during compilation for code that might encounter exceptions such as integer overflow, division by zero, or array out-of-bounds errors, it does not automatically handle these exceptions. If developers fail to write code to catch and correctly handle these exceptions, the program can still crash.

[0041] Fuzz testing is an automated software testing technique. Its core idea is to observe abnormal behavior by inputting a large amount of random data or variations of existing input data into the program under test, thereby discovering potential vulnerabilities. For example, in testing the operating system kernel, abnormal behavior in the kernel is typically triggered by calling system calls and passing in a large number of different parameter values, thus discovering kernel vulnerabilities (bugs). However, existing fuzz testing schemes for operating system kernels have the following problems: these schemes typically target operating system kernels written in C, lacking specificity for the strict exception handling features of the Rust language. For example, there is no specific handling for the unpacking function mentioned above, or for the automatic insertion of checks in code that may cause exceptions such as integer overflow, division by zero, and array out-of-bounds errors. This results in existing operating system kernel fuzz testing schemes lacking effective targeting of the system calls used in Rust-written operating system kernels during testing. Consequently, the effectiveness of triggering exceptions during testing is poor, making it difficult to efficiently discover potential vulnerabilities in the system kernel.

[0042] To address the aforementioned technical problems, this specification provides a testing method for operating system kernels based on the Rust language. Figure 1 This diagram illustrates a testing method for a Rust-based operating system kernel according to an embodiment of this specification. Figure 1 As shown, an operating system kernel written in Rust can be compiled into an intermediate representation (IR). The IR then identifies the target location of potential unhandled exception code and the exception-related variables within that location. Forward trace analysis is then performed at this location to determine the target location in the IR corresponding to a predefined potential exception and the target variable within that location. Further forward trace analysis identifies the system call interface associated with the target location in the operating system kernel, as well as the call variables associated with the target variable within those system call interfaces. Subsequently, test cases can be generated for this operating system kernel based on the identified system call interfaces and call variables. Running these test cases triggers potential exceptions, thereby uncovering potential vulnerabilities within the operating system kernel.

[0043] The advantage of this method lies in its ability to easily identify the locations of pre-defined potential exceptions and their associated variables by compiling the source code of the Rust-based operating system kernel into an intermediate representation. Furthermore, backward tracing analysis based on control flow and data flow can be performed on these variables to precisely determine the system call interfaces associated with those variables within the operating system kernel, as well as the call variables associated with those variables within those system call interfaces. In other words, the system call interfaces and call variables related to potential exceptions can be accurately identified. By generating and running test cases targeting these system call interfaces and call variables, the probability of triggering exceptions in the Rust-based operating system kernel through testing can be significantly increased, thereby effectively improving the efficiency of discovering operating system kernel vulnerabilities through testing.

[0044] The following section further elaborates on the detailed process of this method. Figure 2 A flowchart illustrating a testing method for a Rust-based operating system kernel according to an embodiment of this specification is shown. Figure 2 The method includes at least the following steps:

[0045] Step S201: Obtain the source code of the operating system kernel based on the Rust language, compile the source code into an intermediate representation, and generate a function call graph between functions contained in the operating system kernel based on the intermediate representation;

[0046] Step S203: Through the function call graph, determine the target location in the intermediate representation corresponding to the preset potential anomaly and the target variable in the target location corresponding to the potential anomaly; perform backward tracing analysis on the target variable based on the function call graph and the target location to determine the system call interface in the operating system kernel associated with the target variable and the call variable in the system call interface associated with the target variable;

[0047] Step S205: Generate test cases for the operating system kernel based on the system call interface and the call variables.

[0048] First, in step S201, the source code of the operating system kernel based on the Rust language can be obtained and compiled into an intermediate representation. Then, a function call graph of the functions contained in the operating system kernel can be generated based on the intermediate representation.

[0049] This step allows you to obtain the source code of the operating system kernel written in Rust. An operating system is the foundational software that runs on computer hardware, providing a stable, efficient, and secure operating environment for users and applications. Typically, the operating system manages computer hardware resources (such as processors, memory, storage devices, input / output devices, etc.), coordinates the concurrent execution of multiple programs, and provides a unified interface for applications. The operating system kernel is the core part of the operating system. Typically, the kernel has the highest control over system resources and is used for the most basic system functions, such as process scheduling, memory management, device drivers, file system support, and handling system calls. Source code, on the other hand, is a set of instructions written in a programming language that describes the functionality and logic of a computer program. Source code can be compiled into machine code that a computer can execute. In different embodiments, the source code of the kernel of different specific operating systems written in Rust can be obtained; this specification does not limit this.

[0050] After obtaining the source code of the Rust operating system kernel, this source code can be compiled into an intermediate representation (IR). An intermediate representation (IR) is an intermediate language generated during the process of converting source code into machine code. The intermediate representation serves as a bridge between the source code and the target machine code, representing program logic in an abstract, hardware-platform-independent form. In different embodiments, the obtained source code can be compiled into different specific types of intermediate representations. In different embodiments, the Rust operating system kernel source code can be compiled into intermediate representations of different specific classes. In one embodiment, the source code can be compiled into a mid-level intermediate representation (MIR) using the Rust compiler (rustc). After obtaining the intermediate representation, a function call graph of the functions contained in the operating system kernel can be generated based on it. A function call graph is a directed graph used to represent the call relationships between functions in a program. In different embodiments, the specific type of the generated function call graph can be different. In one embodiment, a static call graph of the functions contained in the operating system kernel can be generated.

[0051] Then, in step S203, by using preset identification rules, the target location corresponding to the preset potential anomaly in the intermediate representation and the target variable corresponding to the potential anomaly in the target location are determined. Furthermore, based on the function call graph and the target location, a backward tracing analysis is performed on the target variable to determine the system call interface in the operating system kernel associated with the target variable, and the call variables in the system call interface associated with the target variable.

[0052] A potential exception is an exception or error state that may be triggered under specific conditions during program execution, often caused by vulnerabilities in the code that could trigger exceptions. However, these vulnerabilities are often not yet exposed in previous program runs. In different implementations, the potential exception can be different specific exceptions. In one embodiment, it can be one or more of the following: unwrap exception, array out-of-bounds exception, numerical overflow exception, negation exception, division by zero error exception, and remainder-zero error exception.

[0053] In different embodiments, the target location and target variable can be determined according to different, preset specific identification rules. In the above embodiment compiled as MIR, the target location and target variable can be determined by any one or more of the following identification rules: If the potential exception is a depackaging exception, the target location can be the location of the depackaging call in the intermediate representation, and the target variable can be the call parameter of the depackaging call; if the potential exception is an array out-of-bounds exception, the target location can be the location of the boundary check instruction in the intermediate representation, and the target variable can be the length parameter and index parameter of the boundary check instruction; if the potential exception is a numerical overflow exception, the target location can be the location of the overflow check statement in the intermediate representation, and the target variable can be... The left and right operands of the overflow check statement; if the potential exception is a negative value negation exception, the target position can be the position of the negation overflow check statement in the intermediate representation, and the target variable can be the left and right operands of the negation overflow check statement; if the potential exception is a division by zero error exception, the target position can be the position of the division by zero check statement in the intermediate representation, and the target variable is the divisor parameter of the division by zero check statement; if the potential exception is a remainder-zero error exception, the target position can be the position of the remainder-zero check statement in the intermediate representation, and the target variable is the modulus parameter of the division by zero check statement.

[0054] After determining the target location and target variable, backward tracing analysis can be performed on the target variable based on the function call graph and the target location to identify the system call interface in the operating system kernel associated with the target variable, and the call variables associated with the target variable within the system call interface. Backward tracing starts from a specific target point in the program and traces back the variables, conditions, or input sources it depends on, moving in the opposite direction of control and data flow. Therefore, in one embodiment, backward tracing analysis based on data flow and control flow can be performed based on the function call graph and target location to identify the system call interface in the operating system kernel associated with the target variable, and the call variables associated with the target variable within the system call interface. In different specific embodiments, the specific methods for performing backward tracing analysis based on data flow and control flow based on the function call graph and target location can differ. In one specific embodiment, the call dependencies between functions in the operating system kernel (referred to as inter-function call dependencies) can be determined based on the function call graph, and the intra-function control dependencies and intra-function data dependencies can be determined based on the control and data flow within the function bodies of the functions in the operating system kernel. Based on the target location, inter-function call dependencies, intra-function control dependencies, and intra-function data dependencies, the system call interfaces in the operating system kernel associated with the target variable, as well as the call variables in those system call interfaces associated with the target variable, are determined. In this way, system call interfaces and their call parameters that are highly correlated with triggering potential exceptions can be accurately identified.

[0055] In real-world production scenarios, the number of potential anomalies to be monitored is often large. To facilitate subsequent batch testing of these anomalies, system call interfaces and call variables associated with multiple potential anomalies can be saved in a preset dictionary. Therefore, in one embodiment, after determining the system call interfaces in the operating system kernel associated with the target variable, and the call variables in the system call interfaces associated with the target variable, the mapping relationship between the system call interfaces and the call variables can also be added to the preset dictionary.

[0056] Subsequently, in step S205, test cases for the operating system kernel can be generated based on the system call interface and the call variables. In this step, test cases for the operating system kernel can be generated based on the system call interface and call variables obtained in system step S203. In the embodiment where the mapping relationship between the system call interface and the call variables is added to a preset dictionary, the test cases can also be generated based on the mapping relationship stored in the dictionary.

[0057] In different specific embodiments, test cases of different specific types can be generated based on system call interfaces and call variables for different types of potential exceptions. For example, in one specific embodiment, if the potential exception is an array out-of-bounds exception, an out-of-bounds test case for the operating system kernel can be generated based on the system call interface and call variables. In another specific embodiment, if the potential exception is a division-by-zero error exception, a division-by-zero test case for the operating system kernel can be generated based on the system call interface and call variables.

[0058] In one embodiment, after step S205, test cases generated in step S205 can be generated, and the test cases can be run. Based on the results of the test cases, vulnerabilities existing in the operating system kernel can be determined. In one example, if the test case triggers a potential exception, it can be determined that a vulnerability related to that potential exception exists in the operating system kernel. In another example, if the test case does not trigger a potential exception, it can be determined that no vulnerability related to that potential exception was found in the operating system kernel through testing. It should be noted that, generally speaking, even if the test case does not trigger a potential exception, it cannot be completely determined that a vulnerability related to that potential exception does not exist in the operating system kernel; it can only be determined that no vulnerability related to that potential exception was found through testing.

[0059] According to yet another embodiment, a testing apparatus for an operating system kernel based on the Rust language is also provided. Figure 4 The diagram illustrates a structural design of a test apparatus for a Rust-based operating system kernel according to an embodiment of this specification. Figure 4 As shown, the device 400 includes:

[0060] The acquisition unit 401 is configured to acquire the source code of the operating system kernel based on the Rust language, compile the source code into an intermediate representation, and generate a function call graph between functions contained in the operating system kernel based on the intermediate representation;

[0061] The determining unit 402 is configured to, through preset identification rules, determine the target position corresponding to the potential anomaly in the intermediate representation and the target variable corresponding to the preset potential anomaly in the target position; perform backward tracing analysis on the target variable based on the function call graph and the target position to determine the system call interface associated with the target variable in the operating system kernel and the call variable associated with the target variable in the system call interface;

[0062] Test unit 403 is configured to generate test cases for the operating system kernel based on the system call interface and the call variables.

[0063] In another aspect, embodiments of this specification provide a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform any of the methods described above.

[0064] In another aspect, embodiments of this specification provide a computing device, including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement any of the methods described above.

[0065] It should be understood that the descriptions such as "first" and "second" in this article are merely for the sake of simplicity in description and to distinguish similar concepts, and do not have any other limiting function.

[0066] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0067] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0068] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0069] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes said elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0070] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0071] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations 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, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0072] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0073] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0074] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0075] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0076] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0077] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0078] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0079] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0080] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of these embodiments. Various modifications and variations can be made to these embodiments by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A testing method for operating system kernels based on the Rust language, comprising: Obtain the source code of the operating system kernel based on the Rust language, compile the source code into an intermediate representation, and generate a function call graph between functions contained in the operating system kernel based on the intermediate representation; By using preset identification rules, the target location corresponding to the preset potential anomaly in the intermediate representation and the target variable corresponding to the potential anomaly in the target location are determined; based on the function call graph and the target location, a backward tracing analysis is performed on the target variable to determine the system call interface in the operating system kernel associated with the target variable and the call variable in the system call interface associated with the target variable; Based on the system call interface and the call variables, test cases are generated for the operating system kernel.

2. The method according to claim 1, further comprising: Run the test cases, and determine the vulnerabilities existing in the operating system kernel based on the results of the test cases.

3. The method according to claim 1, wherein, Based on the system call interface and the call variables, test cases are generated for the operating system kernel, including: The value of the calling variable is mutated to obtain the mutated value corresponding to the calling variable; Based on the system call interface and the mutation value, test cases are generated for the operating system kernel.

4. The method according to claim 1, wherein, Backward tracing analysis based on the function call graph and target location includes: backward tracing analysis based on data flow and control flow based on the function call graph and target location.

5. The method according to claim 1, further comprising: After determining the system call interface in the operating system kernel associated with the target variable, and the call variable in the system call interface associated with the target variable, the mapping relationship between the system call interface and the call variable is added to a preset dictionary; Based on the system call interface and the call variables, generate test cases for the operating system kernel; The test cases are generated based on the mapping relationships stored in the dictionary.

6. The method according to claim 1, wherein, The potential exceptions include one or more of the following: Unwrap exception, array out of bounds exception, numerical overflow exception, negative value inversion exception, division by zero error exception, and remainder error exception.

7. The method according to claim 6, wherein, The intermediate representation is a mid-level intermediate representation (MIR); the identification rules include any one or more of the following: If the potential exception is an unpacking exception, the target location is the location of the unpacking call in the intermediate representation, and the target variable is the call parameter of the unpacking call; If the potential exception is an array out-of-bounds exception, the target position is the position where the boundary check instruction is located in the intermediate representation, and the target variable is the length parameter and index parameter of the boundary check instruction; If the potential exception is a numerical overflow exception, the target position is the position of the overflow check statement in the intermediate representation, and the target variables are the left operand and right operand of the overflow check statement. If the potential exception is a negative value negation exception, the target position is the position of the negation overflow check statement in the intermediate representation, and the target variable is the left operand and the right operand of the negation overflow check statement; If the potential exception is a division-by-zero error exception, the target position is the position of the division-by-zero check statement in the intermediate representation, and the target variable is the divisor parameter of the division-by-zero check statement; If the potential exception is a remainder-zero error exception, the target position is the position of the remainder-zero check statement in the intermediate representation, and the target variable is the modulus parameter of the division-by-zero check statement.

8. A testing device for a Rust-based operating system kernel, comprising: The acquisition unit is configured to acquire the source code of an operating system kernel based on the Rust language, compile the source code into an intermediate representation, and generate a function call graph between functions contained in the operating system kernel based on the intermediate representation; The determination unit is configured to, through preset identification rules, determine the target location in the intermediate representation corresponding to a preset potential anomaly and the target variable in the target location corresponding to the potential anomaly; perform backward tracing analysis on the target variable based on the function call graph and the target location to determine the system call interface in the operating system kernel associated with the target variable and the call variable in the system call interface associated with the target variable; The test unit is configured to generate test cases for the operating system kernel based on the system call interface and the call variables.

9. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of any one of claims 1-8.

10. A computing device comprising a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of any one of claims 1-8.

Images