A method, device and equipment for fuzz testing of operating system kernel

Abstract

The present invention provides an operating system kernel fuzz testing method, device and equipment, which relate to the field of kernel fuzz testing technology. By obtaining the initial input and splitting the initial input to generate an input set; performing fuzz testing on the input set and obtaining the fuzz testing results; storing the fuzz testing results in a key component inference file to generate a key component inference table; generating a seed selection strategy in the seed library in combination with the key component inference table to guide seed mutation selection. By identifying and utilizing the key components in the system call sequence, the coverage of the fuzz test is improved. A correspondence between the key components in the system call sequence and the corresponding path basic blocks is established to better explore potential security vulnerabilities. According to the selection of mutation points, different mutation strategies are executed to effectively improve the existing fuzz testing method and improve the efficiency and quality of vulnerability mining.

Description

Technical Field

[0001] The present application relates to the field of kernel fuzz testing technology, and in particular to a method, apparatus, and device for kernel fuzz testing of an operating system. Background Art

[0002] As kernel operating system versions continue to update and kernel code continues to grow, the number of kernel-related vulnerabilities listed in CVE (Common Vulnerabilities & Exposures) continues to rise. The kernel is becoming increasingly complex, encompassing a vast number of functions, subsystems, and drivers. This increases the concealment and difficulty of vulnerability discovery. To accelerate vulnerability detection, an increasing number of automated tools are being developed and used for kernel vulnerability discovery. Fuzz testing, as a proven vulnerability discovery method, has been widely used in this field.

[0003] Syzkaller is a kernel vulnerability fuzz testing platform developed by Google, capable of testing on multiple operating system platforms. It uses system call templates to generate standardized system call sequences, and both test generation and execution are implemented in a virtual machine. Syzkaller generates test cases by generating parameters for memory objects, such as buffers, that are legally accessible. Using a kernel code compilation instrumentation testing approach, Syzkaller uses the Linux kernel's KCOV feature to instrument the kernel code and recompile it to generate target system code. It then guides the kernel fuzz testing process by obtaining kernel execution path information and calculating coverage. The selection table is a key component of Syzkaller, recording the probability that a system call should be called before another. These probabilities are adjusted based on testing requirements and coverage targets to ensure that the generated test cases cover as many different kernel code paths as possible. The selection table also guides test case mutation strategies—that is, how to mutate existing test cases to generate new test cases. These mutation strategies are based on the probabilistic relationships between system calls and the system call templates to ensure that the generated new test cases have a certain coverage and are capable of discovering potential kernel vulnerabilities.

[0004] The quality of test cases greatly affects the efficiency of fuzz testing. However, randomly generated test cases consisting of system calls are difficult to pass or mutate multiple times before there is progress in coverage. Moreover, the randomly selected mutation points may result in inputs that are likely to have the same effect as previous test cases or even invalid inputs.

[0005] Therefore, how to solve the low quality of test cases in kernel fuzz testing has become a technical problem that needs to be solved urgently. Summary of the Invention

[0006] In order to solve the problem of low quality of test cases in kernel fuzz testing, the present application provides an operating system kernel fuzz testing method, device and equipment.

[0007] In the first aspect, the present application provides an operating system kernel fuzz testing method using the following technical solutions:

[0008] A fuzz testing method for an operating system kernel, comprising:

[0009] Obtaining an initial input, and performing splitting processing on the initial input to generate an input set;

[0010] Performing a fuzzy test on the input set and obtaining a fuzzy test result;

[0011] Storing the fuzzy test results in a key component inference file to generate a key component inference table;

[0012] In the seed library, a seed selection strategy is generated in combination with the key component inference table to guide seed variation selection.

[0013] Optionally, the step of obtaining an initial input and splitting the initial input to generate an input set includes:

[0014] Obtaining an initial input and determining a number of seeds in the initial input;

[0015] Perform descending splitting according to the number of seeds to generate a corresponding number of groups;

