Kernel-driven virtual device fuzzing method and device based on large language model

Abstract

This invention relates to a method and apparatus for fuzzing kernel-driven virtual devices based on a large language model. The method includes: extracting key device interaction information from the source code of the target driver using static analysis, and generating a driver context knowledge base by structurally indexing the kernel source code tree in the entire operating system kernel; under the constraints of the driver context knowledge base and predefined modeling specifications, iteratively guiding the large language model to generate a QEMU virtual device model using the key device interaction information, and performing initialization interactions to obtain a fully initialized virtual device model; in the QEMU environment, using the Syzkaller fuzzing framework to perform fuzzing tests on the fully initialized virtual device model against the system call sequence generated by the target driver, and collecting potential defect information under code coverage feedback and memory safety detection conditions. This method effectively resolves the core contradiction between the difficulty of simultaneously achieving automated scalability and high model fidelity.

Description

Technical Field

[0001] This invention belongs to the field of operating system kernel driver testing technology, specifically relating to a method and apparatus for fuzz testing of kernel driver virtual devices based on a large language model. Background Technology

[0002] The security and stability of the operating system kernel are the cornerstone of modern computing systems. As a key component within the kernel that directly interacts with hardware, device drivers constitute one of the largest and most risky subsystems within the kernel. Device drivers contain numerous execution paths constrained by device interfaces, register states, and interactive behaviors. The triggering of their code highly depends on the specific feedback provided by the hardware device at runtime. When there is a lack of real or correctly interacting device support, these execution paths are often difficult to cover in actual operation, causing the relevant code to remain in an untestable state for a long time, becoming a potential threat to kernel security and reliability.

[0003] Fuzzing has proven to be an effective means of discovering kernel vulnerabilities (e.g., the Syzkaller framework), but its performance is severely limited by hardware dependencies in device driver testing scenarios. Existing testing solutions generally face the challenge of "hardware binding": on the one hand, real hardware is expensive, diverse in type, and difficult to deploy and scale on a large scale; on the other hand, the number of pre-built general-purpose device models in mainstream simulation platforms (such as QEMU) is far less than the number of device drivers actually supported by the kernel (for example, the Linux kernel supports more than 13,000 PCI devices, while the PCI device models implemented in QEMU are less than one percent of that). Under these conditions, many drivers stall during the initialization phase due to a lack of matching device feedback, making it impossible to explore subsequent complex execution paths, which greatly limits the coverage depth and vulnerability discovery capabilities of fuzzing.

[0004] To alleviate these problems, existing research has attempted to replace real hardware by constructing virtual devices that can interact with drivers. However, existing methods have significant limitations in practice. For example, automated modeling methods, such as PrIntFuzz, generate device models with coarse granularity, typically only simulating simple register read operations and failing to provide advanced semantic features such as interrupts and DMA required for driver initialization. On the other hand, methods such as USBFuzz heavily rely on manually designed device models or specific bus interfaces, resulting in high coupling between the model and the driver and poor versatility and scalability.

[0005] In summary, the biggest problem with existing technologies is that automatically generated virtual device models are difficult to match precisely with target-driven behavior semantics, while high-fidelity modeling methods heavily rely on manual intervention or specific hardware interfaces, resulting in a long-standing lack of effective and universal solutions between scalable automated testing and high-fidelity device simulation. Summary of the Invention

[0006] To address the aforementioned problems in the existing technology, this invention provides a fuzz testing method and apparatus for kernel-driven virtual devices based on a large language model. The technical problem to be solved by this invention is achieved through the following technical solution: This invention provides a method and apparatus for fuzzing kernel driver virtual devices based on a large language model. The method includes: performing the following steps on a target driver in an operating system kernel based on analyzable source code: Static analysis is used to extract key device interaction information from the source code of the target driver, and a driver context knowledge base is generated by performing a structured index on the kernel source code tree in the entire operating system kernel. Under the constraints of the driver context knowledge base and predefined modeling specifications, the QEMU virtual device model is generated iteratively by using the key device interaction information. The model is then corrected based on compilation checks and runtime feedback until the QEMU virtual device model can complete the initialization interaction with the target driver, resulting in the virtual device model after initialization. In the QEMU environment, the Syzkaller fuzzing framework is used to perform fuzzing tests on the virtual device model after initialization based on the system call sequence generated by the target driver, and potential defect information is collected under the conditions of code coverage feedback and memory safety detection.

