An operating system kernel-oriented fuzz testing method

Abstract

The present application relates to the technical field of software testing, and discloses a kind of fuzzy testing method for operating system kernel, the present application solves the problem that the existing fuzzy testing method for operating system kernel is difficult to ensure the effective isolation of test and the efficient identification and verification of vulnerability when being implemented in virtualization environment.The present application is improved according to the problem that hypervisor is not combined with fuzzy testing at present, by combining Hypervisor technology and N-predictive model, aiming at improving the security test of Guest OS kernel, the method manages multiple Guest OS instances in parallel through Hypervisor layer, and uses N-predictive model to optimize the generation process of test cases, N-predictive model is based on Markov hypothesis, by considering historical system call sequence to predict the next system call, so as to generate test cases that can trigger vulnerabilities, not only improve the efficiency of fuzzy testing, but also can find unknown vulnerabilities according to the fuzzy test results of different guest os kernel, improve security and reliability.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, specifically to a fuzzing method for operating system kernels. Background Technology

[0002] Fuzzing techniques can help uncover vulnerabilities hidden in the operating system kernel. Virtualization provides a software approach to create simulated environments that support the running of 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 associated with Hypervisor stem from design or implementation flaws in virtual devices. Vulnerabilities hidden in virtual devices, such as stack buffer overflows, integer overflows, and use after free, undermine Hypervisor's isolation guarantees, allowing hackers to compromise the host and access all virtual machines running on it, thus posing a serious threat to the entire virtualization environment.

[0003] Existing research does not combine Hypervisor with fuzzing, which presents some challenges and difficulties. Running fuzzing in a virtualized environment increases system complexity, and monitoring and analyzing fuzzing results in a virtualized environment is even more complex because it is necessary to take into account the state of the virtual machine and the host system and ensure accurate identification and reporting of potential vulnerabilities.

[0004] To address the aforementioned issues, an innovative design was developed based on the existing fuzzing methods for operating system kernels. Summary of the Invention

[0005] The purpose of this invention is to provide a fuzzing method for operating system kernels. This method, which uses this device, solves the problem that existing fuzzing methods for operating system kernels are difficult to implement in virtualized environments, making it difficult to ensure effective isolation of tests and efficient identification and verification of vulnerabilities.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a fuzz testing method for operating system kernels, comprising a Hypervisor-based VM operating system kernel testing framework and a test case generation method based on an N-prediction model. The Hypervisor-based VM operating system kernel testing framework includes the following components:

[0007] Manager: The host running on a microkernel operating system has two main functions. First, it is responsible for managing and scheduling the reproduction of crashes in the queue to ensure that vulnerabilities are reproduced in a stable environment and to verify the validity of the crashes. Second, when there are no crashes to be reproduced, it manages and starts the fuzzing process. The manager is also responsible for persistently storing the corpus, which is used as the input dataset for fuzzing. The crash information includes the storage of details of the triggered crashes.

[0008] Fuzzer: Runs in a virtual machine, and multiple fuzzers can be deployed within a single virtual machine to achieve parallel testing. First, it guides the generation of test inputs and the minimization of the corpus through fuzz testing to optimize test efficiency and coverage. Then, it communicates with the administrator via remote calls. When new test coverage or crashes are found, it notifies the administrator to trigger the crash reproduction process. Finally, it starts the executor to execute specific test cases and receives the execution results.

[0009] Reproducer: Runs in a virtual machine and is mainly responsible for crash reproduction. In a stable and controlled environment, it re-executes the test cases that caused the crash to verify the reproducibility and stability of the crash. Then, it uses the executor to schedule and call the executor to execute the test cases that reproduce the crash, ensuring the consistency of the test environment.

[0010] Executor: Works closely with the fuzzer and reproducer, responsible for receiving test cases from the fuzzer or reproducer, executing these test cases in an isolated environment, and then returning 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 an N-prediction model: Based on the Markov assumption, construct a suitable N-prediction model that predicts the next system call based on the previous N system calls.

