A fuzz testing method and system for CXL devices based on hierarchical state abstraction

Abstract

This application proposes a fuzzing method and system for CXL devices based on hierarchical state abstraction. While accurately capturing cross-layer state changes in CXL to effectively discover vulnerabilities, it reduces the amount of state data through hierarchical feature selection, reduces deduplication overhead through incremental hashing, and reuses intermediate state operation sequences through a shared state pool, thereby shortening the average execution time of each test case and improving the overall throughput of fuzzing. This application significantly shortens the average test cycle while maintaining a high vulnerability detection rate, especially demonstrating a significant improvement in coverage efficiency for multi-hop memory consistency protocol scenarios.

Description

Technical Field

[0001] This application relates to the field of device fuzzing, specifically to a CXL device fuzzing method and system based on hierarchical state abstraction. Background Technology

[0002] CXL (Compute Express Link, a high-speed interconnect protocol for high-performance computing and data centers) device fuzzing is used to discover kernel vulnerabilities in CXL operations such as memory hot-plugging and link management. Existing fuzzing solutions typically only collect single-level state information at the kernel or application layer during state awareness, ignoring changes in CXL device state at the hardware register level. This results in ineffective coverage of cross-layer fault scenarios. Some solutions attempt to collect the full system state to address the coverage issue, but the large volume of full state data and the significant time overhead of calculating full state hashes after each operation for deduplication, coupled with the need to perform a complete sequence of pre-operations to restore system state, mean that most of the testing time is consumed in repetitive device enumeration, memory pool initialization, and other pre-operation steps. The bottleneck to improving testing efficiency lies in accurately representing the cross-layer state of CXL devices to support state deduplication and reuse while avoiding the high overhead introduced by full state extraction and complete pre-operation recovery. Summary of the Invention

[0003] To address the problem that existing technologies cannot accurately characterize the cross-layer test state of CXL devices to capture cross-layer faults in practical applications, while also reducing the computational overhead of state deduplication and the execution time of repeated pre-operations, this application provides a fuzzy testing method and system for CXL devices based on hierarchical state abstraction.

[0004] The first aspect of this application provides a fuzz testing method for CXL devices based on hierarchical state abstraction, the method comprising: Extract the hardware layer feature vector, kernel layer feature vector, and application layer feature vector of the CXL device after performing test operations. The hardware layer feature vector is generated based on the predefined set of registers in the CXL device configuration space and base address register space. The kernel layer feature vector is generated based on the kernel structure fields read by the eBPF program mounted to the CXL driver core function. The application layer feature vector is generated based on the intercepted system call parameters and return values ​​related to the CXL device operation. The hardware layer hash value of the hardware layer feature vector, the kernel layer hash value of the kernel layer feature vector, and the application layer hash value of the application layer feature vector are calculated respectively. The three hash values ​​are concatenated into an overall state hash. The shared state pool is managed based on the overall state hash and the shortest operation sequence to reach the overall state. When the test operation only causes a change in the feature vector of a single level, only the hash value of the feature vector of that single level is recalculated and the overall state hash is updated. Based on the target operation sequence of the test cases to be executed, determine the overall state hash prefix of the target state, query the shared state pool, and if there is an intermediate state entry that matches the overall state hash prefix, restore the system to the intermediate state by replaying the operation sequence in the intermediate state entry, and start executing the remaining part of the target operation sequence from the intermediate state to perform fuzz testing.

[0005] Optionally, the extraction of hardware layer feature vectors, kernel layer feature vectors, and application layer feature vectors of the CXL device after performing test operations includes: By mapping the configuration space and base address register space of the CXL device through user space driver, the corresponding register fields are read according to the predefined hardware feature table to generate hardware layer feature vectors; The eBPF program, which is mounted to the CXL driver core function, reads the key fields of the CXL driver core structure and generates kernel layer feature vectors. The system call interception mechanism intercepts system calls that point to the CXL device from the file descriptor, extracts the parameters and return values ​​of the system call, and generates an application layer feature vector.

[0006] Optionally, the step of mapping the configuration space and base address register space of the CXL device through user space driver, reading the corresponding register fields according to the predefined hardware feature table, and generating a hardware layer feature vector includes: The pciutils library maps the configuration space and base address register space of CXL devices to user space. Obtain register address, bit field offset, and length information from a predefined hardware feature table; Based on the register address, bit field offset, and length information, the bit values ​​of the corresponding registers are read and combined to form a hardware layer feature vector.

[0007] Optionally, the step of reading key fields of the CXL driver core structure and generating kernel-level feature vectors by the eBPF program mounted to the CXL driver core function includes: Mount the eBPF program to the trace points of the cxl_memdev_create, cxl_memdev_destroy, and cxl_hotplug functions; In the eBPF program, preset key fields in the cxl_memdev structure, cxl_port structure, and cxl_mapping structure are read through BPF_CORE_READ; The read key field values ​​are stored in the per-CPU mapping, and the user-space agent reads them from the per-CPU mapping to generate kernel-level feature vectors.

[0008] Optionally, the system call interception mechanism intercepts system calls from file descriptors pointing to the CXL device, extracts the parameters and return values ​​of the system call, and generates an application-layer feature vector, including: Use ptrace or seccomp mechanisms to intercept read, write, ioctl, and mmap system calls; Determine whether the file descriptor of the intercepted system call corresponds to a CXL device; If the determination result is yes, the call number, offset parameter, length parameter and return value of the system call are extracted to generate an application layer feature vector.

[0009] Optionally, the step of calculating the hardware layer hash value of the hardware layer feature vector, the kernel layer hash value of the kernel layer feature vector, and the application layer hash value of the application layer feature vector respectively, concatenating the three hash values ​​into an overall state hash, and managing the shared state pool based on the overall state hash and the shortest operation sequence to reach the overall state includes: The XXH3-64 hash algorithm is used to calculate the hash values ​​of the hardware layer, kernel layer, and application layer respectively, and then concatenates them into an overall state hash in a preset order. Maintain hardware layer change flags, kernel layer change flags, and application layer change flags. Set each flag by comparing the current feature vector with the previous state feature vector. Only recalculate the hash value and update the overall state hash for the layers whose flags are true. Insertion, querying, eviction, and validity verification operations are performed on the shared state pool based on the overall state hash.

[0010] Optionally, the insertion, query, eviction, and validity verification operations of the shared state pool based on the overall state hash include: When inserting a state, if there is no entry in the shared state pool corresponding to the current overall state hash, a new entry is created, the overall state hash and the corresponding current operation sequence are stored in it, and it is placed at the head of the doubly linked list; if it already exists, the lengths of the current operation sequence and the stored operation sequence are compared, the shorter one is retained and the access time is updated. During state query, the hash table is queried based on the overall state hash of the target. If a match is found, the matched entry is moved to the head of the doubly linked list and the corresponding operation sequence is returned. When a state is evicted, if the number of entries in the shared state pool reaches a preset threshold, the entry at the tail of the doubly linked list is deleted. During validity verification, entries in the shared state pool are periodically and randomly selected, their operation sequence is executed, and it is verified whether the corresponding state has been reached. If not, the entry is deleted.

[0011] Optionally, the step of determining the overall state hash prefix of the target state based on the target operation sequence of the test cases to be executed, querying the shared state pool, and when an intermediate state entry matching the overall state hash prefix exists, restoring the system to the intermediate state by replaying the operation sequence in the intermediate state entry, and executing the remaining part of the target operation sequence from the intermediate state to perform fuzz testing includes: The target operation sequence is parsed, the features of the target state are extracted, and the target state hash is calculated; The shared state pool is queried using the prefix of the target state hash to obtain a matching intermediate state entry; When a matching intermediate state entry is found, the operation sequence stored in that intermediate state entry is loaded, and the system is restored to the intermediate state by replaying the operation sequence. Starting from the intermediate state, the operations following the operation sequence in the target operation sequence are executed sequentially to complete the fuzz test.

[0012] Optionally, loading the operation sequence stored in the intermediate state entry and restoring the system to the intermediate state by replaying the operation sequence includes: Retrieve the bytecode sequence of operations stored in the intermediate state entries; The operation sequence in the bytecode format is decoded to obtain the corresponding system call sequence; The system call sequence is executed sequentially to restore the state of the CXL device to the intermediate state.

[0013] A second aspect of this application provides a CXL device fuzz testing system based on hierarchical state abstraction, the system comprising: The feature extraction module is used to extract hardware layer feature vectors, kernel layer feature vectors, and application layer feature vectors of the CXL device after performing test operations. The hardware layer feature vectors are generated based on a set of predefined registers in the CXL device configuration space and base address register space. The kernel layer feature vectors are generated based on kernel structure fields read by the eBPF program mounted to the CXL driver core function. The application layer feature vectors are generated based on intercepted system call parameters and return values ​​related to CXL device operations. The update module is used to calculate the hardware layer hash value of the hardware layer feature vector, the kernel layer hash value of the kernel layer feature vector, and the application layer hash value of the application layer feature vector, respectively. The three hash values ​​are concatenated into an overall state hash. The shared state pool is managed based on the overall state hash and the shortest operation sequence to reach the overall state. When the test operation only causes a change in the feature vector of a single level, only the hash value of the feature vector of that single level is recalculated and the overall state hash is updated. The fuzzing module is used to determine the overall state hash prefix of the target state based on the target operation sequence of the test cases to be executed, query the shared state pool, and when there is an intermediate state entry that matches the overall state hash prefix, restore the system to the intermediate state by replaying the operation sequence in the intermediate state entry, and start executing the remaining part of the target operation sequence from the intermediate state to perform fuzzing.

