Kernel driver protection method and device, equipment and medium

Abstract

This disclosure discloses kernel driver protection methods, devices, equipment, and media, relating to the field of computers, and particularly to the technical field of computer security. First, in response to the detection of at least one preset kernel hook point being triggered in the kernel, the operation that triggered the kernel hook point is determined. Then, if the operation is kernel file reading, the file type of the read file is determined. Next, if the file type is a kernel module file, it is determined whether the read file is a preset file. Finally, if the read file is a preset file, the loading of the kernel module for the read file is intercepted.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to the field of computer security technology, specifically to kernel driver protection methods, devices, equipment, and media. Background Technology

[0002] Currently, kernel driver protection can typically be achieved by verifying the digital signature of a kernel module during loading using kernel module signing. Alternatively, a separate kernel LSM (Linux Security Modules) module can be developed to implement security policy checks in kernel space. However, the first method requires enabling the kernel during compilation and cannot be dynamically deployed at runtime, while the second method still suffers from a race condition window between user space and kernel space, making it vulnerable to bypassing by attackers. These approaches fail to meet the security requirements of kernel driver protection and require recompiling the kernel or loading third-party kernel modules, resulting in high deployment complexity. Therefore, proposing a kernel driver protection method to reduce deployment complexity and improve reliability to meet security requirements is a pressing issue that needs to be addressed. Summary of the Invention

[0003] This disclosure provides a kernel driver protection method, apparatus, device, and medium. The specific solution is as follows:

[0004] According to one aspect of this disclosure, a kernel driver protection method is provided, comprising: In response to the detection of at least one preset kernel hook point in the kernel being triggered, the operation of triggering the kernel hook point is determined; In the case where the operation is kernel file reading, determine the file type of the file being read; If the file type is a kernel module file, determine whether the read file is a preset file; If the read file is the preset file, intercept the loading of the kernel module of the read file.

[0005] According to another aspect of this disclosure, a kernel driver protection device is provided, comprising: The first determining module is used to determine the operation of triggering the kernel hook point in response to the detection of at least one preset kernel hook point in the kernel; The second determining module is used to determine the file type of the read file when the operation is kernel file reading; The third determining module determines, in the case that the file type is a kernel module file, whether the read file is a preset file; An interception module is used to intercept the loading of the kernel module of the read file if the read file is the preset file.

[0006] According to another aspect of this disclosure, an electronic device is provided, comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the method described in the above embodiments.

[0007] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause the computer to perform the method described in the above embodiments.

[0008] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method described in the above embodiments.

[0009] The kernel driver protection method, apparatus, device, and medium disclosed herein have the following beneficial effects: First, in response to the detection of at least one preset kernel hook point in the kernel, the operation that triggered the kernel hook point is determined. Then, if the operation is kernel file reading, the file type of the read file is determined. Next, if the file type is a kernel module file, it is determined whether the read file is a preset file. Finally, if the read file is a preset file, the loading of the kernel module for the read file is intercepted. This improves the reliability of kernel driver protection and meets the security requirements of kernel driver protection.

[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0011] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein: Figure 1 A flowchart illustrating a kernel driver protection method provided in an embodiment of this disclosure; Figure 2 A flowchart illustrating a kernel driver protection method provided in another embodiment of this disclosure; Figure 3 A flowchart illustrating a kernel driver protection method provided in another embodiment of this disclosure; Figure 4This is a schematic diagram of the driver interception workflow of the kernel driver protection method proposed in this disclosure; Figure 5 A flowchart illustrating a kernel driver protection method provided in another embodiment of this disclosure; Figure 6 A schematic diagram of the data flow in the workflow for replacing PCI information for kernel driver protection proposed in this disclosure; Figure 7 This is a schematic diagram of the system architecture of the kernel driver protection method proposed in this disclosure; Figure 8 This is a schematic diagram of the structure of a kernel driver protection device provided in an embodiment of the present disclosure; Figure 9 This is a block diagram of an electronic device used to implement the kernel driver protection method of the embodiments of this disclosure. Detailed Implementation

[0012] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0013] This disclosure relates to the field of computer security technology.

[0014] Computer security (also known as computer information security) is a comprehensive security system that uses technology, management, systems, and regulations to protect computers and related equipment, hardware and software, data, and network environment, prevent various risks and malicious behaviors, and ensure the legal, stable, and reliable operation of the system and the authenticity and controllability of data.

[0015] It should be noted that the acquisition, storage, use, and processing of data in this disclosed technical solution comply with the relevant provisions of national laws and regulations and do not violate public order and good morals.

[0016] The examples in this disclosure may involve user data, data acquisition, and / or use. All of these aspects comply with relevant laws, regulations, and provisions. In the examples of this disclosure, all data collection, acquisition, processing, manipulation, forwarding, and use are conducted with the user's knowledge and confirmation. Accordingly, when implementing each example, the type, scope of use, and usage scenarios of any data or information that may be involved should be communicated to the user and their authorization obtained through appropriate means in accordance with relevant laws and regulations. The specific methods of notification and / or authorization may vary depending on the actual situation and application scenario, and this disclosure does not impose any limitations on them.

[0017] In this disclosure and the sample solutions, any processing of personal information will be conducted only on a legal basis (such as with the consent of the data subject or as necessary for the performance of a contract) and will only be carried out within the scope stipulated or agreed upon. A user's refusal to process personal information beyond what is necessary for basic functions will not affect the user's use of basic functions.

[0018] The kernel driver protection method, apparatus, electronic device, and storage medium of this disclosure are described below with reference to the accompanying drawings.

[0019] Figure 1 This is a flowchart illustrating a kernel driver protection method provided in an embodiment of this disclosure.

[0020] like Figure 1 As shown, this kernel driver protection method includes: Step 101: In response to detecting the triggering of at least one preset kernel hook point in the kernel, determine the operation that triggers the kernel hook point.

[0021] It should be noted that the application scenarios of the kernel driver protection method proposed in this disclosure can be set according to actual needs. For example, it can be applied to cloud platform security protection such as preventing tenants from bypassing the virtualization layer to directly access the physical XPU in public cloud and private cloud environments, container security isolation such as preventing containers from loading unauthorized kernel drivers in cluster / container environments, kernel-level access control in security research environments such as malware analysis sandboxes, and hardware fingerprint spoofing such as XPU virtualization and anti-probing scenarios. This disclosure does not limit these scenarios.

[0022] XPU stands for eXtended Processing Unit.

[0023] It should be noted that the kernel driver protection method proposed in this disclosure can be implemented through the eBPF LSM mechanism. This mechanism allows security policies to be dynamically mounted at kernel runtime without recompiling the kernel, thus reducing deployment complexity.

[0024] In other words, before executing the kernel driver protection method proposed in this disclosure, the eBPF bytecode can be loaded and verified first to verify whether the eBPF code is safe and legal. If the verification is successful, the eBPF program is mounted to the kernel hook point and the BPF program link ID is registered to the link_id_map (the hash table that comes with eBPF). Thus, kernel driver protection can be achieved through the eBPFLSM mechanism.

[0025] eBPF, short for Extended Berkeley Packet Filter, is a lightweight security virtual machine built into the Linux kernel.

[0026] LSM is short for Linux Security Modules.

[0027] Among them, link_id_map is a whitelist of eBPF program link identifiers, which can be used to restrict the execution and permissions of unauthorized eBPF programs, thereby ensuring system security.

[0028] Kernel hook points can include security module hooks and observation point hooks.

