Kernel driver module uninstallation method, electronic device, program product, and medium

Abstract

The present application discloses a kernel driver module uninstallation method, electronic device, program product, and medium, which relate to the field of operating system technology. First, the calling operations and system call table in the operating system can be monitored. The calling operations include module loading call, module unloading call, symbol call, and system resource allocation call. Subsequently, the symbol call relationship between kernel driver modules can be determined based on the symbol call to obtain the explicit dependency relationship between the kernel driver modules. Moreover, the same system resources used / hijacked same system calls between kernel driver modules can be determined based on the module loading call, system resource allocation call, and system call table to obtain the implicit dependency relationship between kernel driver modules. That is, the dependency relationship between kernel driver modules can be dynamically monitored. Furthermore, when the module unloading call is triggered, the unloading order between kernel driver modules can be determined based on the above dependency relationship, and the kernel driver modules can be unloaded in an orderly manner, thereby improving the unloading reliability.

Description

Technical Field

[0001] The present application relates to the field of operating system technology, and in particular to a kernel driver module uninstallation method, electronic device, program product, and medium. Background Art

[0002] In operating system software, kernel driver modules enhance the operating system's functionality and are a core component. Because kernel driver modules have dependencies on each other, the correct uninstallation order must be ensured. Incorrect uninstallation order can cause system crashes or functional failures.

[0003] In the related art, the uninstallation order of kernel driver modules is set only based on the statically recorded kernel driver module dependencies, which is not suitable for the dynamic dependencies between kernel driver modules. Summary of the Invention

[0004] The present application provides a kernel driver module uninstallation method, electronic device, program product, and storage medium, which can dynamically record the dependency relationship between kernel driver modules and determine the uninstallation order between kernel driver modules based on the dependency relationship, thereby improving the reliability of kernel driver module uninstallation.

[0005] This application provides a kernel driver module uninstallation method, including:

[0006] Monitor the call operations and system call table in the operating system; call operations include module loading calls, module unloading calls, symbol calls, and system resource allocation calls;

[0007] Determine the symbolic call relationship between kernel driver modules based on symbolic call, and obtain the explicit dependency relationship between kernel driver modules;

[0008] According to module loading calls, system resource allocation calls, and system call tables, the same system resources used by kernel driver modules / the same system calls hijacked are determined, and the implicit dependency relationship between kernel driver modules is obtained;

[0009] When the module uninstall call is triggered, the target kernel driver module to be uninstalled by the module uninstall call is determined, the uninstall order of the target kernel driver module and its associated kernel driver modules is determined according to the explicit dependency and implicit dependency, and the kernel driver module is uninstalled according to the uninstall order.

[0010] The present application also provides an electronic device, comprising:

[0011] memory for storing computer programs;

[0012] The processor is used to implement the above-mentioned kernel driver module unloading method when executing a computer program.

[0013] The present application also provides a computer program product, including a computer program or instructions, which implements the above-mentioned kernel driver module unloading method when the computer program or instructions are executed by a processor.

[0014] The present application also provides a non-volatile computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are loaded and executed by a processor, the above-mentioned kernel driver module unloading method is implemented.

[0015] The beneficial effects of the present invention are as follows: first, the present invention can monitor call operations and the system call table in the operating system. Call operations include module loading calls, module unloading calls, symbolic calls, and system resource allocation calls. Subsequently, the present invention can first determine the symbolic call relationships between kernel driver modules based on the symbolic calls, thereby obtaining explicit dependencies between the kernel driver modules. Furthermore, the present invention can also determine the same system resources used / hijacked by the kernel driver modules based on the module loading calls, system resource allocation calls, and the system call table, thereby obtaining implicit dependencies between the kernel driver modules. Specifically, the present invention can not only determine the dependencies between the kernel driver modules based on the same system resources used / hijacked by the kernel driver modules, but also dynamically detect these implicit dependencies. Finally, when a module unloading call is triggered, the present invention can determine the target kernel driver module to be unloaded by the module unloading call, and determine the unloading order of the target kernel driver module and its associated kernel driver modules based on the explicit and implicit dependencies. The kernel driver modules can then be unloaded based on the unloading order, adapting to the dynamic dependencies between kernel driver modules and thereby improving the reliability of kernel driver module unloading.

[0016] The present invention also provides an electronic device, a computer program product, and a non-volatile computer-readable storage medium, which have the above-mentioned beneficial effects. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0018] Figure 1 A flowchart of a kernel driver module uninstallation method provided by an embodiment of the present invention;

[0019] Figure 2 A schematic diagram of a kernel driver module unloading device provided by an embodiment of the present invention;

[0020] Figure 3 A flowchart of another kernel driver module uninstallation method provided by an embodiment of the present invention;

[0021] Figure 4 A structural block diagram of another kernel driver module unloading device provided by an embodiment of the present invention;

[0022] Figure 5 This is a structural block diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0023] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0024] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0025] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0026] In operating system software, kernel driver modules enhance operating system functionality and are core components of the operating system. Dependencies exist between kernel driver modules. These dependencies are reflected not only in explicit calling relationships between kernel driver modules but also in their shared use of system resources (such as memory and handles) and their joint hijacking of system calls. For example, mainstream kernel driver-based host security software primarily implements system call hijacking. If multiple security software programs are installed on the same host, and their kernel driver modules hijack the same system call, this creates an implicit dependency between them. This means that kernel driver module A dynamically loads a function pointer from kernel driver module B without explicitly calling it through symbols. In this case, uninstalling kernel driver module B will cause kernel driver module A to trigger a null pointer exception. For another example, if multiple kernel driver modules communicate through shared memory, releasing a memory segment after uninstalling one kernel driver module can trigger memory out-of-bounds accesses by other kernel driver modules. Therefore, uninstalling kernel driver modules becomes more complex when multiple modules depend on each other. The correct uninstallation order must be ensured during uninstallation. An incorrect uninstallation sequence can lead to system crashes or functional failures.

[0027] In related technologies, three methods are usually used to determine the uninstallation order of kernel driver modules:

[0028] 1. Static dependency management: Using the pre-generated static file modules.dep containing the dependencies of each kernel driver module, when loading or unloading a kernel driver module, it checks whether the other kernel driver modules it depends on have been loaded or unloaded. Dependency relationships are usually generated by the depmod tool when installing the system or compiling the system kernel.

[0029] 2. Reference counting mechanism: The kernel maintains a reference count for each kernel driver module, counting explicit usage such as symbol calls and user space handles. A reference count of 0 indicates that the driver module is not used by other driver modules and can be uninstalled.

