Fuzzy testing method for operating system kernel

Abstract

The invention relates to the technical field of software testing, discloses a fuzzy testing method for an operating system kernel, and solves the problem that effective isolation of a test and efficient recognition and verification of vulnerabilities are difficult to ensure when an existing fuzzy testing method for the operating system kernel is implemented in a virtualization environment. According to the method, improvement is carried out according to the problem that hypervisor and fuzzy testing are not combined at present, a Hypervisor technology and an N-prediction model are combined, the purpose of improving safety testing of a Guest OS kernel is achieved, parallel management is carried out on a plurality of Guest OS instances through a Hypervisor layer, the generation process of a test case is optimized through the N-prediction model, and therefore the safety testing efficiency of the Guest OS kernel is improved. The N-prediction model predicts the next system call by considering the historical system call sequence on the basis of Markov hypothesis, so that the test case with more trigger vulnerabilities is generated, the fuzzy test efficiency is improved, the unknown vulnerability can be found according to different fuzzy test results of guest os kernel, and the safety and reliability are improved.

Description

Technical Field

[0001] The present invention relates to the technical field of software testing, and in particular to a fuzzy testing method for an operating system kernel. Background Art

[0002] Fuzz testing technology can help discover vulnerabilities hidden in the operating system kernel. Virtualization provides a software way to create a simulated environment to support running various operating systems on a single physical hardware system. The virtualization hypervisor or virtual machine manager is the core of this technology. Hypervisor technology is the core of virtualization. The main security threats related to Hypervisor stem from design or implementation defects in virtual devices. Vulnerabilities hidden in virtual devices, such as stack buffer overflow, integer overflow, and use after free, undermine the isolation guarantee of Hypervisor, allowing hackers to break into the host and access all virtual machines running on it, thus posing a serious threat to the entire virtualization environment.

[0003] There is no existing research on combining Hypervisor with fuzz testing, which involves some challenges and difficulties. Running fuzz testing in a virtualized environment will increase the complexity of the system. Monitoring and analyzing the results of fuzz testing in a virtualized environment will be more complicated because it is necessary to take into account the status of the virtual machine and the host system and ensure that potential vulnerabilities are accurately identified and reported.

[0004] To address the above problems, an innovative design is carried out based on the original fuzz testing method for the operating system kernel. Summary of the invention

[0005] The purpose of the present invention is to provide a fuzz testing method for the operating system kernel, which adopts the present device to work, thereby solving the problem that the existing fuzz testing method for the operating system kernel is difficult to ensure effective isolation of the test and efficient identification and verification of vulnerabilities when implemented in a virtualized environment.

[0006] To achieve the above object, the present invention provides the following technical solution: a fuzzy testing method for an operating system kernel, comprising a VM operating system kernel testing framework based on Hypervisor and a test case generation method based on an N-prediction model, wherein the VM operating system kernel testing framework based on Hypervisor comprises the following components:

[0007] Manager: A host running on a microkernel operating system. The manager has two main functions. The first is to manage and schedule the reproduction of the crashes to be reproduced in the queue to ensure that the vulnerability is reproduced in a stable environment and verify the validity of the crash. The second is to manage and start the fuzz testing process when there is no crash to be reproduced. The manager is also responsible for persistent storage of the corpus, which is used as the input data set for fuzz testing. The crash information includes the storage of the details of the triggered crash.

[0008] Fuzzer: It runs in a virtual machine, and multiple fuzzers can be deployed in one virtual machine to achieve parallel testing. It first generates test inputs and manages the minimization of the corpus through fuzz testing to optimize test efficiency and coverage. It then communicates with the manager through remote calls. When new test coverage or crash is found, it notifies the manager to trigger the crash reproduction process, and then starts the executor to execute specific test cases and receive the execution results.

[0009] Reproducer: runs in the virtual machine and is mainly responsible for crash reproduction. In a stable and controlled environment, it re-executes the test case that caused the crash to verify the reproducibility and stability of the crash. Then, the executor schedules and calls the executor to execute the test case that reproduces the crash to ensure the consistency of the test environment.