[0029] Among them, the security module hook, also known as "LSM hooks", etc., may include at least the security module hooks shown below. The specific settings can be configured according to actual needs, and this disclosure does not limit them: Linux security module / kernel post-read hook (lsm / kernel_post_read_file): a security check hook point after a file read operation is completed; Linux security module / inode unlink hook (lsm / inode_unlink): a security control hook point for file deletion (unlinking inodes); Linux security module / inode permission verification hook (lsm / inode_permission): Inode (file / directory) access permission detection hook point; Linux security modules / process termination hooks (lsm / task_kill): Security interception hooks for process termination operations; Linux Security Modules / BPF Hooks (lsm / bpf): BPF operation security control hook points.

[0030] Among them, the observation point hooks, also known as "tracepoint hooks", may include at least the observation point hooks shown below. The specific settings can be configured according to actual needs, and this disclosure does not limit them: System call - Extended open file entry tracking point hook (sys_enter_openat): Triggered before the openat file opening operation is executed; System call - Extended open file exit tracking point hook (sys_exit_openat): Triggered after the openat file opening operation is completed; System call - file read entry tracking point hook (sys_enter_read): Triggered before the file read operation is performed; System call - file read exit tracking point hook (sys_exit_read): triggered after the file read operation is completed; System call - File close enter tracking point hook (sys_enter_close): Triggered before the file close operation is performed.

[0031] The aforementioned multiple observation point hooks can be combined to form a complete state machine, tracking the entire lifecycle of file read operations in the virtual file system (sysfs).

[0032] In this disclosure, by monitoring at least one preset kernel hook point in the kernel, when any kernel hook point is triggered, the corresponding triggering operation can be determined based on the triggering scenario of that kernel hook point. For example, when the triggered kernel hook point is lsm / kernel_post_read_file, it can be determined that the operation triggering this hook point is the kernel reading a file and that the file has already been read; or when the triggered kernel hook point is sys_enter_openat, it can be determined that the operation triggering this hook point is a user-space file opening operation via a system call, etc. This disclosure does not limit this.

[0033] Step 102: If the operation is kernel file reading, determine the file type of the file that has been read.

[0034] The file type can be determined based on the actual situation. For example, the file type of the read file can be a kernel module file, an executable program, or a dynamic library, etc., and this disclosure does not limit it.

[0035] It should be noted that the specific implementation method for determining the file type of the read file can be set according to actual needs, and this disclosure does not limit it.

[0036] For example, in some possible implementations, the file type can be determined by parsing the inode corresponding to the read file, but this disclosure does not limit this.

[0037] For example, in some possible implementations, it is also possible to check whether the identifier of the read file is READING_MODULE to determine whether the file is a kernel module file.

[0038] Among them, READING_MODULE is a status constant / enumeration item that can be used to mark that the file belongs to a module file that is currently in the reading or loading process.

[0039] Step 103: If the file type is a kernel module file, determine whether the read file is a preset file.

[0040] The kernel module file may also be referred to as "Kernel Module File", etc., and this disclosure does not limit it.

[0041] The preset file can be a pre-defined kernel module file that the module to be intercepted from loading. It can be set according to actual needs. For example, the preset file can at least include xpu.ko, device.ko and the full file path of the file, but this disclosure does not limit this.

[0042] Among them, xpu.ko is the dedicated hardware driver module file for XPU.

[0043] Among them, device.ko is a general device management auxiliary module file.

[0044] It should be noted that the specific implementation of determining whether a read file is a preset file can be set according to actual needs, and this disclosure does not limit it.

[0045] For example, in some possible implementations, since there may be a large number of filenames with the same name in the kernel, such as multiple "xpu.ko", in order to accurately intercept the loading of the target file module, the file path and filename of the read file (such as xpu.ko) can be extracted first. Then, based on the file path and filename of the read file, it can be matched with the file path and filename of the preset file. This can accurately determine whether the read file is the target file to be intercepted. If the match is successful, it can be determined that the read file is the preset file. If the match is unsuccessful, it can be determined that the read file is not the preset file. The specific determination can be made according to the actual situation, and this disclosure does not limit it.

[0046] Step 104: If the read file is a preset file, intercept the loading of the kernel module of the read file.

[0047] In this disclosure, when the read file is a preset file, the loading of the kernel module of the read file can be intercepted, thereby realizing kernel module loading detection in the kernel and accurate interception before loading, eliminating race conditions and improving the accuracy and reliability of kernel driver protection.

[0048] In some possible implementations, when the loading of a kernel module that has already read a file is intercepted, an error code can be generated and returned to the Ring Buffer.

[0049] The specific implementation of the error code can be set as needed. For example, it can be the standard error code of the Linux system, such as -EPERM (e.g., -1), indicating execution failure, operation rejection, etc.

[0050] Among them, the Ring Buffer is a circular buffer that serves as a communication tool between the eBPF kernel mode and user mode. It can transmit events, logs, alarms, etc., intercepted by eBPF in the kernel to user-mode programs in real time.

[0051] In other words, in some possible implementations, during the kernel driver module loading interception process, POST_READ events and / or SYM_DATA events can also be generated and sent to the Ring Buffer.

[0052] The POST_READ event is a callback notification event that occurs after the kernel file read operation is completed.

[0053] The SYM_DATA event is a callback notification event that sends complete symbol information (name, address, type, size, etc.) when the kernel symbol table (which records the addresses and attributes of kernel functions / variables) is accessed / modified.

[0054] In this embodiment, firstly, in response to the detection of at least one pre-set kernel hook point in the kernel, the operation that triggered the kernel hook point is determined. Then, if the operation is kernel file reading, the file type of the read file is determined. Next, if the file type is a kernel module file, it is determined whether the read file is a pre-set file. Finally, if the read file is a pre-set file, the loading of the kernel module for the read file is intercepted. Therefore, by pre-setting lightweight hook points in the kernel, deployment can be carried out during kernel runtime without recompiling the kernel, reducing the deployment complexity of kernel driver protection. Operation verification and interception are implemented internally within the kernel, eliminating the need for user-space detection and completely eliminating race conditions. This effectively prevents attackers from bypassing the protection. Simultaneously, it can accurately identify specified files to intercept module loading, improving the reliability of kernel driver protection and meeting its security requirements.

[0055] Figure 2 This is a flowchart illustrating a kernel driver protection method provided in another embodiment of this disclosure.

[0056] like Figure 2 As shown, this kernel driver protection method includes: Step 201: In response to detecting the triggering of at least one preset kernel hook point in the kernel, determine the operation that triggers the kernel hook point.

[0057] Step 202: If the operation is kernel file reading, determine the file type of the file that has been read.

[0058] Step 203: If the file type is a kernel module file, determine whether the read file is a preset file.

[0059] The specific implementation of steps 201 to 203 can be found in the detailed descriptions of other embodiments in this disclosure, and will not be repeated here.

[0060] Step 204: If the read file is not a preset file, obtain the symbol table of the read file.

[0061] The symbol table, also known as the "Symbol Table", is a mapping table in the kernel module file that stores symbol names, locations, and types.

[0062] In this disclosure, if the read file is not a preset file, in order to further confirm whether the read file is the file loaded by the module to be intercepted, the symbol table of the file can be obtained to resolve the symbols of the file.

[0063] It should be noted that the specific implementation method for obtaining the symbol table of the read file can be set according to actual needs, and this comparison does not limit it.