[0007] Compared with the prior art, the beneficial effects of the present invention are as follows: To address the long-standing lack of an effective and generalized solution for balancing scalable automated testing and high-fidelity device simulation, this invention provides a kernel-driven virtual device fuzzing method and apparatus based on a large language model. This method effectively resolves the core contradiction of the difficulty in simultaneously achieving "automated scalability" and "high-fidelity modeling" by deeply integrating the code generation capabilities of the large language model with systematic engineering constraints and verification mechanisms. Specifically, by extracting key device interaction information from the driver source code and constraining the output of the large language model according to predefined modeling specifications, the semantic accuracy of the generated virtual device is ensured, overcoming the problems of coarse model behavior and semantic deficiencies in existing methods. Through phased "structure-behavior" modeling and a closed-loop correction mechanism of "compile checking-run feedback," automated verification and repair of the generated model are achieved, enabling the virtual device to complete initialization interaction with the target driver, thereby transforming driver code lacking hardware support into a testable object. Finally, the interactive virtual device is integrated into the Syzkaller fuzzing framework, and coverage and security detection tools are enabled to achieve automated exploration and vulnerability discovery of deep driver paths, ensuring both testing automation and testing depth. Attached Figure Description

[0008] Figure 1 This is a flowchart of the kernel driver virtual device fuzzing method based on a large language model provided in an embodiment of the present invention; Figure 2 This is a detailed modeling result diagram of the first 24 Linux kernel driver examples provided in this embodiment of the invention under three major language models; Figure 3 This is a detailed modeling result diagram of the last 26 Linux kernel driver examples provided in this embodiment of the invention under three major language models; Figure 4 This is based on the embodiments of the present invention. Figure 2-3 Venn diagram of the complementary capabilities of data in China. Detailed Implementation

[0009] The present invention will be further described in detail below with reference to specific embodiments, but the implementation of the present invention is not limited thereto.

[0010] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. In addition, those skilled in the art can combine and integrate the different embodiments or examples described in this specification.

[0011] The following is a detailed description of the fuzz testing method and apparatus for kernel-driven virtual devices based on a large language model, proposed in this invention, with reference to the accompanying drawings.

[0012] It should be understood that this invention is strictly limited to a design "targeted at a specific driver" because kernel driver testing is essentially an exact-matching problem: each driver encodes a unique "contract" for interacting with a specific hardware device. This invention abandons the impractical path of building generic or universal virtual devices, instead adopting a precise "one-to-one" strategy—extracting the specific device interaction requirements from the source code of a single target driver and dynamically generating a highly customized, behavior-matching virtual device model for it. This core principle ensures that the entire automated process, from static analysis and constraint modeling to feedback and repair, always revolves around a clear and verifiable object, thus transforming the grand challenge of "how to test all drivers" into a solvable problem of "how to automatically build a dedicated test companion for any given driver," fundamentally achieving a breakthrough in hardware dependency.

[0013] Figure 1 This is a flowchart of a kernel driver virtual device fuzzing method based on a large language model provided in an embodiment of the present invention. Figure 1 As shown, this method targets a target driver within an operating system kernel based on analyzable source code and performs the following steps: S1: Use static analysis to extract key device interaction information from the source code of the target driver, and perform structured indexing of the kernel source code tree in the entire operating system kernel to generate a driver context knowledge base. S2: Under the constraints of the driver context knowledge base and predefined modeling specifications, the large language model is iteratively guided to generate a QEMU virtual device model using key device interaction information, and corrections are made based on compilation checks and runtime feedback until the QEMU virtual device model can complete the initialization interaction with the target driver, thus obtaining the virtual device model after initialization. S3: In the QEMU environment, the Syzkaller fuzzing framework is used to perform fuzzing tests on the virtual device model after initialization based on the system call sequence generated by the target driver, and potential defect information is collected under the conditions of code coverage feedback and memory safety detection.