[0030] 3. Fixed uninstallation order: Uninstall driver modules in a predefined order. For example, if you know that driver module A depends on driver module B, uninstall driver module B first, then uninstall driver module A.

[0031] However, static dependency management cannot perceive the dynamic runtime dependencies of kernel driver modules. If a module references other modules through dynamic loading, conditional triggering, etc. at runtime, the static file cannot record these temporary dependencies. For example, module A calls request_module("B") to load module B after a specific event is triggered, but modules.dep does not contain the dependency relationship from A to B. In addition, reference counting cannot distinguish dependency levels, and reference counting only counts the total number of dependencies of each driver module, and cannot identify dependency relationships. In addition, by fixing the uninstallation order, it is impossible to adapt to scenarios where runtime dependencies change dynamically, such as real-time adjustments of module dependencies due to external configuration in a container environment.

[0032] In view of this, in order to solve the technical problem of how to orderly uninstall kernel driver modules based on the dynamic dependencies between kernel driver modules, the present invention can provide a kernel driver module unloading method. First, the call operations and system call table in the operating system can be monitored to dynamically determine the explicit and implicit dynamic dependencies between kernel driver modules. Then, when the modules are unloaded, the unloading order of the kernel driver modules can be determined based on the dynamic dependencies, thereby improving the reliability of kernel driver module unloading.

[0033] It should be noted that this embodiment does not limit the hardware device that executes this method; the hardware device can be configured based on actual application requirements. For example, it can be a mobile device (such as a mobile phone or tablet), a personal computer, or a server. Furthermore, since the present invention involves monitoring the kernel state of an operating system, the present invention can include a kernel detection mechanism within the local machine and implement kernel state monitoring through this mechanism. This embodiment does not limit the specific kernel detection mechanism; for example, it can be a kprobe, eBPF, etc.

[0034] For easier understanding, please refer to Figure 1 , Figure 1 A flowchart of a kernel driver module uninstallation method provided by an embodiment of the present invention may include:

[0035] S101. Monitor the call operations and system call table in the operating system; the call operations include module loading call, module unloading call, symbol call, and system resource allocation call.

[0036] In this step, in order to determine the dynamic dependency between kernel driver modules, it is first necessary to monitor the call operations and system call table in the operating system.

[0037] Call operations are those related to kernel driver module startup, operation, and uninstallation. These operations can be used to determine a kernel driver module's calls to other kernel driver modules and its use of system resources. These monitored call operations include module loading calls (init_module), module uninstallation calls (delete_module), symbolic calls (request_module), and system resource allocation calls (such as the memory allocation function kmalloc). Module loading calls load kernel driver modules; module uninstallation calls uninstall kernel driver modules; symbolic calls allow kernel driver modules to call each other; and system resource allocation calls allow kernel driver modules to request system resources.

[0038] In addition, by monitoring write events in the system call table (sys_call_table), the kernel driver module that intercepted the system operation and the system call number of the intercepted system operation can be determined. The present invention can record the kernel driver modules that intercepted the same system call number and establish a dependency relationship between the kernel driver modules that intercepted the same system call number.

[0039] It should be noted that this embodiment does not limit how to monitor the call operation in the operating system. For example, a hook function can be set in the operation function corresponding to the call operation, and the hook function can be used to detect the triggering of the call operation and obtain the call information of the call operation through the hook function.

[0040] Based on this, monitoring of the call operations triggered in the operating system can include:

[0041] Step 11: Set the hook function in the operation function corresponding to the calling operation.

[0042] Step 12: Use the hook function to detect the triggering of the call operation, and obtain the call information of the call operation through the hook function.

[0043] S102: Determine the symbolic call relationship between the kernel driver modules according to the symbolic call, and obtain the explicit dependency relationship between the kernel driver modules.

[0044] In this step, the symbol call function request_module(const char *fmt,...) is first resolved to obtain the symbol call relationship between kernel driver modules and use it as an explicit dependency. For example, in the following example, module B exports a function, and module A references module B's symbol. This is called module A explicitly depends on module B (A→B):

[0045] Module B:

[0046] void b_function(void) { ...} / / ;

[0047] EXPORT_SYMBOL(b_function);

[0048] Module A:

[0049] extern void b_function(void);

[0050] a_function() { b_function();} / / .

[0051] S103: Determine the same system resources used / hijacked same system calls between kernel driver modules according to module loading calls, system resource allocation calls, and a system call table, and obtain implicit dependencies between kernel driver modules.

[0052] In this step, it is considered that in addition to establishing explicit dependencies between kernel driver modules through symbolic calls, they can also establish implicit dependencies by sharing system resources and hijacking the same system calls. However, this implicit dependency is usually established dynamically and cannot be recorded by pre-setting static associations between kernel driver modules. Therefore, this embodiment can dynamically monitor module loading calls, system resource allocation calls, and system call tables, thereby dynamically determining the same system resources used / the same system calls hijacked between kernel driver modules, thereby establishing implicit dependencies between kernel driver modules that access the same system resources and establishing implicit dependencies between kernel driver modules that hijack the same system calls. It can be seen that this embodiment can effectively record the dynamic dependencies between kernel driver modules, thereby improving the reliability of kernel driver module unloading.

[0053] Specifically, this embodiment can determine the same system resources used between kernel driver modules based on module loading calls and system resource allocation calls, and can determine the same system calls hijacked between kernel driver modules based on a system call table.

[0054] Based on this, the same system resources used by kernel driver modules / the same system calls hijacked are determined based on module loading calls, system resource allocation calls, and the system call table. The implicit dependencies between kernel driver modules are obtained, which may include:

[0055] Step 21: Determine the same system resources accessed by the kernel driver modules based on the module loading call and the system resource allocation call, and establish an implicit dependency relationship between the kernel driver modules that access the same system resources.

[0056] It should be noted that kernel driver modules can share various system resources, such as memory and handles.

[0057] Step 22: Determine the same system calls hijacked between kernel driver modules according to the system call table, and establish implicit dependency relationships between the kernel driver modules that hijack the same system calls.

[0058] The following describes how to determine the same system resources accessed by kernel driver modules based on module loading calls and system resource allocation calls based on a specific example. Based on this, determining the same system resources accessed by kernel driver modules based on module loading calls and system resource allocation calls may include:

[0059] Step 31: When a system resource allocation call is triggered, determine the memory address allocated by the system resource allocation call and the first kernel driver module that triggers the system resource allocation call.

