A dynamic security check method for a Linux driver loading stage

Abstract

The present disclosure provides a dynamic security verification method for a Linux driver loading stage, comprising: in response to the existence of a driver to be loaded into a kernel, intercepting the driver by using a security verification hook registered on a driver loading path of the kernel; performing static integrity verification on the driver by verifying a digital signature and a file hash value of the driver; in response to the driver passing the static integrity verification, comparing resource requirement information of the driver with a system resource occupation state to generate a resource rationality score; extracting static behavior features of the driver, comparing the static behavior features with a malicious driver feature library and a normal driver baseline library respectively to generate a behavior feature security score; obtaining a comprehensive security score by weighted summation according to the resource rationality score and the behavior feature security score; and judging whether the comprehensive security score is greater than a preset comprehensive threshold, if yes, allowing the driver to be loaded, and if not, refusing to load the driver.

Description

Technical Field

[0001] This disclosure relates to the field of computer operating system security technology, and more specifically to a dynamic security verification method for the loading stage of Linux drivers. Background Technology

[0002] Drivers run at the operating system kernel level, which has the highest execution level. In Linux systems, drivers exist as kernel modules. Once a malicious driver is loaded into the kernel, it can bypass most security protection mechanisms, such as user-space firewalls and sandboxes, posing a serious threat to the system. Summary of the Invention

[0003] In view of the above problems, this disclosure provides a dynamic security verification method for the Linux driver loading stage, which not only verifies the static integrity of the driver before loading, but also dynamically analyzes the rationality of its resource requests and behavioral characteristics.

[0004] This disclosure provides a dynamic security verification method for the Linux driver loading stage, comprising: in response to the existence of a driver to be loaded into the kernel, intercepting the driver using a security verification hook registered on the driver loading path in the kernel; performing static integrity verification on the driver by verifying the driver's digital signature and file hash value; in response to the driver passing the static integrity verification, comparing the driver's resource requirement information with the system resource occupancy status to generate a resource rationality score; extracting the static behavioral features of the driver, comparing the static behavioral features with a malicious driver feature library and a normal driver baseline library respectively to generate a behavioral feature security score, wherein the static behavioral features include at least one of the following: overall file hash, code segment hash, symbol table call pattern, license declaration, initialization segment size and features, and string constant features; the malicious driver feature library includes the static behavioral features of known malicious drivers, and the normal driver baseline library includes the static behavioral features of known safe drivers; obtaining a comprehensive security score by weighted summation of the resource rationality score and the behavioral feature security score; determining whether the comprehensive security score is greater than a preset comprehensive threshold; if so, allowing the driver to load; otherwise, refusing to load the driver.

[0005] According to embodiments of this disclosure, a security verification hook is registered between kernel system calls and format parsing.

[0006] According to embodiments of this disclosure, performing static integrity verification on a driver includes: using a multiplexed encryption and integrity verification framework to perform digital signature verification on the driver; calculating the hash value of the driver file using a 256-bit secure hash algorithm and comparing it with a registered baseline hash value; determining whether the digital signature verification passes and whether the hash comparison is consistent; if yes, determining that the driver passes the static integrity verification; if no, determining that the driver fails the static integrity verification, refusing to load the driver, and recording an audit log.

[0007] According to embodiments of this disclosure, comparing the resource requirement information of the driver with the system resource occupancy status to generate a resource rationality score includes: performing memory address range conflict detection, input / output port occupancy detection, interrupt number security range detection, and resource request range detection based on the resource requirement information and system resource occupancy status; calculating the resource rationality score by weighted summation based on the detected memory address range conflict score, input / output port occupancy score, interrupt number security range score, and resource request range score, and no longer performing the step of extracting the static behavioral features of the driver and comparing the static behavioral features with the malicious driver feature library and the normal driver baseline library to generate a behavioral feature security score.

[0008] According to embodiments of this disclosure, a method for obtaining resource requirement information includes: parsing the module file structure of a driver and extracting the module information segment, identifying resource-related parameters from the parameter declaration field of the module information segment; performing static analysis on the driver's code, identifying the driver's resource request function calls, and obtaining the driver's resource request amount; wherein, the resource-related parameters include at least one of base address, interrupt number, and input / output port, and the resource request function calls include at least one of resource region request, memory mapping, and interrupt request.