[0064] In some possible implementations, eBPF programs are strictly limited by the verifier: stack space is limited in bytes (e.g., 512 bytes), unbounded loops are prohibited, and pointer access must be done through helper functions. To address these limitations, the section header table of the read file can be obtained first and stored in the first array mapping table (Per-CPU array mapping table) corresponding to the CPU performing the kernel file read operation. Then, a safe loop function is called to traverse the first array mapping table, locate and obtain the symbol table of the read file, and store it in the second array mapping table corresponding to the CPU. Thus, by storing the section header table in the Per-CPU array mapping table, stack overflow and data corruption can be effectively avoided, and the safe loop function avoids unbounded loops, optimizing the file parsing process and improving the stability and efficiency of file parsing.

[0065] The section header table, also known as the "Section Headers", is the file's overall directory navigation table. It records the name, location, size, and purpose of all sections in the file and serves as the sole navigation basis for the kernel to load driver modules.

[0066] The first array mapping table is a CPU-independent array mapping table (Per-CPU array mapping table), which can also be called "shdr_ctx_map" and is used to store the section header table context. In other words, by allocating a separate data copy / memory to each CPU, this disclosure allows each CPU to read and write only its own dedicated data, avoiding data pollution and improving data reading efficiency.

[0067] The safe loop function can be configured as needed. For example, it can be the bpf_loop helper function introduced in kernel version 5.17 and later, which supports the number of runtime iterations.

[0068] It should be noted that the parameters of the loop function may differ when calling the safe loop function to traverse different data. For example, when calling the safe loop function to traverse the section header table in the first array mapping table, the safe loop function can be "bpf_loop(shnum,scan_shdrs_cb,&ctx,0)", where shnum is the total number of section headers in the file (determining how many times to loop), scan_shdrs_cb is the section header scanning callback function (parses one section header per loop), &ctx passes the temporary context data used for parsing (here, the data stored in the first array mapping table), and 0 is a fixed value, which is not limited in this disclosure.

[0069] In other words, a safe loop function includes a callback function. By encapsulating the scanning logic (used to traverse and parse relevant information) in the callback function of the safe loop function, the stack usage of each function can be kept below the byte limit (such as 512 bytes).

[0070] The second data mapping table, similar to the first data mapping table, is also a CPU-independent array mapping table, which can also be called "sym_ctx_map" and is used to store the symbol table context.

[0071] Specifically, in some possible implementations, when calling the safe loop function to traverse the first array mapping table, locate and obtain the symbol table of the read file, one can first loop through the section header table data in the first array mapping table, filter out the symbol table section of type SHT_SYMTAB, and locate and read the symbol table based on the section header information.

[0072] SHT_SYMTAB is an abbreviation for Section Header Type - Symbol Table Segment (SHT_SYMTAB).

[0073] Step 205: Determine whether there is a symbol in the symbol table that matches any of the preset target symbols.

[0074] The target symbol can be a preset XPU driver feature symbol, which can be set according to actual needs. For example, the target symbol can include, but is not limited to, the module PCI-DRM device table symbol (mod_pci__drm_pci_table_device_table), the module PCI-kernel module device table symbol (mod_pci__kl_module_device_table_device_table), the PCI device table (DRM) module symbol (mod_device_table__pci__drm_pci_table), and the PCI device table (kernel module) module symbol (mod_device_table__pci__kl_module_device_table), etc. This disclosure does not limit it.

[0075] PCI stands for Peripheral Component Interconnect.

[0076] DRM stands for Direct Rendering Manager.

[0077] In this disclosure, after obtaining the symbol table of the read file, the symbol table can be traversed based on a preset target symbol to confirm whether a matching symbol exists in the symbol table.

[0078] In some possible implementations, a safe loop function is called to traverse the second array mapping table and match it with each preset target symbol to determine if a symbol in the symbol table matches any target symbol. Thus, by traversing the second array mapping table through a safe loop function, the risk of kernel infinite loops can be eliminated. Furthermore, compared to accessing global data across cores, storing the symbol table context in an independent array mapping table corresponding to the respective CPU can effectively reduce performance overhead under multi-core concurrency and significantly improve read speed, thereby enhancing the efficiency of kernel driver protection.

[0079] For example, a safe loop function for traversing the second array map can be "bpf_loop(sym_count,scan_syms_cb,&ctx,0)", where sym_count is the total number of functions / symbols in the symbol table, scan_syms_cb is the symbol scan callback function (checking one driver function / symbol per loop), and &ctx passes context data (here, symbol table data in the second array map), which is not limited in this disclosure.

[0080] Specifically, in some possible implementations, when calling the safe loop function to traverse the second array mapping table and match each preset target symbol, the memory offset of the string table can be obtained by parsing and calculating from the SHT_SYMTAB symbol table segment first. Then, based on the memory offset of the string table, the storage location of each symbol name in the symbol table can be located. Thus, when traversing the second array mapping table, the numeric index in the symbol table can be converted into the complete symbol name for subsequent symbol matching.

[0081] Step 206: If a symbol matching the target symbol exists in the symbol table, generate and return an interception event to intercept the loading of the kernel module of the read file.

[0082] The interception event, also known as "kmod_event", is used to record complete information about the entire process of this module loading interception and can be used to generate logs.

[0083] In this disclosure, if a symbol matching the target symbol exists in the symbol table, it can be determined that the read file is a PCI hardware driver file such as XPU in the kernel. At this time, the loading of the kernel module of the read file can be intercepted, thereby realizing security protection for drivers such as XPU, while effectively filtering ordinary kernel modules and improving the accuracy of kernel driver protection.

[0084] In some possible implementations, when generating and returning intercepted events, the events can be reported to user space via kmod_rb.

[0085] Among them, kmod_rb is a Ring Buffer for passing reported intercepted events to user space, and its size can be set to 16 megabytes (MB) (it can be set as needed, and there is no limit here).

[0086] In some possible implementations, if no symbol matching the target symbol exists in the symbol table, it can be determined that the read file is a non-standard ELF file. In this case, module loading can be allowed and handed over to the kernel's native module loader for processing. Since non-standard ELF files cannot run normally, the kernel's native module loader will automatically refuse to load the read file.

[0087] In some possible implementations, when the operation involves deleting a kernel file, the type of the file to be deleted and the operation permissions are verified to intercept unauthorized deletion operations on critical kernel files.

[0088] It should be noted that the kernel hook point for capturing kernel file deletion operations can be lsm / inode_unlink, which can be used to protect driver protection binaries in the kernel.

[0089] Among them, the kernel critical files can be set according to actual needs. For example, kernel critical files may include kernel driver files and security protection-related files, such as the user-mode main loader binary program file (driver_protection), the eBPF object file (driver_protection.bpf.o), etc., which are not limited in this disclosure.

[0090] In this disclosure, when intercepting unauthorized deletion operations on critical kernel files, the unlink operation can be blocked. Unlink is the operation of removing or removing a node from a doubly linked list in the kernel.

[0091] In some possible implementations, when the operation is a file write operation, the type of the file to be written and the operation permissions are verified to intercept unauthorized write operations to critical kernel files.

[0092] It should be noted that the kernel hook point for capturing file write operations can be lsm / inode_permission, which can be used to protect binary files in the kernel.

[0093] In some possible implementations, when the operation is to send a termination signal to a process, the type and operation permissions of the process to receive the signal are verified, and unauthorized termination signals sent to critical processes are intercepted.

[0094] Among them, critical processes can be configured as needed. For example, critical processes may include security protection programs (Guardian processes) such as user-space master control programs protected by eBPF, etc., but this disclosure does not limit them.