[0060] Step 32: When the module loading call is triggered, determine the second kernel driver module loaded by the module loading call.

[0061] Step 33: Read the kernel code of the second kernel driver module and determine whether the second kernel driver module uses the memory address.

[0062] Step 34: If it is determined that the second kernel driver module uses the memory address, then determine that the first kernel driver module and the second kernel driver module use the same memory resource.

[0063] Steps 31-34 demonstrate how to determine whether kernel driver modules use the same memory address. First, when a system resource allocation call (specifically, kmalloc) is triggered, the memory address allocated by the system resource allocation call can be determined, and the first kernel driver module that triggered the system resource allocation call can be identified through the call stack. Subsequently, when a module load call is triggered, the currently loaded second kernel driver module can be determined, and the code segment of the second kernel driver module can be scanned to determine whether the second kernel driver module uses the memory address allocated for the first kernel driver module. If the second kernel driver module is determined to use this memory address, it can be determined that the first and second kernel driver modules use the same memory resources. Consequently, the two kernel driver modules have an implicit association, and the second kernel driver module is dependent on the first kernel driver module.

[0064] As can be seen, in this embodiment, the first kernel driver module and the second kernel driver module do not have a direct calling relationship, but rather establish a dependency relationship through shared memory. Related technologies cannot record this implicit dependency, but the present invention can detect and extract this implicit dependency through dynamic detection, thereby improving the reliability of kernel driver module uninstallation.

[0065] S104. When the module uninstall call is triggered, determine the target kernel driver module to be uninstalled by the module uninstall call, determine the uninstall order of the target kernel driver module and its associated kernel driver modules according to the explicit dependency and implicit dependency, and uninstall the kernel driver modules according to the uninstall order.

[0066] In this step, when a module uninstall call is determined to be triggered, the target kernel driver module to be uninstalled by the module uninstall call can be first determined. Subsequently, the target kernel driver module and its associated kernel driver modules can be determined based on explicit dependencies and implicit dependencies, and the uninstallation order of the target kernel driver module and its associated kernel driver modules can be determined. Finally, the kernel driver modules can be uninstalled according to the uninstallation order.

[0067] It's important to note that the associated kernel driver modules here refer to kernel driver modules that directly or indirectly depend on the target kernel driver module. For example, if module A depends on module B, and module B depends on module C, then module B directly depends on module C, and module A indirectly depends on module C. To uninstall module C, both modules A and B must be uninstalled.

[0068] It can be seen that, in this embodiment, when uninstalling the kernel driver module, all dynamically dependent modules can be uninstalled, thereby improving the uninstallation reliability and avoiding system crash or function failure caused by the wrong uninstallation sequence.

[0069] Furthermore, to improve the efficiency of determining the uninstallation order, this embodiment can use the above-mentioned explicit dependencies and implicit dependencies to construct a dependency graph, record the above-mentioned dependencies in a graphical form, and generate the uninstallation order based on the dependency graph.

[0070] Based on this, the method may further include:

[0071] Step 41: Create nodes and directed edges based on explicit dependencies and implicit dependencies; nodes represent kernel driver modules, and directed edges represent dependencies between kernel driver modules.

[0072] In this step, nodes and directed edges are created based on explicit and implicit dependencies. Nodes represent kernel driver modules, and directed edges represent dependencies between kernel driver modules. For example, if module A depends on module B, the directed edge between modules A and B is A→B.

[0073] Step 42: Add nodes and directed edges to the dependency graph.

[0074] In one possible scenario, the following data structure can be used to record the dependencies between modules:

[0075] struct dependency_graph { / / Dependency graph data structure;

[0076] struct list_head nodes; / / node list (module);

[0077] struct rb_root fast_lookup; / / Fast lookup of red-black tree root;

[0078] spinlock_t lock; / / concurrent access lock;

[0079] }; / / End of data structure.

[0080] struct dependency_node { / / node structure;

[0081] char *name; / / module name;

[0082] atomic_t ref_count; / / Number of references;

[0083] struct list_head dependents; / / Modules that depend on this node;

[0084] struct list_head dependencies; / / Modules that this node depends on;

[0085] struct list_head pending_ops; / / pending uninstall operation queue;

[0086] }; / / End of data structure.

[0087] Accordingly, determining the uninstallation order of the target kernel driver module and its associated kernel driver modules according to the explicit dependency relationship and the implicit dependency relationship may include:

[0088] Step 51: In the dependency graph, determine the kernel driver modules that are directly or indirectly dependent on the target kernel driver module and use them as associated kernel driver modules, and determine the uninstallation order of the target kernel driver module and the associated kernel driver modules.

[0089] Furthermore, since recording and updating the dependency graph consumes relatively high computing resources, it will increase the burden on the local machine when the local machine is in a high-load state. Therefore, before creating nodes and directed edges based on the above-mentioned dependency relationships, this embodiment can also obtain the hardware resource occupancy rate of the electronic device (i.e., the local machine). If the hardware resource occupancy rate is greater than a preset threshold, only explicit dependencies and implicit dependencies can be recorded. If the hardware resource occupancy rate is not greater than the preset threshold, nodes and directed edges can be created based on the explicit dependencies and implicit dependencies, and the dependency graph can be updated.

[0090] Based on this, before creating nodes and directed edges based on explicit dependencies and implicit dependencies, you can also include:

[0091] Step 61: Determine whether the hardware resource usage of the electronic device is greater than a preset threshold.

[0092] Step 62: If the hardware resource usage is greater than a preset threshold, the explicit dependency and the implicit dependency are recorded.

[0093] Step 63: If the hardware resource usage is not greater than the preset threshold, proceed to the step of creating nodes and directed edges according to explicit dependencies and implicit dependencies.

[0094] For example, CPU utilization can be derived from the kernel_cpustat structure (kernel_processor status) by obtaining CPU time statistics. In high-load scenarios, when CPU utilization exceeds 80%, lazy graph update mode is triggered, which only records dependency change events and delays updates to the global dependency graph. If it is below 80%, the dependency graph is updated.