[0010] Executor: Works closely with the fuzzer and reproducer, is responsible for receiving test cases from the fuzzer or reproducer, executes these test cases in an isolated environment, and then returns the execution results to the fuzzer or reproducer that initiated the call;

[0011] The method for generating test cases based on the N-prediction model includes the following steps:

[0012] S1: Collect test cases: In the initial stage, collect a batch of basic system call test cases as a starting point;

[0013] S2: Construct N-prediction model: Based on the Markov hypothesis, construct a suitable N-prediction model, which predicts the next system call based on the given previous N system calls;

[0014] S3: Experimentally determine the N value: Experimentally test the model prediction effect under different N values ​​and select the most appropriate N value, that is, determine that the model considers multiple system calls to make the best prediction;

[0015] S4: Generate a new system call sequence: start from an initial system call, use the N-prediction model to predict the next system call, and add it to the current sequence, use the newly predicted system call as a new input, use the model again to predict the next system call, and continue to add it to the sequence, repeat this process until the preset sequence length is reached or other stopping conditions are met;

[0016] S5: Evaluate new system call sequences: Analyze the newly generated system call sequences to identify the vulnerable sequential system call patterns that may be contained therein, execute these sequences on the target system, and observe and record the system response, especially abnormal behavior or crash information;

[0017] S6: Update the corpus: Add newly generated test cases, system call sequences, and any crash information data collection and analysis materials to the corpus. This new data will be used in future test iterations to improve the effectiveness and coverage of the test;

[0018] S7: Use fuzz testing loop: Use the updated corpus as input and re-execute the entire process, including generating new system call sequences, evaluation, and updating the corpus steps, to form a continuous fuzz testing loop.

[0019] Further, the steps of using the reproducer are as follows:

[0020] S1: The manager is located in T-Hyper and performs fuzz testing on the kernel in the Guest OS starting from the microkernel through Hypervisor;

[0021] S2: There is a crash waiting to be reproduced in the queue. Start the virtual machine and the reproducer. Re-execute and verify the test case that triggered the crash in a stable environment.

[0022] Further, the fuzzer is used in the following steps:

[0023] S1: The administrator starts and manages the environment for fuzz testing the kernel of the Guest OS through Hypervisor in the virtualized environment of T-Hyper;

[0024] S2: If there is no crash to be reproduced in the queue, the manager is started, and multiple VMs are started. Multiple fuzzers are placed in different VMs, and multiple fuzzers in the VMs are called through the configuration information received by the manager to start fuzz testing.

[0025] S3: After starting multiple fuzzers, generate or mutate test cases based on the initial seed corpus, call executors to execute test cases, collect execution information, and finally send feedback information back to the microkernel to minimize and update the corpus;

[0026] S4: Use the N-prediction model to improve the efficiency and quality of test case generation and discover more potential vulnerabilities. Combine the N-prediction model, determine the optimal N value through experiments to optimize the prediction accuracy, generate system call sequences containing potential vulnerability patterns as new test cases, continuously update the corpus and cyclically generate and execute tests, while monitoring the results to optimize the model.

[0027] Furthermore, in step S1, the manager starts from the microkernel in the hypervisor and initializes the manager's configuration according to the content in the config file. It starts multiple instances. In the model, multiple different VM instances are started, but in each VM instance, there are multiple fuzzer processes performing fuzz testing at the same time, thereby improving efficiency.

[0028] Furthermore, in step S2, the reproducer is mainly responsible for reproducing and verifying the test case that has triggered the crash in a stable environment.

[0029] Furthermore, in step S3, the fuzzifier leads the fuzzifying process, which includes input, generation and mutation, and sends the input that triggers new coverage back to the manager process through RPC. During the execution of the test case, the executor is started to execute the test case. Each executor executes an input, accepts the program executed by the fuzzifier and returns the result.