[0016] An input set is generated according to the corresponding number of groups.

[0017] Optionally, the step of performing a fuzzy test on the input set and obtaining a fuzzy test result includes:

[0018] Using the input set as an initial seed directory for fuzz testing;

[0019] Generating a seed file set from the initial seed set according to source characteristics;

[0020] The coverage rate is recorded in the seed file set using Syzkaller's KCOV mechanism as the fuzz testing result.

[0021] Optionally, before the step of recording coverage in the seed file set using the Syzkaller KCOV mechanism as the fuzz testing result, the method further includes:

[0022] An initialization key component inference table is established, and the elements in the initialization key component inference table are set to 0, the rows are set to key components, and the columns are set to the edges triggered by the key components.

[0023] Optionally, the step of recording coverage using Syzkaller's KCOV mechanism in the seed file set as a fuzz testing result includes:

[0024] Select a target seed from the seed file and execute the target seed;

[0025] Determine whether the target seed triggers a new coverage through Syzkaller's KCOV mechanism;

[0026] When it is determined that the target seed triggers a new coverage, the target seed is sent to a key component recording module so that the key component recording module updates the initialized key component inference table;

[0027] After determining the execution of each seed in the seed file, a coverage record is obtained as a fuzz testing result.

[0028] Optionally, the step of sending the target seed to a key component recording module so that the key component recording module updates the initialized key component inference table includes:

[0029] Sending the target seed to a key component recording module so that the key component recording module obtains the last call of the target seed and the edge triggering new coverage corresponding to the target seed;

[0030] The last call of the target seed is used as row information, and the edge that triggers the new coverage corresponding to the target seed is used as column information;

[0031] The initialization key component inference table is updated according to the row information and the column information.

[0032] Optionally, the step of generating a seed selection strategy in the seed library in combination with the key component inference table to guide seed variation selection includes:

[0033] Sending the key component inference table to a key component processing module in the seed library so that the key component processing module generates queue information according to the row information and column information in the key component inference table;

[0034] A strategy set is generated according to the queue information and implemented to guide seed mutation selection.

[0035] In a second aspect, the present application provides an operating system kernel fuzz testing device, wherein the operating system kernel fuzz testing includes:

[0036] An input set module, configured to obtain an initial input and perform splitting processing on the initial input to generate an input set;

[0037] A fuzzy test result module, configured to perform a fuzzy test on the input set and obtain a fuzzy test result;

[0038] A key component inference table module, configured to store the fuzzy test results into a key component inference file to generate a key component inference table;

[0039] A selection strategy module is used to generate a seed selection strategy in the seed library in combination with the key component inference table to guide seed variation selection.

[0040] In a third aspect, the present application provides an operating system kernel fuzz testing device, which includes: a memory and a processor. When the processor runs the operating system kernel fuzz testing program stored in the memory, it executes the method described above.

[0041] In a fourth aspect, the present application provides a computer-readable storage medium comprising instructions, which, when executed on a computer, enable the computer to execute the method described above.

[0042] In summary, this application has the following beneficial technical effects:

[0043] This application obtains the initial input and splits it to generate an input set; performs fuzz testing on the input set and obtains the fuzz testing results; stores the fuzz testing results in a key component inference file to generate a key component inference table; and generates a seed selection strategy in the seed library in combination with the key component inference table to guide seed mutation selection. By identifying and utilizing the key components in the system call sequence, the coverage of the fuzz test is improved. A correspondence between the key components in the system call sequence and the corresponding path basic blocks is established to better explore potential security vulnerabilities. Based on the selection of mutation points, different mutation strategies are executed to effectively improve the existing fuzz testing method and improve the efficiency and quality of vulnerability mining. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1 This is a schematic diagram of the structure of an operating system kernel fuzz testing device for the hardware operating environment involved in the embodiment of the present application;

[0045] Figure 2 This is a flowchart of the first embodiment of the operating system kernel fuzz testing method of the present application;