[0095] Based on the above embodiments, the present invention can first monitor call operations and the system call table in the operating system. These call operations include module load calls, module unload calls, symbol calls, and system resource allocation calls. Subsequently, the present invention can first determine the symbolic call relationships between kernel driver modules based on the symbolic calls, thereby obtaining explicit dependencies between the kernel driver modules. Furthermore, the present invention can also determine the same system resources used / hijacked by the kernel driver modules based on the module load calls, the system resource allocation calls, and the system call table, thereby obtaining implicit dependencies between the kernel driver modules. This not only determines the dependencies between the kernel driver modules based on the same system resources used / hijacked by the kernel driver modules, but also dynamically detects these implicit dependencies. Finally, when the module unload call is triggered, the present invention can determine the target kernel driver module to be unloaded by the module unload call, and determine the unloading order of the target kernel driver module and its associated kernel driver modules based on the explicit and implicit dependencies. The kernel driver modules can then be unloaded based on this unloading order, adapting to the dynamic dependencies between kernel driver modules and thereby improving the reliability of kernel driver module unloading.

[0096] Based on the above embodiment, considering that the dependencies between kernel driver modules are relatively complex, such as when multiple kernel driver modules are interdependent, it is difficult to directly determine the order in which the kernel driver modules should be uninstalled based on the dependencies. Therefore, in this embodiment, the hierarchy and importance of the kernel driver modules can be determined based on the dependencies between the kernel driver modules and the kernel driver modules' usage of system resources. The uninstallation order can then be determined based on the hierarchy and importance, thereby further improving the reliability of kernel driver module uninstallation.

[0097] The following first determines the module hierarchy and importance. Based on this, the method may also include:

[0098] S201 . In a dependency graph, divide each kernel driver module into layers according to the dependency relationship and the number of dependencies of each node to obtain a layer corresponding to each kernel driver module.

[0099] In this step, each kernel driver module is first divided into layers based on the dependencies and number of dependencies of each node, obtaining the corresponding layer for each kernel driver module. This is because the deeper the kernel driver module's layer, the more likely it is to be dependent on other kernel driver modules, making it more difficult to uninstall. On the other hand, the shallower the kernel driver module's layer, the less likely it is to be dependent on other kernel driver modules, or even not at all, making it easier to uninstall. Therefore, the layer is a key factor in determining the order in which kernel driver modules are uninstalled.

[0100] Specifically, in this embodiment, the layers can be divided into three types: basic layer, middle layer, and leaf layer. The following is the division method of these three layers:

[0101] Based on this, the kernel driver modules are divided into levels according to the dependency relationship and the number of dependencies of each node, and the corresponding levels of each kernel driver module are obtained, which may include:

[0102] Step 71: Divide the nodes whose number of dependencies is greater than a preset threshold into the base layer.

[0103] In this step, the kernel module of the base layer belongs to the kernel module of the operating system, such as a file system driver.

[0104] Step 72: Divide the nodes whose number of dependencies is not greater than a preset threshold and which depend on the base layer nodes into the middle layer.

[0105] In this step, the kernel module of the middle layer belongs to the module that depends on the base layer but is also depended on by other modules.

[0106] Step 73: Divide the nodes that depend on the middle-layer nodes but are not depended on into the leaf layer.

[0107] In this step, the kernel modules of the leaf layer only depend on other modules, but are not depended on by other modules.

[0108] S202 : Perform weighted processing on the amount of system resources and the level used by each kernel driver module to obtain a module importance value of each kernel driver module.

[0109] In this step, the amount of system resources used by each kernel driver module (such as memory usage and number of handles) must also be obtained. This is because the more system resources a kernel driver module uses, the greater the number of potential kernel driver modules that share system resources with it. Consequently, uninstalling this kernel driver module will impact a larger number of kernel driver modules. Subsequently, this step can weight the amount of system resources used and the level of each kernel driver module to obtain a module importance value for each kernel driver module. One possible weighting method could be:

[0110] W = α⋅memory_usage + β⋅handle_count + γ⋅depth;

[0111] Where W represents the module's importance; memory_usage represents memory usage, handle_count represents the number of handles, and depth represents the depth of the hierarchy. α, β, and γ are adjustable coefficients reflecting the importance of different resources. α and β measure the impact of module resource usage on offload priority. It's worth noting that α, β, and γ can be adjusted based on application requirements. For example, for resource-sensitive systems (such as embedded devices), α and β may need to be increased. γ reflects the impact of the dependency hierarchy on offload priority. Higher dependency levels increase coupling, and systems with high real-time requirements (such as industrial control) require a higher γ.

[0112] Furthermore, after obtaining the above dependency graph, the uninstallation order can be pre-determined in the dependency graph based on the hierarchy and module importance numbers, so that a quick uninstallation can be performed when a module uninstallation call is triggered. The following describes the specific process of determining the uninstallation order based on the hierarchy and module importance numbers. Based on this, the method can also include:

[0113] S301: Detect whether there is a strongly connected component in the dependency graph.

[0114] In this embodiment, a strongly connected component refers to a set of nodes in a directed graph where any two nodes are reachable from each other (e.g., paths u→v and v→u exist). If a dependency graph contains strongly connected components, then there is a circular dependency between the modules. For example, if module A depends on B, and B also depends on A, then modules A and B cannot be uninstalled sequentially.

[0115] When strongly connected components are detected, considering that there may be multiple sets of circular dependencies within the dependency graph, the classic topological sorting algorithm cannot be used to determine the uninstallation order between modules. Other means are needed to generate the uninstallation order.

[0116] Of course, if no strongly connected components are detected, it means that the dependency in the dependency graph is linear, and the classic topological sorting algorithm can be used to determine the unloading order.

[0117] S302: If there is no strongly connected component, the topological structure of the dependency graph determines a third uninstallation order.

[0118] In this step, the third uninstallation order is the linear uninstallation order between kernel driver modules. For example, if there is an edge u→v in the dependency graph, then in the sorting result, module u must be uninstalled before node module v.

[0119] Furthermore, after obtaining the third uninstallation sequence, when the module uninstallation call is triggered, the uninstallation sequence of the target kernel driver module and the associated kernel driver modules can be directly determined according to the third uninstallation sequence.

[0120] Accordingly, determining the uninstallation order of the target kernel driver module and the associated kernel driver modules may include:

[0121] Step 81: Determine the uninstallation order of the target kernel driver module and the associated kernel driver modules according to the third uninstallation order.

[0122] S303. If there is a strongly connected component, the strongly connected component is converted into a special node and the dependency graph is updated. At the same time, the module importance value of the special node is determined according to the module importance values ​​of the kernel driver modules forming the strongly connected component.

[0123] In this step, if a strongly connected component is detected in the dependency graph, it is necessary to collapse the strongly connected component into a single special node, that is, to use the special node to replace the multiple nodes that constitute the strongly connected component. Subsequently, this embodiment can update the dependency graph based on the special node until the circular dependency in the dependency graph is eliminated. It is understood that the multiple kernel driver modules corresponding to the special node must be uninstalled simultaneously, and cannot be uninstalled sequentially.