[0030] Furthermore, the N-prediction model is combined in step S4 to collect test cases that trigger different types of crashes and test cases that do not trigger crashes, so as to obtain system calls through test cases. Then, the N-prediction model is applied to the test input to collect vulnerable sequential system call patterns of system calls with a length of n, generate new test cases, and package them into a corpus to guide the test case generation phase. The newly generated test cases must contain continuous vulnerable patterns, and new system calls are still inserted after the sequence, so as to improve the efficiency of fuzz testing and discover new vulnerabilities.

[0031] Further, the method steps for calling test cases mentioned in the method for generating test cases based on the N-prediction model are as follows:

[0032] S1: Select the initial system call or test case from the corpus;

[0033] S2: Use the N-prediction model to predict the next system call and add it to the current sequence;

[0034] S3: Repeat S2 until a system call sequence that meets the length requirement is generated;

[0035] S4: Evaluate the newly generated system call sequence to check whether it contains known vulnerable patterns or potential vulnerability trigger points;

[0036] S5: Package the evaluated test cases into a corpus for subsequent use.

[0037] Furthermore, the method steps for collecting and analyzing crash information data mentioned in the method for generating test cases based on the N-prediction model are as follows:

[0038] S1: Execute the newly generated test cases and monitor the system’s response;

[0039] S2: Collect the test cases that trigger the crash and related crash information;

[0040] S3: Analyze the cause of the crash to determine whether it is caused by a new vulnerability.

[0041] Further, the method steps of using the fuzzy test loop mentioned in the method of generating test cases based on the N-prediction model are as follows:

[0042] S1: Repeat the process of test case generation, execution, crash collection and analysis;

[0043] S2: Update the corpus and N-prediction model based on newly discovered vulnerabilities and vulnerable patterns;

[0044] S3: Optimize the test case generation strategy to improve testing efficiency and vulnerability discovery rate.

[0045] Compared with the prior art, the present invention has the following beneficial effects:

[0046] The present invention proposes a fuzz testing method for operating system kernel. The existing fuzz testing method for operating system kernel is difficult to ensure effective isolation of testing and efficient identification and verification of vulnerabilities when implemented in a virtualized environment. The present invention improves the problem that hypervisor and fuzz testing are not currently combined. By combining Hypervisor technology and N-prediction model, the method aims to improve the security test of Guest OS kernel. The method manages multiple Guest OS instances in parallel through the Hypervisor layer, and optimizes the test case generation process by using the N-prediction model. The N-prediction model is based on the Markov hypothesis and predicts the next system call by considering the historical system call sequence, thereby generating a test case that is more likely to trigger vulnerabilities. This method not only improves the efficiency of fuzz testing, but also can discover unknown vulnerabilities according to the fuzz testing results of different guest OS kernels, especially those vulnerabilities that are difficult to discover with traditional testing tools. In this way, the method of the present invention significantly improves the security and reliability of the operating system. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Figure 1 It is a flow chart of the VM operating system kernel test framework based on Hypervisor of the present invention;

[0048] Figure 2 The flowchart of the method for generating test cases based on the N-prediction model of the present invention. DETAILED DESCRIPTION

[0049] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0050] In order to further understand the content of the present invention, the present invention is described in detail in conjunction with the accompanying drawings.

[0051] Combination Figure 1-2 A fuzz testing method for operating system kernel includes a VM operating system kernel testing framework based on Hypervisor and a test case generation method based on N-prediction model.

[0052] The present invention will be further described below in conjunction with the embodiments.

[0053] See also Figure 1,Manager: A host running on a microkernel operating system. The manager has two main functions. The first is to manage and schedule the reproduction of the crashes to be reproduced in the queue to ensure that the vulnerability is reproduced in a stable environment and verify the validity of the crash. The second is to manage and start the fuzz testing process when there is no crash to be reproduced. The manager is also responsible for persistent storage of the corpus, which is used for the input data set of the fuzz test. The crash information includes the storage of the details of the triggered crash;

[0054] Fuzzer: It runs in a virtual machine, and multiple fuzzers can be deployed in one virtual machine to achieve parallel testing. It first generates test inputs and manages the minimization of the corpus through fuzz testing to optimize test efficiency and coverage. It then communicates with the manager through remote calls. When new test coverage or crash is found, it notifies the manager to trigger the crash reproduction process, and then starts the executor to execute specific test cases and receive the execution results.