[0046] Figure 3 This is an application diagram of the first embodiment of the operating system kernel fuzz testing method of the present application;

[0047] Figure 4 This is a software design flow diagram of the first embodiment of the operating system kernel fuzz testing method of the present application;

[0048] Figure 5 This is a schematic diagram of a key component recording module of the first embodiment of the operating system kernel fuzz testing method of the present application;

[0049] Figure 6 This is a schematic diagram of the key component processing module of the first embodiment of the operating system kernel fuzz testing method of the present application;

[0050] Figure 7 This is a structural block diagram of the first embodiment of the operating system kernel fuzz testing device of the present application. DETAILED DESCRIPTION

[0051] In order to make the purpose, technical solutions and advantages of this application more clearly understood, the present application is further described in detail below through the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0052] Reference Figure 1 , Figure 1 This is a schematic diagram of the structure of the operating system kernel fuzz testing device in the hardware operating environment involved in the embodiment of the present application.

[0053] like Figure 1 As shown, the operating system kernel fuzz testing device may include: a processor 1001, such as a central processing unit (CPU), a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. Among them, the communication bus 1002 is used to realize the connection and communication between these components. The user interface 1003 may include a display screen (Display), an input unit such as a keyboard (Keyboard), and the user interface 1003 may optionally include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a wireless fidelity (Wireless-Fidelity, Wi-Fi) interface). The memory 1005 may be a high-speed random access memory (Random Access Memory, RAM) or a stable non-volatile memory (Non-Volatile Memory, NVM), such as a disk storage. The memory 1005 may optionally be a storage device independent of the aforementioned processor 1001.

[0054] Those skilled in the art will understand that Figure 1 The structure shown in does not constitute a limitation on the operating system kernel fuzz testing device, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0055] like Figure 1As shown, the memory 1005 as a storage medium may include an operating system, a network communication module, a user interface module, and an operating system kernel fuzz testing program.

[0056] exist Figure 1 In the operating system kernel fuzzy testing device shown, the network interface 1004 is mainly used for data communication with the network server; the user interface 1003 is mainly used for data interaction with the user; the processor 1001 and the memory 1005 in this application can be set in the operating system kernel fuzzy testing device, and the operating system kernel fuzzy testing device calls the operating system kernel fuzzy testing program stored in the memory 1005 through the processor 1001, and executes the operating system kernel fuzzy testing method provided by the embodiment of this application.

[0057] The present invention provides a method for fuzz testing the kernel of an operating system. Figure 2 , Figure 2 This is a flow chart of the first embodiment of the operating system kernel fuzz testing method of this application.

[0058] In this embodiment, the operating system kernel fuzz testing method includes the following steps:

[0059] Step S10: Obtain initial input and split the initial input to generate an input set.

[0060] It should be noted that the system call relationships derived from a simple empirical analysis of Syzkaller's selection table are of low quality and insufficient for maintaining high-quality test case generation. Furthermore, they do not consider parameter-level selection guidance strategies. MoonShine captures explicit and implicit dependencies between system calls and uses a seed distillation algorithm to prepare high-quality seeds for Syzkaller. SyzVegas uses the EXP3 algorithm to dynamically and automatically adjust task and seed selection in Syzkaller to improve coverage performance. HEALER defines a binary influence relationship to describe system call dependencies, where the execution of one system call affects the execution path of another. This is recorded in a two-dimensional relationship table.

[0061] However, these fuzz testing methods typically generate input randomly and lack the ability to identify and utilize key components of system call sequences, resulting in low test case coverage. Existing technologies often fail to effectively record the mapping between key components of the input system call sequence that contribute to coverage and the corresponding basic blocks, making it difficult to deeply identify potential security vulnerabilities. Traditional fuzz testing methods also lack intelligent selection of mutation points, making it difficult to specifically explore the system's state space and effectively improving the efficiency and quality of vulnerability discovery.

