Fuzzy testing method, device and equipment for kernel of operating system

Abstract

The invention provides an operating system kernel fuzz testing method, device and equipment, and relates to the technical field of kernel fuzz testing. The method comprises the following steps: acquiring initial input, and splitting 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 result into a key component inference file to generate a key component inference table; and generating a seed selection strategy in the seed bank in combination with the key component inference table so as to guide seed variation selection. By identifying and utilizing key components in a system calling sequence, the coverage rate of the fuzzy test is improved. And establishing a corresponding relationship between the key component in the system call sequence and the basic block of the corresponding path, so as to better mine potential security vulnerabilities. Different variation strategies are executed according to selection of variation points, so that an existing fuzzy testing method is effectively improved, and the vulnerability mining efficiency and quality are improved.

Description

Technical Field

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

[0002] With the continuous update of kernel operating system versions, the kernel code continues to grow, and the number of vulnerabilities involving the kernel in CVE (Common Vulnerabilities & Exposures) continues to rise. The kernel is becoming more and more complex, and it contains a large number of functions, subsystems, and drivers, which increases the concealment and difficulty of vulnerability discovery. In order to speed up the vulnerability detection process, more and more automated tools are developed and used to mine kernel vulnerabilities. Fuzz testing, as a vulnerability mining method with good practical effects, has been widely used in the field of kernel vulnerability mining.

[0003] Syzkaller is a kernel vulnerability fuzz testing platform developed by Google, which can be tested on multiple operating system platforms. It uses system call templates to generate system call sequences that meet the specifications, and puts both the test generation and execution parts into a virtual machine. Syzkaller generates test cases by generating memory object parameters such as buffers that are legally accessed. Using the kernel code compilation and instrumentation testing method, it uses the KCOV feature of the Linux kernel to instrument the kernel code and recompile to generate system target code. Then, the kernel fuzz testing process is guided by obtaining path information during kernel execution and calculating coverage. The selection table is an important part of Syzkaller, which records the probability values ​​that a system call should be called before another system call. These probability values ​​are adjusted according to the test requirements and coverage targets to ensure that the generated test cases can cover different paths of the kernel code as much as possible. The selection table also guides the mutation strategy of the test cases, that is, how to mutate existing test cases to generate new test cases. These mutation strategies are based on the probabilistic relationship between system calls and system call templates to ensure that the generated new test cases have a certain coverage and can discover 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, the key component inference table is combined to generate a seed selection strategy 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 in the initial seed set according to source characteristics;

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

[0021] Optionally, before the step of recording the coverage rate in the seed file set using the KCOV mechanism of Syzkaller 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 the KCOV mechanism of Syzkaller 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 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 initialization 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 that triggers new coverage corresponding to the target seed;

[0030] The last call of the target seed is used as row information, and the edge corresponding to the target seed that triggers the new coverage 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 guides seed mutation selection.

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

[0036] An input set module, used for obtaining an initial input and performing splitting processing on the initial input to generate an input set;

[0037] A fuzzy test result module, used for performing a fuzzy test on the input set and obtaining a fuzzy test result;

[0038] A key component inference table module, used for storing 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, the device comprising: a memory, a processor, and the processor executes the method described above when running the operating system kernel fuzz testing program stored in the memory.