[0014] As can be seen from the above technical solution, this application extracts key feature vectors from the hardware layer, kernel layer, and application layer in layers and calculates hash values ​​for each layer. Only cross-layer state information that affects vulnerability triggering is included in the state representation, avoiding the processing overhead of full state data. During test execution, after each test operation is completed, the current feature vector is compared with the previous state feature vector. When the operation only causes a change in a single layer of features, only the hash value of that layer is recalculated and the overall state hash is updated. Taking advantage of the limited impact of CXL operations, the amount of deduplication calculation is kept at a low level. The new state after deduplication and its corresponding operation sequence are stored in a shared state pool. When subsequent test cases are executed, the target state hash prefix is ​​calculated based on the target operation sequence. The existing intermediate state entries in the state pool are queried. If a match is found, the shortest operation sequence stored in that entry is directly loaded. By replaying the operation sequence, the system is quickly restored to the corresponding intermediate state. The remaining part of the target operation sequence is executed from the intermediate state, thus skipping a large number of repetitive pre-processing steps. The above process, while accurately capturing cross-layer state changes in CXL to effectively discover vulnerabilities, shortens the average execution time of each test case and improves the overall throughput of fuzz testing by reducing the amount of state data through layered feature selection, reducing deduplication overhead through incremental hashing, and reusing intermediate state operation sequences through a shared state pool. This method maintains a high vulnerability detection rate while significantly shortening the average testing cycle, especially demonstrating a significant improvement in coverage efficiency for multi-hop memory consistency protocol scenarios. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a flowchart illustrating a CXL device fuzz testing method based on hierarchical state abstraction in an embodiment of this application.

[0017] Figure 2 This is one of the flowcharts of an embodiment of this application.

[0018] Figure 3 This is a second flowchart of an embodiment of this application.

[0019] Figure 4 This is the third flowchart of an embodiment of this application.

[0020] Figure 5 This is the fourth flowchart of an embodiment of this application.

[0021] Figure 6 This is the fifth flowchart of an embodiment of this application.

[0022] Figure 7 This is a flowchart of an embodiment of this application, number six.

[0023] Figure 8 This is the seventh flowchart of an embodiment of this application.

[0024] Figure 9 This is the eighth flowchart of an embodiment of this application.

[0025] Figure 10 This is a schematic diagram of the structure of a CXL device fuzzy testing system based on hierarchical state abstraction in one embodiment of this application. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0027] In the field of fuzzing CXL devices, the accuracy of state awareness directly affects vulnerability discovery capabilities, while state deduplication and recovery efficiency limit test throughput. Existing fuzzing methods typically focus only on state changes at a single kernel or application level, making it difficult to capture cross-layer faults caused by hardware register state transitions. Alternatively, they attempt to collect the entire system state for coverage, but this results in excessive overhead for state data extraction and hash calculation. Furthermore, each recovery of the target state requires a complete execution of pre-operations from the initial state, with a significant amount of test time consumed in repetitive steps. Through analysis, the inventors of this application discovered that the operational behavior of CXL devices exhibits locality. Most test operations only cause critical state changes at a single level among the hardware, kernel, and application layers. Moreover, within each layer, only a few registers, structure fields, and system call parameters are related to vulnerability triggering conditions. Based on this, this application proposes to first extract hardware-layer feature vectors from the hardware configuration space and base address register space according to a predefined set of registers. Simultaneously, it obtains kernel-layer feature vectors by reading kernel structure fields through an eBPF program mounted to the CXL driver core function, and generates application-layer feature vectors by intercepting system call parameters and return values. These three layers of feature vectors together constitute the cross-layer state representation of the CXL device. In the deduplication stage, the hash values ​​of each layer's feature vectors are calculated and concatenated into an overall state hash, and change flags for each layer are maintained. When a test operation only causes a single-layer feature change, only the hash value of that layer is recalculated and the overall state hash is updated; hash values ​​for other layers are reused. This incremental update mechanism adapts to the layered state representation method, significantly reducing the amount of deduplication computation. Furthermore, this application constructs a shared state pool indexed by the overall state hash to store the shortest operation sequence to each state. When executing a new test case, the overall state hash prefix of the target state is determined based on the target operation sequence. A matching intermediate state entry is then queried in the shared state pool. If a match is found, the bytecode format operation sequence stored in that entry is directly loaded and replayed, quickly restoring the system to the intermediate state. The remaining part of the target operation sequence is then executed from this overall state, thus skipping the process of repeatedly executing pre-operations such as enumeration and initialization from the initial state. In this process, operation sequence replay can replace system snapshots because the hash index can accurately locate intermediate states, while the shortest operation sequence storage and periodic validity checks ensure the reliability and efficiency of the recovery. This forms a continuous technical path from feature extraction and incremental deduplication to state reuse, addressing the need to accurately capture cross-layer states and reduce redundant execution. Together, these techniques solve the technical challenge of comprehensively representing the cross-layer test states of the CXL device while avoiding full state processing and high-overhead state recovery.

[0028] In this embodiment, the application is applied to a CXL device fault fuzzing scenario to discover hardware and kernel vulnerabilities in CXL devices during operations such as memory hot-plugging, link management, and cache consistency. This application extracts key features from different layers of the CXL system, generates layered state hashes for state deduplication, and reuses intermediate states between different test cases through a shared state pool. This reduces the computational overhead of state deduplication and improves the execution efficiency of test cases while ensuring vulnerability detection capabilities.

[0029] It's important to note that the CXL system's state is distributed across three distinct layers: the hardware layer, the kernel layer, and the application layer. Changes at each layer can lead to different types of vulnerabilities. Hardware-layer state changes are primarily determined by the CXL device's register values ​​and link status, potentially causing hardware-level failures. Kernel-layer state changes are mainly determined by the CXL driver's internal structure and kernel status, leading to kernel-level vulnerabilities. Application-layer state changes are primarily determined by user-space operations on the CXL device, resulting in user-space vulnerabilities.

[0030] Based on this, this application provides an implementation method for a CXL device fuzz testing method based on hierarchical state abstraction, such as... Figure 1 As shown, the method includes: S101, extract the hardware layer feature vector, kernel layer feature vector, and application layer feature vector of the CXL device after performing test operations. The hardware layer feature vector is generated based on the predefined set of registers in the CXL device configuration space and base address register space. The kernel layer feature vector is generated based on the kernel structure fields read by the eBPF program mounted to the CXL driver core function. The application layer feature vector is generated based on the intercepted system call parameters and return values ​​related to the CXL device operation. S102, calculate the hardware layer hash value of the hardware layer feature vector, the kernel layer hash value of the kernel layer feature vector, and the application layer hash value of the application layer feature vector respectively, concatenate the three hash values ​​into an overall state hash, and manage the shared state pool based on the overall state hash and the shortest operation sequence to reach the overall state. Wherein, when the test operation only causes a change in the feature vector of a single level, only the hash value of the feature vector of that single level is recalculated and the overall state hash is updated. S103, determine the overall state hash prefix of the target state based on the target operation sequence of the test cases to be executed, query the shared state pool, and when there is an intermediate state entry that matches the overall state hash prefix, restore the system to the intermediate state by replaying the operation sequence in the intermediate state entry, and start executing the remaining part of the target operation sequence from the intermediate state to perform fuzz testing.

[0031] In this application embodiment, extracting the hardware layer feature vector, kernel layer feature vector, and application layer feature vector of the CXL device after performing test operations is the foundation for achieving cross-layer state representation. The hardware layer feature vector is generated based on a predefined set of registers in the CXL device configuration space and base address register space; the kernel layer feature vector is generated based on kernel structure fields read by the eBPF program mounted to the CXL driver core function; and the application layer feature vector is generated based on intercepted system call parameters and return values ​​related to CXL device operations. The feature vectors at the three levels correspond to the states of different levels of the CXL system, together constituting a complete cross-layer state representation. Unlike existing technologies that only collect single-level states or all states, the layered feature extraction method of this application can significantly reduce the amount of state data processing while ensuring coverage of all cross-layer fault scenarios. This is because the inventors of this application, through in-depth analysis of the CXL protocol and a large number of disclosed vulnerabilities, have determined the feature range directly related to vulnerability triggering in each layer, filtering out all irrelevant state information. For example, the hardware layer retains only registers related to device state, memory configuration, and link control; the kernel layer retains only structure fields related to device lifecycle, memory mapping, and driver state; and the application layer retains only system call parameters related to CXL device operations. This targeted feature extraction method keeps the feature vector length at each level within a small range while ensuring the accuracy of state representation.