[0055] Reproducer: runs in the virtual machine and is mainly responsible for crash reproduction. In a stable and controlled environment, it re-executes the test case that caused the crash to verify the reproducibility and stability of the crash. Then, the executor schedules and calls the executor to execute the test case that reproduces the crash to ensure the consistency of the test environment.

[0056] Executor: Works closely with the fuzzer and reproducer, is responsible for receiving test cases from the fuzzer or reproducer, executes these test cases in an isolated environment, and then returns the execution results to the fuzzer or reproducer that initiated the call;

[0057] The steps for using the reproducer are as follows: Step 1: The manager is in T-Hyper, starting from the microkernel, passing through Hypervisor, and performing fuzz testing on the kernel in the Guest OS; Step 2: There is a crash to be reproduced in the queue, start the virtual machine, start the reproducer, and re-execute and verify the test case that triggered the crash in a stable environment.

[0058] The steps of using the fuzzer are as follows: Step 1: In the virtualized environment of T-Hyper, the manager starts and manages the environment for fuzz testing the kernel of the Guest OS through Hyperv isor; Step 2: If there is no crash to be reproduced in the queue, the manager is started, and multiple VM virtual machines are started, and multiple fuzzers are placed in different virtual machines respectively. The multiple fuzzers in the virtual machines are called through the configuration information received by the manager to start fuzz testing; Step 3: After starting multiple fuzzers, test cases are generated or mutated according to the initial seed corpus, and the executor is called to execute the test cases, collect execution information, and finally send feedback information back to the microkernel to minimize and update the corpus;

[0059] In the first step of using the fuzzer, the manager starts from the microkernel in Hypervisor and initializes the manager's configuration according to the content in the config file. It can start multiple instances. In our model, multiple different VM instances are started, but in each VM instance, multiple fuzzer processes can perform fuzz testing at the same time, thereby improving efficiency.

[0060] In the second step of using the fuzzer, the reproducer is mainly responsible for reproducing and verifying the test cases that have triggered the crash in a stable environment.

[0061] In the third step of using the fuzzifier, the fuzzer leads the fuzzing process to generate and mutate inputs, and sends the inputs that trigger new coverage back to the manager process through RPC. During the execution of the test case, the executors are started to execute the test case. Each executor executes an input, accepts the program executed by the fuzzer and returns the result.

[0062] Specifically, by deploying the manager, fuzzer, reproducer and executor components in the virtual machine to work together to complete the test task, the manager, as the control center of the framework, runs on the microkernel operating system and is responsible for scheduling the crash reproduction and fuzz testing process. When there is a crash to be reproduced in the queue, the manager starts the reproducer in the virtual machine and re-executes the test case that caused the crash in a stable and controlled environment to verify its reproducibility and stability. If there is no crash to be reproduced in the queue, the manager starts the fuzz testing process and executes it through Hypervi SOR deploys multiple fuzzers in multiple virtual machines to achieve parallel testing. The fuzzer is responsible for generating or mutating test inputs, calling the executor to execute test cases in an isolated environment, and collecting execution results to optimize test efficiency and coverage. At the same time, the manager is also responsible for persistent storage of the corpus, which contains initial test cases, system call sequences, crash information, and crash information for subsequent analysis and improvement. During the test, the fuzzer communicates with the manager through remote procedure calls (RPCs). When new test coverage or crashes are found, the manager is notified to start the crash reproduction process. The reproducer re-executes the test cases that caused the crash in the virtual machine according to the manager's instructions, and ensures the consistency of the test environment through the executor. The executor works closely with the fuzzer and reproducer to receive and execute test cases, and then returns the execution results to the component that initiated the call. In addition, the framework also introduces the N-prediction model, the specific details of which will be described later. The model is based on historical system call data and generates test cases containing potential vulnerable patterns by predicting system call sequences, which further improves the effectiveness and coverage of the test. In summary, based on Hypervi Sor's VM operating system kernel testing framework provides strong support for the security testing of the operating system kernel through an integrated and automated testing process, combined with virtualization technology and intelligent test case generation methods, effectively improving the testing efficiency and reliability. Using Hypervis Sor for fuzz testing can isolate the testing process in a virtual environment to ensure that the test will not affect the real system. Hypervis Sor can quickly deploy new virtual machine instances, thereby accelerating the preparation process for fuzz testing. Hypervis Sor combined with fuzz testing can provide a safer, more flexible and more efficient testing environment, which helps to discover and fix potential security vulnerabilities in the operating system kernel.