[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, the present application includes the following beneficial technical effects:

[0043] This application obtains the initial input and splits the initial input 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; 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. The correspondence between the key components in the system call sequence and the corresponding path basic blocks is established to better mine potential security vulnerabilities. According to the selection of mutation points, different mutation strategies are executed to effectively improve the existing fuzz testing methods and improve the efficiency and quality of vulnerability mining. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1 It is a schematic diagram of the structure of an operating system kernel fuzzy test device in a hardware operating environment involved in an 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 schematic diagram of the software design process 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 a key component processing module of the first embodiment of the operating system kernel fuzz testing method of the present application;

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

[0051] In order to make the purpose, technical solution and advantages of the present 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 the present application and are not used to limit the present application.

[0052] Reference Figure 1 , Figure 1 This is a schematic diagram of the structure of an operating system kernel fuzzy testing device for 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 optional user interface 1003 may also 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 also 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 less 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 the present 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 in the embodiment of the present application.

[0057] The present application embodiment provides an operating system kernel fuzz testing method, referring to Figure 2 , Figure 2 This is a flowchart of the first embodiment of the operating system kernel fuzz testing method of the present 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 relationship obtained by simple empirical analysis in Syzkaller's selection table is of low quality and is not sufficient to maintain the generation of high-quality test cases. In addition, the parameter-level selection guidance strategy is not considered. MoonShine captures the explicit and implicit dependencies between system calls. It uses a seed distillation algorithm to prepare high-quality seeds for Syzkaller. SyzVegas uses the EXP3 algorithm to dynamically and automatically adjust the task selection and seed selection in Syzkaller to improve coverage performance. HEALER defines a binary influence relationship to describe the dependency of system calls, where the execution of one system call affects the execution path of another system call. And it is recorded in a two-dimensional relationship table.

[0061] However, these fuzz testing methods usually generate input randomly and lack the recognition and utilization of key components in the system call sequence, resulting in low coverage of test cases. The existing technology often cannot effectively record the correspondence between the key parts of the input system call sequence that contribute to the coverage and the corresponding path basic blocks during the fuzz testing phase, making it difficult to deeply explore potential security vulnerabilities. Traditional fuzz testing methods lack intelligence in the selection of mutation points, making it difficult to explore the state space of the system in a targeted manner, and unable to effectively improve the efficiency and quality of vulnerability mining.

[0062] It can be understood 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 that may be triggered by a combination of multiple system calls. When processing the feedback information, system calls with different parameters are regarded as one for statistics. In the later fuzz testing process, the information in the table is used to perform auxiliary fuzz testing with a certain probability, and the selection of system calls in the mutation stage is assisted according to the information in the table and the three different categories of key components, including selecting a new system call to insert and selecting a system call 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 an 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 split processing to form multiple groups of inputs. Each group undergoes the fuzzy testing process separately, and records the key component information that triggers the new coverage, saves it to the key component inference file of the host, and modifies the key component inference table after the key component is processed. Seed selection is performed based on the seed library, and seed mutation is guided based on the information in the key component inference table.

[0065] Step S20: Perform a fuzzy test on the input set and obtain the fuzzy test result.

[0066] In the 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 according to the number of system calls it contains. Each time, delete a system call from the end and store it as a seed and also as the object for the next deletion.

[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 to trigger a new coverage and enter the key component recording module instead of jumping to judgment 2.

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

[0074] Judgment 2: Judgment whether the seed catalog is fully executed is to 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 according to source characteristics; and using Syzkaller's KCOV mechanism in the seed file set to record coverage as a 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 recording coverage in a seed file set using Syzkaller's KCOV mechanism 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 determining 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 initialization 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 initialization 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 in the figure, when the seed triggers a new coverage, enters the key component recording module. The last call X of the seed is taken as a row, and the start and end basic block addresses corresponding to the triggered path are concatenated into edge Y as a column and 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 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; generating a strategy set according to 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, the system calls with different parameters are regarded 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, record the path {Yi, Yj, Yk, ...}, and add the key components of the corresponding order {Xi, Xj, Xk, ...} to queue 3. It is recommended to select it when no new coverage is generated for a long time.

[0090] 2) A single edge Y that cannot be combined into a path, and only one key component X is needed to reach and trigger this edge. Intersect with the X,Y pairs with a weight of 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, in the subsequent fuzz test, the key component information obtained is selected with a certain probability to guide the fuzz test. The probability changes dynamically according to the effects of the two strategies. The case of using key information to guide the fuzz test: customize the probability of selecting components from the three queues.

[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 attribute of queue 1 as the test case with high probability for testing and mutation.

[0093] 2) In the early mutation stage, it is recommended to select the system call with one-to-one attribute of 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 stage, the coverage rate grows slowly. Record the last basic block currently triggered, and search for the edge with the basic block as the starting part and its corresponding key component in the trigger edge of the key component inference table. If multiple key components are found, select the many-to-one system call sequence of queue 3 with high probability for splicing.

[0095] It can be understood that this embodiment infers the key components in the input based on the corpus information obtained from the feedback during the kernel fuzz testing process. The key components are learned from the 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 the key parts of the system call sequence that contribute to the coverage and the corresponding path basic blocks to guide the seed mutation selection of the fuzz test.

[0096] Compared with the existing technology, the differences of this technology mainly include the following aspects:

[0097] 1) Establishment of key component inference table: This technology establishes a key component inference table to associate the key components in the system call sequence with the corresponding basic blocks to form 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 processing of correspondence: Different from the traditional one-to-one correspondence, this technology divides the correspondence into three cases and proposes corresponding processing strategies. This flexible processing can better adapt to different test scenarios and requirements, and improve the flexibility and applicability of the test.