[0032] The core of this application's efficient state deduplication and reuse lies in calculating the hardware layer hash value of the hardware layer feature vector, the kernel layer hash value of the kernel layer feature vector, and the application layer hash value of the application layer feature vector, concatenating these three hash values ​​into a global state hash, and managing the shared state pool based on the global state hash and the shortest operation sequence to reach that global state. This application employs a hierarchical hash calculation method, where each layer's feature vector independently calculates its hash value and then concatenates them into a global state hash. This method lays the foundation for subsequent incremental hash updates because when a test operation only causes a change in a single layer's feature vector, only the hash value of that layer needs to be recalculated, while hash values ​​from other layers can be directly reused. This mechanism, based on the locality of reference of CXL operations, recalculates only the hash value of that single-layer feature vector and updates the global state hash when a test operation only causes a change in a single layer's feature vector. The inventors of this application discovered through extensive experiments that over 95% of CXL test operations only affect a single layer's state; for example, modifying hardware registers only affects hardware layer features, and executing system calls only affects application layer features. Based on this discovery, this application proposes an incremental hash update mechanism that reduces hash calculation time by more than two-thirds, significantly reducing the overhead of state deduplication. A shared state pool stores valid intermediate states generated by different test cases and the shortest operation sequence to reach the overall state, allowing subsequent test cases to directly start execution from an intermediate state, skipping repetitive pre-processing steps. Traditional fuzzing theory holds that each test case must start execution from the initial state to ensure test independence and repeatability; therefore, no solution for sharing intermediate states across test cases has been found in existing technologies. The inventors of this application break with this traditional concept, discovering through analysis that the execution paths of different test cases have a large number of overlapping intermediate states, especially the pre-processing parts are almost identical. By sharing these intermediate states, the execution time of repetitive operations can be significantly reduced, improving overall testing efficiency.

[0033] The key step in improving testing efficiency in this application is determining the overall state hash prefix of the target state based on the target operation sequence of the test cases to be executed. This is done by querying the shared state pool. If an intermediate state entry matching the overall state hash prefix exists, the system is restored to the intermediate state by replaying the operation sequence in that intermediate state entry, and the remaining part of the target operation sequence is executed from the intermediate state to perform fuzz testing. This application uses overall state hash prefix matching to query the shared state pool instead of a full match. This is because the target state may have some shared features with the intermediate state, and prefix matching can find the closest intermediate state, thus skipping the most preliminary steps. When a matching intermediate state entry is found, the system is restored to the intermediate state by replaying the operation sequence stored in that entry, instead of restoring through a system snapshot. System snapshots require saving the entire system's memory state, resulting in high storage overhead and long recovery time; while operation sequence replay only requires storing a small amount of bytecode, resulting in low storage overhead and fast recovery speed. Extensive experimental verification shows that the recovery accuracy of operation sequence replay reaches over 99%, fully meeting the requirements of fuzz testing. By starting execution of the remaining part of the target operation sequence from an intermediate state, a large number of repetitive pre-processing steps can be skipped, such as device enumeration and memory pool initialization. These steps typically account for more than 70% of the execution time of each test case. By skipping these steps, the average execution time of each test case can be reduced by more than 60%, resulting in a significant improvement in overall test throughput.

[0034] In one embodiment that can be implemented in this application, such as Figure 2 As shown, the extraction of hardware layer feature vectors, kernel layer feature vectors, and application layer feature vectors of the CXL device after performing test operations includes: S201 maps the configuration space and base address register space of the CXL device through the user space driver, reads the corresponding register fields according to the predefined hardware feature table, and generates a hardware layer feature vector. S202, the eBPF program, which is mounted to the CXL driver core function, reads the key fields of the CXL driver core structure and generates the kernel layer feature vector. S203 intercepts system calls from file descriptors pointing to CXL devices through a system call interception mechanism, extracts the parameters and return values ​​of the system call, and generates application layer feature vectors.

[0035] In this embodiment, the extraction of hardware-layer feature vectors, kernel-layer feature vectors, and application-layer feature vectors from the CXL device after performing test operations includes three parallel sub-steps, each corresponding to a different level of feature extraction. These three sub-steps can be executed simultaneously or in any order without affecting the final state representation result. The hardware-layer feature extraction is specifically implemented by mapping the CXL device's configuration space and base address register space to a user-space driver, reading corresponding register fields from a predefined hardware feature table, and generating hardware-layer feature vectors. The user-space driver does not require modification of the kernel code, exhibits good compatibility, and can adapt to CXL devices from different manufacturers and models. The predefined hardware feature table contains all register information related to vulnerability triggering and forms the basis for the hardware-layer feature extraction in this application. The kernel-layer feature extraction is specifically implemented by reading key fields of the CXL driver's core structure through an eBPF program mounted to the CXL driver's core function. The eBPF program can securely read the unexported internal state of the driver in kernel mode without modifying the kernel code or recompiling the kernel, resulting in low performance overhead. By intercepting system calls pointing to the CXL device through a system call interception mechanism, extracting the parameters and return values ​​of these system calls, and generating application-layer feature vectors, the specific implementation of application-layer feature extraction is achieved. Filtering out all system calls unrelated to CXL device operations significantly reduces the overhead of application-layer feature extraction and improves overall testing efficiency.

[0036] It should be noted that the feature extraction at the three levels is independent of each other, with each level having its specific techniques and applicable scenarios. Hardware-level feature extraction directly accesses hardware registers, obtaining the most basic hardware state information, which is the foundation for discovering hardware-level faults and cross-layer faults. Kernel-level feature extraction reads the internal state of the driver through the eBPF program, obtaining the runtime state information of the kernel driver, which is the foundation for discovering kernel vulnerabilities. Application-level feature extraction intercepts system calls to obtain user-mode operation information, obtaining the user's operations on the CXL device, which is the foundation for discovering user-mode triggered vulnerabilities. The features at these three levels complement each other, together forming a complete cross-layer state representation. In existing technologies, either only a single level of features is collected, resulting in cross-layer faults not being covered; or the entire state is collected, resulting in excessive overhead. This application solves both the coverage and overhead problems through targeted feature extraction at three levels.

[0037] In one embodiment that can be implemented in this application, such as Figure 3 As shown, the step of mapping the configuration space and base address register space of the CXL device through user space driver, reading the corresponding register fields according to the predefined hardware feature table, and generating a hardware layer feature vector includes: S301 maps the configuration space and base address register space of the CXL device to user space through the pciutils library; S302, obtain register address, bit field offset and length information from the predefined hardware feature table; S303, based on the register address, bit field offset and length information, read the bit value of the corresponding register and combine them to form a hardware layer feature vector.

[0038] In this embodiment, the configuration space and base address register space of the CXL device are mapped by the user space driver. The corresponding register fields are read according to a predefined hardware feature table to generate a hardware layer feature vector, comprising three specific sub-steps. Mapping the configuration space and base address register space of the CXL device to user space using the pciutils library is fundamental to hardware register access. The pciutils library is a general-purpose PCI device access library that supports all devices conforming to the PCI specification, including CXL devices. Through the pciutils library, the configuration space and base address register space of the CXL device can be mapped to the user-space virtual address space, allowing hardware registers to be accessed like ordinary memory. This method does not require modification of the kernel driver code or loading of additional kernel modules, exhibiting good compatibility and ease of use. Obtaining register address, bit field offset, and length information from the predefined hardware feature table is crucial for targeted feature extraction. The predefined hardware feature table was determined by the inventors of this application through analysis of the CXL protocol specification and numerous publicly disclosed CXL vulnerabilities, containing only registers and bit fields directly related to vulnerability triggering. For example, the link status register contains information such as link connectivity and link error status, which directly affect the triggering of hardware failures; the memory pool base address register determines the mapping range of CXL memory and is related to memory access vulnerabilities; the hot-plug status register reflects the hot-plug status of the device and is related to vulnerabilities during the hot-plug process. Each entry in the predefined hardware feature table contains the PCI configuration space address of the register, the start offset and length of the bit field, and the vulnerability type corresponding to that register. Based on the register address, bit field offset, and length information, the bit values ​​of the corresponding register are read and combined to form a hardware layer feature vector, which is the final step in generating the hardware layer feature vector. When reading registers, only the addresses and bit fields specified in the predefined feature table are read, avoiding reading irrelevant register contents, further improving the speed of feature extraction. The read bit values ​​are combined into a fixed-length hardware layer feature vector in a predefined order for subsequent hash calculations.