[0014] S3: Experiment to determine the N value: Test the model prediction effect under different N values ​​through experiments, select the most suitable N value, that is, determine the model to consider multiple system calls to make the optimal prediction;

[0015] S4: 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 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 vulnerable sequential system call patterns that may be contained within them, execute these sequences on the target system, and observe and record the system response, especially abnormal behavior or crash information;

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

[0018] S7: Use a fuzzing loop: Using the updated corpus as input, re-execute the entire process, including generating a new system call sequence, evaluation, and corpus updates, forming a continuous fuzzing loop.

[0019] Furthermore, the steps for using the reproducer are as follows:

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

[0021] S2: There are crashes to be reproduced in the queue. Start the virtual machine and start the reproducer. In a stable environment, re-execute and verify the test cases that triggered the crash.

[0022] Furthermore, the steps for using the fuzzer are as follows:

[0023] S1: In the T-Hyper virtualization environment, the administrator starts and manages the environment for fuzzing the kernel of the Guest OS through Hypervisor;

[0024] S2: If there are no crashes to be reproduced in the queue, after starting the manager, start multiple virtual machines, put multiple fuzzers into different virtual machines, and call multiple fuzzers in the virtual machines according to the configuration information received by the manager to start fuzz testing.

[0025] S3: After starting multiple fuzzers, test cases are generated or mutated based on the initial seed corpus. The executor is called to execute the test cases, execution information is collected, and finally the feedback information is sent back to the microkernel to minimize and update the corpus.

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

[0027] Furthermore, in step S1, the administrator starts from the microkernel in hypervisor and initializes the administrator's configuration according to the contents of the configuration file. It starts multiple instances, which in the model are multiple different VM instances. However, in each VM instance, multiple fuzzer processes perform fuzz testing simultaneously, thereby improving efficiency.

[0028] Furthermore, in step S2, the reproducer is primarily responsible for reproducing and verifying the test cases that have already triggered a crash in a stable environment.

[0029] Furthermore, in step S3, the fuzzer leads the fuzzing process, which includes input, generation, and mutation. The input that triggers the new coverage is sent back to the manager process via RPC. During the execution of test cases, the executor is started to execute the test cases. Each executor executes one input, accepts the program executed by the fuzzer, and returns the result.

[0030] Furthermore, in step S4, an N-prediction model is incorporated to collect test cases that trigger different types of crashes and test cases that do not trigger crashes, thereby obtaining system calls through test cases. Then, the N-prediction model is applied to the test input to collect vulnerable sequence system call patterns of system calls of length 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 are still inserted after the sequence, improving the efficiency of fuzz testing and discovering new vulnerabilities.

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

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

[0033] S2: Predict the next system call using the N-prediction model 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 for known vulnerability patterns or potential vulnerability trigger points;

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

[0037] Furthermore, the 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 test cases that trigger crashes and related crash information;

[0040] S3: Analyze the cause of the crash and determine if it was caused by a new vulnerability.

[0041] Furthermore, the steps of the method for generating test cases based on the N-prediction model using a fuzzy testing loop are as follows:

[0042] S1: The process of continuously generating, executing, collecting, and analyzing test cases;

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

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

[0045] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0046] This invention proposes a fuzzing method for operating system kernels. Existing fuzzing methods for operating system kernels struggle to ensure effective test isolation and efficient vulnerability identification and verification in virtualized environments. This invention addresses the current lack of integration between Hypervisor and fuzzing by combining Hypervisor technology with an N-prediction model to enhance security testing of Guest OS kernels. The method manages multiple Guest OS instances in parallel through a Hypervisor layer and utilizes an N-prediction model to optimize test case generation. Based on the Markov assumption, the N-prediction model predicts the next system call by considering historical system call sequences, thus generating test cases more likely to trigger vulnerabilities. This approach not only improves the efficiency of fuzzing but also enhances the ability to discover unknown vulnerabilities based on fuzzing results from different Guest OS kernels, particularly those difficult to detect with traditional testing tools. In this way, the proposed method significantly improves the security and reliability of the operating system. Attached Figure Description