[0009] According to embodiments of this disclosure, static behavioral features are compared with a malicious driver feature library and a normal driver baseline library to generate a behavioral feature security score, including: comparing the static behavioral features with the malicious driver feature library to obtain a malicious similarity score; comparing the static behavioral features with the normal driver baseline library to obtain a normal deviation score; and generating a behavioral feature security score based on the malicious similarity score and the normal deviation score.

[0010] According to embodiments of this disclosure, a method for updating a malicious driver signature library and a normal driver baseline library includes: in response to a driver being refused to load, writing the static behavioral characteristics of the driver as a new malicious driver sample increment into the malicious driver signature library; in response to a driver being allowed to load, collecting runtime behavioral data of the driver after the driver is loaded, wherein the runtime behavioral data includes at least one of actual resource usage, running status data, and system environment change data; and updating the normal driver baseline based on the runtime behavioral data.

[0011] The second aspect of this disclosure provides a dynamic security verification system for the Linux driver loading stage, which can be used to implement the aforementioned dynamic security verification method for the Linux driver loading stage. The system includes: a driver interception module, used to intercept the driver by utilizing a security verification hook registered on the driver loading path in the kernel when a driver to be loaded into the kernel is present; a static verification module, used to perform static integrity verification on the driver by verifying the driver's digital signature and file hash value; a resource analysis module, used to compare the driver's resource requirement information with the system resource occupancy status to generate a resource rationality score when the driver passes the static integrity verification; and a behavioral feature comparison module, used to extract driver... The program's static behavioral characteristics are compared with both a malicious driver signature library and a normal driver baseline library to generate a behavioral characteristic security score. The static behavioral characteristics include at least one of the following: overall file hash, code segment hash, symbol table call pattern, license declaration, initialization segment size and characteristics, and string constant characteristics. The malicious driver signature library includes the static behavioral characteristics of known malicious drivers, and the normal driver baseline library includes the static behavioral characteristics of known safe drivers. A comprehensive decision module is used to obtain a comprehensive security score by weighted summation of the resource rationality score and the behavioral characteristic security score. It then determines whether the comprehensive security score is greater than a preset comprehensive threshold. If so, the driver is allowed to load; otherwise, loading the driver is rejected.

[0012] A third aspect of this disclosure provides an electronic device comprising: one or more processors; and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors perform the dynamic security verification method described above for the Linux driver loading phase.

[0013] A fourth aspect of this disclosure also provides a computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, cause the processor to perform the dynamic security verification method described above for the Linux driver loading phase.

[0014] The dynamic security verification method for the Linux driver loading stage provided in this disclosure intercepts the driver to be loaded by registering a security verification hook on the kernel's driver loading path, and performs static integrity verification, dynamic resource request reasonableness scoring, and behavioral feature comparison based on a malicious driver signature library and a normal driver baseline library. Since multi-dimensional security verification is completed before the driver is loaded into the kernel, it at least partially solves the technical problem that existing Linux driver loading security verification mainly relies on a single static signature or hash check, making it difficult to identify malicious drivers with legitimate signatures but abnormal behavior. This achieves the technical effect of blocking drivers with abnormal behavior or excessive resource requests before loading, thereby improving the Linux kernel's defense-in-depth capabilities. Attached Figure Description

[0015] Figure 1 A flowchart illustrating a dynamic security verification method during the Linux driver loading phase according to an embodiment of this disclosure is shown schematically.

[0016] Figure 2 A schematic diagram illustrating the overall system architecture according to an embodiment of the present disclosure is shown.

[0017] Figure 3 This schematically illustrates the main flow from driver interception to final decision according to an embodiment of the present disclosure;

[0018] Figure 4 This illustration schematically shows a flowchart of the dynamic resource request rationality verification according to an embodiment of the present disclosure;

[0019] Figure 5 A flowchart illustrating a baseline comparison of behavioral features according to an embodiment of the present disclosure is shown schematically.

[0020] Figure 6 A flowchart illustrating the dynamic update of the security baseline according to an embodiment of this disclosure is shown schematically.

[0021] Figure 7 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0022] The embodiments of the present disclosure will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the disclosure. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of the present disclosure for ease of explanation. However, it will be apparent that one or more embodiments may be practiced without these specific details. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts of the present disclosure.