[0014] The specific execution method for each step will now be explained.

[0015] In one application scenario, the operating system kernel based on analyzable source code is the Linux kernel. The Linux kernel is currently the most mature and widely used open-source operating system kernel, and its complete source code is publicly available, providing the necessary data foundation for performing the static analysis and structured indexing of the full kernel source tree of this invention. Secondly, the Linux kernel possesses a clear and unified device driver model architecture (such as PCI, USB, etc.), and the hardware interaction patterns in its driver code (such as the pci_driver structure, probe function, MMIO / PIO access, etc.) are highly standardized and extractable. Furthermore, a very complete testing and simulation ecosystem has been built around the Linux kernel, including the QEMU virtualization platform, the Syzkaller fuzzing framework, and coverage and security testing toolchains such as KCOV and KASAN. This provides direct technical support for fully realizing the automated closed loop of "generation-interaction-testing" in this invention. Therefore, choosing the Linux kernel as an example can most clearly and completely demonstrate the technical solution and implementation path of this invention.

[0016] It should be noted that any operating system kernel (such as FreeBSD) that meets the following general technical conditions ("driver source code can be statically analyzed", "can build a global source code knowledge base" and "can perform interactive verification in a virtualization environment") can be applied to the method proposed in this invention.

[0017] Specifically, S1 includes: S1.1 Using allmodconfig, the kernel source code tree in the Linux kernel is modularly configured and compiled to obtain multiple compiled source codes.

[0018] The purpose of this step is to prepare a complete and consistent view of the kernel code for subsequent static analysis. `allmodconfig` is a standard configuration command provided by the Linux kernel build system. Executing this command generates a configuration file whose core function is to enable compilation support for all optional driver modules (especially device drivers) as much as possible. This ensures that during subsequent compilation, the code of the target driver and all kernel components it may depend on (such as related APIs, data structures, and subsystems) will be processed, making it available for static analysis tools (such as LLVM-based toolchains) to parse.

[0019] S1.2. Using a static analysis method based on LLVM, the struct pci_driver structure, pci_device_id table, probe callback function logic, register macro definitions, and configuration space access modes defined in the target driver are extracted from multiple compiled source codes to form key information for device interaction.

[0020] This step is the data foundation construction phase of this invention. Its core is to automatically and accurately extract the "requirements list" and "operation manual" for interaction with hardware devices from the target-driven source code. The LLVM compiler framework can convert the source code into a high-level intermediate representation (IR) independent of the specific programming language. Static analysis on this IR can overcome obstacles such as macro definitions and conditional compilation, allowing for the analysis of the principles of a sophisticated circuit. Figure 1 In this way, it can accurately identify the definitions of all data structures in the code, the calling relationships between functions, and the access patterns to specific memory or port addresses, without actually running the code.

[0021] Specifically, the identity that a virtual device must present in the system can be determined through the struct pci_driver structure and the pci_device_id table, especially the vendor ID and device ID. This is a prerequisite for the driver to successfully identify and bind to the device.

[0022] By utilizing the probe callback function logic, we can understand what steps the driver needs to perform to prepare resources (such as allocating memory space, mapping registers, requesting interrupts, etc.) after discovering the device, and thus know what resources the virtual device needs to provide during the initialization phase and how to respond.

[0023] Furthermore, by analyzing the address offsets (macro definitions) and specific operation sequences (access patterns) of read and write registers in the driver code, it is possible to infer which registers the device can control, their functions, and the access order and return values ​​expected by the driver.