[0095] It should be noted that when determining whether a process is a critical process, the process's comm field can be matched with the comm field of a predefined critical process. If a match is found, the process is identified as critical. Specifically, since the process comm field in the Linux kernel is fixed at 16 bytes, the process comm field can be truncated first, and then the truncated 16 bytes can be matched with the truncated comm field of the critical process.

[0096] The comm field, also known as "command name" or "process command name," is used to identify the process.

[0097] It should be noted that the kernel hook point for capturing operations that send termination signals to processes can be lsm / task_kill, which can be used to protect Guardian processes, etc.

[0098] In some possible implementations, if the operation involves at least one of uninstalling, unmounting, or modifying a kernel security protection module, permission verification is performed on the operation to block unauthorized operations.

[0099] The kernel security protection module can be configured as needed. For example, the kernel security protection module can be an eBPF program, but this disclosure does not limit it.

[0100] It should be noted that the kernel hook point that captures at least one of the operations of unloading, unmounting, and modifying kernel security protection modules can be lsm / bpf. This hook point can be used to protect eBPF programs or links, blocking operations such as BPF_LINK_DETACH, BPF_LINK_UPDATE, and BPF_PROG_DETACH. Through this kernel hook point, operations targeting eBPF programs can be precisely identified and blocked.

[0101] BPF_LINK_UPDATE is used for eBPF link unloading, disconnecting the link (the connection between the eBPF program and the kernel hook point).

[0102] Among them, BPF_LINK_UPDATE is for hot updating of eBPF links, which does not uninstall the link, but directly replaces the eBPF program bound to the link.

[0103] Among them, BPF_PROG_DETACH is used to separate the eBPF program and directly unload the eBPF program from the kernel hook point.

[0104] It should be noted that the operation permission verification for each of the above operations can be performed based on the preset permission configuration. The permission configuration can include permission configuration parameters for various operations, which can be set as needed. This disclosure does not limit this.

[0105] It should be noted that this disclosure may also include a whitelist mechanism, which may contain process identifiers that are allowed to perform cleanup operations. For example, the whitelist mechanism may include the Guardian process, meaning that the Guardian process itself may be allowed to perform cleanup operations; this disclosure does not limit this.

[0106] Therefore, by setting multiple kernel hook points in the kernel to perform kernel verification and interception, a multi-layered protection system for the kernel is constructed, which greatly enhances the kernel driver protection capability, significantly expands the applicable scenarios of kernel driver protection, and improves the comprehensiveness and reliability of kernel driver protection.

[0107] In this embodiment, firstly, in response to the detection of at least one preset kernel hook point in the kernel, the operation that triggered the kernel hook point is determined. If the operation is kernel file reading, the file type of the read file is determined. Then, if the file type is a kernel module file, it is determined whether the read file is a preset file. If the read file is not a preset file, the symbol table of the read file is obtained. Next, it is determined whether there is a symbol in the symbol table that matches any preset target symbol. Finally, if there is a symbol in the symbol table that matches the target symbol, an interception event is generated and returned, intercepting the loading of the kernel module of the read file. Thus, by capturing operations targeting kernel drivers through preset kernel hook points and verifying the symbol table of the read kernel module file, the loading of kernel modules for PCI driver files such as XPU is accurately intercepted. This achieves full-process kernel driver protection implemented through the kernel, eliminating the race condition window period during user-mode detection and kernel-mode execution, and improving the accuracy and reliability of the kernel driver protection method.

[0108] Figure 3 This is a flowchart illustrating a kernel driver protection method provided in another embodiment of this disclosure.

[0109] like Figure 3 As shown, this kernel driver protection method includes: Step 301: In response to detecting the triggering of at least one preset kernel hook point in the kernel, determine the operation that triggers the kernel hook point.

[0110] Step 302: If the operation is kernel file reading, determine the file type of the file that has been read.

[0111] Step 303: If the file type is a kernel module file, determine whether the read file is a preset file.

[0112] The specific implementation of steps 301 to 303 can be found in the detailed descriptions of other embodiments in this disclosure, and will not be repeated here.

[0113] Step 304: If the read file is not the preset file, verify the header bytes of the read file to obtain the verification result.

[0114] In this disclosure, since the file being read is a kernel module file and its format is ELF, its header bytes are the header bytes of an ELF file. By verifying the header bytes of the file being read, it can be determined whether the file being read is a standard ELF file and the verification result can be obtained.

[0115] ELF stands for Executable and Linkable Format.

[0116] It should be noted that the specific implementation method for verifying the header bytes of the read file can be set according to actual needs, and this disclosure does not limit it.

[0117] For example, in some possible implementations, a magic number check can be performed on the header bytes of the read file, that is, to verify whether the read file is a standard ELF file by checking the first bytes of the file, such as the first 4 fixed bytes of the file. This disclosure does not limit this.

[0118] Step 305: If the verification result is successful, obtain the symbol table of the read file.

[0119] In this disclosure, if the verification result is successful, it can be determined that the read file is a standard ELF file, at which point the symbol table of the read file can be obtained. Therefore, by verifying the file header bytes, the file format can be quickly identified, non-standard ELF files can be intercepted, and unnecessary calculations can be reduced. Obtaining the symbol table after successful verification ensures its legitimacy and reliability, providing a reliable data foundation for subsequent kernel detection and interception.

[0120] It should be noted that the specific implementation of obtaining the symbol table of the read file can be found in the relevant content of the above embodiments of this disclosure, and will not be described in detail here.

[0121] In some possible implementations, if the verification result is unsuccessful, it can be determined that the read file is a non-standard ELF file. In this case, module loading can be allowed without intercepting the module loading behavior of the file, and the kernel's native module loader can handle it.

[0122] Step 306: Determine whether there is a symbol in the symbol table that matches any of the preset target symbols.

[0123] Step 307: If a symbol matching the target symbol exists in the symbol table, generate and return an interception event to intercept the loading of the kernel module of the read file.

[0124] The specific implementation of steps 306 to 307 can be found in the detailed descriptions of other embodiments in this disclosure, and will not be repeated here.

[0125] In this embodiment, firstly, in response to the detection of at least one preset kernel hook point in the kernel, the operation triggering the kernel hook point is determined. If the operation is kernel file reading, the file type of the read file is determined. Then, if the file type is a kernel module file, it is determined whether the read file is a preset file. If the read file is not a preset file, the header bytes of the read file are verified to obtain a verification result. Then, if the verification result is successful, the symbol table of the read file is obtained, and it is determined whether there is a symbol in the symbol table that matches any preset target symbol. Finally, if there is a symbol in the symbol table that matches the target symbol, an interception event is generated and returned, intercepting the kernel module loading of the read file. Thus, when the kernel read file is a kernel module file, and when the read file is not a preset file to be intercepted, by verifying the file header bytes to determine whether the file is a standard ELF file, and then executing the subsequent file detection process based on the successful verification to determine whether to intercept the module loading of the file, there is no need to waste resources processing files that fail verification, thereby improving the reliability and resource utilization of kernel driver protection.

[0126] To facilitate understanding of the kernel driver protection method proposed in this disclosure, the following will be combined with... Figure 4 The driver interception workflow of the kernel driver protection method proposed in this disclosure is illustrated with an example. Figure 4 This is a schematic diagram of the driver interception workflow of the kernel driver protection method proposed in this disclosure.

[0127] Figure 4 In this example, xpu.ko and device.ko are used as examples of the default files.

[0128] like Figure 4 As shown, in response to the capture of the kernel reading a .ko file (kernel module file) (which can trigger the POST_READ event), the read .ko file is judged to determine whether the file is the preset file, i.e., xpu.ko or device.ko. If it is, i.e., the file is the preset file, -1 (error code) is returned, and the kernel module loading of the file is intercepted. It can be intercepted silently without writing events, that is, it only intercepts, does not log, does not alarm, and completes the interception silently.