[0062] It is understandable that the application scenario diagram described in this embodiment is as follows Figure 3 As shown, in the kernel fuzz testing process of the classic tool Syzkaller, when the execution of an input triggers a new path, this embodiment records the mutated part of the input other than the inheritance from the parent seed as a key component, and records it together with the new path in the key component inference table of the host's working directory. By processing the key information fed back, three types of key information are obtained, including a one-to-one relationship in which a system call triggers only one edge, a one-to-many relationship in which a system call triggers multiple edges, and a many-to-one relationship in which multiple system call combinations may trigger. When processing the feedback information, system calls with different parameters are treated as one and counted. In the later fuzz testing process, the information in the table is used to perform auxiliary fuzz testing with a certain probability. The selection of system calls in the mutation phase is assisted based on the information in the table and the three different categories of key components, including selecting a new system call to insert and selecting system calls for parameter mutation.

[0063] In a specific implementation, the steps of obtaining an initial input and splitting the initial input to generate an input set include: obtaining the initial input and determining the number of seeds in the initial input; performing a decreasing split according to the number of seeds to generate a corresponding number of groups; and generating an input set according to the corresponding number of groups.

[0064] It can be understood that the initial high-quality input enters the seed library and undergoes preliminary splitting processing to form multiple groups of inputs. Each group undergoes the fuzz testing process separately, and the key component information that triggers the new coverage is recorded and saved to the host's key component inference file. After the key components are processed, the key component inference table is modified. Seed selection is performed based on the seed library, and the information in the key component inference table is used to guide seed mutation.

[0065] Step S20: Perform fuzzy testing on the input set and obtain the fuzzy testing results.

[0066] In specific implementation, Figure 4 As shown, this embodiment includes two modules for key component processing (key component recording module and key component processing module) to learn key components using high-quality seeds. It includes the following steps:

[0067] Step 1: Initialize the key component inference table. Set all elements in table R to 0, rows to key components, and columns to corresponding triggered edges.

[0068] Step 2: High-quality seed processing. For each seed, divide it into multiple test cases based on the number of system calls it contains. Each time, delete one system call from the end and store it as a seed, which will also be deleted next time.

[0069] Step 3: Obtain a processed seed set, which is derived from the same initial seed as a group;

[0070] Step 4: Place the processed seed folder into the seed directory to be tested.

[0071] Step 5: Select the seed, execute the seed, and use Syzkaller's KCOV mechanism to record the coverage.

[0072] Judgment 1: Determine whether a new coverage is triggered and enter the key component recording module, instead of jumping to judgment 2.

[0073] Step 7: Enter the key component recording module to perform operations.

[0074] Judgment 2: Determine whether all seed catalogs have been executed, and then enter the key component processing module.

[0075] Step 8: Process the information recorded in the key component inference table.

[0076] In a specific implementation, the steps of performing fuzz testing on an input set and obtaining fuzz testing results include: using the input set as an initial seed directory for fuzz testing; generating a seed file set in the initial seed set based on source characteristics; and using Syzkaller's KCOV mechanism in the seed file set to record coverage as the fuzz testing result.

[0077] It should be noted that before using Syzkaller's KCOV mechanism to record coverage in the seed file set as the fuzz testing result, it also includes: establishing an initialization key component inference table, and setting the elements in the initialization key component inference table to 0, the rows to the key components, and the columns to the edges triggered by the key components.

[0078] In a specific implementation, the steps of using Syzkaller's KCOV mechanism to record coverage in a seed file set as a fuzz test result include: selecting a target seed in the seed file and executing the target seed; judging whether the target seed triggers new coverage through Syzkaller's KCOV mechanism; when it is determined that the target seed triggers new coverage, sending the target seed to the key component recording module so that the key component recording module updates the initialized key component inference table; after judging that each seed in the seed file is executed, obtaining the coverage record as the fuzz test result.