[0047] Figure 1 This is a flowchart of the VM operating system kernel testing framework based on Hypervisor of the present invention;

[0048] Figure 2 This is a flowchart of the test case generation method based on the N-prediction model of the present invention. Detailed Implementation

[0049] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0050] To further understand the content of this invention, a detailed description of the invention will be provided in conjunction with the accompanying drawings.

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

[0052] The present invention will be further described below with reference to embodiments.

[0053] Please see Figure 1The manager is a host running a microkernel operating system. The manager has two main functions: first, it is responsible for managing and scheduling the reproduction of crashes in the queue to ensure that the vulnerability is reproduced in a stable environment and to verify the validity of the crash; second, when there are no crashes to be reproduced, it manages and starts the fuzzing process. The manager is also responsible for persistently storing the corpus, which is used as the input dataset for fuzzing. The crash information includes the storage of details of the triggered crash.

[0054] Fuzzer: Runs in a virtual machine, and multiple fuzzers can be deployed within a single virtual machine to achieve parallel testing. First, it guides the generation of test inputs and the minimization of the corpus through fuzz testing to optimize test efficiency and coverage. Then, it communicates with the administrator via remote calls. When new test coverage or crashes are found, it notifies the administrator to trigger the crash reproduction process. Finally, it starts the executor to execute specific test cases and receives the execution results.

[0055] Reproducer: Runs in a virtual machine and is mainly responsible for crash reproduction. In a stable and controlled environment, it re-executes the test cases that caused the crash to verify the reproducibility and stability of the crash. Then, it uses the executor to schedule and call the executor to execute the test cases that reproduce the crash, ensuring the consistency of the test environment.

[0056] Executor: Works closely with the fuzzer and reproducer, responsible for receiving test cases from the fuzzer or reproducer, executing these test cases in an isolated environment, and then returning 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 administrator is located in T-Hyper, starting from the microkernel, passing through Hypervisor, and performing fuzz testing on the kernel in the Guest OS; Step 2: There are crashes to be reproduced in the queue, start the virtual machine, start the reproducer, and re-execute and verify the test cases that triggered the crash in a stable environment.

[0058] The steps for using a fuzzer are as follows: Step 1: In the T-Hyper virtualization environment, the administrator starts and manages the environment for fuzzing the Guest OS kernel through Hypervisor; Step 2: If there are no crashes to be reproduced in the queue, after starting the administrator, multiple virtual machines are started, and multiple fuzzers are placed in different virtual machines. The administrator calls multiple fuzzers in the virtual machines according to the configuration information received, and starts fuzzing; Step 3: After starting multiple fuzzers, test cases are generated or mutated according to the initial seed corpus, the executor is called to execute the test cases, execution information is collected, and finally the feedback information is sent back to the microkernel to minimize and update the corpus;

[0059] In step one of the fuzzer usage steps, the administrator starts from the microkernel in HyperVirus and initializes the administrator configuration according to the contents of the configuration file. It can start multiple instances. In our model, multiple different VM instances are started. However, in each VM instance, multiple fuzzer processes can perform fuzz tests simultaneously, thereby improving efficiency.

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

[0061] In step three of the fuzzer usage, the fuzzer leads the fuzzing process by generating and mutating inputs, and sends the inputs that trigger new coverage back to the manager process via RPC. During the execution of test cases, the executors are started to execute the test cases. Each executor executes one input, accepts the program executed by the fuzzer, and returns the result.