[0129] If not, i.e. the file is not a default file, the ELF header is parsed and verified. If the verification fails, the file is determined to be a non-standard ELF file, module loading is allowed, and the file is handed over to the kernel's native module loader for processing.

[0130] If the verification passes, the symbol table of the file is obtained and traversed. If the preset target symbol is not found in the symbol table, the file is determined to be a non-standard ELF file, and the module loading is allowed.

[0131] If the preset target symbol exists in the symbol table, write the interception event to the Ring Buffer, return -1, and load the interception module.

[0132] It should be noted that, Figure 4 The specific implementation of each step of the workflow shown can be found in the relevant content of the above embodiments of this disclosure, and will not be described in detail here.

[0133] Figure 5 This is a flowchart illustrating a kernel driver protection method provided in another embodiment of this disclosure.

[0134] like Figure 5 As shown, this kernel driver protection method includes: Step 501: In response to detecting the triggering of at least one preset kernel hook point in the kernel, determine the operation that triggers the kernel hook point.

[0135] The specific implementation of step 501 can be found in the detailed descriptions of other embodiments in this disclosure, and will not be repeated here.

[0136] Step 502: In the case of a system call that opens a device file in user mode, extract the file path of the system call, traverse and match the preset target path list, and determine whether the file path is the target path.

[0137] Among them, the device file can be a PCI hardware device file in the kernel. Specifically, it can be a file that stores the vendor / device identifier of the PCI device.

[0138] The target path list, also known as "targets_map," is a list of file paths for PCI hardware devices in the kernel. The specific PCI device file paths included can be set according to actual needs. For example, the target path list can include the paths to the vendor and / or device files of PCI hardware devices; this disclosure does not limit this.

[0139] It should be noted that the method for generating the target path list can be set according to actual needs, and this disclosure does not limit it.

[0140] In some possible implementations, the generation process of the target path list can be as follows: First, traverse all PCI hardware devices in the kernel, reading at least one of the vendor identifier and device identifier for each PCI hardware device. Then, based on preset filtering conditions and the identifiers of each PCI hardware device, determine the target devices. Finally, generate the target path list based on the paths of the hardware identifier files of each target device. This allows for the dynamic determination of devices to hide fingerprints according to user needs to prevent fingerprint leakage, thereby improving kernel security and operational stability.

[0141] The filtering conditions can be used to filter PCI devices that need to hide fingerprints. They can be set according to actual needs, and this disclosure does not limit them.

[0142] The fingerprint of a PCI device is its unique identifier, which can consist of the device's identifiers. For example, a PCI device's fingerprint can include at least the vendor identifier and the device identifier.

[0143] For example, in some possible implementations, the filtering conditions can be implemented as command-line arguments (--target-vendor / --target-device), etc. The specific settings can be configured as needed, and this disclosure does not limit them.

[0144] It should be noted that the generation of the target path list can be performed during the user-mode initialization phase at the very beginning of the kernel driver protection method proposed in this disclosure.

[0145] In this disclosure, when determining whether a file path is a target path, the file path can be determined as a target path if a path matching the file path exists in the target path list. Alternatively, if no path matching the file path exists in the target path list, the file path can be determined as not a target path. The specific determination can be made based on the actual situation, and this disclosure does not limit this.

[0146] In this disclosure, the system calls for opening device files in user space can be captured and tracked through the kernel hook point sys_enter_openat. Then, the file path corresponding to the system call is extracted, and the extracted file path is matched with the target path list. If a match is found, the file path is determined as the target path. At this point, the thread identifier (such as tgid) of the current system call and the file type (vendor or device) of the file to be opened by the system call can be associated and stored in pending_open_map.

[0147] Here, tgid is short for Thread Group ID, which is a unique number used by the kernel to identify a process (thread group). Among them, pending_open_map is an eBPF mapping table that can be used to pass status information between entering (sys_enter_openat) and exiting (sys_exit_openat) the openat system call. It can temporarily associate the thread identifier and file type of the system call.

[0148] It should be noted that when storing file types in pending_open_map, identifiers can be used to represent the type. For example, the number "1" can represent a vendor file, and "2" can represent a device file; this disclosure does not impose any limitations on this.

[0149] Step 503: If the file path is the target path, open the corresponding device file and read the contents of the device file.

[0150] For example, a system call to open a device file in user mode could be to open the vendor file of a PCI device, which includes the device's manufacturer identifier.

[0151] In some possible implementations, the kernel can also generate a file descriptor (fd) based on the opening result when opening a file. If the file is opened successfully, the fd is greater than or equal to 0. If the file is not opened successfully, the fd is less than 0.

[0152] In this disclosure, the file descriptor (fd) returned by the kernel can be obtained first through the kernel hook point sys_exit_openat. Then, the thread identifier of the current system call is checked in pending_open_map. If it exists and the fd is greater than or equal to 0, the thread identifier and fd are bound to the file type, stored in pci_fd_map, and the relevant contents in pending_open_map are deleted.

[0153] Among them, pci_fd_map is a long-term mapping table for eBPF. It can exist throughout the entire process of opening a file and is used to track file descriptors. It can also be used to make judgments for kernel hooks in subsequent read and write operations.

[0154] It should be noted that when binding the thread identifier and file descriptor (fd) with the file type and storing them in pci_fd_map, the thread identifier can be shifted left by 32 bits (this is just an example and is not a limitation). The shifted thread identifier and fd are used as the key, and the file type is used as the value, and stored in pci_fd_map.

[0155] Then, the kernel hook point sys_enter_read is used to capture the moment when the system call initiates a read operation (the kernel opens the file but has not yet read the data). Based on the thread identifier of the current system call, the pci_fd_map is searched. If the thread identifier exists in pci_fd_map, it can be determined that the current read operation is an operation on the target device file. The read content is stored in the user-space buffer and the user-space buffer pointer is saved. The file descriptor, the buffer pointer and the file type are associated and stored in pending_read_map.

[0156] Among them, pending_read_map is a temporary mapping table dedicated to eBPF read operations, which can be used to transfer data between sys_enter_read and sys_exit_read.

[0157] It should be noted that in some possible implementations, when storing the user-mode buffer pointer, since the pointer is 64 bits, the buffer address can be stored in the lower 56 bits, and the file type can be stored in the higher 8 bits (left-shifted 56 bits), ultimately obtaining a 64-bit variable: the higher 8 bits are the file type, and the lower 56 bits are the buffer pointer. Thus, two pieces of information can be stored in one value, without the need for a complex structure, saving map space.

[0158] Step 504: Replace the read file content based on the preset replacement content corresponding to the device file.

[0159] The replacement content can be used to replace the read file content, and it can be preset according to actual needs. For example, when the read file content is the manufacturer's identifier of a PCI device, the replacement content can be the replacement identifier of that manufacturer's identifier. For example, if the manufacturer's identifier of a PCI device is "0x1234" (for example only), it can be replaced with "0x5462" (for example only). This disclosure does not limit this.

[0160] For example, in some possible implementations, the replacement content corresponding to the device file can be obtained from the BPF configuration mapping table (cfg_map), which at least contains the real manufacturer / device identifier of the target PCI device, the corresponding replacement identifier, and the device file path. This disclosure does not limit this.