[0039] For example, a predefined hardware feature table can contain multiple register entries, each corresponding to a hardware register associated with vulnerability triggering. For instance, the first entry corresponds to the link status register, address 0x08, bit offset 0, and length 16, corresponding to link connectivity and link error states; the second entry corresponds to the memory pool base address register, address 0x10, bit offset 0, and length 32, corresponding to the starting physical address of CXL memory; the third entry corresponds to the memory pool size register, address 0x14, bit offset 0, and length 32, corresponding to the total size of CXL memory; and the fourth entry corresponds to the hot-plug status register, address 0x30, bit offset 0, and length 1, corresponding to the hot-plug status of the device. When reading a hardware register, the entire register value is first read according to the register address, and then the corresponding bit value is extracted according to the bit offset and length. For example, for the link status register, the 16-bit value at address 0x08 is read as the feature value of that register. The feature values ​​of all registers are combined in a predefined order to form a 128-byte hardware layer feature vector for subsequent hash calculations. The hardware layer feature vectors generated in this way have a fixed length and contain all hardware state information related to vulnerability triggering, while filtering out all irrelevant statistical and debugging information.

[0040] It should be noted that the predefined hardware feature table is not fixed and can be adjusted according to different test scenarios and different types of CXL devices. For example, for CXL memory devices, register entries related to memory error correction and memory interleaving can be added; for CXL cache devices, register entries related to cache coherency and cache line status can be added. Adjusting the predefined hardware feature table does not require modifying the core code of this application; only the feature table file needs to be updated, demonstrating good scalability. Those skilled in the art can add or delete register entries in the predefined hardware feature table according to actual test requirements to adapt to different test scenarios.

[0041] In one embodiment that can be implemented in this application, such as Figure 4 As shown, the process of reading key fields of the CXL driver core structure and generating kernel-level feature vectors by the eBPF program mounted to the CXL driver core function includes: S401, mount the eBPF program to the trace points of the cxl_memdev_create, cxl_memdev_destroy and cxl_hotplug functions; S402, in the eBPF program, the preset key fields in the cxl_memdev structure, cxl_port structure and cxl_mapping structure are read through BPF_CORE_READ; S403, the read key field values ​​are stored in the per-CPU mapping, and the user-space agent reads from the per-CPU mapping and generates a kernel layer feature vector.

[0042] In this embodiment, the eBPF program, mounted to the CXL driver's core functions, reads key fields of the CXL driver's core structure to generate a kernel-level feature vector, comprising three specific sub-steps. Mounting the eBPF program to the tracepoints of the `cxl_memdev_create`, `cxl_memdev_destroy`, and `cxl_hotplug` functions is fundamental to kernel state acquisition. These functions are crucial for handling device lifecycle and state changes in the CXL driver, and their execution causes significant changes in the kernel state. Tracepoints are a static hook mechanism provided by the kernel, allowing user-mode programs to insert custom code at specific locations during kernel function execution. The eBPF program can be mounted to these tracepoints, automatically triggered when kernel functions are executed, thereby obtaining kernel runtime state information. Reading preset key fields from the `cxl_memdev`, `cxl_port`, and `cxl_mapping` structures via `BPF_CORE_READ` within the eBPF program is key to obtaining the driver's internal state. BPF_CORE_READ is a secure read primitive provided by the extended Berkeley packet filter, which allows for the secure reading of fields from arbitrary kernel structures in kernel mode, even if the structure's definition changes across different kernel versions. This feature enables the kernel-level feature extraction code in this application to be compatible with different kernel versions without requiring modifications for each version. The cxl_memdev structure is the core structure representing CXL memory devices in the CXL driver, containing information such as the device ID, status, and number of memory mappings; the cxl_port structure represents a CXL port, containing information such as the port's status and connected device information; the cxl_mapping structure represents the CXL memory mapping relationship, containing information such as the starting address, length, and permissions of the mapping. The key fields in these structures directly reflect the running state of the CXL driver and are closely related to the triggering of kernel vulnerabilities. Storing the read key field values ​​in the per-CPU mapping, and having the user-mode agent read from the per-CPU mapping and generate kernel-level feature vectors, is crucial for achieving data transmission between kernel mode and user mode. The per-CPU mapping is a data structure provided by the extended Berkeley packet filter. Each CPU core has its own independent copy, thus preventing lock contention between multiple CPU cores and resulting in high data transfer efficiency. The user-space agent reads the structure field values ​​collected from the kernel space from the per-CPU mapping via the BPF system call, and then combines them into a fixed-length kernel-level feature vector in a predefined order for subsequent hash calculations.

[0043] Specifically, the writing and loading process of the eBPF program is as follows. First, the source code of the eBPF program is written in C language, including the mounting definition of trace points and data acquisition logic. Then, the source code is compiled into bytecode using the Extended Berkeley Package Filter Compiler. Next, the user-space agent loads the bytecode into the kernel via the BPF system call and mounts it to the specified trace point. When the kernel executes to the mounted trace point, it automatically triggers the execution of the eBPF program. During the execution of the eBPF program, the key field values ​​of the specified structure are read using BPF_CORE_READ, and then these values ​​are stored in the per-CPU mapping. The user-space agent periodically polls the per-CPU mapping, reads the kernel state information stored therein, and generates kernel-level feature vectors. This method has low performance overhead because the eBPF program runs in kernel mode, does not require context switching, and there is no lock contention in the per-CPU mapping. Compared with existing technologies that obtain kernel state by reading procfs or sysfs files, the method in this application can obtain unexported internal driver state information with lower performance overhead. Existing technologies can typically only obtain state information exported from the kernel, which is often not detailed enough and cannot reflect the internal operating state of the driver. However, the method in this application can directly read the fields of the driver's core structure to obtain the most detailed kernel state information, which is crucial for discovering kernel vulnerabilities.

[0044] For example, the eBPF program attaches to the tracepoint of the `cxl_memdev_create` function, which is triggered when the kernel creates a new CXL memory device. During eBPF execution, the program uses `BPF_CORE_READ` to read the `[dev.id]` field, the `state` field, and the `nr_mappings` field of the `cxl_memdev` structure. The `[dev.id]` field is the unique identifier of the device, the `state` field represents the current state of the device, and the `nr_mappings` field represents the number of memory mappings for that device. After reading these field values, they are stored in the per-CPU mapping, using `[dev.id]` as the key and `state` and `nr_mappings` as the values. The user-space agent reads these values ​​from the per-CPU mapping and then combines them in a predefined order to form part of the kernel-level feature vector. Similarly, the eBPF program attaches to the trace points of the `cxl_memdev_destroy` and `cxl_hotplug` functions. When the device is destroyed or a hot-plug operation is performed, the corresponding structure field values ​​are collected, and the kernel-level feature vector is updated. This method can track the state changes of the CXL driver in real time, ensuring the accuracy of the kernel-level feature vector.

[0045] In one embodiment that can be implemented in this application, such as Figure 5 As shown, the system call interception mechanism intercepts system calls from file descriptors pointing to the CXL device, extracts the parameters and return values ​​of the system call, and generates an application-layer feature vector, including: S501 uses ptrace or seccomp mechanisms to intercept read, write, ioctl, and mmap system calls; S502, determine whether the file descriptor of the intercepted system call corresponds to the CXL device; S503, if the judgment result is yes, extract the call number, offset parameter, length parameter and return value of the system call to generate an application layer feature vector.

[0046] In this embodiment, a system call interception mechanism is used to intercept system calls from file descriptors pointing to CXL devices, extract the parameters and return values ​​of these system calls, and generate application-layer feature vectors. This process includes three specific sub-steps. Intercepting the read, write, ioctl, and mmap system calls using ptrace or seccomp mechanisms is fundamental to system call interception. ptrace is a process tracing mechanism that can intercept all system calls of a process and obtain the parameters and return values ​​of those system calls, making it suitable for debugging scenarios. seccomp is a secure computation mode that can filter process system calls, allowing only specified system calls to be executed, making it suitable for production environments with lower performance overhead. This application allows for the selection of appropriate interception mechanisms based on different testing scenarios, demonstrating good flexibility. read, write, ioctl, and mmap are the four most commonly used system calls for user-space programs to operate on CXL devices; almost all user-space CXL operations are implemented through these four system calls. Intercepting these four system calls allows for the acquisition of all user-space operation information on the CXL device. Determining whether the file descriptor of the intercepted system call corresponds to the CXL device is crucial for filtering irrelevant system calls. When a user-space program opens a CXL device, it obtains a corresponding file descriptor. All operations on this device are performed through this file descriptor. By determining whether the file descriptor of a system call belongs to a CXL device, over 99% of system calls unrelated to CXL operations can be filtered out, significantly reducing the overhead of application-layer feature extraction. The method for determining whether a file descriptor corresponds to a CXL device is to read the device path corresponding to the file descriptor and check if this path belongs to the character device path of the CXL device. If the result is yes, the call number, offset parameter, length parameter, and return value of the system call are extracted to generate an application-layer feature vector. This is the final step in generating the application-layer feature vector. The extracted parameters include fields directly related to CXL device operations. For example, the ioctl command code determines the specific operation type, and the mmap offset and length determine the mapped memory range. These parameters directly affect the user-space operations on the CXL device and are closely related to vulnerabilities triggered in user space.