[0062] Specifically, components such as a manager, fuzzer, reproducer, and executor are deployed within a virtual machine to work collaboratively to complete testing tasks. The manager, acting as the framework's control center, runs on a microkernel operating system and is responsible for scheduling crash reproduction and fuzzing processes. When a crash to be reproduced exists in the queue, the manager starts the reproducer within the virtual machine, re-executing the test cases that caused the crash in a stable and controlled environment to verify their reproducibility and stability. If there are no crashes to be reproduced in the queue, the manager initiates the fuzzing process via Hypervisor. SOR deploys multiple fuzzers across multiple virtual machines to achieve parallel testing. The fuzzers are responsible for generating or mutating test inputs, invoking executors to execute test cases in isolated environments, and collecting execution results to optimize test efficiency and coverage. Simultaneously, the manager is responsible for persistently storing the corpus, which contains initial test cases, system call sequences, and crash information for subsequent analysis and improvement. During testing, the fuzzers communicate with the manager via Remote Procedure Calls (RPC). When new test coverage or crashes are detected, they notify the manager to initiate a crash reproduction process. The reproducer, according to the manager's instructions, re-executes the test cases that caused the crash in the virtual machine, ensuring test environment consistency through the executor. The executor works closely with the fuzzers and reproducers, receiving and executing test cases, and returning the execution results to the initiating component. Furthermore, this framework introduces an N-prediction model (details will be described later). This model, based on historical system call data, generates test cases containing potential vulnerability patterns by predicting system call sequences, further improving test effectiveness and coverage. In summary, based on Hypervi... HyperviSor's VM operating system kernel testing framework provides robust support for operating system kernel security testing through an integrated and automated testing process, combined with virtualization technology and intelligent test case generation methods. This effectively improves testing efficiency and reliability. Using HyperviSor for fuzzing isolates the testing process in a virtual environment, ensuring that the test does not affect the real system. HyperviSor can quickly deploy new virtual machine instances, thereby accelerating the fuzzing preparation process. The combination of HyperviSor and fuzzing provides a more secure, flexible, and efficient testing environment, which helps to discover and fix potential security vulnerabilities in the operating system kernel.

[0063] Please see Figure 2The method for generating test cases based on the N-prediction model involves the following steps: 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 the N-prediction model: Based on the Markov assumption, build a suitable N-prediction model that predicts the next system call based on the given first N system calls; Step 3: Experimentally determine the N value: Test the model's prediction effect under different N values ​​through experiments, and select the most suitable N value, i.e., determine the optimal prediction value for the model considering multiple system calls; 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 new input and use the model again to predict the next system call. Step 5: Evaluate the new system call sequence: Analyze the newly generated system call sequence to identify any vulnerable sequential system call patterns it may contain. 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 collected and analyzed to the corpus. This new data will be used for future test iterations to improve the effectiveness and coverage of the tests. Step 7: Use a fuzzing loop: Using the updated corpus as input, re-execute the entire process, including generating new system call sequences, evaluating, and updating the corpus, forming a continuous fuzzing loop.

[0064] In step S4 of the fuzzer, an N-prediction model is incorporated to collect test cases that trigger different types of crashes and test cases that do not trigger crashes. This allows system calls to be obtained through test cases. Then, the N-prediction model is applied to the test input to collect vulnerable sequence system call patterns of system calls of length n, generating new test cases and packaging 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 can still be inserted after the sequence, improving the efficiency of fuzz testing and discovering new vulnerabilities.

[0065] The test case generation method based on the N-prediction model mentions the following steps: Step 1: Select an initial system call or test case from the 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 vulnerability patterns or potential vulnerability trigger points.

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

[0067] The 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 cases and monitor the system's response; Step 2: Collect the test cases that triggered the crash and related crash information; Step 3: Analyze the cause of the crash and determine whether it was caused by a new vulnerability.

[0068] The method for generating test cases based on the N-prediction model, which uses a fuzzy testing loop, involves the following steps: Step 1: Continuously repeat the process of generating, executing, collecting, and analyzing test cases; Step 2: Update the corpus and N-prediction model based on newly discovered vulnerabilities and vulnerability patterns; Step 3: Optimize the test case generation strategy to improve testing efficiency and vulnerability discovery rate.