[0079] It should be noted that the step of sending the target seed to the key component recording module so that the key component recording module updates the initialized key component inference table includes: sending the target seed to the key component recording module so that the key component recording module obtains the last call of the target seed and the edge corresponding to the target seed that triggers new coverage; using the last call of the target seed as row information and the edge corresponding to the target seed that triggers new coverage as column information; and updating the initialized key component inference table according to the row information and the column information.

[0080] Step S30: Store the fuzzy test results into a key component inference file to generate a key component inference table.

[0081] It is understandable that if Figure 5 The key component recording module shown above is entered when a seed triggers a new coverage. The last call X of the seed is used as a row, and the start and end basic block addresses corresponding to the triggered path are concatenated into edges Y as columns, which are stored in the key component inference table. That is, R(X,Y) = 1.

[0082] Step S40: Generate a seed selection strategy in the seed library in combination with the key component inference table to guide seed variation selection.

[0083] In a specific implementation, a seed selection strategy is generated in the seed library in combination with a key component inference table to implement the steps of guiding seed variation selection, including: sending the key component inference table to the key component processing module in the seed library so that the key component processing module generates queue information based on the row information and column information in the key component inference table; generating a strategy set based on the queue information and implementing the guidance of seed variation selection.

[0084] It is understandable that if Figure 6 The key component processing module shown processes the collected key component inference table.

[0085] Add a new column to sum the data of each row as the weight of the key component corresponding to the row. When calculating, treat system calls with different parameters as one system call:

[0086] 1) Critical components with weights greater than 1 are important critical components that trigger multi-branch nodes and are stored in queue 1. They are recommended for the initial stage of fuzz testing.

[0087] 2) A key component with a weight equal to 1 can only trigger one edge.

[0088] Add a new row to sum the data in each column as the criterion for whether the corresponding edge is reachable. Combine the reachable edges and statistically determine whether they can be connected to form a path:

[0089] 1) Edges that can be combined into a longer path are recorded as the path {Yi, Yj, Yk, ...}. The key components of the corresponding order {Xi, Xj, Xk, ...} are added to queue 3. This is recommended when no new coverage is generated for a long time.

[0090] 2) A single edge Y that cannot be combined into a path. Only one key component, X, is required to reach and trigger this edge. Intersect the X, Y pairs with weight 1 in the sum column to obtain a one-to-one corresponding XY pair, and add it to queue 2.

[0091] In the specific implementation, during subsequent fuzz testing, the acquired key component information is selected with a certain probability to guide fuzz testing. The probability changes dynamically based on the effectiveness of the two strategies. When using key information to guide fuzz testing, the probability of selecting components from the three queues is customized.

[0092] 1) If the initial seed is not set, the test case selection can be guided by the key component information. It is recommended to select the system call with one-to-many property in queue 1 as the test case with high probability for testing and mutation.

[0093] 2) In the early mutation phase, it is recommended to select a system call with a one-to-one property in queue 2 with high probability. Insert the system call into the seed. If the system call already exists in the seed, mutate the parameters of the corresponding system call in the seed.

[0094] 3) In the later mutation phase, coverage growth slows. Record the last basic block currently triggered. Search the triggering edges in the key component inference table for edges starting with that basic block and their corresponding key components. If multiple key components are found, select the many-to-one system call sequence in queue 3 with high probability for concatenation.

[0095] As you can understand, this embodiment infers key components in the input based on the corpus information obtained as feedback during kernel fuzz testing. Key components are learned from existing test cases and crash inputs using probabilistic statistical methods. Its uniqueness lies in the establishment of a key component inference table that records the correspondence between key coverage-contributing components in system call sequences and the corresponding basic blocks in the path, guiding the selection of seed mutations for fuzz testing.

[0096] Compared with existing technologies, this technology has the following differences:

[0097] 1) Establishment of key component inference table: This technology establishes a key component inference table to associate key components in the system call sequence with corresponding basic blocks, forming a mapping relationship. The establishment of this table can help the system select seed input more effectively during the fuzz testing process, thereby improving the efficiency and coverage of test case generation.