[0124] Furthermore, since this embodiment uses special nodes to replace multiple kernel driver modules, the module importance value of the special node needs to be re-determined based on the module importance values ​​of the kernel driver modules that form the strongly connected components.

[0125] S304 . In the updated dependency graph, each node is divided into levels according to the dependency relationship and the number of dependencies of each node to obtain the node level of each node.

[0126] In this step, after using special nodes to update the dependency graph, each node needs to be re-divided into levels based on the dependency relationship and the number of dependencies of each node to obtain the node level of each node. The specific division method can be referred to steps 71 to 73 and will not be repeated here.

[0127] S305 , sorting the modules of each node in each node level according to their module importance values ​​to obtain the first uninstallation order in each node level.

[0128] In this step, since the importance of each node and special node is different, it is necessary to sort the modules of each node according to their importance values ​​in each node level to obtain the first uninstallation order in each node level, so as to prioritize the kernel driver modules corresponding to the most important nodes for uninstallation.

[0129] S306: Determine a second uninstallation order among node levels.

[0130] In this step, the second unloading order between node layers may be, for example, leaf layer→middle layer→base layer.

[0131] Furthermore, after obtaining the first uninstallation order and the second uninstallation order, when the module uninstallation call is triggered, the uninstallation order of the target kernel driver module and the associated kernel driver modules can be directly determined according to the first uninstallation order and the second uninstallation order.

[0132] Accordingly, determining the uninstallation order of the target kernel driver module and the associated kernel driver modules may include:

[0133] Step 91: Determine the uninstallation order of the target kernel driver module and the associated kernel driver modules according to the first uninstallation order and the second uninstallation order.

[0134] The following describes the kernel driver module uninstallation process. Based on this, kernel driver module uninstallation can include:

[0135] S401: Determine the node to be uninstalled according to the uninstallation order, and judge whether the node is a special node.

[0136] S402: If the node is not a special node, uninstall the kernel driver module corresponding to the node.

[0137] S403: If the node is a special node, all kernel driver modules forming the special node are uninstalled as a whole.

[0138] In steps S401-S403, because a special node corresponds to multiple kernel driver modules, and these multiple kernel driver modules need to be uninstalled simultaneously, it is necessary to determine whether the node to be uninstalled is a special node before uninstallation. If it is a special node, all kernel driver modules that form the special node must be uninstalled as a whole. If it is not a special node, the kernel driver module corresponding to the node is directly uninstalled.

[0139] Furthermore, considering that the kernel driver module may fail to be uninstalled due to many factors, this embodiment can also move the kernel driver module that failed to be uninstalled to a waiting queue, and retry the uninstallation at a scheduled time or wait for an external event to trigger.

[0140] Based on this, after uninstalling the kernel driver module according to the uninstallation order, the following steps may also be included:

[0141] Step 1101: If the kernel driver module fails to be uninstalled, the kernel driver module is added to the queue to be processed and the dependency graph is updated.

[0142] Step 1102: If the kernel driver module is successfully uninstalled, the dependency graph is updated.

[0143] Step 1103: Periodically trigger module uninstall call for the kernel driver module in the queue to be processed. If the kernel driver module in the queue to be processed is successfully uninstalled, it is removed from the queue to be processed.

[0144] It is worth noting that the kernel driver module moved into the pending queue has been logically uninstalled, so other kernel driver modules cannot call the kernel driver module moved into the pending queue. To this end, this embodiment can also determine whether the kernel driver module targeted by the call operation is in the pending queue when the call operation is triggered. If it is, the call operation can be blocked to achieve the effect of logical uninstallation for the module that failed to be uninstalled.

[0145] Based on this, the method may further include:

[0146] Step 1201: When it is determined that a call operation is triggered, it is determined whether the kernel driver module targeted by the call operation is in a queue to be processed.

[0147] Step 1202: If yes, the calling operation is shielded.

[0148] Step 1203: If not, the call operation is released.

[0149] Based on the above embodiment, the following describes the above kernel driver module uninstallation method based on specific schematic diagrams and examples. Figure 2 , Figure 2 This is a schematic diagram of a kernel driver module uninstallation device provided by an embodiment of the present invention. The device may include a dynamic dependency capture module, a dependency graph modeling and updating module, an autonomous uninstallation order derivation module, a conflict handling module, and a performance optimization module. The dynamic dependency capture module uses kprobes to monitor kernel driver module loading and unloading, resource allocation system calls, symbolic calls, and the sys_call_table, recording explicit and implicit dependencies. The dependency graph modeling and updating module uses a directed graph to represent the dependencies between kernel driver modules in real time. The autonomous uninstallation order derivation module uses a hierarchical sorting algorithm based on resource weights to resolve uninstallation order issues in circular dependency scenarios. When the conflict handling module detects a module that cannot be uninstalled, it initiates an adaptive degradation protocol, adds the module to a pending queue, and periodically retries or waits for external event triggers. The performance optimization module, under high load (system CPU usage >80%), only records dependency change events, delaying dependency graph merging to reduce performance overhead. When the load decreases, it immediately merges the event queues to ensure real-time dependency graph performance.

[0150] Please refer to Figure 3 , Figure 3 A flowchart of another kernel driver module uninstallation method provided by an embodiment of the present invention, the process specifically includes:

[0151] (1) Initialize the dependency graph: Define a dependency graph, which involves the following two data structures. Dependency graph: Nodes are modules, and edges are dependency relationships (if A depends on B, there is an edge A->B). Module information table: Stores the name, status, and dependency list of each module.

[0152] struct dependency_graph { / / Data structure header;

[0153] struct list_head nodes; / / node list (module);

[0154] struct rb_root fast_lookup; / / Fast lookup of red-black tree root;

[0155] spinlock_t lock; / / concurrent access lock;

[0156] };

[0157] struct dependency_node { / / Data structure header;

[0158] char *name; / / module name;

[0159] atomic_t ref_count; / / Number of references;

[0160] struct list_head dependents; / / Modules that depend on this node;

[0161] struct list_head dependencies; / / Modules that this node depends on;

[0162] struct list_head pending_ops; / / pending uninstall operation queue;

[0163] }.

[0164] (2) Monitor core system calls and symbols: Use kprobe to perform real-time dependency monitoring on module loading and unloading system calls, resource allocation system calls, symbolic calls, and sys_call_table.