[0023] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0024] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0025] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0026] Figure 1 A flowchart illustrating a dynamic security verification method during the Linux driver loading phase according to an embodiment of this disclosure is shown, such as... Figure 1 As shown, embodiments of this disclosure provide a dynamic security verification method during the Linux driver loading phase. Specifically, the process includes: S100, in response to the existence of a driver to be loaded into the kernel, intercepting the driver using a security verification hook registered on the driver loading path in the kernel; S200, performing a static integrity check on the driver by verifying its digital signature and file hash value; S300, in response to the driver passing the static integrity check, comparing the driver's resource requirements with the system resource usage status to generate a resource rationality score; S400, extracting the driver's static behavioral features, comparing these features with a malicious driver signature library and a normal driver baseline library to generate a behavioral feature security score. The static behavioral features include at least one of the following: overall file hash, code segment hash, symbol table call pattern, license declaration, initialization segment size and features, and string constant features. The malicious driver signature library includes the static behavioral features of known malicious drivers, and the normal driver baseline library includes the static behavioral features of known safe drivers; S500, obtaining a comprehensive security score by weighted summation of the resource rationality score and the behavioral feature security score; S600, determining whether the comprehensive security score is greater than a preset comprehensive threshold. If so, allowing the driver to load; otherwise, rejecting the driver loading.

[0027] When a user-mode application calls commands such as insmod / modprobe to request the loading of a driver, the request first enters kernel space. (See also...) Figure 2 The schematic diagram illustrates the overall system architecture. The security verification hook is located on the kernel's driver loading path, forming a driver interception module. This module intercepts the driver to be loaded from the normal loading process, preventing it from directly entering the ELF parsing and module initialization stages. Combined with... Figure 3 The schematic diagram illustrates the main flow from driver interception to final decision. After interception, the method sequentially performs static integrity verification and dynamic resource request analysis. Static behavioral characteristics include at least one of the following: overall file hash, code segment hash, symbol table call pattern, license declaration, initialization segment size and characteristics, and string constant characteristics.

[0028] This embodiment implements dual verification—static integrity check and dynamic resource behavior assessment—before the driver enters the kernel, effectively compensating for the shortcomings of traditional single static signature or hash verification. Even if a malicious driver has a legitimate signature, it can be identified through comparison of resource request rationality and behavioral characteristic baselines, thereby blocking drivers with abnormal behavior or excessive resource requests before loading, significantly improving the security protection capabilities of the Linux kernel.

[0029] In the above method, the security verification hook is registered between the kernel's system calls and format parsing. (See reference...) Figure 2 The system architecture diagram shown illustrates that the driver interception module is attached to the kernel driver loading path via a security verification hook. In the Linux kernel, the typical driver loading process involves the user-space `insmod / modprobe` command triggering the system calls `init_module` or `finit_module`, followed by the ELF parsing stage, and finally, `module_init` to complete initialization. This embodiment places the security verification hook between the system call and the ELF format parsing, intercepting the driver before the kernel executes module file parsing and before the driver image is actually incorporated into the kernel runtime. For example, this interception point can be implemented using the `security_load_module` hook function in the Linux Security Modules (LSM) framework, ensuring that all kernel modules to be loaded must first be reviewed by the security verification module.

[0030] By placing a security verification hook between system calls and ELF parsing, interception and verification of driver code and data can be completed before the kernel actually interprets and executes them. This prevents kernel state pollution or vulnerability exploitation that might be triggered by malicious drivers during the format parsing phase. Furthermore, this location is within the kernel's native loading path, allowing implementation via the LSM framework without modifying the kernel source code.