[0047] Specifically, the system call interception process is as follows: When using the ptrace mechanism, the user-space agent attaches to the test process as a tracer, setting tracing options to intercept system calls. When the test process executes a system call, it is paused by ptrace, and the user-space agent obtains the system call's parameters and return value. When using the seccomp mechanism, the user-space agent loads seccomp rules when the test process starts, allowing only specified system calls to be executed, and sends system call information to the user-space agent. When the test process executes a system call, seccomp sends system call information to the user-space agent, which processes it accordingly. For each intercepted system call, the user-space agent first obtains the first parameter of the system call, i.e., the file descriptor. Then, by reading the symbolic link / proc / [pid] / fd / [fd], it obtains the device path corresponding to that file descriptor. If the device path starts with / dev / cxl, it means that the file descriptor corresponds to a CXL device, and the system call's parameters and return value need to be extracted; otherwise, the system call is ignored. The extracted parameters include the system call number, the offset and length parameters for `read` and `write`, the command code parameter for `ioctl`, the offset and length parameters for `mmap`, and the return value of the system call. These parameters are combined in a predefined order to form a fixed-length application-layer feature vector for subsequent hash calculations.

[0048] For example, when the test process executes an ioctl system call to operate on a CXL device, the user-space agent intercepts the system call. First, it obtains the first parameter of the system call, file descriptor 3. Then, it reads the symbolic link ` / proc / [pid] / fd / 3` to obtain the device path ` / dev / cxl0`, confirming that the file descriptor corresponds to a CXL device. Next, it extracts the system call number 16, the ioctl command code 0x1234, and the system call return value 0. These parameters are combined in a predefined order to form part of the application-layer feature vector. If the test process executes a regular file read system call, and the file descriptor corresponds to the device path ` / dev / sda`, then the user-space agent will ignore the system call and not perform feature extraction. This method effectively filters out irrelevant system calls, retaining only information related to CXL device operations, significantly reducing the overhead of application-layer feature extraction.

[0049] In one embodiment that can be implemented in this application, such as Figure 6 As shown, the step of calculating the hardware layer hash value of the hardware layer feature vector, the kernel layer hash value of the kernel layer feature vector, and the application layer hash value of the application layer feature vector, concatenating the three hash values ​​into an overall state hash, and managing the shared state pool based on the overall state hash and the shortest operation sequence to reach the overall state includes: S601 uses the XXH3-64 hash algorithm to calculate the hardware layer hash value, kernel layer hash value and application layer hash value respectively, and concatenates them into an overall state hash in a preset order; S602 maintains hardware layer change flags, kernel layer change flags, and application layer change flags. It sets each flag by comparing the current feature vector with the previous state feature vector, and only recalculates the hash value and updates the overall state hash for the layers whose flags are true. S603 performs insertion, query, eviction, and validity verification operations on the shared state pool based on the overall state hash.

[0050] In this embodiment, the hardware layer hash value of the hardware layer feature vector, the kernel layer hash value of the kernel layer feature vector, and the application layer hash value of the application layer feature vector are calculated separately. These three hash values ​​are then concatenated into an overall state hash. A shared state pool is managed based on this overall state hash and the shortest operation sequence to reach the overall state, comprising three specific sub-steps. The XXH3-64 hash algorithm is used to calculate the hardware layer hash value, kernel layer hash value, and application layer hash value respectively, and concatenates them into an overall state hash in a preset order. This is the basis for generating a unique state identifier. The XXH3-64 hash algorithm is a non-encrypted hash algorithm with fast computation speed and low hash collision probability, making it suitable for high-frequency hash computation scenarios. This application chooses the XXH3-64 hash algorithm because it is much faster than other hash algorithms when processing short data, and the length of each layer feature vector in this application is within a few hundred bytes, making it very suitable for using the XXH3-64 algorithm. The three hash values ​​are concatenated in the order of hardware layer, kernel layer, and application layer into a 24-byte overall state hash, serving as a unique identifier for the system state. This layered concatenation method ensures that each part of the overall state hash corresponds to a state level, enabling subsequent incremental hash updates. Maintaining hardware-level change flags, kernel-level change flags, and application-level change flags, setting each flag by comparing the current feature vector with the previous state's feature vector, and recalculating the hash value only for levels with true flags to update the overall state hash, is the core of incremental hash updates. Through extensive experiments, the inventors of this application discovered that over 95% of CXL test operations only affect a single level of state; for example, modifying hardware registers only affects hardware-level features, and executing system calls only affects application-level features. Based on this finding, this application proposes an incremental hash update mechanism. After each operation, only the current feature vector is compared with the feature vector of the previous state, marking the changed levels, and only recalculating the hash value of the changed levels; hash values ​​for other levels are directly reused. This method reduces hash calculation time by more than two-thirds, significantly reducing the overhead of state deduplication. Using the overall state hash for insertion, querying, eviction, and validity verification operations in the shared state pool is the specific method for managing the shared state pool. The shared state pool uses the overall state hash as an index to store the shortest operation sequence to reach each state, enabling fast state lookup and reuse.

[0051] It should be noted that the implementation of the incremental hash update mechanism relies on a hierarchical state representation. If a full state hashing method is used, the hash value of the entire state needs to be recalculated after each operation, making incremental updates impossible. This application makes incremental updates possible by dividing the state into three independent levels, with each level calculating its hash value independently. Traditional techniques generally assume that to ensure the accuracy of state hashing, the hash value of the entire state needs to be recalculated each time. The inventors of this application, through in-depth analysis of the CXL system architecture and operational behavior, discovered the hierarchical locality characteristic of CXL operations and proposed an incremental hash update mechanism based on this characteristic.

[0052] In one embodiment that can be implemented in this application, such as Figure 7 As shown, the insertion, query, eviction, and validity verification operations for the shared state pool based on the overall state hash include: S701, when inserting a state, if there is no entry corresponding to the current overall state hash in the shared state pool, a new entry is created, the overall state hash and the corresponding current operation sequence are stored in it, and placed at the head of the doubly linked list; if it already exists, the lengths of the current operation sequence and the stored operation sequence are compared, the shorter one is retained and the access time is updated. S702, during the state query, the hash table is queried based on the overall state hash of the target. If a match is found, the matched entry is moved to the head of the doubly linked list and the corresponding operation sequence is returned. S703, when a state is evicted, if the number of entries in the shared state pool reaches a preset threshold, delete the entry at the tail of the doubly linked list. S704: During validity verification, entries in the shared state pool are periodically and randomly selected, their operation sequence is executed, and the corresponding state is verified. If the state is not reached, the entry is deleted.

[0053] In this embodiment, the insertion, query, eviction, and validity verification operations of the shared state pool based on the overall state hash include four specific sub-steps. When inserting a state, if there is no entry in the shared state pool corresponding to the current overall state hash, a new entry is created, the overall state hash and the corresponding current operation sequence are stored, and the entry is placed at the head of the doubly linked list. If the entry already exists, the lengths of the current operation sequence and the existing operation sequence are compared, and the shorter one is retained, with the access time updated. This is the specific method for implementing state insertion and shortest operation sequence retention. The shared state pool is implemented using a data structure combining a hash table and a doubly linked list. The hash table is used for fast querying of state entries, and the doubly linked list is used to implement the LRU eviction policy. When inserting a new state, the hash table is first checked to see if a corresponding entry exists. If not, a new state entry is created, the overall state hash and the current operation sequence are stored in the entry, and the entry is added to the head of the doubly linked list. If the entry already exists, the lengths of the current operation sequence and the existing operation sequence are compared, and the shorter operation sequence is retained because the shorter operation sequence has a shorter replay time and a faster state recovery speed. Simultaneously, the last access time of the entry is updated, and the entry is moved to the head of the doubly linked list. During state lookup, the hash table is queried based on the overall state hash. If a match is found, the matched entry is moved to the head of the doubly linked list and the corresponding operation sequence is returned. This is the specific method for achieving fast state lookup. When querying a state, the overall state hash is used to search the hash table, with a time complexity of O(1). If a match is found, the entry is moved to the head of the doubly linked list, the last access time is updated, and the corresponding operation sequence is returned. If a match is not found, null is returned. During state eviction, when the number of entries in the shared state pool reaches a preset threshold, the entry at the tail of the doubly linked list is deleted. This is the specific method for implementing the LRU eviction strategy. When the number of entries in the shared state pool reaches the preset maximum threshold, the entry at the tail of the doubly linked list, i.e., the least recently used entry, is deleted to release memory space. This eviction strategy can ensure that the most frequently used state entries are always retained in the shared state pool, increasing the probability of state reuse. During validity verification, entries in the shared state pool are periodically randomly selected, their operation sequences are executed, and it is verified whether the corresponding state has been reached. If not, the entry is deleted. This is the key to ensuring the validity of the state pool. System background operations, including automatic garbage collection by kernel threads and automatic hardware error correction, alter the system state but are not recorded by test cases, thus invalidating some state entries in the shared state pool. Using invalidated state entries to restore the system state will cause test case execution to fail. To avoid this, this application periodically verifies the validity of entries in the shared state pool. During each verification, a certain proportion of state entries are randomly selected, their corresponding operation sequences are executed, and then the overall state hash of the current system is calculated and compared with the hash stored in the entry.If they match, the overall state entry is valid; if they do not match, the overall state entry is invalid and should be removed from the shared state pool.