[0161] For example, in some possible implementations, the cfg_map can be generated during the user-space initialization phase. When generating the cfg_map, a spoof_cfg configuration structure (including the actual device identifier, replacement identifier, and device file path) can be constructed first, and then this configuration structure can be written into the cfg_map.

[0162] Step 505: Return the replaced content.

[0163] In this disclosure, after replacing the read file content, the replaced content can be returned to the user-space buffer, thereby effectively preventing the leakage of device information in the kernel and ensuring kernel security.

[0164] In this disclosure, the end of a system call read operation can be captured by the kernel hook point sys_exit_read. The pending_read_map is searched based on the thread identifier of the system call. If the thread identifier exists in the pending_read_map, it can be determined that the current system call is reading the target file. The number of bytes read is verified to determine if it is valid. If the verification passes, the file content (such as vendor identifier or device identifier strings) stored in the user-space buffer is read. The file content is compared byte by byte with the corresponding content of the target device (real vendor identifier, device identifier). If the comparison passes, the file content in the user-space buffer is modified to the corresponding replacement content, a replacement event is generated and returned to the Ring Buffer, and then reported to the user-space guardian process. Finally, the relevant content in the pending_read_map is deleted.

[0165] It should be noted that when verifying the number of bytes read, verification can be performed using preset upper and lower limits, which can be set according to actual conditions and needs. For example, the upper limit can be set to 20 bytes and the lower limit to 6 bytes; this disclosure does not impose any restrictions on this.

[0166] Replacement events, also known as spoof events, are used to record data related to PCI device information replacement operations, such as thread identifier, file descriptor, original PCI information, replaced information, and timestamps.

[0167] It should be noted that when generating a replacement event and returning it to the Ring Buffer, it can be reported to the user-space guardian process via spoof_rb.

[0168] Among them, spoof_rb is the Ring Buffer for reporting replacement events, and its size can be 1MB.

[0169] Finally, by using the kernel hook point sys_enter_close, the file descriptor (fd) is obtained from the system call, and the relevant content in pci_fd_map is deleted based on the fd to perform a cleanup operation and avoid generating invalid data.

[0170] In summary, this disclosure can utilize the multiple kernel hook points described above (such as...) Figure 6As shown, Figure 6 The diagram illustrates the data flow in the kernel driver protection PCI information replacement workflow proposed in this disclosure. By working together, the target PCI device file information can be intercepted and replaced, completely eliminating kernel PCI device information leakage and ensuring kernel security.

[0171] It should be noted that, through Figure 6 The specific implementation methods of PCI information replacement using the multiple kernel hooks shown can be referred to the relevant descriptions in the embodiments of this disclosure, and will not be repeated here.

[0172] In this embodiment, firstly, in response to the detection of at least one preset kernel hook point in the kernel, the operation triggering the kernel hook point is determined. If the operation is a system call to open a device file in user mode, the file path of the system call is extracted, a preset target path list is traversed and matched to determine if the file path is a target path. Then, if the file path is a target path, the corresponding device file is opened, the contents of the device file are read, and the read file contents are replaced based on preset replacement content corresponding to the device file. Finally, the replaced content is returned. Therefore, by capturing a system call to open a device file in user mode through a kernel hook point, extracting the file path and checking if it is a target path, opening the corresponding file and reading its contents, replacing the read file contents and returning the replacement value, the leakage of kernel driver device information can be effectively prevented, greatly improving kernel driver security and the reliability of kernel driver protection.

[0173] The following is combined Figure 7 The system architecture of the kernel driver method proposed in this disclosure is illustrated with an example. Figure 7 This is a schematic diagram of the system architecture of the kernel driver protection method proposed in this disclosure.

[0174] Figure 7 In this kernel driver protection system 700, the system may include: a compile-time dependency layer 701, a user space layer 702, and a kernel space layer 703.

[0175] The user space layer 702 may include at least the application layer 7021 and the user-space data layer 7022.

[0176] The application layer 7021 may include at least a user-mode loader (driver_protection.c), a user-mode daemon (driver_protection), and instance lock management. The loader can be used to scan sysfs, load BPF objects, attach hooks, poll ring buffers, output events / logs to the terminal, etc.

[0177] Furthermore, a user-mode loader may include at least: libbpf: A user-space BPF development library used for loading, validating, and mounting BPF objects; PCI Scanner: Used to scan the hardware device information directory under the sysfs virtual file system; Configuration builder: Used to generate the spoof_cfg configuration structure; Link registry: Used to record BPF program link identifiers into link_id_map; Event Poller: Uses the poll mechanism (IO multiplexing mechanism) to poll the Ring Buffer and read event data reported by BPF; Event handler: parses and processes the read event data.

[0178] The user-space data layer 7022 may include at least local events / logs and rule configurations.

[0179] The kernel space layer 703 may include at least a security boundary layer 7031, a core logic layer 7032, a kernel-mode data layer 7033, and a hardware and kernel layer 7034.

[0180] The security boundary layer 7031 may include kernel hooks (such as the kernel hooks mentioned in this disclosure).

[0181] The core logic layer 7032 may include at least an interception module, a replacement module, a multi-layer protection mechanism, and BPF helper functions.

[0182] It should be noted that the interception module, replacement module, and multi-layer protection mechanism can all cooperate with the corresponding kernel hook points in the security boundary layer 7031 to complete the corresponding kernel driver protection process. For details, please refer to the relevant descriptions in the above embodiments of this disclosure; further details will not be repeated here.

[0183] Among them, BPF helper functions are tools specifically provided by the Linux kernel for eBPF programs. For example, they can include at least map-related operations, safe loops, and functions for obtaining thread identifiers, etc. The specific functions can be set as needed, and this disclosure does not limit them.

[0184] The kernel-mode data layer 7033 may include at least the event channel (Ring Buffer), the mapping tables mentioned in the above embodiments of this disclosure (such as cfg_map, targets_map, pci_fd_map, pending_open_map, etc.), the path temporary cache mapping table (path_scratch_map), the vendor information temporary cache mapping table (vendor_scratch_map), etc.

[0185] Among them, the hardware and kernel layer 7034 may include at least the kernel module loader, LSM framework, system call path (Syscall path), PCI device, Sysfs interface, and interception targets and protected objects (such as kernel drivers, PCI hardware devices, etc.).

[0186] The following is about Figure 7 The following examples illustrate at least the data flow directions that exist in the system. These examples are for illustrative purposes only and are not intended to be limiting: 1. Configure data flow: User space scan → cfg_map → Kernel BPF program matching.

[0187] 2. Intercepting event stream: Kernel detection → kmob_rb → User-space polling → Log output.

[0188] 3. Disguised replacement event flow: sysfs access → kernel replacement → spoof_rb → user-space polling → log output.

[0189] In this disclosure, the compile-time dependency layer (top layer) contains the external dependencies and intermediate artifacts required to build the system: kernel BTF image file; kernel BTF (BPF Type Format) information, exported by the bpf tool; vmlinux.h; kernel type definition header file automatically generated based on BTF, which must be included when compiling eBPF programs; and driver_protection.bpf.o; the compiled BPF bytecode object file, which is read and loaded into the kernel by the user-mode loader.

[0190] The data flow for this layer is: BTF → bpf tool → image file → clang → driver protection eBPF target file (driver_protection.bpf.o).

[0191] Furthermore, when implementing the kernel driver protection method proposed in this disclosure, user-mode initialization can be performed first: 1. Scan all PCI devices in the Hardware Device Information directory under the sysfs virtual file system.

[0192] 2. Construct the cfg_map structure and targets_map.