[0031] In the above method, performing static integrity verification on the driver further includes: reusing the encryption and integrity verification framework to perform digital signature verification on the driver; calculating the hash value of the driver file using a 256-bit secure hash algorithm and comparing it with the registered baseline hash value; determining whether the digital signature verification passes and whether the hash comparison is consistent; if yes, the driver is determined to have passed the static integrity verification; if no, the driver is determined to have failed the static integrity verification, the driver is refused to be loaded, and an audit log is recorded. Specifically, combined with Figure 2 The static verification module shown in the overall system architecture diagram and Figure 3 In step S2 of the main process, this embodiment first reuses the existing encryption and integrity verification framework in the Linux kernel to perform digital signature verification on the driver. For example, the kernel module signature mechanism (CONFIG_MODULE_SIG) or the Integrity Measurement Architecture (IMA) / Extended Verification Module (EVM) can be used to verify the signature chain of the .ko file. At the same time, the SHA-256 algorithm is used to calculate the hash value of the entire driver file, and the calculation result is compared with the benchmark hash value pre-registered in the trusted benchmark library. If the digital signature verification passes and the file hash value matches the benchmark hash value, the driver is determined to have passed the static integrity verification and enters the subsequent dynamic resource behavior evaluation stage; if any one of them fails, the static integrity verification is deemed to have failed, loading is directly refused, and the audit log is recorded.

[0032] By reusing existing mature frameworks such as IMA / EVM in the kernel to implement digital signature verification, and supplementing it with SHA-256 file hash comparison, the integrity and authenticity of the driver files can be ensured without introducing additional complex encryption implementations.

[0033] In the above method, the method for obtaining resource requirement information includes: parsing the module file structure of the driver and extracting the module information segment, identifying resource-related parameters from the parameter declaration fields of the module information segment; performing static analysis on the driver code, identifying the driver's resource allocation function calls, and obtaining the driver's resource allocation amount; wherein, the resource-related parameters include at least one of base address, interrupt number, and input / output port, and the resource allocation function calls include at least one of resource region allocation, memory mapping, and interrupt allocation. Specifically, refer to... Figure 4The schematic flowchart illustrating the dynamic resource request rationality verification process, from steps S301 to S303, first parses the module file structure from the intercepted driver file. Taking a Linux kernel module as an example, the module file is an ELF format .ko file containing a .modinfo section. This section declares module parameters (parm fields), such as base_addr, irq, io_port, etc., which constitute resource-related parameters. Further, static analysis is performed on the driver code to identify kernel function calls involving resource requests, such as request_region for I / O port resource region requests, ioremap for memory mapping, and request_irq for interrupt requests, and the corresponding resource request amounts are statistically analyzed. Through this combination of parsing and static analysis, resource requirement information at the driver declaration and actual coding levels is obtained.

[0034] By parsing explicit parameter declarations in the .modinfo section and resource allocation function calls in the static code, this embodiment achieves dual extraction of driver resource requirements. Compared to solutions that rely solely on module metadata, this embodiment can more comprehensively identify the memory address range, I / O ports, interrupt numbers, and other resources that the driver may actually occupy during loading and execution, providing a complete and reliable data foundation for subsequent resource rationality scoring.

[0035] In the above method, comparing the driver's resource requirements information with the system resource occupancy status to generate a resource rationality score further includes: based on the resource requirements information and system resource occupancy status, performing memory address range conflict detection, input / output port occupancy detection, interrupt number security range detection, and resource request range detection respectively; calculating the resource rationality score by weighted summation based on the detected memory address range conflict score, input / output port occupancy score, interrupt number security range score, and resource request range score, and no longer performing the step of extracting the driver's static behavioral features and comparing the static behavioral features with the malicious driver feature library and the normal driver baseline library respectively to generate a behavioral feature security score. Specifically, continue to refer to Figure 4The schematic flowchart for dynamic resource request rationality verification shows that in step S304, the system compares the previously acquired resource requirement information with the current system resource occupancy status item by item: checking whether the memory address range requested by the driver overlaps with the physical memory area already occupied by the kernel or the mapped I / O memory area; checking whether the I / O port requested is occupied by other devices or drivers; checking whether the interrupt number requested exceeds the system's allowed safe range or has been occupied; checking whether the amount of resources requested (such as memory size, DMA buffer size, etc.) exceeds the typical reasonable range for this type of driver. In step S305, if any of the checks shows a high risk, the corresponding conflict is directly marked and a load rejection path is triggered; if no high-risk item exists, in step S306, based on the four check results, a memory address range conflict score, an input / output port occupancy score, an interrupt number safety range score, and a resource request range score are generated respectively, and then weighted and summed according to the following formula to obtain the resource rationality score:

[0036] S_res=w_m×S_mem+w_i×S_io+w_q×S_irq+w_a×S_amt.