[0063] See also Figure 2, the method steps for calling test cases mentioned in the test case generation method based on the N-prediction model are as follows: Step 1: Collect test cases: In the initial stage, collect a batch of basic system call test cases as a starting point; Step 2: Build an N-prediction model: Based on the Markov hypothesis, build a suitable N-prediction model, which predicts the next system call based on the given first N system calls; Step 3: Experimentally determine the N value: Experimentally test the model prediction effect under different N values, and select the most appropriate N value, that is, determine that the model considers multiple system calls for optimal prediction; Step 4: Generate a new system call sequence: Starting from an initial system call, use the N-prediction model to predict the next system call, and add it to the current sequence, use the newly predicted system call as a new input, and use the model again to predict the next system Call, and continue to add to the sequence, repeating this process until the preset sequence length is reached or other stopping conditions are met; Step 5: Evaluate new system call sequences: Analyze the newly generated system call sequences, identify the vulnerable sequential system call patterns that may be contained therein, execute these sequences on the target system, observe and record the system response, especially abnormal behavior or crash information; Step 6: Update the corpus: Add the newly generated test cases, system call sequences, and any crash information data collection and analysis materials to the corpus. These new data will be used for future test iterations to improve the effectiveness and coverage of the test; Step 7: Use the fuzzy test loop: Use the updated corpus as input to re-execute the entire process, including generating new system call sequences, evaluation, and updating the corpus steps to form a continuous fuzzy test loop;

[0064] The N-prediction model is combined in the S4 step of the fuzzer to collect test cases that trigger different types of crashes and test cases that do not trigger crashes, so as to obtain system calls through test cases. Then, the N-prediction model is applied to the test input to collect the vulnerable sequential system call patterns of system calls with a length of n, generate new test cases, and package them into the corpus to guide the test case generation stage. The newly generated test cases must contain continuous vulnerable patterns, and new system calls can still be inserted after the sequence, which improves the efficiency of fuzz testing and discovers new vulnerabilities.

[0065] The test case generation method based on the N-prediction model includes the following steps: Step 1: Select an initial system call or test case from a corpus; Step 2: Use the N-prediction model to predict the next system call and add it to the current sequence; Step 3: Repeat Step 2 until a system call sequence that meets the length requirement is generated; Step 4: Evaluate the newly generated system call sequence to check whether it contains known vulnerable patterns or potential vulnerability trigger points;

[0066] Step 5: Package the evaluated test cases into a corpus for subsequent use.

[0067] The method steps for collecting and analyzing crash information data mentioned in the test case generation method based on the N-prediction model are as follows: Step 1: Execute the newly generated test case and monitor the system's response; Step 2: Collect the test cases that trigger the crash and related crash information; Step 3: Analyze the cause of the crash to determine whether it is caused by a new vulnerability.

[0068] The method steps of using the fuzz testing cycle mentioned in the test case generation method based on the N-prediction model are as follows: Step 1: Continuously repeat the process of test case generation, execution, crash collection and analysis; Step 2: Update the corpus and N-prediction model according to newly discovered vulnerabilities and vulnerable patterns; Step 3: Optimize the test case generation strategy to improve testing efficiency and vulnerability discovery rate.

