An operating system fuzzing method based on high-speed snapshot and recovery
By capturing and restoring the complete initial state of the operating system in the operating system kernel fuzzing, the problems of incomplete state reset and excessive time overhead are solved, achieving efficient and stable fuzzing results that are suitable for various operating environments.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHINESE PEOPLES LIBERATION ARMY UNIT 61660
- Filing Date
- 2026-05-15
- Publication Date
- 2026-07-03
Smart Images
Figure CN122332297A_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of operating system kernel fuzzing technology, specifically involving an operating system fuzzing method based on high-speed snapshots and recovery. Background Technology
[0002] As the foundational software platform of information systems, the operating system's kernel security directly determines the reliability of the entire system's operating environment. Fuzzing is a core technical method for detecting operating system kernel vulnerabilities and driver defects. By injecting a large number of randomly generated or mutated valid system call sequences into the target system, potential kernel anomalies are triggered, thereby identifying security flaws.
[0003] In operating system kernel fuzzing, the execution of each test case irreversibly modifies the kernel state, including changes to memory data structures, rewriting register contents, file system cache pollution, and changes in peripheral queue states. State remnants from preceding test cases pollute the execution environment of subsequent test cases, leading to three prominent problems: First, unstable test states; state changes introduced by preceding operations may trigger anomalies not caused by the test cases themselves, or mask real defects, resulting in false positives or false negatives. Second, difficulty in vulnerability reproduction; due to the continuous evolution of the system state, the conditions under which the same test case triggers a vulnerability in different execution rounds are difficult to reproduce. Third, limited test throughput; to reduce state interference, existing solutions require the introduction of state reset operations during testing.
[0004] In existing technologies, there are two main solutions to mitigate the aforementioned state interference problem. The first solution is a periodic restart mechanism, which involves performing a full restart of the target operating system after executing a predetermined number of test cases to reset the system state. Some kernel fuzzing tools employ a strategy of restarting the system once every thousand test cases. The second solution is manual state cleanup, which involves writing a dedicated cleanup script to target and remove known state modifications during test case execution intervals, such as terminating residual processes or deleting temporary files. The implementation process for both solutions can be summarized as follows: start the target operating system and complete initialization; execute several test cases and record the execution results; determine whether a preset restart or cleanup threshold has been reached; if not, continue executing subsequent test cases; if the threshold has been reached, execute a system restart or run the cleanup script; after resetting or cleanup, return to the test case execution phase to continue testing.
[0005] The aforementioned existing technical solutions have the following shortcomings during implementation: manual state cleanup can only cover known state changes such as process lists and temporary files, and cannot eliminate deep-level state changes such as kernel-mode memory pollution, processor register remnants, and kernel data structure changes, so the problem of incomplete state cleanup still exists; the system restart operation has a significant time overhead, with a single restart process usually taking tens of seconds to several minutes, and after restarting, the kernel loading, driver initialization, and necessary service startup must be completed again, with non-testing components accounting for more than 60% of the total test time, resulting in low test efficiency; because some modifications to the system state by previous test cases are not completely cleared, the same test cases may exhibit different execution paths or abnormal behaviors in multiple executions, resulting in low stability of vulnerability reproduction.
[0006] In summary, existing operating system kernel fuzzing techniques suffer from drawbacks such as incomplete state reset and excessive reset time overhead, leading to insufficient test accuracy and limited test efficiency. Summary of the Invention
[0007] In view of the problems of insufficient test accuracy and limited efficiency caused by incomplete state reset and excessive reset time in the existing technology, this application provides an operating system fuzzing method based on high-speed snapshot and recovery. By capturing the complete initial state of the operating system through high-speed snapshot, and quickly restoring it to the initial state before the execution of each test case, the method achieves millisecond-level accurate reset of the kernel-mode fuzzing environment, thereby improving the stability of vulnerability reproduction and the overall test throughput.
[0008] To achieve the above technical objectives, this application specifically employs the following technical solution: In one aspect of this application, an operating system fuzzing method based on high-speed snapshots and recovery is provided, comprising the following steps: S1. Start the target operating system and complete environment initialization; S2. Generate an initial state snapshot of the operating system after completing environment initialization, and store the initial state snapshot; S3. Before executing each test case, read the initial state snapshot from storage and restore the operating system to the state recorded in the initial state snapshot; S4. After the recovery is complete, generate test cases and inject the test cases into the operating system for execution; S5. Record the execution results of the test cases.
[0009] In one implementation, step S2, generating an initial state snapshot of the operating system after completing environment initialization, includes: The system captures complete state data of the operating system through the underlying interface. The complete state data includes memory data, CPU register status, process / thread information, file system status, and peripheral device status. The captured complete state data is compressed and stored, and assigned a unique identifier.
[0010] In one implementation, restoring the operating system to the state recorded in the initial state snapshot in step S3 includes: Suspend the execution of all processes within the operating system; Overwrite the memory data and CPU register states with the values recorded in the initial state snapshot; The state of processes and threads is reset based on the initial state snapshot; Restore the file system cache and disk data to the state recorded in the initial state snapshot; Restore the peripheral's interactive state to the initial configuration recorded in the initial state snapshot.
[0011] In one implementation, restoring the operating system to the state recorded in the initial state snapshot in step S3 further includes: After the recovery operation is completed, a consistency check is performed on all critical states; Recovery is confirmed to be complete only when the verification result matches the baseline of the initial state snapshot.
[0012] In one implementation, the generation speed of the initial state snapshot and the recovery speed of the operating system both reach the millisecond or microsecond level.
[0013] In one implementation, the generation of the initial state snapshot and the restoration of the operating system are achieved based on a copy-on-write mechanism and atomic verlay switching, which completes the disk state switching by operating only on metadata to avoid full data copying.
[0014] In one implementation, generating test cases includes: generating a random sequence of system calls, or mutating a seed sequence of system calls based on coverage feedback to obtain the test cases.
[0015] In one implementation, the generation and injection of the test cases are performed by the Syzkaller framework, and the test cases are variant test cases for specific system calls.
[0016] In one implementation, the method is based on a KVM virtualization environment, and the generation of an initial state snapshot and the restoration of the operating system to the state recorded in the initial state snapshot are performed by calling the KVM ICTL interface.
[0017] In one implementation, the method is based on a physical embedded device without a virtualization environment, and the generation of an initial state snapshot and the restoration of the operating system to the state recorded in the initial state snapshot are performed through a hardware debugging interface.
[0018] The beneficial effects of this application are as follows: 1) By capturing and restoring the complete system state, including memory data, register state, process information, file system state, and peripheral configuration, the state pollution caused by previous test cases is eliminated, ensuring that each test case is executed in a strictly consistent initial environment, thus fundamentally solving the test interference problem caused by incomplete state cleanup in existing solutions.
[0019] 2) By adopting a high-speed snapshot and recovery mechanism, the time overhead of state reset is compressed to the millisecond level. Compared with the tens of seconds to several minutes of time consumed by existing solutions that rely on system restart or script cleanup, the proportion of non-testing links in the overall test process is greatly reduced, and the throughput efficiency of fuzz testing is significantly improved.
[0020] 3) Since all test cases share the exact same initial execution environment, the vulnerability triggering conditions can be stably reproduced. The anomaly can be reproduced by repeatedly executing the same test case, effectively reducing the difficulty of defect location and root cause analysis.
[0021] 4) This method can be implemented in various operating environments through virtualization interfaces or hardware debugging interfaces, adapting to virtualization platforms, physical servers and embedded devices. It does not require writing customized cleanup logic for specific operating system versions or kernel configurations, and has good general deployment capabilities. Attached Figure Description
[0022] Figure 1 This is a flowchart illustrating one embodiment of the operating system fuzzing method based on high-speed snapshots and recovery according to this application; Figure 2 This is a flowchart illustrating the process of performing fuzz testing on the Linux kernel in a KVM virtualization environment in Embodiment 1 of this application; Figure 3 This is a flowchart illustrating the process of performing fuzz testing on an RT-Thread system in an embedded device, as described in Embodiment 2 of this application. Detailed Implementation
[0023] The technical solution of this application will be clearly and completely described below with reference to specific embodiments. However, those skilled in the art will understand that the embodiments described below are only some embodiments of this application, not all embodiments, and are only used to illustrate this application, and should not be regarded as limiting the scope of this application. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0024] Addressing the long-standing technical contradiction between state contamination and low reset efficiency in operating system kernel fuzzing, the applicant analyzed existing periodic reboots and manual cleanup solutions and found that the root cause lies in the dynamic nature of the operating system's runtime state and the hidden nature of state remnants. Manual cleanup only covers user-mode visible objects and cannot reach deeper states such as kernel data structures, processor registers, and peripheral queues; while system reboots can achieve a complete reset, the hardware self-test, kernel loading, and service initialization stages in the boot process inevitably introduce delays of seconds or even minutes, fundamentally conflicting with the high-frequency iterations required for fuzzing.
[0025] To resolve the trade-off between the integrity and speed of state reset, this application captures the complete system state at the moment the operating system completes environment initialization but before any test cases are executed, forming a definite and reproducible baseline. Before each subsequent round of test case execution, this baseline state is directly loaded into the system, replacing a "reboot" with "replay." This decouples state reset from the time-consuming initialization process, making the reset speed depend only on the read / write bandwidth of the state data, and no longer limited by the operating system's startup logic.
[0026] To avoid omissions caused by manual cleanup-style selective overwriting in determining the granularity of state capture, the capture scope must cover all bytes of memory, all processor registers, the process control block chain, file system metadata and cache, and the registers and queue configurations of peripheral interfaces, forming a complete encapsulation of the operating system runtime context. The state recovery process follows the reverse path of capture, performing atomic write-back on each subsystem, and avoiding full data migration through metadata operations such as copy-on-write and overlay switching, keeping the pause of a single recovery to the millisecond level.
[0027] This forms a closed testing process of "single snapshot after initialization - full state recovery before each test case - injection execution and recording - loop iteration", which eliminates the state propagation of previous test cases and compresses the reset time to the millisecond level, thus solving the technical contradiction between state consistency and throughput efficiency that has long existed in fuzz testing.
[0028] In one specific implementation, an operating system fuzzing method based on high-speed snapshots and recovery is provided. Its overall technical architecture mainly includes four core modules: snapshot generation module, snapshot storage module, snapshot recovery module, and test execution module.
[0029] The snapshot generation module is responsible for capturing and generating a complete snapshot of the target state of the operating system; the snapshot storage module is responsible for persistently storing and managing the generated snapshot data; the snapshot recovery module is responsible for using the stored snapshot to accurately restore the operating system to the corresponding state; and the test execution module is responsible for generating and injecting test cases and monitoring and recording the execution results of the operating system.
[0030] Reference Figure 1 As shown, the specific implementation process is as follows: S1. Start the target operating system and complete the environment initialization.
[0031] First, the target operating system is booted. The target operating system refers to the operating system kernel used as the test object in this fuzzing technique, such as the Linux kernel or a Windows Embedded system. The boot process is not merely about powering on and booting; rather, it involves automatically executing a series of operations according to the target operating system's standard boot procedure, including kernel image loading, kernel driver initialization, and the startup of predefined necessary system services. The goal is to move the target operating system out of an undefined or uncontrollable intermediate state and into a running state that can be precisely quantified and reproduced.
[0032] Secondly, complete the environment initialization. This aims to ensure that the target operating system reaches and maintains a stable initial state. A stable initial state means that no unplanned user processes are running on the system, and all kernel data structures and hardware configurations are at their default or preset baseline values. For example, apart from the kernel's own core daemons, there are no orphan processes left over from previous operations; there are no unwritten data blocks in the file system cache; and peripheral interface configurations are at power-on default parameters, not values modified during a test.
[0033] S2. Generate an initial state snapshot of the operating system after completing environment initialization, and store the initial state snapshot.
[0034] The snapshot generation module captures complete operating system state data through low-level interfaces. It calls pre-established low-level access interfaces to perform state capture on the target operating system in a stable initial state. The specific form of the low-level interface depends on the test environment; for example, in a virtualization environment, it could be a virtual machine introspection interface provided by the virtualization layer, while in a physical machine or embedded environment, it could be a dedicated hook module residing in the kernel.
[0035] To ensure the consistency of the captured state data, the capture operation includes an atomicity guarantee mechanism: at the instant the capture command is initiated, the execution of CPU instructions and input / output operations are paused or frozen, and all pending input / output transactions are forcibly refreshed and completed. Within this freeze window, the snapshot generation module fully reads and records all key data representing the instantaneous overall state of the operating system.
[0036] The scope of capturing complete state data is defined as follows: Memory data, encompassing all bytes of physical and virtual memory; Register status, encompassing the real-time values of all general-purpose registers and control registers of the central processing unit; Process and thread information, covering the identifiers, scheduling status, and complete context data of all processes in the system; File system status, including disk partition table structure, all file metadata attributes, and data to be written back in the relevant cache; Peripheral status, encompassing all device control registers and input / output port mapping data that interact with the hardware.
[0037] The captured complete state data is compressed and stored, and assigned a unique identifier. The snapshot generation module encapsulates the captured multi-dimensional state data into a single dataset and performs compression to reduce storage space usage. Subsequently, the snapshot generation module transmits the compressed snapshot data to the snapshot storage module for persistent storage. The snapshot storage module can be implemented as a local high-speed solid-state drive or a high-speed in-memory database to meet the performance requirements of high-frequency, fast reads. Upon completion of the storage operation, the snapshot storage module assigns a unique identifier to the generated initial state snapshot. This unique identifier is used to accurately index and retrieve the corresponding snapshot data in subsequent recovery processes, ensuring that the same initial state data is loaded for each recovery operation.
[0038] S3. Before executing each test case, read the initial state snapshot from storage and restore the operating system to the state recorded in the initial state snapshot.
[0039] First, before initiating the execution flow of each new test case, the test execution module sends a recovery request to the snapshot recovery module. Upon receiving the recovery request, the snapshot recovery module reads the compressed state data corresponding to the unique identifier of the initial state snapshot from the snapshot storage module, decompresses it, and reconstructs a complete state description dataset in memory. Subsequently, the snapshot recovery module calls the underlying recovery interface to perform reverse state restoration of the running target operating system based on the data of each dimension in the initial state snapshot. The restoration operation follows a strict sequential and atomicity guarantee mechanism, as follows: 1) Suspend the execution of all processes within the operating system. The snapshot recovery module sends control commands to the CPU scheduling unit through the low-level interface, forcibly suspending the instruction execution of all virtual CPUs or physical CPU cores. The suspension operation provides a contention-free safety window for subsequent memory overwriting and peripheral reset, avoiding inconsistencies in state caused by concurrent process execution.
[0040] 2) The snapshot recovery module overwrites the memory data and CPU register states with the values recorded in the initial snapshot. Page by page, the snapshot recovery module overwrites the data in the physical and virtual memory spaces with the memory byte data recorded in the initial snapshot. Simultaneously, the snapshot recovery module overwrites the values of all general-purpose registers and control registers of the CPU with the register state values recorded in the initial snapshot. This overwrite operation ensures that the CPU's instruction execution start point after recovery is perfectly aligned with the snapshot time.
[0041] 3) Reset the state of processes and threads based on the initial state snapshot. The snapshot recovery module traverses the list of process and thread information recorded in the initial snapshot, restoring the process identifier, scheduling priority, context data, and wait queue relationships within the corresponding process control block and thread control block in the operating system kernel to the values recorded in the initial snapshot. After the reset, all execution entities running in the system are completely consistent with the initial state snapshot in terms of quantity, attributes, and scheduling relationships.
[0042] 4) Restore the file system cache and disk data to the state recorded in the initial snapshot. The snapshot recovery module performs layered restoration for the file system: for persistent disk data, it uses a reverse rollback operation of the copy-on-write overlay or a direct data block overwrite operation to restore the disk partition table, file metadata, and file data content to their initial state; for the file system cache in memory, it forcibly replaces dirty data and metadata cache entries in the cache pages with the cache content recorded in the initial state snapshot. Through this operation, the disk view and cache view of the file system achieve a unified state consistent with the initial state snapshot time.
[0043] 5) Restore the peripheral's interactive state to the initial configuration recorded in the initial snapshot. The snapshot recovery module scans the peripheral state data in the initial snapshot record, and for virtualized input / output devices, peripheral component interconnect devices, etc., resets the corresponding device queues, device control register values, and hardware interface configuration parameters. The reset operation returns the peripheral from any possible intermediate interactive state to the ready state after power-on initialization.
[0044] Furthermore, in the final stage of the recovery operation, the snapshot recovery module performs a post-recovery consistency check. The snapshot recovery module performs integrity verification on the recovery results of all critical states. Verification methods include comparing the hash values of the recovered critical memory regions with the baseline hash values pre-stored in the initial state snapshot, or scanning the dirty bitmap to check for any incorrectly written-back state pages. Only when the verification results confirm that all critical states match the initial state snapshot baseline correctly does the snapshot recovery module determine that the single recovery operation has been successfully completed. After successful determination, the snapshot recovery module sends a ready signal to the test execution module, indicating that the target operating system has accurately returned to its initial state and new test cases can be safely injected.
[0045] S4. After the recovery is complete, generate test cases and inject the test cases into the operating system for execution.
[0046] After receiving the ready signal from the snapshot recovery module, the test execution module initiates the test case generation process. The ready signal indicates that the target operating system has accurately reverted to the baseline state recorded in the initial snapshot, meeting the safe conditions for injecting new test cases. The test execution module constructs test cases according to a preset generation strategy. The generation strategy includes a random generation strategy and a feedback-based mutation generation strategy. The random generation strategy refers to the test execution module randomly selecting system call numbers and randomly filling in parameters according to the system call interface specification to form a system call sequence. The feedback-based mutation generation strategy refers to the test execution module maintaining a global coverage bitmap, selecting seeds covering new code paths from the seed corpus based on the coverage feedback information updated after the execution of previous test cases, and performing mutation operations on the system call parameters or call order of the seeds to generate a derived system call sequence. The generated test cases are morphologically represented as an ordered sequence of system calls, such as the sequential combination of "open file operation call, write file operation call, input / output control operation call", constituting a complete test load.
[0047] The test execution module injects the constructed system call sequence into the target operating system, which has been restored to its initial state. The injection path can be chosen differently depending on the test environment and the characteristics of the target operating system. One injection method involves using a proxy program running in the user space of the target operating system to execute each call instruction in the system call sequence sequentially, simulating the process of a user-space process initiating a service request to the kernel. Another injection method involves using an injection module residing in kernel space within the test framework to bypass the user-space interface and directly submit the system calls to the kernel's entry point processing function. After the injection operation is complete, the target operating system executes the injected system call sequence according to the standard kernel processing flow, with each kernel submodule responding to and processing each call request sequentially.
[0048] The test execution module initiates real-time monitoring of the target operating system's execution process while injecting test cases. The monitoring scope covers kernel output responses, scheduling behavior, and abnormal signals. Through pre-defined monitoring probes or kernel log interfaces, the test execution module captures all observable behavioral information generated during the execution of test cases by the operating system, which is then used for subsequent steps to determine execution results and identify vulnerabilities.
[0049] S5. Record the execution results of the test cases.
[0050] The test execution module obtains the operating system execution process information monitored in step S4 and judges the execution results of the test cases. The judgment is based on whether the operating system exhibits abnormal behavior during the execution of the test cases. Abnormal behavior includes: the operating system crashes and stops responding, the kernel triggers a panic and outputs call stack dump information, and abnormal signals are generated that are not caught by the operating system's error handling mechanism.
[0051] If the operating system exhibits any of the above-mentioned abnormal behaviors, the test execution module marks the test case execution result as a vulnerability-triggered state. Specifically, the test case processing flow for the vulnerability-triggered state includes: storing the test case that triggers the vulnerability in the seed corpus, prioritizing its addition to the test queue as a high-value seed for subsequent mutation generation; updating the global code coverage bitmap, recording the kernel code path information covered by this test case, and using a feedback map to guide the generation direction of subsequent test cases; recording crash-related on-site information, comprehensively collecting and persistently storing test case details, real-time CPU register values, and memory snapshots at the time of vulnerability triggering, providing complete data support for subsequent vulnerability analysis and localization.
[0052] If the operating system is determined not to exhibit any abnormal behavior (i.e., the execution process terminates normally or returns the expected error code), the test execution module marks the test case execution result as "no abnormality." For test cases with no abnormality, the test execution module discards them, neither retaining them in the seed corpus nor triggering deep logging of debugging information.
[0053] Furthermore, the test execution module uses the latest feedback information to guide seed selection and mutation operations for the next test cycle. The module reads the updated global coverage bitmap, evaluates the contribution of various sub-elements in the current seed corpus to code coverage, and prioritizes seeds that can cover new code paths or trigger new kernel states. For the selected seeds, the module performs parameter mutation or sequence structure mutation operations to generate test cases for the next round.
[0054] The test execution module repeatedly executes steps S3 to S5, which is a closed-loop iteration consisting of snapshot restoration, test case generation and injection execution, and execution result recording and feedback processing. The loop terminates when either of the following two conditions is met: the cumulative number of executed test cases reaches a preset threshold; or a manual termination command is received from an external source.
[0055] In some embodiments, the time required to generate the initial state snapshot and the time required to restore the operating system to the state recorded in the initial state snapshot are both on the order of milliseconds or microseconds. The technical means to achieve millisecond or microsecond-level snapshot generation and restoration speeds lies in combining a copy-on-write mechanism with atomic overlay switching. Specifically, for disk state snapshot generation and restoration operations, a full copy of physical data blocks is not performed; instead, the logical state is instantly switched by modifying the metadata pointer. During snapshot generation, the original disk state is marked as the read-only base layer, and new write operations are redirected to the copy-on-write differential layer. During restoration, the differential layer data is instantly discarded through the atomic rollback operation of the overlay, causing the disk state pointer to point back to the base layer. The time overhead of metadata operations is far lower than that of a full data copy, thereby compressing the pause window for state capture and restoration to within milliseconds or even microseconds.
[0056] In some embodiments, the test cases are further variant test cases targeting specific system calls. A specific system call refers to a system call interface selected as a single test target during fuzzing, such as a dedicated system call targeting the i_uring subsystem, mutex lock operation interface, or network protocol stack entry function. Variant test cases targeting specific system calls centrally apply abnormal values such as boundary values, null pointers, and excessively large buffer addresses in parameter construction to selectively trigger the internal error handling path of the target system call.
[0057] In some embodiments, the technical solution of this application is implemented based on a kernel virtual machine virtualization environment. The operations of generating an initial state snapshot and restoring the operating system to the state recorded in the initial state snapshot are executed by calling the kernel virtual machine's input / output control interface. The snapshot generation module calls the snapshot creation instructions in the input / output control interface to atomically capture the virtual machine memory pages, CPU register states, and disk metadata in kernel mode. The snapshot recovery module calls the snapshot recovery instructions in the input / output control interface to reverse-overwrite the aforementioned state data onto the running virtual machine. The kernel virtual machine's input / output control interface provides low-level access to the full state of the virtualization guest, supporting snapshot generation and recovery operations to be completed at the virtual machine manager level in a high-privilege, guest-free manner.
[0058] In other embodiments, the technical solution of this application is implemented on a physical embedded device without a virtualization environment. The operations of generating an initial state snapshot and restoring the operating system to the state recorded in the initial state snapshot are executed through a hardware debugging interface. The hardware debugging interface includes, but is not limited to, a Joint Test Action Group (JTA) debugging interface or a serial line debugging interface. The snapshot generation module sends a state read instruction to the target chip through the hardware debugging interface, directly reading all bytes of data from the static random access memory (SRAM), all register values of the central processing unit (CPU), and the status of peripheral configuration registers, and encapsulating this into an initial state snapshot. The snapshot recovery module sends a reset signal to the target chip through the hardware debugging interface, and then writes the stored data, register values, and peripheral configuration records from the initial state snapshot byte-by-byte to the corresponding physical address. Through the hardware debugging interface, the solution of this application achieves complete system state capture and accurate recovery even on physical devices lacking virtualization layer support.
[0059] Example 1 This embodiment performs fuzz testing on the Linux kernel in a KVM virtualization environment, utilizing KVM's virtualization interface to achieve high-speed snapshots and recovery, referring to... Figure 2 As shown, the specific steps are as follows: 1. Initial snapshot generation Start the Linux 5.4 kernel in the KVM virtual machine, execute systemd to complete system initialization, and ensure that no additional processes are running; The snapshot generation module calls KVM's ICTL interface KVM_SNAPSHT_CREATE, specifies the snapshot type as "external snapshot" (only records the differences from the base image), and captures the virtual machine's memory, CPU status, and disk metadata; The characteristic of millisecond or microsecond-level snapshot generation lies in the combination of copy-on-write (CW) and atomic verlaypivt, which completes disk state switching only through metadata operations without any data copying. The KVM module's ictl interface KVM_SNAPSHT_CREATE is called to atomically capture the states of memory, registers, file systems, and peripherals in kernel mode. Combined with minimizing the bdrv_drain freeze window, the capture pause is strictly controlled within milliseconds.
[0060] The generated snapshot file (approximately 2GB, compressed to 500MB) is stored on the host's high-speed SSD and named "init_snapsht_001".
[0061] 2. Snapshot recovery process: Before each test case is executed, the snapshot recovery module calls the KVM_SNAPSHT_RESTRE interface to load "init_snapsht_001"; The KVM hypervisor first pauses the execution of the virtual machine VCPU, then overwrites the memory data and CPU register values with the values recorded in the snapshot, and restores the disk metadata to its initial state. The recovery process takes about 80 milliseconds (far less than the 30 seconds of a system reboot). Once completed, the Linux system state inside the virtual machine is completely consistent with that after initialization (e.g., the process list only contains basic processes such as systemd).
[0062] 3. Test Execution and Results: The test execution module uses the Syzkaller framework to generate variant test cases (including abnormal parameters, such as oversized buffer addresses) for the sys_i_uring system call. After executing the test case in the virtual machine, a kernel panic (Kernel panic - nt syncing:Attempted t kill init!) was detected, triggering the vulnerability; The vulnerability was recorded along with the kernel stack information at the time of the crash. By repeatedly executing the same test case (with a snapshot restored before each execution), the vulnerability could be reliably reproduced, and it was eventually identified as a buffer overflow vulnerability in the i_uring module.
[0063] Example 2 This embodiment targets the RT-Thread system (without virtualization environment) in an embedded device, implementing snapshot and recovery through a hardware debugging interface, referencing... Figure 3 As shown, the specific steps are as follows: 1. Initial snapshot generation: The RT-Thread system is programmed onto the ARM Crtex-M4 chip. After startup, it completes the initialization of peripherals such as UART and SPI and enters the ready state. The snapshot generation module reads all register values, SRAM data (512KB), and Flash configuration information of the chip through the JTAG debug interface to generate an initial snapshot (stored as a binary file). The snapshot contains key information such as RT-Thread's thread control block, semaphore state, and peripheral register configuration, and takes about 200 milliseconds to generate.
[0064] 2. Snapshot recovery process: Before each test, the snapshot recovery module sends a reset signal to the chip via the JTAG interface, and then writes the initial snapshot data into the SRAM, registers and peripheral configuration. After recovery, the thread state and peripheral connections of the RT-Thread system are consistent with the initial state (e.g., the UART baud rate remains at 9600, and there are no unprocessed interrupts), and the recovery takes about 150 milliseconds.
[0065] 3. Test Execution and Results: The test execution module generates test cases for the rt_mutex_take system call (such as passing a null pointer and repeatedly releasing a mutex that has already been released). After injecting the test case, a deadlock was detected in the system (thread scheduling stalled). By restoring the snapshot and repeating the test case, the deadlock was confirmed to be reproducible stably. The issue was ultimately identified as a flaw in the error handling logic of the RT-Thread mutex module under a null pointer parameter.
[0066] Although the embodiments of this application have been described above in conjunction with the accompanying drawings, this application is not limited to the specific embodiments and application fields described above. The specific embodiments described above are merely illustrative and instructive, not restrictive. Those skilled in the art can make many other forms based on the guidance of this specification and without departing from the scope of protection of the claims of this application, and these are all within the scope of protection of this application.
Claims
1. A high-speed snapshot and recovery based operating system fuzzing method, characterized in that, Includes the following steps: S1. Start the target operating system and complete environment initialization; S2. Generate an initial state snapshot of the operating system after completing environment initialization, and store the initial state snapshot; S3. Before executing each test case, read the initial state snapshot from storage and restore the operating system to the state recorded in the initial state snapshot; S4. After the recovery is complete, generate test cases and inject the test cases into the operating system for execution; S5. Record the execution results of the test cases.
2. The high-speed snapshot and recovery based operating system fuzz testing method of claim 1, wherein, Step S2, which generates an initial state snapshot of the operating system after completing environment initialization, includes: The system captures complete state data of the operating system through the underlying interface. The complete state data includes memory data, CPU register status, process / thread information, file system status, and peripheral device status. The captured complete state data is compressed and stored, and assigned a unique identifier.
3. The high-speed snapshot and recovery based operating system fuzz testing method of claim 1, wherein, Step S3, restoring the operating system to the state recorded in the initial state snapshot, includes: Suspend the execution of all processes within the operating system; Overwrite the memory data and CPU register states with the values recorded in the initial state snapshot; The state of processes and threads is reset based on the initial state snapshot; Restore the file system cache and disk data to the state recorded in the initial state snapshot; Restore the peripheral's interactive state to the initial configuration recorded in the initial state snapshot.
4. The high-speed snapshot and recovery based operating system fuzz testing method of claim 1 or 3, wherein, Step S3, restoring the operating system to the state recorded in the initial state snapshot, further includes: After the recovery operation is completed, a consistency check is performed on all critical states; Recovery is confirmed to be complete only when the verification result matches the baseline of the initial state snapshot.
5. The operating system fuzzing method based on high-speed snapshots and recovery according to claim 1, characterized in that, The generation speed of the initial state snapshot and the recovery speed of the operating system both reach the millisecond or microsecond level.
6. The high-speed snapshot and recovery based operating system fuzz testing method of claim 1, wherein, The generation of the initial state snapshot and the restoration of the operating system are based on the copy-on-write mechanism and atomic verlay switching. The disk state switching is completed by operating only on metadata to avoid full data copying.
7. The high-speed snapshot and recovery based operating system fuzz testing method of claim 1, wherein, The generation of test cases includes: generating a random system call sequence, or mutating a seed system call sequence based on coverage feedback to obtain the test cases.
8. The high-speed snapshot and recovery based operating system fuzz testing method of claim 1, wherein, The generation and injection of the test cases are performed by the Syzkaller framework, and the test cases are variant test cases for specific system calls.
9. The high-speed snapshot and recovery based operating system fuzz testing method of claim 1, wherein, The method is implemented based on the KVM virtualization environment. The generation of the initial state snapshot and the restoration of the operating system to the state recorded in the initial state snapshot are executed by calling the KVM ICTL interface.
10. The high-speed snapshot and recovery based operating system fuzz testing method of claim 1, wherein, The method is implemented on a physical embedded device without a virtualization environment. The generation of the initial state snapshot and the restoration of the operating system to the state recorded in the initial state snapshot are executed through a hardware debugging interface.