[0037] Wherein, S_mem is the memory address range conflict score, S_io is the input / output port occupancy score, S_irq is the interrupt number security range score, S_amt is the resource request range score, and w_m, w_i, w_q, and w_a are the corresponding weight coefficients, satisfying w_m + w_i + w_q + w_a = 1. The value range of each sub-score can be uniformly set to [0,1], where 1 indicates that it is completely reasonable and conflict-free, and 0 indicates that there is a serious conflict or the request exceeds the range. When S_res is lower than the preset resource threshold or any high-risk item exists, loading is directly rejected, and the behavioral feature security scoring step is not executed.

[0038] Specifically, the scoring rules for memory address range conflicts include: the kernel uses the allocated physical memory region table and I / O memory mapping table to detect address overlap between the memory mapping region declared by the driver to be loaded and each allocated interval. If there is no conflict and it is within the safe address whitelist (avoiding the BIOS reserved area, ACPI table area, and kernel image area), it is scored as 1.0; if there is no conflict but it is close to a high-risk area, such as the video memory reserved area, the evaluation score is scored as 0.9; if there is partial overlap but no high-risk boundary is triggered, the score is deducted linearly according to the overlap ratio; if there is a complete conflict or the restricted interval is hit, it is scored as 0 and marked as high risk.

[0039] Specifically, the scoring rules for input / output port occupancy include: the kernel maintains an allocated I / O port bitmap through the ioport_resource tree; the range of I / O ports declared by the driver to be loaded is bitwise ANDed with the allocated bitmap; if all bits are 0, it is initially determined that the port is not occupied; further, the kernel checks the safe port whitelist, avoiding the system reserved DMA / system controller port 0x00xFF and the ISA reserved area 0xC000xFFF; if this is passed, it is recorded as 1.0; finally, the kernel checks whether the number of ports is within the reasonable range of a normal driver (typically 1~32); if it exceeds the limit, points are deducted linearly according to the excess ratio; if any check fails, it is recorded as 0 and marked as high risk.

[0040] Specifically, the scoring rules for the interrupt number security range score include: the kernel uses the irq_desc status array and / proc / interrupts to count the occupancy of each IRQ. If the IRQ declared by the driver to be loaded does not appear in the registered interrupt vector table, it is initially determined that it is not occupied. The kernel compares the IRQ with the system's preset safe interrupt range, avoiding system reserved vectors such as IRQ0 / 1 / 2 / 3 / 4 / 6 / 8 / 13 / 14. If it belongs to a safe and reassignable IRQ, the kernel further checks whether the interrupt triggering method (shared, level-triggered) declared by the driver is compatible with the current processing method of the IRQ. Finally, the kernel counts the number of shared handlers for the IRQ in the loaded devices. If the occupancy rate reaches a medium level, it is recorded as 0.9. If any check fails, it is recorded as 0 and marked as high risk.

[0041] Specifically, the scoring rules for the resource request range score include: the kernel baseline library pre-stores the resource request statistical ranges for each type of driver according to device type, where μ is the mean and σ is the standard deviation. The statistical range for the DMA buffer request of a typical network card driver is [μ-2σ, μ+2σ]. If the resource request of the driver to be loaded is within the range of [μ-σ, μ+σ], it is recorded as 1.0; if it is within the range of [μ-2σ, μ+2σ] but deviates from the mean by 1σ to 2σ, it is linearly deducted to 0.6 to 0.8 according to the degree of deviation; if it is within the range of [μ-3σ, μ+3σ] but deviates from the mean by 2σ to 3σ, it is linearly deducted to 0.2 to 0.4 according to the degree of excess; if it exceeds [μ-3σ, μ+3σ] or is outside the preset high-risk boundary, it is recorded as 0 and marked as high risk.

[0042] By comparing the driver's resource requirements with the actual system occupancy in a multi-dimensional quantitative manner, this embodiment can identify resource conflicts or abnormal resource requests that may cause system stability issues before loading. In particular, it directly rejects loading when high-risk resource conflicts are detected, improving system operating efficiency and security.