[0024] S1.3. Based on key information about device interaction and the results of structured indexing of the kernel source code tree, construct a driver context knowledge base.

[0025] This step is the knowledge integration and context enhancement stage of the present invention, the core of which is to create a semantically rich "development encyclopedia" that is specifically tailored for goal-driven development.

[0026] In S1.3, the raw data structures (such as `struct pci_driver`), function logic (probe flow), and constant definitions (register offsets) extracted from S1.2 are converted into a unified, machine-readable structured data format (such as JSON, Protocol Buffers, or a custom schema). Each entry is labeled with its source (such as source filename and line number) and type. Furthermore, all symbols (macros, functions, structures, enumerations) obtained after analyzing the entire kernel source tree, along with their definition locations, dependencies, and call relationships, are organized into a relational database. This allows for rapid location of symbol definitions and related source code based on symbol names. Subsequently, the system automatically analyzes each item in the "Device Interaction Key Information" and associates it with relevant entries in the "Structured Index".

[0027] For example, when the "Key Information on Device Interaction" indicates that the driver calls the function pci_enable_msi(), the build process will: search the "Structured Index" for the complete function prototype of pci_enable_msi, its header file, and other kernel functions that it may call internally. It will also create an association record in the knowledge base, binding the requirement that "the driver needs MSI interrupt capability" to the kernel API (pci_enable_msi) necessary to implement that requirement and its related knowledge.

[0028] The data, after being correlated, is encapsulated into a knowledge service with a specific query interface, and finally aggregated to obtain the driving context knowledge base. This interface supports at least: 1) Exact query: Returns all related definitions and contexts for a symbol name (such as ioremap).

[0029] 2) Related queries: Given an entry from "device interaction key information" (such as "the driver performs a 32-bit write operation at offset 0x10 of BAR0"), return possible kernel functions (such as writel), data types, and related device model examples associated with this operation.

[0030] 3) Contextual completion: Given a code snippet and cursor position (simulating the state of a large language model being generated halfway), it can identify missing or undefined identifiers in the snippet and return the most likely relevant definition from the index for completion.

[0031] After obtaining the driver context knowledge base, the core virtual device generation and correction phase (S2) is entered.

[0032] First, this phase is conducted under the constraints of two key predefined modeling specifications, which are directly derived from the static analysis results and aim to strictly prevent free speculation in the Large Language Model (LLM) and ensure the realism of the generated model. Here, the large language models in S2 include Qwen3-Max, GPT-5.1, and Gemini3 Pro; and the predefined modeling specifications include: 1) Force the extraction of the vendor ID and device ID from the first entry in the static const struct pci_device_id table in the key information of device interaction as the identification identifier of the QEMU virtual device model; it should be understood that this specification ensures that the virtual device has a unique identity that the driver can correctly identify and bind to, which is the logical starting point for all subsequent interactions.

[0033] 2) The declaration of the corresponding BAR index, address space type, and size in the QEMU virtual device model is only permitted when the size or type of the BAR is explicitly defined in the target driver; otherwise, speculation about undefined BAR indexes is prohibited, and related placeholder code in the QEMU virtual device model must be removed. It should be understood that this specification follows the "evidence-driven" principle, preventing the model from fabricating hardware resources and ensuring the accuracy of device resource declarations, which is crucial for a device to successfully complete driver resource requests (such as pci_request_regions).

[0034] Under the above strict constraints, the initialized virtual device model is generated through the following three stages (structural modeling stage, behavioral modeling stage, and feedback repair stage).

[0035] The goal of the structural modeling phase is to build a "correct but blank" device framework based on the driver's static expectations of the device. Specifically, based on the static definitions within the key device interaction information, the PCI configuration space layout and base address register declaration in the QEMU virtual device template are filled in, and the introduction of any device runtime logic is prohibited at this stage, generating a QEMU virtual device model. The core constraint of this stage is to prohibit the introduction of any device runtime logic (such as interrupt responses, register read / write callbacks), and only complete the "static identity registration" and "resource requirement declaration" of the device in the system's eyes, generating a QEMU virtual device model skeleton without any behavior.