[0069] Specifically, initial system calls or test cases are selected from the initial test cases, system call sequences, and crash information contained in the corpus. Then, an N-prediction model continuously predicts and adds new system calls to the current sequence until a system call sequence meeting a specific length is generated. The newly generated sequence is then evaluated to check for known vulnerability patterns or points that may trigger new vulnerabilities. If the evaluation is successful, the test case is added to the corpus for subsequent testing. During testing, the newly generated test cases are executed, and the system's response is monitored. Test cases that trigger crashes and their crash information are collected. Subsequently, in-depth analysis is performed... Analyzing the causes of crashes and confirming whether they are caused by new vulnerabilities is achieved through continuous fuzzing cycles. This involves iterating through test case generation, execution, crash collection, and analysis to continuously discover new vulnerabilities and vulnerability patterns. After each cycle, the corpus and N-prediction model are updated based on the newly discovered information, and the test case generation strategy is optimized to improve testing efficiency and vulnerability discovery rate. In summary, the test case generation method based on the N-prediction model effectively improves the relevance of test cases and vulnerability discovery capabilities by combining intelligent prediction with continuous fuzzing, providing strong support for the security assurance of software systems.

[0070] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

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

Claims

1. A fuzzing method for operating system kernels, comprising a Hypervisor-based VM operating system kernel testing framework and a test case generation method based on an N-prediction model, characterized in that: The Hypervisor-based VM operating system kernel testing framework includes the following components: Manager: The host running on a microkernel operating system has two main functions. First, it is responsible for managing and scheduling the reproduction of crashes in the queue to ensure that vulnerabilities are reproduced in a stable environment and to verify the validity of the crashes. Second, when there are no crashes to be reproduced, it manages and starts the fuzzing process. The manager is also responsible for persistently storing the corpus, which is used as the input dataset for fuzzing. The crash information includes the storage of details of the triggered crashes. Fuzzer: Runs in a virtual machine, and multiple fuzzers can be deployed within a single virtual machine to achieve parallel testing. First, it guides the generation of test inputs and the minimization of the corpus through fuzz testing to optimize test efficiency and coverage. Then, it communicates with the administrator via remote calls. When new test coverage or crashes are found, it notifies the administrator to trigger the crash reproduction process. Finally, it starts the executor to execute specific test cases and receives the execution results. Reproducer: Runs in a virtual machine and is mainly responsible for crash reproduction. In a stable and controlled environment, it re-executes the test cases that caused the crash to verify the reproducibility and stability of the crash. Then, it uses the executor to schedule and call the executor to execute the test cases that reproduce the crash, ensuring the consistency of the test environment. Executor: Works closely with the fuzzer and reproducer, responsible for receiving test cases from the fuzzer or reproducer, executing these test cases in an isolated environment, and then returning 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 an N-prediction model: Based on the Markov assumption, construct a suitable N-prediction model that predicts the next system call based on the previous N system calls. S3: Experiment to determine the N value: Test the model prediction effect under different N values ​​through experiments, select the most suitable N value, that is, determine the model to consider multiple system calls to make the optimal prediction; S4: 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 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 vulnerable sequential system call patterns that may be contained within them, execute these sequences on the target system, and observe and record the system response, especially abnormal behavior or crash information; S6: Update Corpus: Add newly generated test cases, system call sequences, and any crash information data collection and analysis to the corpus. This new data will be used in future test iterations to improve test effectiveness and coverage. S7: Use a fuzzing loop: Using the updated corpus as input, re-execute the entire process, including generating a new system call sequence, evaluation, and corpus updates, forming a continuous fuzzing loop.