[0165] (3) Parse metadata to obtain dependencies: Analyze the parameters of the core system calls and symbols monitored in step (2). By parsing the module loading function init_module(void __user *umod, unsigned long len,const char __user *uargs) after the hook, obtain the module name and the number of times this module is referenced. By parsing the symbol call request_module(const char *fmt, ...), obtain the module dependency. By parsing resource allocation system calls such as void *kmalloc(size_t size, int flags), identify implicit dependencies, such as recording the memory address allocated by kmalloc and the call stack. When loading the kernel driver module, scan the code segment of the module to determine whether the memory address is used by the driver module. If it is used, it means there is a dependency. Based on the function address in the call stack information, query / proc / kallsyms to determine which kernel driver module triggered the kmalloc call. By monitoring the write events of sys_call_table, the hijacked module and system call number can be obtained. When other driver modules want to hijack the same system call number, the dependency relationship is obvious.

[0166] (4) Calculate CPU utilization and make a judgment: CPU time statistics can be directly obtained through the kernel_cpustat structure to determine CPU utilization. In high-load scenarios, when CPU utilization exceeds 80%, the lazy update graph mode is triggered. That is, only dependency change events are recorded and updates to the global dependency graph are delayed. If it is not higher than 80%, proceed to step (5).

[0167] (5) Update the dependency graph: Use the dependency_graph data structure defined in step (1) to represent module dependencies. Add dependency edges: For example, when module A calls request_module("B"), add an A→B edge. If B is not loaded, trigger a cascade load and mark A as a dependent of B.

[0168] (6) Weight Assignment: Each module is assigned a weight based on its resource usage (memory, handle count) and dependency level. Formula: W = α⋅memory_usage + β⋅handle_count + γ⋅depth, where α, β, and γ are adjustable coefficients reflecting the importance of different resources. α and β measure the impact of module resource usage on the uninstallation priority. Resource-sensitive systems (such as embedded devices) require increasing α and β; γ reflects the impact of the dependency level on the uninstallation priority. The higher the dependency level, the greater the coupling. Systems with high real-time requirements (such as industrial control) require increasing γ.

[0169] (7) Hierarchical division: Base layer: core modules that are depended on by multiple modules (such as file system drivers). Middle layer: modules that depend on the base layer but are also depended on by other modules. Leaf layer: modules that only depend on other modules and are not depended on by other modules.

[0170] (8) Detecting Circular Dependencies: Detect strongly connected components (SCCs) using the Tarjan algorithm. A strongly connected component is a set of nodes in a directed graph where any two nodes are reachable from each other (paths u→v and v→u exist). If an SCC contains at least two nodes, then there is a circular dependency within the SCC (e.g., module A depends on B, and B also depends on A). If there is no circular dependency, a classic topological sort, i.e., a linear sorting algorithm, is used. Specifically, if there is an edge u→v in the graph, then in the sorting result, node u must appear before node v.

[0171] (9) Hierarchical sorting: Calculate the cumulative resource weight W = ∑W(m) of all modules in the SCC, shrink each SCC into a single node, form a new directed unordered graph, and layer it according to the topological order of the shrinking graph, from the leaf layer to the base layer. In each layer, the SCCs are sorted in descending order according to their weight, forming a global dependency graph unloading sequence.

[0172] (10) Uninstallation: Detect the module to be uninstalled by hijacking delete_module() and uninstall it according to the global dependency graph uninstall sequence. That is, uninstall from the leaf layer to the base layer in order, and execute within the layer according to the sorting result. If the uninstallation fails, go to step (11), otherwise go to step (12).

[0173] (11) Add to the delay queue: If the module cannot be uninstalled, the module will be added to the pending queue and retried periodically or wait for external events to trigger, such as sending a notification to the user-mode management process through Netlink for manual decision-making or scripted processing.

[0174] (12) Update the dependency graph: remove nodes and update the dependencies of related edges.

[0175] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0176] The embodiment of the present application also provides a kernel driver module unloading device. Figure 4 , Figure 4 A structural block diagram of another kernel driver module unloading device provided by an embodiment of the present invention, the device may include:

[0177] Monitoring module 401 is used to monitor the call operations and system call table in the operating system; the call operations include module loading call, module unloading call, symbol call, and system resource allocation call;

[0178] An explicit dependency relationship determination module 402 is configured to determine the symbolic call relationship between kernel driver modules based on the symbolic call, and obtain the explicit dependency relationship between the kernel driver modules;

[0179] An implicit dependency determination module 403 is configured to determine the same system resources used or the same system calls hijacked between kernel driver modules based on module loading calls, system resource allocation calls, and a system call table, thereby obtaining implicit dependencies between kernel driver modules.

[0180] Uninstall module 404 is used to determine the target kernel driver module to be uninstalled by the module uninstall call when the module uninstall call is triggered, determine the uninstall order of the target kernel driver module and its associated kernel driver modules according to the explicit dependency and implicit dependency, and uninstall the kernel driver module according to the uninstall order.

[0181] Optionally, the implicit dependency determination module 403 may include:

[0182] A first implicit dependency determination submodule is used to determine the same system resources accessed by kernel driver modules based on module loading calls and system resource allocation calls, and to establish implicit dependency relationships between kernel driver modules that access the same system resources;

[0183] The second implicit dependency determination submodule is used to determine the same system calls hijacked between kernel driver modules according to the system call table, and establish implicit dependency relationships between the kernel driver modules that hijack the same system calls.

[0184] Optionally, the first implicit dependency determination submodule may include:

[0185] An information reading unit, configured to determine, when a system resource allocation call is triggered, a memory address allocated by the system resource allocation call and a first kernel driver module that triggers the system resource allocation call;

[0186] A kernel driver module positioning unit, configured to determine a second kernel driver module loaded by the module loading call when the module loading call is triggered;

[0187] A code scanning unit, configured to read the kernel code of the second kernel driver module and determine whether the second kernel driver module uses a memory address;

[0188] The determining unit is configured to determine that the first kernel driver module and the second kernel driver module use the same memory resource if it is determined that the second kernel driver module uses the memory address.

[0189] Optionally, the monitoring module 401 may include:

[0190] The hook function setting submodule is used to set the hook function in the operation function corresponding to the calling operation;

[0191] The call operation monitoring submodule is used to detect the triggering of the call operation using the hook function and obtain the call information of the call operation through the hook function.

[0192] Optionally, the device may further include:

[0193] Create a module to create nodes and directed edges based on explicit dependencies and implicit dependencies; nodes represent kernel driver modules, and directed edges represent dependencies between kernel driver modules;

[0194] Add module for adding nodes and directed edges to the dependency graph;

[0195] The uninstall module 404 may include:

[0196] The uninstallation order determination submodule is used to determine the kernel driver modules that directly or indirectly depend on the target kernel driver module in the dependency graph and use them as associated kernel driver modules, and to determine the uninstallation order of the target kernel driver module and the associated kernel driver modules.

[0197] Optionally, the device may further include:

[0198] The performance optimization module is used to determine whether the hardware resource utilization rate of the electronic device is greater than a preset threshold; if the hardware resource utilization rate is greater than the preset threshold, the explicit dependency and implicit dependency are recorded; if the hardware resource utilization rate is not greater than the preset threshold, the step of creating nodes and directed edges based on the explicit dependency and implicit dependency is entered.

[0199] Optionally, the device may further include:

[0200] The hierarchical division module is used to divide the kernel driver modules into different levels according to the dependency relationship and the number of dependencies of each node in the dependency graph, and obtain the corresponding level of each kernel driver module;

[0201] The importance determination module is used to perform weighted processing on the amount and level of system resources used by each kernel driver module to obtain the module importance value of each kernel driver module.

[0202] Optionally, the hierarchical division module may include:

[0203] The base layer partitioning submodule is used to partition nodes whose number of dependencies is greater than a preset threshold into the base layer;

[0204] The middle layer partitioning submodule is used to partition nodes whose number of dependencies is not greater than a preset threshold and which depend on the base layer nodes into the middle layer;

[0205] The leaf layer partitioning submodule is used to partition the nodes that depend on the middle layer nodes but are not depended on into the leaf layer.

[0206] Optionally, the device may further include:

[0207] Detection module, used to detect whether there are strong connected components in the dependency graph;

[0208] The node contraction module is used to convert the strongly connected component into a special node if it exists and update the dependency graph. At the same time, the module importance value of the special node is determined according to the module importance value of each kernel driver module that forms the strongly connected component.

[0209] The node hierarchical module is used to divide each node into different levels according to the dependency relationship and the number of dependencies of each node in the updated dependency graph, and obtain the node level of each node;

[0210] A first uninstallation order determination module is used to sort the modules of each node according to their importance values ​​in each node level to obtain a first uninstallation order in each node level;

[0211] A second uninstallation sequence determination module, configured to determine a second uninstallation sequence between node levels;

[0212] Accordingly, the uninstallation order determines the submodules, which can be used to:

[0213] The uninstallation order of the target kernel driver module and the associated kernel driver module is determined according to the first uninstallation order and the second uninstallation order.

[0214] Optionally, it may also include:

[0215] a third uninstallation order determination module, configured to determine a third uninstallation order according to the topological structure of the dependency graph if no strongly connected component exists;

[0216] Accordingly, the uninstallation order determines the submodules, which can be used to:

[0217] The uninstallation order of the target kernel driver module and the associated kernel driver modules is determined according to the third uninstallation order.

[0218] Optionally, the uninstall module 404 may be used to:

[0219] Determine the node to be uninstalled according to the uninstallation order and determine whether the node is a special node;

[0220] If the node is not a special node, the kernel driver module corresponding to the node is uninstalled;

[0221] If the node is a special node, all kernel driver modules forming the special node are uninstalled as a whole.

[0222] Optionally, the device may further include:

[0223] A queue adding and graph updating module is used to add the kernel driver module to the pending queue and update the dependency graph if the kernel driver module fails to be uninstalled;

[0224] A graph update module is used to update the dependency graph if the kernel driver module is successfully uninstalled;

[0225] The retry module is used to periodically trigger a module uninstall call on the kernel driver module in the pending queue. If the kernel driver module in the pending queue is successfully uninstalled, it is removed from the pending queue.

[0226] Optionally, the device may further include:

[0227] The shielding module is used to determine whether the kernel driver module targeted by the calling operation is in the waiting queue when determining that the calling operation is triggered; if so, shield the calling operation.

[0228] The description of the features in the embodiment corresponding to the kernel driver module uninstallation device can refer to the relevant description of the embodiment corresponding to the kernel driver module uninstallation method, and will not be repeated here.

[0229] Please refer to Figure 5 , Figure 5 This is a structural block diagram of an electronic device provided by an embodiment of the present invention. The embodiment of the present invention provides an electronic device 10, including a processor 11 and a memory 12; wherein the memory 12 is used to store computer programs; the processor 11 is used to execute the kernel driver module unloading method provided by the aforementioned embodiment when executing the computer program.

[0230] For the specific process of the above kernel driver module uninstallation method, reference may be made to the corresponding content provided in the aforementioned embodiments, which will not be described in detail here.

[0231] Furthermore, the memory 12 as a carrier for resource storage may be a read-only memory, a random access memory, a magnetic disk or an optical disk, etc., and the storage method may be temporary storage or permanent storage.

[0232] In addition, the electronic device 10 also includes a power supply 13, a communication interface 14, an input / output interface 15 and a communication bus 16; wherein the power supply 13 is used to provide operating voltage for each hardware device on the electronic device 10; the communication interface 14 can create a data transmission channel between the electronic device 10 and an external device, and the communication protocol it follows is any communication protocol that can be applied to the technical solution of the present invention, and is not specifically limited here; the input / output interface 15 is used to obtain external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs and is not specifically limited here.

[0233] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above-mentioned kernel driver module uninstallation method embodiments when running.

[0234] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0235] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps of any of the above-mentioned kernel driver module unloading method embodiments are implemented.

[0236] An embodiment of the present application also provides another computer program product, including a non-volatile computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the steps of any of the above-mentioned kernel driver module unloading method embodiments.

[0237] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0238] The above describes in detail the kernel driver module uninstallation method, electronic device, program product, and storage medium provided by this application. Specific examples are used herein to illustrate the principles and implementation methods of this application. The description of the above embodiments is intended only to facilitate understanding of the method and core concepts of this application. It should be noted that those skilled in the art may make various improvements and modifications to this application without departing from the principles of this application, and such improvements and modifications also fall within the scope of protection of this application.

Claims