[0036] The goal of the behavior modeling phase is to implement the dynamic device behavior expected by the driver for the aforementioned QEMU virtual device model. Specifically, based on the key device interaction information extracted from the target driver source code, which characterizes the memory mapping address space type access mode, interrupt usage, and direct memory access operations required during its initialization process, corresponding runtime behavior callback functions are constructed for the QEMU virtual device model to form a complete device model. The feedback and repair phase is a closed loop of automated verification and incremental improvement. Specifically, the complete device model is compiled and checked, and the compiled device model is loaded into QEMU for initialization interaction with the target driver. Based on compilation error feedback and initialization interaction failure feedback (such as the driver probe function returning an error code), the large language model is guided to iteratively correct the complete device model until the target driver successfully completes initialization (i.e., the probe function returns 0), resulting in the virtual device model after initialization.

[0037] It's important to note that the intelligent guidance mechanism is crucial in both the structural and behavioral modeling phases. Specifically, it guides the large language model to generate the corresponding complete device model code by dynamically constructing structured prompts containing target-driven key source code snippets, key device interaction information obtained from static analysis, and QEMU device modeling examples. When the large language model cannot continue generation due to missing context information (e.g., undefined kernel APIs or data structures), the missing macro definitions, structure or enumeration type definitions are retrieved and supplemented from the driver context knowledge base to complete the context information and support the continuation of the generation process. This mechanism greatly alleviates the limitations of LLM in terms of domain-specific knowledge.

[0038] Furthermore, during the feedback and repair phase, based on compilation error feedback and initialization interaction failure feedback, the large language model is guided to iteratively correct the complete device model, including: During each iteration, the clangd tool performs syntax and type checks on the code of the current complete device model, and obtains the error information as compilation error feedback. The compilation error feedback is then fed back to the large language model to drive it to correct the code of the complete device model generated in the current iteration, generating a corrected device model. The corrected device model is then loaded into the QEMU environment, started, and performs initialization interaction with the target driver. If the target driver's device detection process fails or its initialization callback function (probe function) returns a non-zero status, the QEMU runtime log and driver return status are collected as runtime feedback indicating that the initialization interaction has failed, triggering a new round of iteration correction.

[0039] After the virtual device is generated, the fuzzing phase (S3) begins.

[0040] In S3, the system call sequence generated for the target driver using the Syzkaller fuzzing framework is used. This includes: generating a customized test configuration file based on the official Syzkaller system call description, combined with the source code path of the target driver in the operating system kernel and the device node creation information; enabling the KCOV option in the customized test configuration file to obtain code coverage feedback, and enabling KASAN to detect memory security vulnerabilities, resulting in an enhanced test configuration that supports boot coverage and memory error detection; and generating and executing the system call sequence for the target driver based on the enhanced test configuration to perform high-intensity testing on the initialized virtual device model, explore deep execution paths, and collect potential defect information such as crashes and warnings.

[0041] It should be understood that, furthermore, this information on potential defects can be used for subsequent vulnerability remediation and hardening, security assessment and risk measurement, as well as verifying the realism of the virtual device model. This is because the defects triggered during testing are essentially caused by the interaction between the device behavior simulated by the generated virtual device model and the driver code. If the triggered crash is a known vulnerability that also exists in a real hardware environment, then this strongly proves that the virtual device model generated by this invention closely approximates the behavior of real hardware, verifying the effectiveness and fidelity of the modeling method.