[0043] In the above method, static behavioral features are compared with a malicious driver feature library and a normal driver baseline library respectively to generate a behavioral feature security score. This further includes: comparing the static behavioral features with the malicious driver feature library to obtain a malicious similarity score; comparing the static behavioral features with the normal driver baseline library to obtain a normal deviation score; and generating a behavioral feature security score based on the malicious similarity score and the normal deviation score. Specifically, refer to... Figure 5 The schematic flowchart of the behavioral feature baseline comparison process illustrates the following steps: In step S401, the system first extracts the static behavioral features of the driver to be loaded. These static behavioral features include at least the overall file hash, code segment hash, symbol table call pattern, license declaration, initialization segment size and content, and string constant features. In step S402, the static behavioral features are compared with a malicious driver feature library for similarity. For example, the minimum Hamming distance or cosine similarity between the code segment hash, symbol table call pattern, and known malicious samples is calculated to obtain a malicious similarity score S_mal. In step S403, the same static behavioral feature is compared with a normal driver baseline library for deviation. For example, the standard deviation of the driver to be loaded relative to the mean of the normal baseline in dimensions such as code segment size, initialization segment size, and number of critical system calls is statistically analyzed to obtain a normal deviation score S_dev. In step S404, a behavioral feature security score S_beh is generated based on S_mal and S_dev.

[0044] An exemplary calculation method is: S_beh=α×(1-S_mal)+β×(1-S_dev).

[0045] Where S_mal is the malicious similarity score, with a value of [0,1], the closer to 1, the more similar it is to the known malicious driver; S_dev is the normal deviation score, with a value of [0,1], the closer to 1, the greater the difference from the normal baseline; α and β are weighting coefficients.

[0046] Specifically, the static behavioral characteristics of the driver to be loaded are compared with each sample in the malicious driver feature library in multiple dimensions. The similarity of each dimension is weighted and summed according to preset weights to obtain the comprehensive similarity with a single malicious sample. After traversing the entire feature library, the maximum value is taken as the malicious similarity score.

[0047] Specifically, for the driver to be loaded, the deviation of its deviation from the mean and standard deviation of the normal driver baseline library samples is statistically analyzed in multiple dimensions. The ratio of the difference from the mean to the standard deviation of each dimension is obtained and mapped to [0,1] to obtain the score of each dimension. The normal deviation score is obtained by weighting and summing each dimension according to its weight.

[0048] By simultaneously performing bidirectional comparisons with both a malicious driver signature database and a normal driver baseline database, this embodiment can not only identify known malicious drivers but also discover unknown abnormal drivers whose behavioral characteristics significantly deviate from the normal baseline. By combining blacklist detection with whitelist baseline deviation detection, the false negative and false positive rates for malicious drivers are reduced.

[0049] In the above method, the method for updating the malicious driver signature library and the normal driver baseline library includes: in response to a driver being refused to load, writing the static behavioral characteristics of the driver as a new malicious driver sample increment into the malicious driver signature library; in response to a driver being allowed to load, collecting runtime behavioral data of the driver after the driver has finished loading, wherein the runtime behavioral data includes at least one of actual resource usage, runtime status data, and system environment change data; and updating the normal driver baseline based on the runtime behavioral data. Specifically, refer to... Figure 6 The schematic flowchart of the dynamic update process for the security baseline illustrates that, during normal system operation, this embodiment continuously monitors loaded drivers. When a driver is rejected from loading due to failing static integrity checks, resource rationality scores, or behavioral feature security scores, its static behavioral features are added as a new malicious driver sample increment to the malicious driver feature library so that subsequent similar drivers can be identified more quickly. Once a driver is allowed to load, after loading is complete and it enters the running state, the system collects its actual resource usage (such as actual memory usage, actual I / O port usage range, actual interrupt trigger frequency, etc.), running status data (such as error rate, number of crashes, loading time, etc.), and system environment change data (such as hardware replacement, kernel version upgrade, etc.). The system periodically or based on event triggers statistically compares the newly collected runtime behavioral data with the current normal driver baseline. If the deviation is within an acceptable range, the baseline statistical parameters (such as mean, variance, threshold) are smoothly fine-tuned to achieve smooth baseline updates; if the deviation exceeds the acceptable range, it is marked as abnormal fluctuation, and the baseline threshold is updated after manual review or automatic adjustment, and the normal driver baseline library is adjusted accordingly. The updated normal driver baseline library and malicious driver signature library take effect automatically and can be applied to subsequent driver loading security checks without restarting the system.