[0054] It should be noted that traditional fuzz testing posits that each test case must start execution from the initial state to ensure test independence and repeatability. If test cases share states, the execution result of one test case may affect another, introducing uncontrollable factors and impacting test reliability. Therefore, existing technologies rarely attempt to share intermediate states between different test cases. The inventors of this application break with this traditional concept, discovering through analysis that the execution paths of different test cases contain a large number of overlapping intermediate states, especially the pre-operations, which are almost identical. By sharing these intermediate states, the execution time of repetitive operations can be significantly reduced, improving overall testing efficiency. To ensure test independence and repeatability, this application uses a storage operation sequence method to save states, rather than storing system snapshots. Each state entry stores the shortest operation sequence to reach that overall state. When state recovery is needed, replaying the operation sequence restores the system to the exact same state. This method ensures repeatable state recovery and avoids introducing uncontrollable factors. Furthermore, this application periodically verifies validity and removes state entries that have become invalid due to system background operations, further ensuring the reliability of the state pool. This application abandons the influence of traditional fuzzing concepts, which typically assume that test cases cannot share state, thus failing to consider improving testing efficiency by sharing intermediate states. The embodiments of this application demonstrate reliable state sharing while significantly improving testing efficiency.

[0055] In one embodiment that can be implemented in this application, such as Figure 8 As shown, the step of determining the overall state hash prefix of the target state based on the target operation sequence of the test cases to be executed, querying the shared state pool, and when an intermediate state entry matching the overall state hash prefix exists, restoring the system to the intermediate state by replaying the operation sequence in the intermediate state entry, and executing the remaining part of the target operation sequence from the intermediate state to perform fuzz testing includes: S801, parse the target operation sequence, extract the features of the target state, and calculate the target state hash; S802, query the shared state pool using the prefix of the target state hash to obtain a matching intermediate state entry; S803, when a matching intermediate state entry is found, the operation sequence stored in the intermediate state entry is loaded, and the system is restored to the intermediate state by replaying the operation sequence; S804, Starting from the intermediate state, execute the operations in the target operation sequence that are located after the operation sequence in sequence to complete the fuzz test.

[0056] In this embodiment, the overall state hash prefix of the target state is determined based on the target operation sequence of the test case to be executed. The shared state pool is then queried. If an intermediate state entry matching the overall state hash prefix exists, the system is restored to the intermediate state by replaying the operation sequence in the intermediate state entry. The remaining part of the target operation sequence is then executed from the intermediate state to perform fuzz testing, including four specific sub-steps. Parsing the target operation sequence, extracting the features of the target state, and calculating the target state hash are the foundation for determining the query conditions. The target operation sequence is the set of all operations that the test case needs to execute. By parsing the target operation sequence, the target state features of the system after all operations have been executed can be extracted. Based on these features, the overall state hash prefix of the target state can be calculated. Querying the shared state pool using the prefix of the target state hash to obtain matching intermediate state entries is the specific method for implementing state querying. This application uses prefix matching instead of full matching because the target state may have some identical features with intermediate states. Prefix matching can find the closest intermediate state, thereby skipping the most preliminary steps. For example, if the target operation sequence contains 10 operations, and the intermediate state reached after executing the first 5 operations has the same first 16 bytes of its overall state hash as the target state hash, then execution can begin from this intermediate state, skipping the first 5 operations. When a matching intermediate state entry is found, the operation sequence stored in that entry is loaded, and the system is restored to the intermediate state by replaying that operation sequence; this is key to achieving state recovery. The process of replaying the operation sequence is the same as executing a normal test case, except that no additional operations are required. Starting from the intermediate state, operations following the target operation sequence are executed sequentially to complete fuzz testing, which is the final step in executing the test case. After restoring to the intermediate state, the remaining operations are executed sequentially from the position corresponding to the intermediate state in the target operation sequence to complete the entire test case execution. If no matching intermediate state entry is found, the complete target operation sequence is executed starting from the system's initial state.

[0057] For example, the target operation sequence contains 10 operations, namely operations 1 to 10. Parsing the target operation sequence, the target state characteristics of the system after executing all 10 operations are extracted, and the first 16 bytes of the target state hash are calculated as 0x123456789abcdef0. Using this prefix to query the shared state pool, an intermediate state entry is found whose overall state hash has the same first 16 bytes as the target state hash. The operation sequence corresponding to this entry is operations 1 to 5. Therefore, this operation sequence is loaded, and operations 1 to 5 are replayed, restoring the system to the intermediate state after executing operation 5. Then, starting from operation 6, operations 6 to 10 are executed sequentially to complete the execution of the entire test case. In this way, the repeated execution of operations 1 to 5 is skipped, saving a significant amount of testing time. If no matching intermediate state entry is found, all 10 operations are executed sequentially starting from operation 1.

[0058] In one embodiment that can be implemented in this application, such as Figure 9 As shown, the operation sequence for loading the intermediate state entry and restoring the system to the intermediate state by replaying the operation sequence includes: S901, Obtain the operation sequence in bytecode format stored in the intermediate state entry; S902, decode the bytecode format operation sequence to obtain the corresponding system call sequence; S903, the system call sequence is executed sequentially to restore the state of the CXL device to the intermediate state.

[0059] In this embodiment, loading the operation sequence stored in the intermediate state entry and restoring the system to the intermediate state by replaying the operation sequence includes three specific sub-steps. Obtaining the bytecode-formatted operation sequence stored in the intermediate state entry is the first step in achieving state restoration. The operation sequence is stored in bytecode format, with each operation occupying 1 to 4 bytes, containing the opcode and operands. This compact binary format significantly reduces the storage overhead of the operation sequence while improving replay speed. Decoding the bytecode-formatted operation sequence to obtain the corresponding system call sequence is crucial for replaying the operation sequence. During decoding, the system call type is identified based on the opcode, and then the corresponding operands are extracted and assembled into the system call parameters. For example, opcode 0x01 represents an ioctl system call, with the following 4 bytes being the ioctl command code and the next 4 bytes being the parameter address; opcode 0x02 represents an mmap system call, with the following 8 bytes being the offset and the next 4 bytes being the length. Executing the system call sequence sequentially to restore the CXL device's state to the intermediate state is the final step in achieving state restoration. When executing the system call sequence, each system call is executed sequentially according to the bytecode order, and the return value of each system call is checked to see if it matches the expectation. If the return value matches the expectation, the next system call is executed; if they do not match, it indicates that state recovery has failed, the current test case is terminated, and the entire state entry is removed from the shared state pool. In this way, this application guarantees the accuracy of state recovery.

[0060] It should be noted that this application uses operation sequence replay to restore the system state, rather than a system snapshot, for several reasons. First, the storage overhead of operation sequences is far less than that of system snapshots. System snapshots need to save the entire system's memory state, typically ranging from several GB to tens of GB in size; while operation sequences only need to store a small amount of bytecode, typically ranging from a few KB to several MB in size. Second, operation sequence replay is much faster than system snapshot recovery. System snapshot recovery requires loading the entire memory state from disk into memory, typically taking several seconds to tens of seconds; while operation sequence replay only requires executing a small number of system calls, typically taking several milliseconds to tens of milliseconds. Finally, operation sequence replay has better repeatability. System snapshots may contain some random state information, resulting in inconsistent states each time they are restored; while operation sequence replay is deterministic, and each execution will yield the exact same state. This application has verified through extensive experiments that the recovery accuracy of operation sequence replay reaches over 99%, which fully meets the requirements of fuzz testing.

[0061] The second aspect of this application is a fuzz testing system for CXL devices based on hierarchical state abstraction, such as... Figure 10 As shown, it includes: The feature extraction module 1001 is used to extract the hardware layer feature vector, kernel layer feature vector and application layer feature vector of the CXL device after performing test operations. The hardware layer feature vector is generated based on the predefined set of registers in the CXL device configuration space and base address register space. The kernel layer feature vector is generated based on the kernel structure fields read by the eBPF program mounted to the CXL driver core function. The application layer feature vector is generated based on the intercepted system call parameters and return values ​​related to the CXL device operation. The update module 1002 is used to calculate the hardware layer hash value of the hardware layer feature vector, the kernel layer hash value of the kernel layer feature vector, and the application layer hash value of the application layer feature vector, respectively, concatenate the three hash values ​​into an overall state hash, and manage the shared state pool based on the overall state hash and the shortest operation sequence to reach the overall state. When the test operation only causes a change in the feature vector of a single level, only the hash value of the feature vector of that single level is recalculated and the overall state hash is updated. The fuzzing module 1003 is used to determine the overall state hash prefix of the target state based on the target operation sequence of the test cases to be executed, query the shared state pool, and when there is an intermediate state entry that matches the overall state hash prefix, restore the system to the intermediate state by replaying the operation sequence in the intermediate state entry, and start executing the remaining part of the target operation sequence from the intermediate state to perform fuzzing.