[0042] Corresponding to the above testing method, this embodiment of the invention also provides a kernel driver virtual device fuzzing apparatus based on a large language model. It should be understood that, since the apparatus is basically similar to the method embodiment, the description is relatively simple, and relevant details can be found in the description of the method embodiment. Specifically, the apparatus employs the above-mentioned kernel driver virtual device fuzzing method based on a large language model, and the apparatus includes: The information collection module is used to extract key device interaction information from the source code of the target driver using static analysis, and to generate a driver context knowledge base by performing structured indexing of the kernel source code tree in the entire operating system kernel. The device modeling module, under the constraints of the driver context knowledge base and predefined modeling specifications, uses key device interaction information to iteratively guide the large language model to generate a QEMU virtual device model, and makes corrections based on compilation checks and runtime feedback until the QEMU virtual device model can complete the initialization interaction with the target driver, thus obtaining the virtual device model after initialization. The integration testing module, within the QEMU environment, utilizes the Syzkaller fuzzing framework to perform fuzzing tests on the initialized virtual device model against the system call sequence generated by the target driver, and collects potential defect information under code coverage feedback and memory safety detection conditions.

[0043] To address the long-standing lack of an effective and universal solution for bridging scalable automated testing and high-fidelity device simulation, this invention provides a kernel-driven virtual device fuzzing method and apparatus based on a large language model. This method systematically solves the aforementioned problems by introducing a novel paradigm of "static extraction-structured generation-execution feedback repair," and has the following significant technical effects: 1. By accurately extracting "key device interaction information" from the target-driven source code and constructing a "driver context knowledge base," a reliable data foundation is provided for the generation process. Combined with strict constraints of "predefined modeling specifications" (such as mandating the use of real device IDs and prohibiting speculation of undefined BARs) and a phased "structure-behavior" modeling strategy, it is ensured that the virtual device model generated by the large language model can accurately match the target-driven model in both static configuration and dynamic behavior.

[0044] 2. By dynamically constructing structured prompts containing code snippets, analysis results, and examples to guide the generation process, and automatically supplementing the context using a knowledge base when the model "gets stuck," the intelligence of the guidance is significantly improved. More importantly, a "feedback and repair phase" is designed, including compilation checks and runtime verification, forming an automated closed loop of "generation-verification-correction." This continuously iterates and repairs syntax and semantic errors in the model until successful initialization, thereby greatly improving the success rate and reliability of the modeling process.

[0045] 3. The generated, interactive virtual device model is directly integrated into a mature testing environment based on QEMU and Syzkaller, and KCOV and KASAN are enabled for coverage booting and security testing. This allows driver code that was previously "dormant" due to lack of hardware to be explored by a standard, powerful fuzzing engine, transforming untestable paths into testable objects, greatly expanding the depth and breadth of test coverage.

[0046] Figure 2 and Figure 3 These are detailed modeling results of 50 Linux kernel driver examples provided in this invention under three large language models. Specifically, under the Qwen3-Max, GPT-5.1, and Gemini 3 Pro large language models, the method of this invention performs automated virtual device modeling on 50 randomly selected real Linux kernel drivers; and Figure 2-3 The document details all 50 specific Linux kernel driver names, such as 8139to0, pcwd_pci, and ns83820; and provides annotations for each driver example based on experimental results. √ (Full-Automatic): Fully automatic and successful.

[0047] M (Manual Fix): Success requires manual correction.

[0048] × (Failed): Complete failure.

[0049] Figure 2-3 By providing original, complete, and verifiable experimental data, this paper visually demonstrates the effectiveness of the method of this invention in guiding different large language models to perform modeling on 50 real drivers covering various types, including network, storage, and watchdog timers. As shown in the table in the figure, the method successfully guided different models to handle various device drivers, including network controllers (such as 8139to0) and dedicated hardware interfaces (such as pcwd_pci), verifying its wide applicability.