[0050] By continuously collecting driver behavior data and dynamically updating the security baseline during actual operation, this embodiment enables the malicious driver signature library and the normal driver baseline library to have adaptive capabilities.

[0051] In summary, this invention sets up security verification hooks on the kernel driver loading path to sequentially perform static integrity verification, dynamic resource request rationality assessment, and static behavioral feature baseline comparison. A weighted comprehensive security score is used as the final decision-making basis for whether to allow loading. At the same time, the malicious driver feature library and the normal driver baseline library are dynamically updated during system operation, forming a security defense system covering before, during, and after driver loading.

[0052] Based on the aforementioned dynamic security verification method for the Linux driver loading stage, this disclosure also provides a dynamic security verification system for the Linux driver loading stage, which can be used to implement the aforementioned dynamic security verification method for the Linux driver loading stage, including: a driver interception module, used to intercept the driver by utilizing a security verification hook registered on the driver loading path in the kernel when a driver to be loaded into the kernel exists; a static verification module, used to perform static integrity verification on the driver by verifying the driver's digital signature and file hash value; a resource analysis module, used to compare the driver's resource requirement information with the system resource occupancy status and generate a resource rationality score when the driver passes the static integrity verification; and behavioral characteristics. The comparison module extracts static behavioral features of the driver and compares these features with both a malicious driver signature library and a normal driver baseline library to generate a behavioral feature security score. The static behavioral features include at least one of the following: overall file hash, code segment hash, symbol table call pattern, license declaration, initialization segment size and features, and string constant features. The malicious driver signature library includes static behavioral features of known malicious drivers, and the normal driver baseline library includes static behavioral features of known safe drivers. The comprehensive judgment module calculates a comprehensive security score by weighting and summing the resource rationality score and the behavioral feature security score. It then determines whether the comprehensive security score exceeds a preset comprehensive threshold. If it does, the driver is allowed to load; otherwise, loading is refused.

[0053] Based on the same inventive concept, embodiments of the present invention also provide an electronic device. Figure 7 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Figure 7 As shown, an embodiment of the present invention provides an electronic device including: one or more processors 101, a memory 102, and one or more I / O interfaces 103. The memory 102 stores one or more programs, which, when executed by the one or more processors, enable the one or more processors to implement a dynamic security verification method as described in any of the Linux driver loading phases in the above embodiments; the one or more I / O interfaces 103 are connected between the processor and the memory, configured to enable information interaction between the processor and the memory.

[0054] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read / write interface) 103 is connected between the processor 101 and the memory 102, and can realize information interaction between the processor 101 and the memory 102, including but not limited to a data bus (Bus).

[0055] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.

[0056] In some embodiments, the one or more processors 101 include a field-programmable gate array.

[0057] This invention also provides a computer-readable medium. The computer-readable medium stores a computer program, which, when executed by a processor, implements the steps of the dynamic security verification method during the loading phase of any of the Linux driver embodiments described above. The computer-readable storage medium can be volatile or non-volatile.

[0058] This invention also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code. When the computer-readable code is run in the processor of an electronic device, the processor in the electronic device executes the dynamic security verification method of the Linux driver loading stage described above.

[0059] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0060] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0061] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0062] The computer program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing state information from the computer-readable program instructions. This electronic circuitry can execute the computer-readable program instructions to implement various aspects of the invention.

[0063] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0064] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0065] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0066] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0067] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0068] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of the invention as set forth in the appended claims.

Claims

1. A dynamic security verification method during the Linux driver loading phase, wherein, include: In response to the existence of a driver to be loaded into the kernel, the driver is intercepted using a security check hook registered on the driver loading path in the kernel; Static integrity checks are performed on the driver by verifying its digital signature and file hash value. In response to the driver passing the static integrity check, the resource requirement information of the driver is compared with the system resource occupancy status to generate a resource rationality score; Extract the static behavioral features of the driver, compare the static behavioral features with the malicious driver feature library and the normal driver baseline library respectively, and generate a behavioral feature security score. The static behavioral features include at least one of the following: overall file hash, code segment hash, symbol table call pattern, license statement, initialization segment size and features, and string constant features. The malicious driver feature library includes the static behavioral features of known malicious drivers, and the normal driver baseline library includes the static behavioral features of known safe drivers. A comprehensive security score is obtained by weighted summation of the resource rationality score and the behavioral characteristic security score; Determine whether the overall security score is greater than a preset overall threshold. If yes, allow the driver to load; otherwise, refuse to load the driver.