[0099] 3) Application of UCB algorithm: In the system call selection phase, the technology uses the upper confidence limit algorithm (UCB) to select the system call based on the key component inference table and mutate with a certain probability. The application of this algorithm can enable the system to more intelligently select the mutation direction in different test phases, thereby improving the efficiency and coverage of the test.

[0100] 4) Real-time recording and updating of the test process: This technology records the correspondence between the newly triggered basic blocks and the newly added system calls in real time during the fuzz testing process, and updates the weights of key components according to the specific situation. This real-time recording and updating enables the system to continuously optimize the test strategy during the test process, improving the test effect and the speed of vulnerability discovery.

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

[0102] This embodiment obtains the initial input and splits the initial input 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; 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 mine 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.

[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 method for operating system kernel fuzz testing 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 fuzzy testing device of the present application.

[0105] like Figure 7 As shown, the operating system kernel fuzzy 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, used to perform a fuzzy test on an input set and obtain a fuzzy test result;

[0108] A key component inference table module 30, for storing 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 the seed library in combination with the key component inference table to guide seed variation selection.

[0110] It should be understood that the above is only an example and does not constitute any limitation on 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 limitation on this.

[0111] This embodiment obtains the initial input and splits the initial input 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; 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 mine 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.

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

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

[0114] In addition, it should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or system including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method, article or system. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or system including 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 a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an 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 a read-only memory (ROM) / RAM, a magnetic disk, or an optical disk), and includes a number of instructions for a terminal device (which can be a mobile phone, a computer, a server, or a 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 are not intended to 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; In the seed library, the key component inference table is combined to generate a seed selection strategy to guide seed variation selection.

2. The operating system kernel fuzz testing method according to claim 1, characterized in that: The step of obtaining an initial input and performing splitting processing on the initial input to generate an input set includes: 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 performing a fuzzy test on the input set and obtaining a fuzzy test result comprises: Using the input set as an initial seed directory for fuzz testing; Generating a seed file set in the initial seed set according to source characteristics; The coverage is recorded in the seed file set using the KCOV mechanism of Syzkaller as the fuzz testing result.

4. The operating system kernel fuzz testing method according to claim 3, characterized in that: Before the step of recording the coverage rate in the seed file set using the KCOV mechanism of Syzkaller as the fuzz testing result, the method further includes: 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.

5. The operating system kernel fuzz testing method according to claim 4, characterized in that: The step of recording coverage using the KCOV mechanism of Syzkaller in the seed file set as the fuzz testing result includes: Select a target seed from the seed file and execute the target seed; Determine whether the target seed triggers 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 initialization 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.

6. The operating system kernel fuzz testing method according to claim 5, 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 comprises: 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 that triggers new coverage corresponding to the target seed; The last call of the target seed is used as row information, and the edge corresponding to the target seed that triggers the new coverage is used as column information; The initialization key component inference table is updated according to the row information and the column information.

7. 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 guides seed mutation selection.

8. An operating system kernel fuzzy testing device, characterized in that: The operating system kernel fuzz testing includes: An input set module, used for obtaining an initial input and performing splitting processing on the initial input to generate an input set; A fuzzy test result module, used for performing a fuzzy test on the input set and obtaining a fuzzy test result; A key component inference table module, used for storing 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.

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

10. 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 7.

Images