[0069] Specifically, the initial system call or test case is selected from the initial test cases, system call sequences and crash information contained in the corpus, and then the new system call is continuously predicted and added to the current sequence through the N-prediction model until a system call sequence that meets a specific length is generated. Then, the newly generated sequence is evaluated to check whether it contains known vulnerable patterns or points that may trigger new vulnerabilities. After the evaluation passes, the test case will be added to the corpus for subsequent testing. During the test process, the newly generated test case is executed and the system's response is monitored. The test cases that trigger the crash and their crash information are collected. Then, in-depth analysis is performed. Analyze the cause of the crash and confirm whether it is caused by a new vulnerability. This process is achieved through a continuous fuzz testing cycle, that is, in the iteration of continuous test case generation, execution, crash collection and analysis, new vulnerabilities and vulnerable patterns are continuously discovered. After each cycle, the corpus and N-prediction model are updated according to the newly discovered information, and the test case generation strategy is optimized to improve the test efficiency and vulnerability discovery rate. In short, the test case generation method based on the N-prediction model effectively improves the pertinence and vulnerability discovery capabilities of test cases by combining intelligent prediction with continuous fuzz testing, providing strong support for the security assurance of software systems.

[0070] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device.

[0071] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A fuzz testing method for operating system kernel, including a VM operating system kernel testing framework based on Hypervisor and a test case generation method based on N-prediction model, Features: The Hypervisor-based VM operating system kernel testing framework includes the following components: Manager: A host running on a microkernel operating system. The manager has two main functions. The first is to manage and schedule the reproduction of the crashes to be reproduced in the queue to ensure that the vulnerability is reproduced in a stable environment and verify the validity of the crash. The second is to manage and start the fuzz testing process when there is no crash to be reproduced. The manager is also responsible for persistent storage of the corpus, which is used as the input data set for fuzz testing. The crash information includes the storage of the details of the triggered crash. Fuzzer: It runs in a virtual machine, and multiple fuzzers can be deployed in one virtual machine to achieve parallel testing. It first generates test inputs and manages the minimization of the corpus through fuzz testing to optimize test efficiency and coverage. It then communicates with the manager through remote calls. When new test coverage or crash is found, it notifies the manager to trigger the crash reproduction process, and then starts the executor to execute specific test cases and receive the execution results. Reproducer: runs in the virtual machine and is mainly responsible for crash reproduction. In a stable and controlled environment, it re-executes the test case that caused the crash to verify the reproducibility and stability of the crash. Then, the executor schedules and calls the executor to execute the test case that reproduces the crash to ensure the consistency of the test environment. Executor: Works closely with the fuzzer and reproducer, is responsible for receiving test cases from the fuzzer or reproducer, executes these test cases in an isolated environment, and then returns the execution results to the fuzzer or reproducer that initiated the call; The method for generating test cases based on the N-prediction model includes the following steps: S1: Collect test cases: In the initial stage, collect a batch of basic system call test cases as a starting point; S2: Construct N-prediction model: Based on the Markov hypothesis, construct a suitable N-prediction model, which predicts the next system call based on the given previous N system calls; S3: Experimentally determine the N value: Experimentally test the model prediction effect under different N values ​​and select the most appropriate N value, that is, determine that the model considers multiple system calls to make the best prediction; S4: Generate a new system call sequence: start from an initial system call, use the N-prediction model to predict the next system call, and add it to the current sequence, use the newly predicted system call as a new input, use the model again to predict the next system call, and continue to add it to the sequence, repeat this process until the preset sequence length is reached or other stopping conditions are met; S5: Evaluate new system call sequences: Analyze the newly generated system call sequences to identify the vulnerable sequential system call patterns that may be contained therein, execute these sequences on the target system, and observe and record the system response, especially abnormal behavior or crash information; S6: Update the corpus: Add newly generated test cases, system call sequences, and any crash information data collection and analysis materials to the corpus. This new data will be used in future test iterations to improve the effectiveness and coverage of the test; S7: Use fuzz testing loop: Use the updated corpus as input and re-execute the entire process, including generating new system call sequences, evaluation, and updating the corpus steps, to form a continuous fuzz testing loop.