[0050] Experimental data strongly validates the above-mentioned technical effects: on a test set of 50 Linux 6.18 kernel PCI drivers covering different manufacturers and functions, this method achieves a 74%–78% success rate in automated virtual device modeling; fuzzing based on the generated devices significantly improves driver code coverage and successfully discovers 7 previously unknown kernel crashes. This result empirically demonstrates that this invention not only successfully turns the concept of "one-to-one" precise modeling into reality, but also possesses outstanding practical value in terms of engineering feasibility, testing effectiveness, and vulnerability discovery capabilities.

[0051] Figure 4 This is based on the embodiments of the present invention. Figure 2-3The Venn diagram illustrates the complementary capabilities of the data. The three circles represent Qwen3-Max, GPT-5.1, and Gemini 3 Pro, respectively. The central intersection (yellow area) represents "All Successful," indicating cases successfully handled by all three models. Pairwise intersections, such as the purple area, represent cases where both Qwen3-Max and GPT-5.1 succeeded, meaning both models handled these cases correctly, but Gemini 3 Pro failed. Figure 2-3 Detailed data, Figure 4 Further in-depth analysis was conducted. This demonstrates that the method proposed in this invention has the potential to fully utilize the unique advantages of different models. Experimental results demonstrate the feasibility of further improving coverage and success rate through multi-model collaboration, showcasing the good scalability and robustness of the proposed technical solution.

[0052] In summary, the solution provided by this invention can achieve full automation from driver source code to interactive virtual devices and deep fuzz testing without human intervention or real hardware, providing an efficient and universal new approach to solving the "hardware dependency" problem of kernel driver testing.

[0053] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the concept of the present invention, and all such modifications and substitutions should be considered within the scope of protection of the present invention.

Claims

1. A fuzzing method for kernel-driven virtual devices based on a large language model, characterized in that, This includes performing the following steps for target drivers within an operating system kernel based on analyzable source code: Static analysis is used to extract key device interaction information from the source code of the target driver, and a driver context knowledge base is generated by performing a structured index on the kernel source code tree in the entire operating system kernel. Under the constraints of the driver context knowledge base and predefined modeling specifications, the QEMU virtual device model is generated iteratively by using the key device interaction information. The model is then corrected based on compilation checks and runtime feedback until the QEMU virtual device model can complete the initialization interaction with the target driver, resulting in the virtual device model after initialization. In the QEMU environment, the Syzkaller fuzzing framework is used to perform fuzzing tests on the virtual device model after initialization based on the system call sequence generated by the target driver, and potential defect information is collected under the conditions of code coverage feedback and memory safety detection.

2. The fuzzing method for kernel-driven virtual devices based on a large language model according to claim 1, characterized in that, The operating system kernel based on analyzable source code is the Linux kernel; the process of extracting key device interaction information from the source code of the target driver using static analysis and generating a driver context knowledge base by performing structured indexing of the kernel source code tree in the entire operating system kernel includes: Using allmodconfig, the kernel source code tree in the Linux kernel is modularly configured and compiled to obtain multiple compiled source codes. A static analysis method based on LLVM is used to extract the struct pci_driver structure, pci_device_id table, probe callback function logic, register macro definitions and configuration space access modes defined in the target driver from the multiple compiled source codes, so as to constitute the key information of device interaction; Based on the key information of device interaction and the results of structured indexing of the kernel source code tree, the driver context knowledge base is constructed.

3. The fuzzing method for kernel-driven virtual devices based on a large language model according to claim 2, characterized in that, The predefined modeling specifications include: 1) Forcefully extract the vendor ID and device ID of the first entry from the static const struct pci_device_id table in the device interaction key information as the identification identifier of the QEMU virtual device model; 2) The corresponding BAR index, address space type, and size are only allowed to be declared in the QEMU virtual device model when the size or type of BAR is explicitly defined in the target driver; otherwise, speculation of BAR indexes that are not explicitly defined is prohibited, and the relevant placeholder code in the QEMU virtual device model is deleted.