2. The method according to claim 1, wherein, The security verification hook is registered between the kernel's system calls and format parsing.

3. The method according to claim 1, wherein, The static integrity check performed on the driver includes: The encryption and integrity verification framework is reused to perform digital signature verification on the driver. The hash value of the driver file is calculated using a 256-bit secure hash algorithm and compared with the registered baseline hash value. Determine whether the digital signature verification passes and whether the hash comparison matches; If so, the driver is determined to have passed the static integrity check; If not, the driver is determined to have failed the static integrity check, the driver is refused to be loaded, and an audit log is recorded.

4. The method according to claim 1, wherein, The step of comparing the resource requirement information of the driver with the system resource occupancy status to generate a resource rationality score includes: Based on the resource demand information and the system resource occupancy status, memory address range conflict detection, input / output port occupancy detection, interrupt number security range detection, and resource request range detection are performed respectively. Based on the detected memory address range conflict score, input / output port occupancy score, interrupt number security range score, and resource request range score, a weighted summation is performed to calculate the resource rationality score. The steps of extracting the static behavior features of the driver and comparing the static behavior features with the malicious driver feature library and the normal driver baseline library to generate a behavior feature security score are no longer performed.

5. The method according to claim 1, wherein, The method for obtaining the resource demand information includes: By parsing the module file structure of the driver and extracting the module information segment, resource-related parameters are identified from the parameter declaration field of the module information segment; Static analysis is performed on the driver code to identify the resource request function calls of the driver and obtain the resource request amount of the driver; The resource-related parameters include at least one of base address, interrupt number, and input / output port, and the resource request function call includes at least one of resource region request, memory mapping, and interrupt request.

6. The method according to claim 1, wherein, The step of comparing the static behavioral features with both the malicious driver feature library and the normal driver baseline library to generate a behavioral feature security score includes: The static behavioral features are compared with the malicious driving feature library to obtain a malicious similarity score; The static behavioral features are compared with the normal driving baseline library to obtain a normal deviation score. The behavioral feature security score is generated based on the malicious similarity score and the normal deviation score.

7. The method according to claim 1, wherein, The method for updating the malicious driver signature database and the normal driver baseline database includes: In response to the driver being refused to load, the static behavioral characteristics of the driver are written into the malicious driver feature library as a new malicious driver sample increment. In response to the driver being allowed to load, after the driver is loaded, runtime behavior data of the driver is collected, wherein the runtime behavior data includes at least one of actual resource usage, running status data and system environment change data; The normal driver baseline is updated based on the runtime behavior data.

8. A dynamic security verification system for the Linux driver loading stage, characterized in that, A method for implementing dynamic security verification during the Linux driver loading phase as described in claim 1, comprising: The driver interception module is used to intercept a driver that is to be loaded into the kernel by using a security verification hook registered on the driver loading path in the kernel. The static verification module is used to perform static integrity verification on the driver by verifying the driver's digital signature and file hash value; The resource analysis module is used to compare the resource requirement information of the driver with the system resource occupancy status and generate a resource rationality score in response to the driver passing the static integrity check. The behavior feature comparison module is used to extract the static behavior features of the driver, compare the static behavior features with the malicious driver feature library and the normal driver baseline library respectively, and generate a behavior feature security score. The static behavior features include at least one of the following: overall file hash, code segment hash, symbol table call pattern, license statement, initialization segment size and features, and string constant features. The malicious driver feature library includes the static behavior features of known malicious drivers, and the normal driver baseline library includes the static behavior features of known safe drivers. The comprehensive judgment module is used to obtain a comprehensive security score by weighted summation of the resource rationality score and the behavioral feature security score; and to determine whether the comprehensive security score is greater than a preset comprehensive threshold. If so, the driver is allowed to load; otherwise, the driver is refused to load.

9. An electronic device, comprising: One or more processors; Storage device for storing one or more programs. Wherein, when the one or more programs are executed by the one or more processors, the one or more processors perform the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, cause the processor to perform the method according to any one of claims 1 to 7.

Images