[0062] In this embodiment, we also provide a CXL device fuzzing system based on hierarchical state abstraction. This system includes a three-layer state feature extractor, an incremental hash calculator, a shared state pool manager, and a test case scheduler. The three-layer state feature extractor extracts hardware-layer, kernel-layer, and application-layer feature vectors of the CXL device after executing test operations. The hardware-layer feature vector is generated based on a predefined set of registers in the CXL device's configuration space and base address register space. The kernel-layer feature vector is generated based on kernel structure fields read by the eBPF program mounted to the CXL driver's core function. The application-layer feature vector is generated based on intercepted system call parameters and return values ​​related to CXL device operations. The feature extraction step in the three-layer state feature extractor is the foundation of the entire system. The incremental hash calculator calculates the hardware-level hash value of the hardware-level feature vector, the kernel-level hash value of the kernel-level feature vector, and the application-level hash value of the application-level feature vector. These three hash values ​​are concatenated into a unified state hash. The shared state pool is managed based on this unified state hash and the shortest operation sequence to reach that unified state. When a test operation only causes a change in a single-level feature vector, only the hash value of that single-level feature vector is recalculated, and the unified state hash is updated. The hash calculation step in the incremental hash calculator method is the core of achieving efficient state deduplication. The shared state pool manager stores and manages state entries. Each state entry contains the unified state hash and the shortest operation sequence to reach that unified state, enabling state insertion, querying, eviction, and validity verification operations. The state pool management step in the shared state pool manager method is the foundation for achieving state reuse. The test case scheduler determines the overall state hash prefix of the target state based on the target operation sequence of the test cases to be executed. It then queries the shared state pool manager. If an intermediate state entry matching the overall state hash prefix exists, the system is restored to the intermediate state by replaying the operation sequence in that entry. The remaining part of the target operation sequence is then executed from the intermediate state to perform fuzz testing. The test execution steps within the corresponding methods of the test case scheduler are crucial for improving test efficiency. The various modules of the system interact with each other via memory sharing or message passing. The three-layer state feature extractor sends the extracted feature vectors to the incremental hash calculator. The incremental hash calculator sends the calculated overall state hash to the shared state pool manager and the test case scheduler. The shared state pool manager responds to the test case scheduler's query request, returning the corresponding operation sequence. The test case scheduler schedules the execution of the test cases and sends the newly generated state information to the shared state pool manager for updates.

[0063] For example, the following fuzzing test case of the CXL memory hot-plugging function further illustrates the specific implementation of this application. The test environment includes a general-purpose processor, a CXL memory device, and a computer system running a general-purpose operating system. The test objective is to discover kernel vulnerabilities existing in the CXL memory hot-plugging process. In the traditional fuzzing process, each test case starts from the initial state of the system and executes the following steps in sequence: system reset, CXL device enumeration, memory pool initialization, hot-plugging preparation, hot-plugging operation, fault injection, and state check. Among these, the four steps of system reset, CXL device enumeration, memory pool initialization, and hot-plugging preparation account for most of the execution time of each test case, and these four steps are exactly the same for all test cases, resulting in a large amount of time being wasted on repetitive pre-operations. At the same time, the traditional solution uses global full hashing for state deduplication, and the hash value of the full state needs to be calculated after each operation, and the deduplication overhead accounts for a high proportion of the total test time.

[0064] After adopting the scheme of this application, the first test case is executed from the initial state of the system. During execution, after each operation is completed, the three-layer state feature extractor extracts feature vectors from the hardware layer, kernel layer, and application layer, respectively. After the system reset operation is completed, the extracted hardware layer feature vector contains the reset status register value of the CXL device, the kernel layer feature vector contains the initialization state of the CXL driver, and the application layer feature vector is empty. The incremental hash calculator calculates the hash value of each layer and concatenates them into an overall state hash. This overall state is the new state, and the shared state pool manager inserts it into the shared state pool, with the corresponding operation sequence being the bytecode of the system reset.

[0065] Continue executing the CXL device enumeration operation. This operation only changes the feature vectors at the hardware and kernel levels; the application layer feature vector remains unchanged. The incremental hash calculator only recalculates the hash values ​​at the hardware and kernel levels, reuses the application layer hash value, and updates the overall state hash. This overall state is the new state and is inserted into the shared state pool. The corresponding operation sequence is the bytecode for system reset and CXL device enumeration.

[0066] Next, the memory pool initialization operation is performed, which also only causes changes to the feature vectors of the hardware and kernel layers. The incremental hash calculator recalculates the hash values ​​of the hardware and kernel layers, updating the overall state hash. This overall state is the new state and is inserted into the shared state pool; the corresponding operation sequence is the bytecode of the first three steps.

[0067] Then, a hot-plug preparation operation is performed, which causes changes to the feature vectors at the hardware, kernel, and application layers. The incremental hash calculator recalculates the hash values ​​at all three layers, updating the overall state hash. This overall state is the new state and is inserted into the shared state pool; the corresponding operation sequence is the bytecode of the first four steps.

[0068] Continue executing the hot-plug operation, fault injection, and state check steps to complete the execution of the first test case. During execution, a state deduplication check is performed after each operation. If a duplicate state is found, the current test case is terminated. For example, after executing a fault injection operation, if the calculated overall state hash is the same as a state hash already existing in the shared state pool, it means that the overall state has already been tested, and continuing execution will not discover new vulnerabilities. Therefore, the current test case is terminated immediately to avoid invalid execution.

[0069] After the second test case is generated, the test case scheduler parses its target operation sequence, extracts the features of the target state, and calculates the target state hash prefix. It queries the shared state pool and finds an intermediate state entry indicating hot-plugging preparation is complete, whose hash prefix matches the target state hash prefix. Therefore, it loads the operation sequence stored in that entry, i.e., the bytecode of the first four steps. The bytecode is decoded to obtain the corresponding system call sequence, which is executed sequentially to restore the system to the hot-plugging preparation complete state. The restoration process is relatively short, much shorter than the time required to re-execute the first four steps. After restoration, starting from the hot-plugging preparation complete state, the hot-plug operation, fault injection, and state check steps are executed to complete the execution of the second test case.

[0070] During the execution of the second test case, the hot-plug status register of the CXL device was modified. This operation only caused a change in the feature vector at the hardware layer. The incremental hash calculator only recalculated the hash value at the hardware layer, reused the hash values ​​at the kernel layer and application layer, and updated the overall state hash. This overall state is the new state, inserted into the shared state pool, and the corresponding operation sequence is the bytecode of the first five steps.

[0071] When the third test case is executed, the test case scheduler queries the shared state pool and finds an intermediate state entry indicating that the hot-plug operation has been completed. Therefore, it directly starts the fault injection and state check steps from this overall state, further shortening the execution time of the test case.

[0072] As testing progresses, the number of state entries in the shared state pool gradually increases, allowing subsequent test cases to find more intermediate state entries and skip more pre-processing steps. After a certain number of test cases have been executed, most common intermediate states are stored in the shared state pool, significantly reducing the average execution time of subsequent test cases. For example, by the 1000th test case, the shared state pool contained 200 valid intermediate states, meaning each test case could skip an average of 3 pre-processing steps, reducing execution time by more than 60%.

[0073] During testing, the shared state pool manager periodically performs validity checks. For example, every 10 minutes, 10% of the state entries are randomly selected, and their corresponding operation sequences are executed to verify whether they can be restored to the corresponding state. If a state entry cannot be restored, it is removed from the shared state pool. For instance, if the calculated overall state hash after executing the operation sequence for a state entry is inconsistent with the hash stored in the entry, it indicates that the overall state has become invalid due to system background operations, and therefore it is deleted. Through validity checks, the states in the shared state pool always maintain a high level of validity, ensuring a high success rate for state recovery.

[0074] Test results show that the proposed solution, while maintaining a vulnerability detection rate comparable to traditional solutions, shortens the average testing cycle by a certain percentage and significantly improves the coverage of deep and complex paths. After continuous testing for a period of time, the shared state pool stores thousands of valid intermediate states, further reducing the average execution time of subsequent test cases and significantly improving overall testing efficiency. For example, after 24 hours of continuous testing, the proposed solution executed 11,600 test cases and discovered 5 kernel vulnerabilities; while the traditional solution executed only 3,600 test cases and discovered 2 kernel vulnerabilities in the same time period. The proposed solution not only executed more test cases but also discovered more deep vulnerabilities because more testing resources were used to explore deep and complex paths instead of repeatedly executing preliminary steps.