[0193] 3. Open the compiled eBPF program file using bpf_object_open(), and load the program file into the kernel using bpf_object_load(). During the loading process, the verifier performs security verification.

[0194] 4. Filter target devices according to command line parameters (--target-vendor / --target-device), write the sysfs path of the target device to targets_map to update targets_map, and write the spoof configuration (replacement content configuration) to cfg_map to update cfg_map.

[0195] 5. Call libbpf to load the compiled kernel-mode eBPF protection binary file (driver_protection.bpf.o), automatically complete the mounting operations of all BPF programs, establish instance locks (Unix Socket locks), and prevent multiple instances from running simultaneously.

[0196] 6. Create kmod_rb consumer and spoof_rb consumer.

[0197] Furthermore, during the runtime phase: user space can poll two Ring Buffers (kmod_rb and spoof_rb), receive events reported by kernel space, and format the events to output to the terminal, including timestamps, process information, operation type, file path, etc.

[0198] In this disclosure, multiple functional modules (such as interception modules, replacement modules, and multi-layer protection mechanisms) contained in the kernel space layer share the same eBPF program file: (I) XPU driver interception + self-protection LSM Hooks (5): kernel_post_read_file: Triggered after the kernel module loader reads the contents of the .ko file, it is a key hook point for intercepting the XPU driver.

[0199] inode_unlink: Triggered by file deletion operations (unlink / rm), protecting its own binary file.

[0200] inode_permission: Triggered by file permission checks, it intercepts write operations to its own file.

[0201] task_kill: Triggered by inter-process signal sending, protecting the daemon process from being terminated.

[0202] lsm / bpf: BPF program management operation triggered to prevent its own BPF links from being unloaded.

[0203] Interception process: Filename quick match: If the loaded file name is xpu.ko or device.ko, return -1 directly to block (silent, no event reported).

[0204] ELF symbol depth scan: For other .ko files, parse the ELF header to locate the symbol table and traverse all symbols using bpf_loop().

[0205] Feature symbol matching: Detects PCI device table symbols generated by the MODULE_DEVICE_TABLE macro (supports both formats before and after kernel 6.13).

[0206] The MODULE_DEVICE_TABLE parameter can embed a list of hardware devices supported by the driver into the kernel module, allowing the kernel to automatically identify the hardware, match and load the corresponding driver.

[0207] Blocking and Reporting: If a hit occurs, write kmod_event to RingBuffer and return -1 to block loading.

[0208] Self-protection process: File operations: Check if the target path matches driver_protection or driver_protection.bpf.o.

[0209] Process protection: Check if the target process's comm is driver_protecti (truncated 16 characters).

[0210] BPF Protection: Checks whether a BPF operation originates from a non-daemon process.

[0211] (ii) PCI vendor sysfs masquerading and replacement Tracepoints (5): These form a complete state machine, tracing the entire lifecycle of sysfs file read operations. sys_enter_openat: Records the file paths that a process is currently opening. If a match is found in the target sysfs path, it is marked as "to be traced".

[0212] sys_exit_openat: Records the file descriptor (fd) returned by openat, and stores the (tgid, fd) → path mapping in pci_fd_map.

[0213] sys_enter_read: Checks if the current file descriptor (fd) is in pci_fd_map; if so, saves the user buffer pointer.

[0214] sys_exit_read: Checks if the current file descriptor (fd) is hit. If so, it calls bpf_probe_write_user() to replace the contents of the user buffer, replacing the original vendor string with a forged value.

[0215] sys_enter_close: Clears the file descriptor (fd) records in pci_fd_map.

[0216] It should be noted that, through Figure 7 The system architecture shown implements the kernel driver protection method proposed in this disclosure in a specific way. You can refer to the relevant description in the above embodiments of this disclosure, which will not be repeated here.

[0217] In summary, the kernel driver protection method proposed in this disclosure has at least the following beneficial technical effects: 1. It can be loaded at runtime, resulting in low deployment complexity.

[0218] 2. The interception logic runs in kernel mode and can complete the interception action before the target driver is loaded.

[0219] 3. Supports hot policy updates; rule adjustments do not require service restart.

[0220] 4. It allows for fine-grained control over specific drivers.

[0221] 5. It possesses multi-layered protection capabilities and the ability to spoof and replace hardware information, thereby improving system security.

[0222] 6. The security verification mechanism of the BPF verifier ensures the stability of the system's operation.

[0223] To implement the above embodiments, this disclosure also proposes a kernel driver protection device.

[0224] Figure 8 This is a schematic diagram of the structure of a kernel driver protection device provided in an embodiment of the present disclosure.

[0225] like Figure 8 As shown, the kernel driver protection device 800 includes: a first determination module 801, a second determination module 802, a third determination module 803, and an interception module 804.

[0226] The first determining module 801 is used to determine the operation of triggering the kernel hook point in response to detecting the triggering of at least one preset kernel hook point in the kernel; The second determining module 802 is used to determine the file type of the read file when the operation is kernel file reading; The third determination module 803 is used once to determine whether the read file is a preset file when the file type is a kernel module file; Interception module 804 is used to intercept the loading of kernel modules for a file that has already been read, provided that the read file is a preset file.

[0227] Optionally, the third determining module 803 described above is further configured to: If the read file is not the preset file, obtain the symbol table of the read file; Determine if a symbol in the symbol table exists that matches any preset target symbol; If a symbol matching the target symbol exists in the symbol table, an interception event is generated and returned to intercept the loading of the kernel module of the read file.

[0228] Optionally, the third determining module 803 described above is further configured to: If the read file is not the preset file, the header bytes of the read file are verified to obtain the verification result; If the verification result is successful, obtain the symbol table of the read file.

[0229] Optionally, the third determining module 803 described above is further configured to: Retrieve the section header table of the read file and store it in the first array mapping table corresponding to the central processing unit that performed the kernel file read operation; Call the safe loop function to traverse the first array mapping table, locate and obtain the symbol table of the read file, and store it in the second array mapping table corresponding to the central processing unit.

[0230] Optionally, the third determining module 803 described above is further configured to: Call the safe loop function to traverse the second array mapping table and match it with each preset target symbol to determine whether there is a symbol in the symbol table that matches any target symbol.

[0231] Optionally, the first determining module 801 described above is further configured to: In the case of a system call that opens a device file in user mode, extract the file path of the system call, traverse and match the preset target path list, and determine whether the file path is the target path. If the file path is the target path, open the corresponding device file and read its contents. The read file content is replaced based on the preset replacement content corresponding to the device file; Return the replaced content.

[0232] Optionally, the first determining module 801 described above is further configured to: Iterate through all PCI hardware devices in the kernel and read at least one of the manufacturer identifier and device identifier for each PCI hardware device. The target device is determined based on preset filtering criteria and the identifiers of each PCI hardware device. A list of target paths is generated based on the paths in the hardware identification files of each target device.

[0233] Optionally, the first determining module 801 described above is further configured to perform at least one of the following: When the operation involves deleting kernel files, the type of the file to be deleted and the operation permissions are verified to block unauthorized deletion operations on critical kernel files. In the case of a file write operation, the type of the file to be written and the operation permissions are verified, and unauthorized write operations to critical kernel files are blocked. When the operation is to send a termination signal to a process, the type and operation permissions of the process to receive the signal are verified, and unauthorized termination signals sent to critical processes are intercepted. If the operation involves at least one of uninstalling, unmounting, or modifying a kernel security protection module, the operation will be subject to permission verification to block unauthorized operations.

[0234] It should be noted that the explanation of the aforementioned kernel driver protection method embodiment also applies to the kernel driver protection device of this embodiment, so it will not be repeated here.