2. The fuzzing method for operating system kernels according to claim 1, characterized in that: The steps for using the reproducer are as follows: S1: The administrator is located in T-Hyper, starting from the microkernel and passing through Hypervisor to perform fuzz testing on the kernel in the Guest OS; S2: There are crashes to be reproduced in the queue. Start the virtual machine and start the reproducer. In a stable environment, re-execute and verify the test cases that triggered the crash.

3. The fuzzing method for operating system kernels according to claim 2, characterized in that: The steps for using a fuzzer are as follows: S1: In the T-Hyper virtualization environment, the administrator starts and manages the environment for fuzzing the Guest OS kernel through Hypervisor; S2: If there are no crashes to be reproduced in the queue, after starting the manager, start multiple virtual machines, put multiple fuzzers into different virtual machines, and call multiple fuzzers in the virtual machines according to the configuration information received by the manager to start fuzz testing. S3: After starting multiple fuzzers, test cases are generated or mutated based on the initial seed corpus. The executor is called to execute the test cases, execution information is collected, and finally the feedback information is sent back to the microkernel to minimize and update the corpus. S4: Utilize the N-prediction model to improve the efficiency and quality of test case generation, discover more potential vulnerabilities, combine the N-prediction model, determine the optimal N value through experiments to optimize prediction accuracy, generate system call sequences containing potential vulnerability patterns as new test cases, continuously update the corpus and iteratively generate and execute tests, while monitoring the results to optimize the model.

4. The fuzzing method for operating system kernels according to claim 3, characterized in that: In step S1, the administrator starts from the microkernel in the hypervisor and initializes the administrator's configuration according to the contents of the configuration file. It starts multiple instances, which in the model are multiple different VM instances. However, in each VM instance, multiple fuzzer processes perform fuzz testing simultaneously, thereby improving efficiency.

5. A fuzzing method for operating system kernels according to claim 3, characterized in that: In step S2, the reproducer is primarily responsible for reproducing and verifying the test cases that have triggered a crash in a stable environment.

6. The fuzzing method for operating system kernels according to claim 3, characterized in that: In step S3, the fuzzer leads the fuzzing process, which includes input, generation, and mutation. The input that triggers new coverage is sent back to the manager process via RPC. During the execution of test cases, the executor is started to execute the test cases. Each executor executes one input, accepts the program executed by the fuzzer, and returns the result.

7. A fuzzing method for operating system kernels according to claim 3, characterized in that: In step S4, an N-prediction model is incorporated to collect test cases that trigger different types of crashes and test cases that do not trigger crashes. This allows system calls to be obtained through test cases. Then, the N-prediction model is applied to the test input to collect vulnerable sequence system call patterns of system calls of length n, generating new test cases and packaging them into a corpus to guide the test case generation phase. Newly generated test cases must contain consecutive vulnerable patterns, and new system calls are still inserted after the sequence, improving the efficiency of fuzz testing and discovering new vulnerabilities.

8. A fuzzing method for operating system kernels according to claim 1, characterized in that: The steps for calling the test case method mentioned in the method for generating test cases based on the N-prediction model are as follows: S1: Select an initial system call or test case from the corpus; S2: Predict the next system call using the N-prediction model 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 for known vulnerability patterns or potential vulnerability trigger points; S5: Package the evaluated test cases into the corpus for later use.

9. A fuzzing method for operating system kernels according to claim 1, characterized in that: The 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: S1: Execute the newly generated test cases and monitor the system's response; S2: Collect test cases that trigger crashes and related crash information; S3: Analyze the cause of the crash and determine if it was caused by a new vulnerability.

10. A fuzzing method for operating system kernels according to claim 1, characterized in that: The steps of the method for generating test cases based on the N-prediction model, which uses a fuzzy testing loop, are as follows: S1: The process of continuously generating, executing, collecting, and analyzing test cases; S2: Update the corpus and N-prediction model based on newly discovered vulnerabilities and vulnerability patterns; S3: Optimize test case generation strategies to improve testing efficiency and vulnerability discovery rate.

Images