[0098] 2) Flexible handling of correspondence: Unlike traditional one-to-one correspondence, this technology divides correspondence into three cases and proposes corresponding handling strategies. This flexible handling can better adapt to different test scenarios and requirements, improving test flexibility and applicability.

[0099] 3) Application of the UCB Algorithm: During the system call selection phase, this technology uses the upper confidence bound (UCB) algorithm to select system calls based on a key component inference table, performing mutations with a certain probability. This algorithm enables the system to more intelligently select mutation directions at different testing stages, thereby improving test efficiency and coverage.

[0100] 4) Real-time Recording and Updates of the Testing Process: This technology records the correspondence between newly triggered basic blocks and newly added system calls during fuzz testing, and updates the weights of key components accordingly. This real-time recording and updating enables the system to continuously optimize testing strategies during testing, improving testing effectiveness and vulnerability discovery speed.

[0101] It should be noted that this embodiment is based on a deep learning-based key component identification method that utilizes deep learning technology, particularly neural networks, to automatically learn and identify key components in software programs through a large number of test cases and crash inputs. By identifying the key input components that cause program crashes or anomalies, variant test cases can be generated more specifically, thereby improving test case coverage and the ability to discover potential defects. This learning-based guidance method can more intelligently guide the generation and selection of test cases, thereby improving the efficiency and effectiveness of software testing.

[0102] This embodiment obtains initial input and splits it to generate an input set; performs fuzz testing on the input set and obtains fuzz testing results; stores the fuzz testing results in a key component inference file to generate a key component inference table; and generates a seed selection strategy in the seed library in combination with the key component inference table to guide seed mutation selection. By identifying and utilizing key components in system call sequences, the coverage of fuzz testing is improved. A correspondence between key components in system call sequences and corresponding path basic blocks is established to better explore potential security vulnerabilities. Based on the selection of mutation points, different mutation strategies are executed to effectively improve the existing fuzz testing method and improve the efficiency and quality of vulnerability mining.

[0103] In addition, an embodiment of the present application also proposes a computer-readable storage medium, on which a program for operating system kernel fuzz testing is stored. When the program for operating system kernel fuzz testing is executed by a processor, the steps of the operating system kernel fuzz testing method as described above are implemented.

[0104] Reference Figure 7 , Figure 7 This is a structural block diagram of the first embodiment of the operating system kernel fuzz testing device of this application.

[0105] like Figure 7 As shown, the operating system kernel fuzz testing device proposed in the embodiment of the present application includes:

[0106] An input set module 10 is used to obtain an initial input and split the initial input to generate an input set;

[0107] A fuzzy test result module 20 is used to perform fuzzy testing on the input set and obtain fuzzy test results;

[0108] A key component inference table module 30 is used to store the fuzzy test results into a key component inference file to generate a key component inference table;

[0109] The selection strategy module 40 is used to generate a seed selection strategy in combination with the key component inference table in the seed library to guide seed variation selection.

[0110] It should be understood that the above is only an example and does not constitute any limitation to the technical solution of the present application. In specific applications, technicians in this field can make settings as needed, and the present application does not impose any restrictions on this.

[0111] This embodiment obtains initial input and splits it to generate an input set; performs fuzz testing on the input set and obtains fuzz testing results; stores the fuzz testing results in a key component inference file to generate a key component inference table; and generates a seed selection strategy in the seed library in combination with the key component inference table to guide seed mutation selection. By identifying and utilizing key components in system call sequences, the coverage of fuzz testing is improved. A correspondence between key components in system call sequences and corresponding path basic blocks is established to better explore potential security vulnerabilities. Based on the selection of mutation points, different mutation strategies are executed to effectively improve the existing fuzz testing method and improve the efficiency and quality of vulnerability mining.

[0112] It should be noted that the workflow described above is merely illustrative and does not limit the scope of protection of this application. In actual applications, technicians in this field can select part or all of it according to actual needs to achieve the purpose of this embodiment scheme, and no restrictions are imposed here.