[0075] Those skilled in the art will understand that the solution presented in this application is not only applicable to CXL memory hot-plug testing, but also to other testing scenarios such as CXL link management, cache consistency, and error handling. For different testing scenarios, only the predefined hardware characteristic table, the mount point of the eBPF program, and the scope of system call interception need to be adjusted to adapt to the corresponding testing requirements. The solution presented in this application has good scalability and versatility, and can be widely used in fault fuzzing testing of various CXL devices.

[0076] Furthermore, the solution presented in this application can be combined with other fuzzing optimization techniques to further improve testing efficiency. For example, it can be combined with reinforcement learning-based test case generation techniques, using the hierarchical state hash of this application as the state representation for reinforcement learning to guide the test case generator to prioritize exploring high-risk state paths. It can also be combined with distributed fuzzing techniques, deploying a shared state pool in a distributed cluster, allowing multiple test nodes to share intermediate states in the state pool, further improving overall test throughput.

[0077] This application is not limited thereto. Within the spirit and scope of this application, those skilled in the art can make various modifications and variations to the solution according to actual needs. For example, the contents of the predefined hardware feature table can be adjusted, and certain register fields can be added or deleted to adapt to different types of CXL devices; the size of the shared state pool and the LRU eviction policy can be adjusted to adapt to different test scenarios; the period and ratio of validity verification can be adjusted to achieve a balance between state pool accuracy and verification overhead. These modifications and variations all fall within the protection scope of this application and will not be elaborated upon here.

Claims

1. A fuzz testing method for CXL devices based on hierarchical state abstraction, characterized in that, include: Extract the hardware layer feature vector, kernel layer feature vector, and application layer feature vector of the CXL device after performing test operations. The hardware layer feature vector is generated based on the predefined set of registers in the CXL device configuration space and base address register space. The kernel layer feature vector is generated based on the kernel structure fields read by the eBPF program mounted to the CXL driver core function. The application layer feature vector is generated based on the intercepted system call parameters and return values ​​related to the CXL device operation. The hardware layer hash value of the hardware layer feature vector, the kernel layer hash value of the kernel layer feature vector, and the application layer hash value of the application layer feature vector are calculated respectively. The three hash values ​​are concatenated into an overall state hash. The shared state pool is managed based on the overall state hash and the shortest operation sequence to reach the overall state. When the test operation only causes a change in the feature vector of a single level, only the hash value of the feature vector of that single level is recalculated and the overall state hash is updated. Based on the target operation sequence of the test cases to be executed, determine the overall state hash prefix of the target state, query the shared state pool, and if there is an intermediate state entry that matches the overall state hash prefix, restore the system to the intermediate state by replaying the operation sequence in the intermediate state entry, and start executing the remaining part of the target operation sequence from the intermediate state to perform fuzz testing.

2. The method according to claim 1, characterized in that, The extraction of hardware layer feature vectors, kernel layer feature vectors, and application layer feature vectors of the CXL device after performing test operations includes: By mapping the configuration space and base address register space of the CXL device through user space driver, the corresponding register fields are read according to the predefined hardware feature table to generate hardware layer feature vectors; The eBPF program, which is mounted to the CXL driver core function, reads the key fields of the CXL driver core structure and generates kernel layer feature vectors. The system call interception mechanism intercepts system calls that point to the CXL device from the file descriptor, extracts the parameters and return values ​​of the system call, and generates an application layer feature vector.

3. The method according to claim 2, characterized in that, The process of mapping the configuration space and base address register space of the CXL device through user space driver, reading the corresponding register fields according to the predefined hardware feature table, and generating a hardware layer feature vector includes: The pciutils library maps the configuration space and base address register space of CXL devices to user space. Obtain register address, bit field offset, and length information from a predefined hardware feature table; Based on the register address, bit field offset, and length information, the bit values ​​of the corresponding registers are read and combined to form a hardware layer feature vector.

4. The method according to claim 2, characterized in that, The process of reading key fields of the CXL driver core structure and generating kernel-level feature vectors by the eBPF program mounted to the CXL driver core function includes: Mount the eBPF program to the trace points of the cxl_memdev_create, cxl_memdev_destroy, and cxl_hotplug functions; In the eBPF program, preset key fields in the cxl_memdev structure, cxl_port structure, and cxl_mapping structure are read through BPF_CORE_READ; The read key field values ​​are stored in the per-CPU mapping, and the user-space agent reads them from the per-CPU mapping to generate kernel-level feature vectors.

5. The method according to claim 2, characterized in that, The system call interception mechanism intercepts system calls from file descriptors pointing to CXL devices, extracts the parameters and return values ​​of these system calls, and generates application-layer feature vectors, including: Use ptrace or seccomp mechanisms to intercept read, write, ioctl, and mmap system calls; Determine whether the file descriptor of the intercepted system call corresponds to a CXL device; If the determination result is yes, the call number, offset parameter, length parameter and return value of the system call are extracted to generate an application layer feature vector.

6. The method according to claim 1, characterized in that, The process of calculating the hardware layer hash value of the hardware layer feature vector, the kernel layer hash value of the kernel layer feature vector, and the application layer hash value of the application layer feature vector, concatenating the three hash values ​​into an overall state hash, and managing the shared state pool based on the overall state hash and the shortest operation sequence to reach the overall state includes: The XXH3-64 hash algorithm is used to calculate the hash values ​​of the hardware layer, kernel layer, and application layer respectively, and then concatenates them into an overall state hash in a preset order. Maintain hardware layer change flags, kernel layer change flags, and application layer change flags. Set each flag by comparing the current feature vector with the previous state feature vector. Only recalculate the hash value and update the overall state hash for the layers whose flags are true. Insertion, querying, eviction, and validity verification operations are performed on the shared state pool based on the overall state hash.

7. The method according to claim 6, characterized in that, The operations for insertion, query, eviction, and validity verification of the shared state pool based on the overall state hash include: When inserting a state, if there is no entry in the shared state pool corresponding to the current overall state hash, a new entry is created, the overall state hash and the corresponding current operation sequence are stored in it, and it is placed at the head of the doubly linked list; if it already exists, the lengths of the current operation sequence and the stored operation sequence are compared, the shorter one is retained and the access time is updated. During state query, the hash table is queried based on the overall state hash of the target. If a match is found, the matched entry is moved to the head of the doubly linked list and the corresponding operation sequence is returned. When a state is evicted, if the number of entries in the shared state pool reaches a preset threshold, the entry at the tail of the doubly linked list is deleted. During validity verification, entries in the shared state pool are periodically and randomly selected, their operation sequence is executed, and it is verified whether the corresponding state has been reached. If not, the entry is deleted.

8. The method according to claim 1, characterized in that, The step of determining the overall state hash prefix of the target state based on the target operation sequence of the test cases to be executed, querying the shared state pool, and when an intermediate state entry matching the overall state hash prefix exists, restoring the system to the intermediate state by replaying the operation sequence in the intermediate state entry, and executing the remaining part of the target operation sequence from the intermediate state to perform fuzz testing includes: The target operation sequence is parsed, the features of the target state are extracted, and the target state hash is calculated; The shared state pool is queried using the prefix of the target state hash to obtain a matching intermediate state entry; When a matching intermediate state entry is found, the operation sequence stored in that intermediate state entry is loaded, and the system is restored to the intermediate state by replaying the operation sequence. Starting from the intermediate state, the operations following the operation sequence in the target operation sequence are executed sequentially to complete the fuzz test.

9. The method according to claim 8, characterized in that, The operation sequence for loading the intermediate state entry storage, and restoring the system to the intermediate state by replaying the operation sequence, includes: Retrieve the bytecode sequence of operations stored in the intermediate state entries; The operation sequence in the bytecode format is decoded to obtain the corresponding system call sequence; The system call sequence is executed sequentially to restore the state of the CXL device to the intermediate state.

10. A fuzz testing system for CXL devices based on hierarchical state abstraction, characterized in that, include: The feature extraction module is used to extract hardware layer feature vectors, kernel layer feature vectors, and application layer feature vectors of the CXL device after performing test operations. The hardware layer feature vectors are generated based on a set of predefined registers in the CXL device configuration space and base address register space. The kernel layer feature vectors are generated based on kernel structure fields read by the eBPF program mounted to the CXL driver core function. The application layer feature vectors are generated based on intercepted system call parameters and return values ​​related to CXL device operations. The update module is used to calculate the hardware layer hash value of the hardware layer feature vector, the kernel layer hash value of the kernel layer feature vector, and the application layer hash value of the application layer feature vector, respectively. The three hash values ​​are concatenated into an overall state hash. The shared state pool is managed based on the overall state hash and the shortest operation sequence to reach the overall state. When the test operation only causes a change in the feature vector of a single level, only the hash value of the feature vector of that single level is recalculated and the overall state hash is updated. The fuzzing module is used to determine the overall state hash prefix of the target state based on the target operation sequence of the test cases to be executed, query the shared state pool, and when there is an intermediate state entry that matches the overall state hash prefix, restore the system to the intermediate state by replaying the operation sequence in the intermediate state entry, and start executing the remaining part of the target operation sequence from the intermediate state to perform fuzzing.

Images