[0235] In this embodiment, firstly, in response to the detection of at least one pre-set kernel hook point in the kernel, the operation that triggered the kernel hook point is determined. Then, if the operation is kernel file reading, the file type of the read file is determined. Next, if the file type is a kernel module file, it is determined whether the read file is a pre-set file. Finally, if the read file is a pre-set file, the loading of the kernel module for the read file is intercepted. Therefore, by pre-setting lightweight hook points in the kernel, deployment can be carried out during kernel runtime without recompiling the kernel, reducing the deployment complexity of kernel driver protection. Operation verification and interception are implemented internally within the kernel, eliminating the need for user-space detection and completely eliminating race conditions. This effectively prevents attackers from bypassing the protection. Simultaneously, it can accurately identify specified files to intercept module loading, improving the reliability of kernel driver protection and meeting its security requirements.

[0236] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0237] Figure 9A schematic block diagram of an example electronic device 900 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0238] like Figure 9 As shown, device 900 includes a computing unit 901, which can perform various appropriate actions and processes based on a computer program stored in ROM (Read-Only Memory) 902 or a computer program loaded from storage unit 908 into RAM (Random Access Memory) 903. RAM 903 can also store various programs and data required for the operation of device 900. The computing unit 901, ROM 902, and RAM 903 are interconnected via bus 904. I / O (Input / Output) interface 905 is also connected to bus 904.

[0239] Multiple components in device 900 are connected to I / O interface 905, including: input unit 906, such as keyboard, mouse, etc.; output unit 907, such as various types of monitors, speakers, etc.; storage unit 908, such as disk, optical disk, etc.; and communication unit 909, such as network card, modem, wireless transceiver, etc. Communication unit 909 allows device 900 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0240] The computing unit 901 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 901 include, but are not limited to, CPUs (Central Processing Units), GPUs (Graphics Processing Units), various special-purpose AI (Artificial Intelligence) computing chips, various computing units running machine learning model algorithms, DSPs (Digital Signal Processors), and any suitable processor, controller, microcontroller, etc. The computing unit 901 performs the various methods and processes described above, such as the kernel driver protection method. For example, in some possible implementations, the kernel driver protection method can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 908. In some possible implementations, part or all of the computer program can be loaded and / or installed on device 900 via ROM 902 and / or communication unit 909. When the computer program is loaded into RAM 903 and executed by the computing unit 901, one or more steps of the kernel driver protection method described above can be performed. Alternatively, in other embodiments, computing unit 901 may be configured to perform kernel driver protection methods by any other suitable means (e.g., by means of firmware).

[0241] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, FPGAs (Field Programmable Gate Arrays), ASICs (Application-Specific Integrated Circuits), ASSPs (Application-Specific Standard Products), SOCs (System-on-Chips), CPLDs (Complex Programmable Logic Devices), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0242] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0243] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, RAM, ROM, EPROM (Electrically Programmable Read-Only Memory) or flash memory, optical fiber, CD-ROM (Compact Disc Read-Only Memory), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0244] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (Cathode-Ray Tube) or LCD (Liquid Crystal Display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0245] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include LANs (Local Area Networks), WANs (Wide Area Networks), the Internet, and blockchain networks.

[0246] Computer systems can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. The client-server relationship is established by computer programs running on the respective computers and having a client-server relationship with each other. A server can be a cloud server, also known as a cloud computing server or cloud host, a hosting product within the cloud computing service ecosystem, addressing the shortcomings of traditional physical hosts and VPS (Virtual Private Server) services, such as high management difficulty and weak business scalability. Servers can also be servers for distributed systems or servers incorporating blockchain technology.

[0247] According to embodiments of this disclosure, this disclosure also provides a computer program product that, when an instruction processor in the computer program product is executed, performs the kernel driver protection method proposed in the above embodiments of this disclosure.

[0248] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0249] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A kernel driver protection method, characterized in that, include: In response to the detection of at least one preset kernel hook point in the kernel being triggered, the operation of triggering the kernel hook point is determined; In the case where the operation is kernel file reading, determine the file type of the file being read; If the file type is a kernel module file, determine whether the read file is a preset file; If the read file is the preset file, intercept the loading of the kernel module of the read file.

2. The method as described in claim 1, characterized in that, After determining whether the read file is a preset file when the file type is a kernel module file, the method further includes: If the read file is not a preset file, obtain the symbol table of the read file; Determine whether there exists a symbol in the symbol table that matches any preset target symbol; If a symbol matching the target symbol exists in the symbol table, an interception event is generated and returned to intercept the loading of the kernel module of the read file.

3. The method as described in claim 2, characterized in that, The step of obtaining the symbol table of the file when the read file is not a preset file includes: If the read file is not a preset file, the header bytes of the read file are verified to obtain a verification result; If the verification result is successful, the symbol table of the read file is obtained.

4. The method as described in any one of claims 2-3, characterized in that, The step of obtaining the symbol table of the read file includes: Obtain the section header table of the read file and store it in the first array mapping table corresponding to the central processing unit that performed the kernel file read operation; The safe loop function is called to traverse the first array mapping table, locate and obtain the symbol table of the read file, and store it in the second array mapping table corresponding to the central processing unit.

5. The method as described in claim 4, characterized in that, Determining whether there exists a symbol in the symbol table that matches any preset target symbol includes: The secure loop function is invoked to traverse the second array mapping table and match it with each preset target symbol to determine whether there is a symbol in the symbol table that matches any target symbol.

6. The method as described in claim 1, characterized in that, After determining the operation of triggering the kernel hook point in response to detecting the triggering of at least one preset kernel hook point in the kernel, the method further includes: In the case where the operation is a system call to open a device file in user mode, the file path of the system call is extracted, a preset target path list is traversed and matched, and it is determined whether the file path is a target path. If the file path is the target path, open the corresponding device file and read the contents of the device file; The read file content is replaced based on the preset replacement content corresponding to the device file; Return the replaced content.

7. The method as described in claim 6, characterized in that, The process of generating the target path list includes: Iterate through all PCI hardware devices in the kernel and read at least one of the manufacturer identifier and device identifier for each PCI hardware device. Based on preset filtering criteria and the identifiers of each PCI hardware device, the target device is determined; A target path list is generated based on the path of the hardware identification file of each target device.

8. The method as described in claim 1, characterized in that, After determining the operation of triggering the kernel hook point in response to detecting the triggering of at least one preset kernel hook point in the kernel, the method further includes at least one of the following: In the case where the operation is to delete a kernel file, the type of the file to be deleted and the operation permissions are verified to block unauthorized deletion operations on critical kernel files. In the case of a file write operation, the type of the file to be written and the operation permissions are verified, and unauthorized write operations to the kernel critical files are blocked. When the operation is to send a termination signal to a process, the type and operation permissions of the process to receive the signal are verified, and unauthorized termination signals sent to critical processes are intercepted. If the operation involves at least one of uninstalling, unmounting, or modifying a kernel security protection module, permission verification is performed on the operation to block unauthorized operations.

9. A kernel driver protection device, characterized in that, include: The first determining module is used to determine the operation of triggering the kernel hook point in response to the detection of at least one preset kernel hook point in the kernel; The second determining module is used to determine the file type of the read file when the operation is kernel file reading; The third determining module determines, in the case that the file type is a kernel module file, whether the read file is a preset file; An interception module is used to intercept the loading of the kernel module of the read file if the read file is the preset file.

10. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-8.

11. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-8.

12. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-8.

Images