[0113] In addition, for technical details not fully described in this embodiment, please refer to the method for operating system kernel fuzz testing provided in any embodiment of this application, and will not be repeated here.

[0114] In addition, it should be noted that, in this document, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or system comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or system. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or system comprising the element.

[0115] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0116] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus the necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as read-only memory (ROM) / RAM, magnetic disk, optical disk), and includes a number of instructions for enabling a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods of each embodiment of the present application.

[0117] The above are only preferred embodiments of the present application and do not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A fuzz testing method for an operating system kernel, characterized in that: include: Obtaining an initial input, and performing splitting processing on the initial input to generate an input set; Performing a fuzzy test on the input set and obtaining a fuzzy test result; Storing the fuzzy test results in a key component inference file to generate a key component inference table; generating a seed selection strategy in the seed library in combination with the key component inference table to guide seed variation selection; The step of performing a fuzzy test on the input set and obtaining a fuzzy test result includes: Using the input set as an initial seed directory for fuzz testing; Generating a seed file set in the initial seed directory according to source characteristics; Using Syzkaller's KCOV mechanism in the seed file set to record coverage as a fuzz testing result; Before the step of recording coverage in the seed file set using the KCOV mechanism of Syzkaller as the fuzz testing result, the method further includes: Establishing an initialization key component inference table, and setting the elements in the initialization key component inference table to 0, setting the rows to key components, and setting the columns to edges triggered by the key components; The step of recording coverage using the Syzkaller KCOV mechanism in the seed file set as a fuzz testing result includes: Select a target seed from the seed file and execute the target seed; Determine whether the target seed triggers a new coverage through Syzkaller's KCOV mechanism; When it is determined that the target seed triggers a new coverage, the target seed is sent to a key component recording module so that the key component recording module updates the initialized key component inference table; After determining the execution of each seed in the seed file, a coverage record is obtained as a fuzz testing result.

2. The operating system kernel fuzz testing method according to claim 1, characterized in that: The steps of obtaining an initial input and splitting the initial input to generate an input set include: Obtaining an initial input and determining a number of seeds in the initial input; Perform descending splitting according to the number of seeds to generate a corresponding number of groups; An input set is generated according to the corresponding number of groups.

3. The operating system kernel fuzz testing method according to claim 1, characterized in that: The step of sending the target seed to the key component recording module so that the key component recording module updates the initialized key component inference table includes: Sending the target seed to a key component recording module so that the key component recording module obtains the last call of the target seed and the edge triggering new coverage corresponding to the target seed; The last call of the target seed is used as row information, and the edge that triggers the new coverage corresponding to the target seed is used as column information; The initialization key component inference table is updated according to the row information and the column information.

4. The operating system kernel fuzz testing method according to claim 1, characterized in that: The step of generating a seed selection strategy in the seed library in combination with the key component inference table to guide seed variation selection includes: Sending the key component inference table to a key component processing module in the seed library so that the key component processing module generates queue information according to the row information and column information in the key component inference table; A strategy set is generated according to the queue information and implemented to guide seed mutation selection.

5. An operating system kernel fuzz testing device, characterized in that: Executing the method according to claim 1, the operating system kernel fuzz testing device comprises: An input set module, configured to obtain an initial input and perform splitting processing on the initial input to generate an input set; A fuzzy test result module, configured to perform a fuzzy test on the input set and obtain a fuzzy test result; A key component inference table module, configured to store the fuzzy test results into a key component inference file to generate a key component inference table; A selection strategy module is used to generate a seed selection strategy in the seed library in combination with the key component inference table to guide seed variation selection.

6. An operating system kernel fuzz testing device, characterized in that: The device includes: a memory and a processor, and the processor executes the method according to any one of claims 1 to 4 when running the operating system kernel fuzz testing program stored in the memory.

7. A computer-readable storage medium, characterized in that The method comprises instructions which, when executed on a computer, cause the computer to execute the method according to any one of claims 1 to 4.

Images