1. A kernel driver module uninstallation method, characterized in that: include: Monitor the call operations and system call table in the operating system; the call operations include module loading call, module unloading call, symbol call, and system resource allocation call; Determining the symbolic call relationship between kernel driver modules according to the symbolic call to obtain the explicit dependency relationship between the kernel driver modules; Determining the same system resources used or the same hijacked system calls between the kernel driver modules according to the module loading call, the system resource allocation call, and the system call table, and obtaining an implicit dependency relationship between the kernel driver modules; When the module uninstall call is triggered, determining a target kernel driver module to be uninstalled by the module uninstall call, determining an uninstallation order of the target kernel driver module and its associated kernel driver modules according to the explicit dependency relationship and the implicit dependency relationship, and performing kernel driver module uninstallation according to the uninstallation order; Determining the same system resources used or the same hijacked system calls between the kernel driver modules according to the module loading call, the system resource allocation call, and the system call table, and obtaining the implicit dependency relationship between the kernel driver modules, including: Determining the same system resources accessed by the kernel driver modules according to the module loading call and the system resource allocation call, and establishing the implicit dependency relationship between the kernel driver modules that access the same system resources; The same system calls hijacked between the kernel driver modules are determined according to the system call table, and the kernel driver modules that hijack the same system calls are established with the implicit dependency relationship.

2. The kernel driver module uninstallation method according to claim 1, characterized in that: Determining the same system resources accessed between the kernel driver modules according to the module loading call and the system resource allocation call includes: When the system resource allocation call is triggered, determining the memory address allocated by the system resource allocation call and the first kernel driver module that triggers the system resource allocation call; When the module loading call is triggered, determining a second kernel driver module loaded by the module loading call; Reading the kernel code of the second kernel driver module, and determining whether the second kernel driver module uses the memory address; If it is determined that the second kernel driver module uses the memory address, it is determined that the first kernel driver module and the second kernel driver module use the same memory resource.

3. The kernel driver module uninstallation method according to claim 1, characterized in that: Monitor the call operations triggered in the operating system, including: Setting a hook function in the operation function corresponding to the calling operation; The hook function is used to detect the triggering condition of the calling operation, and the calling information of the calling operation is obtained through the hook function.

4. The kernel driver module uninstallation method according to any one of claims 1 to 3, characterized in that: Also includes: Creating nodes and directed edges according to the explicit dependency and the implicit dependency; The nodes represent the kernel driver modules, and the directed edges represent the dependency relationships between the kernel driver modules; adding the node and the directed edge to a dependency graph; Determining the uninstallation order of the target kernel driver module and its associated kernel driver modules according to the explicit dependency relationship and the implicit dependency relationship includes: In the dependency graph, a kernel driver module that is directly or indirectly dependent on the target kernel driver module is determined as the associated kernel driver module, and an uninstallation order of the target kernel driver module and the associated kernel driver module is determined.

5. The kernel driver module uninstallation method according to claim 4, characterized in that: Before creating nodes and directed edges according to the explicit dependency and the implicit dependency, the method further includes: Determining whether the hardware resource usage of the electronic device is greater than a preset threshold; If the hardware resource occupancy rate is greater than the preset threshold, the explicit dependency relationship and the implicit dependency relationship are recorded; If the hardware resource occupancy rate is not greater than the preset threshold, the process proceeds to the step of creating nodes and directed edges according to the explicit dependency relationship and the implicit dependency relationship.

6. The kernel driver module uninstallation method according to claim 4, characterized in that: Also includes: In the dependency graph, the kernel driver modules are divided into levels according to the dependency relationship and the number of dependencies of each node, so as to obtain the level corresponding to each kernel driver module; The system resource amount and level used by each kernel driver module are weighted to obtain a module importance value of each kernel driver module.

7. The kernel driver module uninstallation method according to claim 6, characterized in that: The step of dividing the kernel driver modules into different levels according to the dependency relationship and the number of dependencies of each node to obtain the level corresponding to each kernel driver module includes: Classify the nodes whose number of dependencies is greater than a preset threshold into the base layer; Classify the nodes whose number of dependencies is not greater than a preset threshold and which depend on the base layer nodes into the middle layer; Nodes that depend on middle-layer nodes but are not depended on are divided into leaf layers.

8. The kernel driver module uninstallation method according to claim 6, characterized in that: Also includes: Detecting whether there is a strongly connected component in the dependency graph; If the strongly connected component exists, convert the strongly connected component into a special node and update the dependency graph, and at the same time determine the module importance value of the special node according to the module importance values ​​of the kernel driver modules forming the strongly connected component; In the updated dependency graph, each node is hierarchically divided according to its dependency and the number of dependencies, to obtain a node hierarchy of each node; In each node level, the modules of each node are sorted according to their module importance values ​​to obtain the first uninstallation order in each node level; determining a second uninstallation order among node hierarchies; Accordingly, determining the uninstallation order of the target kernel driver module and the associated kernel driver module includes: The uninstallation order of the target kernel driver module and the associated kernel driver module is determined according to the first uninstallation order and the second uninstallation order.

9. The kernel driver module uninstallation method according to claim 8, characterized in that: Also includes: If the strongly connected component does not exist, determining a third unloading order according to the topological structure of the dependency graph; Accordingly, determining the uninstallation order of the target kernel driver module and the associated kernel driver module includes: The uninstallation order of the target kernel driver module and the associated kernel driver module is determined according to the third uninstallation order.

10. The kernel driver module uninstallation method according to claim 8, characterized in that: Uninstalling the kernel driver module according to the uninstallation sequence includes: Determining a node to be uninstalled according to the uninstallation order, and judging whether the node is a special node; If the node is not the special node, uninstalling the kernel driver module corresponding to the node; If the node is the special node, all kernel driver modules forming the special node are uninstalled as a whole.

11. The kernel driver module uninstallation method according to claim 4, characterized in that: After the kernel driver module is uninstalled according to the uninstall sequence, the method further includes: If the kernel driver module fails to be uninstalled, the kernel driver module is added to the queue to be processed and the dependency graph is updated; If the kernel driver module is successfully uninstalled, updating the dependency graph; Periodically triggering a module uninstall call for the kernel driver module in the queue to be processed, and removing the kernel driver module from the queue to be processed if the kernel driver module in the queue to be processed is successfully uninstalled.

12. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the kernel driver module uninstallation method according to any one of claims 1 to 11 when executing the computer program.

13. A computer program product comprising a computer program or instructions, characterized in that When the computer program or instruction is executed by a processor, the kernel driver module uninstallation method according to any one of claims 1 to 11 is implemented.

14. A non-volatile computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are loaded and executed by the processor, the kernel driver module uninstallation method according to any one of claims 1 to 11 is implemented.

Images