4. The fuzzing method for kernel-driven virtual devices based on a large language model according to claim 1, characterized in that, The initialized virtual device model is generated through the following three stages: Structural modeling stage: Based on the static definitions within the key device interaction information, fill in the PCI configuration space layout and base address register declaration in the QEMU virtual device template, and prohibit the introduction of any device runtime logic in this stage to generate the QEMU virtual device model; Behavioral modeling phase: Based on the key device interaction information extracted from the target driver source code, which characterizes the memory mapping address space type access mode, interrupt usage, and direct memory access operations required to be displayed during its initialization process, corresponding runtime behavior callback functions are constructed for the QEMU virtual device model to form a complete device model; Feedback and Repair Phase: The complete device model is compiled and checked, and the compiled device model is loaded into QEMU for initialization interaction with the target driver; based on the compilation error feedback and initialization interaction failure feedback, the large language model is guided to iteratively correct the complete device model until the target driver successfully completes initialization, and the virtual device model after initialization is obtained.

5. The fuzzing method for kernel-driven virtual devices based on a large language model according to claim 4, characterized in that, The step of guiding the large language model to iteratively correct the complete device model based on compilation error feedback and initialization interaction failure feedback includes: During each iteration, the clangd tool is used to perform syntax and type checks on the code of the current complete device model, and the error information detected is used as the compilation error feedback. The compilation error is fed back to the large language model to drive it to correct the code of the complete device model generated in the current iteration, and generate a corrected device model. The modified device model is loaded into the QEMU environment, started, and performs initialization interaction with the target driver. If the target driver's device detection process fails or its initialization callback function returns a non-zero state, the QEMU runtime log and driver return status are collected as runtime feedback indicating the failure of the initialization interaction, in order to trigger a new round of iterative correction.

6. The fuzzing method for kernel-driven virtual devices based on a large language model according to claim 4, characterized in that, The structural modeling phase and the behavioral modeling phase also include: By dynamically constructing structured prompts that include key source code segments driven by the target, key device interaction information obtained from static analysis, and QEMU device modeling examples, the large language model is guided to generate the code for the corresponding complete device model.

7. The fuzzing method for kernel-driven virtual devices based on a large language model according to claim 6, characterized in that, Also includes: When the large language model cannot continue to be generated due to missing context information during the generation process, the missing macro definitions, structure or enumeration type definitions are retrieved and supplemented from the driving context knowledge base to complete the context information and support the continuation of the generation process.

8. The fuzzing method for kernel-driven virtual devices based on a large language model according to claim 1, characterized in that, The system call sequence generated for the target driver using the Syzkaller fuzz testing framework includes: Based on the official Syzkaller system call description, and combined with the source code path of the target driver in the operating system kernel and the device node creation information, a customized test configuration file is generated. In the customized test configuration file, the KCOV option is enabled to obtain code coverage feedback, and KASAN is enabled to detect memory security vulnerabilities, resulting in an enhanced test configuration that supports boot coverage and memory error detection. Based on the enhanced test configuration, the system call sequence for the target driver is generated and executed.

9. A kernel-driven virtual device fuzzing device based on a large language model, characterized in that, The apparatus employs the kernel-driven virtual device fuzzing method based on a large language model as described in any one of claims 1 to 8, and the apparatus comprises: The information collection module is used to extract key device interaction information from the source code of the target driver using static analysis, and to generate a driver context knowledge base by performing structured indexing of the kernel source code tree in the entire operating system kernel. The device modeling module, under the constraints of the driver context knowledge base and predefined modeling specifications, uses the key information of device interaction to iteratively guide the large language model to generate a QEMU virtual device model, and makes corrections based on compilation checks and runtime feedback, until the QEMU virtual device model can complete the initialization interaction with the target driver, thus obtaining the virtual device model after initialization. The integrated testing module, within the QEMU environment, utilizes the Syzkaller fuzzing framework to perform fuzzing tests on the initialized virtual device model against the system call sequence generated by the target driver, and collects potential defect information under code coverage feedback and memory safety detection conditions.

Images