2. A fuzz testing method for an operating system kernel according to claim 1, Features: The steps to use the reproducer are as follows: S1: The manager is located in T-Hyper and performs fuzz testing on the kernel in the Guest OS from the microkernel through the Hypervisor. S2: There is a crash waiting to be reproduced in the queue. Start the virtual machine and the reproducer. Re-execute and verify the test case that triggered the crash in a stable environment.

3. A fuzz testing method for an operating system kernel according to claim 2, Features: The steps to use the fuzzer are as follows: S1: The administrator starts and manages the environment for fuzz testing the kernel of the Guest OS through Hypervisor in the virtualized environment of T-Hyper; S2: If there is no crash to be reproduced in the queue, the manager is started, and multiple VMs are started. Multiple fuzzers are placed in different VMs, and multiple fuzzers in the VMs are called through the configuration information received by the manager to start fuzz testing. S3: After starting multiple fuzzers, generate or mutate test cases based on the initial seed corpus, call executors to execute test cases, collect execution information, and finally send feedback information back to the microkernel to minimize and update the corpus; S4: Use the N-prediction model to improve the efficiency and quality of test case generation and discover more potential vulnerabilities. Combine the N-prediction model, determine the optimal N value through experiments to optimize the prediction accuracy, generate system call sequences containing potential vulnerability patterns as new test cases, continuously update the corpus and cyclically generate and execute tests, while monitoring the results to optimize the model.

4. A fuzz testing method for operating system kernel according to claim 3, Features: In step S1, the manager starts from the microkernel in the hypervisor and initializes the manager's configuration according to the content in the configuration file. It starts multiple instances. In the model, multiple different VM instances are started, but in each VM instance, there are multiple fuzzer processes performing fuzz testing at the same time, thereby improving efficiency.

5. The fuzz testing method for operating system kernel according to claim 3, Features: In step S2, the reproducer is mainly responsible for reproducing and verifying the test case that has triggered the crash in a stable environment.

6. A fuzz testing method for operating system kernel according to claim 3, Features: In step S3, the fuzzer leads the fuzzing process, which includes input, generation and mutation, and sends the input that triggers new coverage back to the manager process through RPC. During the execution of the test case, the executor is started to execute the test case. Each executor executes an input, accepts the program executed by the fuzzer and returns the result.

7. A fuzz testing method for operating system kernel according to claim 3, Features: In step S4, the N-prediction model is combined to collect test cases that trigger different types of crashes and test cases that do not trigger crashes, so as to obtain system calls through test cases. Then, the N-prediction model is applied to the test input to collect vulnerable sequential system call patterns of system calls with a length of n, generate new test cases, and package them into the corpus to guide the test case generation phase. The newly generated test cases must contain continuous vulnerable patterns, and new system calls are still inserted after the sequence to improve the efficiency of fuzz testing and discover new vulnerabilities.

8. A fuzz testing method for an operating system kernel according to claim 1, Features: The steps for calling test cases mentioned in the method for generating test cases based on the N-prediction model are as follows: S1: Select the initial system call or test case from the corpus; S2: Use the N-prediction model to predict the next system call and add it to the current sequence; S3: Repeat S2 until a system call sequence that meets the length requirement is generated; S4: Evaluate the newly generated system call sequence to check whether it contains known vulnerable patterns or potential vulnerability trigger points; S5: Package the evaluated test cases into a corpus for subsequent use.

9. A fuzz testing method for an operating system kernel according to claim 1, Features: The steps of the method for collecting and analyzing crash information data mentioned in the method for generating test cases based on the N-prediction model are as follows: S1: Execute the newly generated test cases and monitor the system’s response; S2: Collect the test cases that trigger the crash and related crash information; S3: Analyze the cause of the crash to determine whether it is caused by a new vulnerability.

10. A fuzz testing method for operating system kernel according to claim 1, Features: The steps of the method for using the fuzzy test loop mentioned in the test case generation method based on the N-prediction model are as follows: S1: Repeat the process of test case generation, execution, crash collection and analysis; S2: Update the corpus and N-prediction model based on newly discovered vulnerabilities and vulnerable patterns; S3: Optimize the test case generation strategy to improve testing efficiency and vulnerability discovery rate.

Images