Security hook extension method, device, equipment, storage medium and program product

Abstract

The application discloses a security hook extension method and device, equipment, storage medium and program product. Among them, the method comprises the following steps: constructing an extension security module framework, and allocating an independent hook register for the extension security module framework; in response to a kernel module loading event, obtaining type information of a hook function to be registered in a kernel module corresponding to the kernel module loading event; compatibility comparison is performed between the type information and a standard prototype of a hook function defined in the extension security module framework; in the case that the type compatibility between the type information and the standard prototype is determined, the hook function is written into the hook register. The application solves the technical problems that the external security capability module cannot be flexibly accessed on demand due to the lack of runtime dynamic expansion capability and the corresponding type safety verification mechanism of the native security module framework, and the kernel is easily crashed due to the mismatch of the interface type.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a method, apparatus, device, storage medium, and program product for extending security hooks. Background Technology

[0002] The Linux kernel inserts security hooks into critical system call paths through the LSM framework, with specific policies implemented by security modules such as SELinux and AppArmor. However, traditional LSM modules must be statically integrated into the kernel image during kernel compilation, and cannot be dynamically loaded or unloaded during system runtime. This results in the deployment, updating, and expansion of security policies heavily relying on kernel recompilation, making it difficult to meet the needs of on-demand adjustments in operational scenarios and the rapid iteration requirements of third-party security vendors.

[0003] While existing technologies attempt to achieve runtime extensions by dynamically loading or hijacking existing LSM hooks through kernel modules (KOs), these solutions lack effective type safety verification mechanisms: the kernel only performs basic symbol resolution and dependency checks when loading modules, and cannot verify the type compatibility between the interface signatures of hook functions in the module and the target kernel path. This makes it extremely easy for runtime kernel crashes to occur due to function signature mismatches, structure changes, or kernel version differences. At the same time, existing dynamic solutions also have significant deficiencies in terms of hook coverage, unified management of multiple modules, and lifecycle control, making it difficult to guarantee system stability.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides a security hook extension method, apparatus, device, storage medium, and program product to at least solve the technical problem that external security capability modules cannot be flexibly accessed as needed and are prone to kernel crashes due to interface type mismatch, caused by the lack of runtime dynamic extension capabilities and corresponding type security verification mechanisms in the native security module framework.

[0006] According to one aspect of the embodiments of this application, a security hook extension method is provided, comprising: constructing an extended security module framework and allocating an independent hook registry for the extended security module framework, wherein the extended security module framework is a module statically registered to the security check path of the native security module framework during the kernel initialization phase; responding to a kernel module loading event, obtaining type information of hook functions to be registered in the kernel module corresponding to the kernel module loading event, wherein the kernel module loading event is used to characterize the loading request of an external security capability module to the kernel space, and the type information is used to characterize the interface signature and type definition of the associated data structure of the hook function; performing a compatibility comparison between the type information and the standard prototype of the hook function defined in the extended security module framework, wherein the compatibility comparison is used to determine whether the type information and the standard prototype are type compatible; if it is determined that the type information and the standard prototype are type compatible, writing the hook function into the hook registry, so that the extended security module framework can call the hook function in the hook registry when the native security module framework triggers a security check.

[0007] Optionally, constructing an extended security module framework and allocating a separate hook registry for it includes: during kernel startup, registering the extended security module framework itself to the hook list of the native security module framework by calling its initialization function, wherein the hook list records the hook functions of each security module registered in the native security module framework; creating a separate hook registry in kernel space, wherein the hook registry and the hook list are physically isolated from each other, and the hook registry stores the hook functions of external security capability modules; and constructing and maintaining a hook standard prototype definition table, wherein the hook standard prototype definition table records the standard prototypes of the hook functions supported by the extended security module framework.

[0008] Optionally, in response to a kernel module loading event, obtaining the type information of the hook functions to be registered in the kernel module corresponding to the kernel module loading event includes: when the extended security module framework receives a kernel module loading event, locating the metadata section in the kernel module, wherein the metadata section is used to record the hook registration information to be registered with the extended security module framework; when the metadata section in the kernel module is located, parsing the hook registration information in the metadata section, wherein the hook registration information includes at least one of the following: hook function symbol name, hook function pointer; locating the type metadata segment carried in the kernel module, and based on the hook function symbol name in the hook registration information, querying and extracting the interface signature and type definition of the associated data structure of the corresponding hook function in the type metadata segment to obtain the type information of the hook function, wherein the type metadata segment is generated during the kernel module compilation stage and is used to record the type description information of the data structures of all functions in the kernel module.

[0009] Optionally, the type information includes at least one of the following: the number of parameters, the type identifier of each parameter, and the type identifier of the return value. Comparing the type information with the standard prototype of the hook function defined in the extended security module framework includes: obtaining the standard prototype corresponding to the hook function symbol name in the hook registration information from the hook standard prototype definition table pre-configured in the extended security module framework; comparing whether the number of parameters in the type information is the same as the number of parameters in the standard prototype, and if the number of parameters is the same, continuing to compare the type identifier of each parameter in the type information with the type identifier of each parameter in the standard prototype one by one to determine whether the type identifiers of the parameters are compatible; if the type identifiers of all parameters are compatible, continuing to compare the type identifier of the return value in the type information with the type identifier of the return value in the standard prototype one by one to determine whether the type identifiers of the return values ​​are compatible; if the type identifiers of all return values ​​are compatible, determining that the type information and the standard prototype are type compatible.

[0010] Optionally, determining whether type identifiers are compatible includes: if the type identifiers in the type information are the same as those in the standard prototype, determining that the type identifiers are compatible; if the type identifiers in the type information are different from those in the standard prototype, parsing the first type category of the type identifiers in the type information and the second type category of the type identifiers in the standard prototype; if the first type category and the second type category are different, determining that the type identifiers in the type information and the type identifiers in the standard prototype are incompatible; if the first type category and the second type category are the same, performing a differential comparison based on the essential characteristics of the type category, wherein, if the type category is a type with a wrapping hierarchy, the type information and the type wrapping in the standard prototype are peeled off layer by layer, and the compatibility judgment of the type identifiers is recursively performed on the bottom type after peeling; if the type category is a composite category with members, comparing the compatibility of the member specifications and member types in the type information and the standard prototype; if the type category is an atomic type, determining whether it is compatible by comparing whether the essential characteristics of the type information and the standard prototype are consistent.

[0011] Optionally, the method further includes: when the native security module framework triggers a security check, transferring control and security check context parameters to the extended security module framework by calling the callback function of the extended security module framework; the extended security module framework enters the read protection zone and begins lock-free traversal of the linked list in the hook registry corresponding to the hook type corresponding to the security check context parameters, wherein the read protection zone is used to ensure that the view of the hook registry remains consistent during the traversal; according to the registration order, each hook function in the linked list is called sequentially, and the security check context parameters are passed to the called hook function so that the hook function can perform a security check based on the security check context parameters; when all hook functions in the linked list have been called or the call flow has been short-circuited and terminated, the read protection zone is exited, and the final security determination result is returned to the native security module framework.

[0012] Optionally, the method further includes: in response to a kernel module uninstallation event, acquiring a write lock on the read-write lock corresponding to the hook registry to ensure that no other thread is modifying the hook registry, wherein the kernel module uninstallation event is used to indicate that the kernel module is about to be removed from the kernel space; under the protection of the write lock, traversing the hook registry to locate the hook function registration node of the kernel module corresponding to the kernel module uninstallation event in the hook registry; removing the located hook function registration node from the hook registry and releasing the write lock; synchronously waiting for all read operations that have entered the read protection zone to exit, and releasing the memory resources occupied by the registration node after ensuring that no other thread is referencing the removed hook function registration node, thus completing the safe uninstallation of the kernel module.

[0013] According to another aspect of the embodiments of this application, a security hook extension device is also provided, comprising: an extension framework establishment module, used to construct an extended security module framework and allocate an independent hook registry for the extended security module framework, wherein the extended security module framework is a module statically registered to the security check path of the native security module framework during the kernel initialization phase; a type information acquisition module, used to acquire the type information of the hook function to be registered in the kernel module corresponding to the kernel module loading event in response to the kernel module loading event, wherein the kernel module loading event is used to characterize the loading request of the external security capability module to the kernel space, and the type information is used to characterize the interface signature and type definition of the associated data structure of the hook function; an information compatibility verification module, used to perform a compatibility comparison between the type information and the standard prototype of the hook function defined in the extended security module framework, wherein the compatibility comparison is used to determine whether the type information and the standard prototype are type compatible; and a hook registration writing module, used to write the hook function into the hook registry when it is determined that the type information and the standard prototype are type compatible, so that the extended security module framework can call the hook function in the hook registry when the native security module framework triggers a security check.

[0014] According to another aspect of the embodiments of this application, an electronic device is also provided, including: a memory and a processor, the processor being configured to run a program stored in the memory, wherein the program executes a security hook extension method during runtime.

[0015] According to another aspect of the embodiments of this application, a non-volatile storage medium is also provided, the non-volatile storage medium including a stored computer program, wherein the device where the non-volatile storage medium is located executes a security hook extension method by running the computer program.

[0016] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps of a security hook extension method.

[0017] In this embodiment, an extended security module framework is constructed, and an independent hook registry is allocated to the extended security module framework. The extended security module framework is a module statically registered to the security check path of the native security module framework during kernel initialization. In response to a kernel module load event, the type information of the hook functions to be registered in the kernel module corresponding to the kernel module load event is obtained. The kernel module load event represents a loading request from an external security capability module to the kernel space, and the type information represents the interface signature and associated data structure type definition of the hook function. A compatibility comparison is performed between the type information and the standard prototype of the hook functions defined in the extended security module framework. This compatibility comparison determines whether the type information and the standard prototype are type-compatible. If type compatibility is determined between the type information and the standard prototype... In this case, hook functions are written into the hook registry so that the extended security module framework can call the hook functions in the hook registry when the native security module framework triggers a security check. By deploying the extended security module framework in the kernel security check path as a dynamic access intermediary, and relying on an independent hook registry, external security capability modules can be mounted on demand. Based on compile-time type metadata, the hook function interface signature is pre-computed for compatibility verification during the loading phase. This achieves the goal of dynamically extending security hooks at runtime without recompiling the kernel, while pre-intercepting the risk of interface type mismatch. This solves the technical problem that the native security module framework lacks runtime dynamic extension capabilities and corresponding type security verification mechanisms, which makes it impossible for external security capability modules to be flexibly accessed on demand and prone to kernel crashes due to interface type mismatch. Attached Figure Description

[0018] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0019] Figure 1 This is a hardware structure block diagram of a computer terminal (or electronic device) for implementing a method for security hook extension according to an embodiment of this application;

[0020] Figure 2 This is a schematic diagram of a method flow for extending a security hook according to an embodiment of this application;

[0021] Figure 3 This is a schematic diagram of a system architecture for a runtime security hook extension scheme based on BTF type verification, provided according to an embodiment of this application.

[0022] Figure 4 This is a schematic diagram of the overall process of a runtime security hook extension scheme based on BTF type verification provided in the embodiments of this application;

[0023] Figure 5 This is a schematic diagram of an eLSM initialization process provided according to an embodiment of this application;

[0024] Figure 6 This is a schematic diagram of a storage structure for BTF information in a KO according to an embodiment of this application;

[0025] Figure 7 This is a schematic diagram of the eLSM framework loading process when a security module KO is loaded, according to an embodiment of this application.

[0026] Figure 8 This is a schematic diagram of a BTF prototype verification process provided according to an embodiment of this application;

[0027] Figure 9 This is a schematic diagram of a recursive comparison logic for BTF type compatibility provided in an embodiment of this application;

[0028] Figure 10 This is a schematic diagram illustrating the process of mounting and invoking a runtime security hook according to an embodiment of this application;

[0029] Figure 11 This is a schematic diagram of a hook unloading process provided according to an embodiment of this application;

[0030] Figure 12 This is a schematic diagram of a safety hook extension device provided according to an embodiment of this application. Detailed Implementation

[0031] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0032] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0033] To facilitate a better understanding of the embodiments of this application by those skilled in the art, some technical terms or nouns involved in the embodiments of this application are explained as follows:

[0034] BTF: BPF Type Format, a metadata format used in the kernel to describe kernel data structure types, providing a standardized method for debugging symbols and type information.

[0035] eLSM: Extended LSM, an extended Linux security module framework that supports dynamically attaching security hooks at runtime via kernel modules (KO).

[0036] LSM: Linux Security Module, a security module framework for the Linux kernel that provides a mechanism for inserting security check hooks into critical kernel paths.

[0037] KO: Kernel Object, a binary file (.ko file) generated by compiling a Linux kernel module.

[0038] BPF: Berkeley Packet Filter, a virtual machine in the Linux kernel used to perform efficient packet filtering and kernel tracing.

[0039] BTF information: Type description data generated when compiling a kernel or module, including meta-information such as structures, enumerations, and function prototypes.

[0040] Security hook functions: Callback functions registered on critical paths in the kernel, used to perform security checks and access control.

[0041] Function prototype: A declaration that describes the function's parameter types, number of parameters, and return type.

[0042] BTF ID: A numeric index used in the BTF system to uniquely identify types and functions.

[0043] In related technologies, the Linux kernel uses the native security module framework LSM (Linux Security Module) to insert security hooks on the paths of critical system calls, enabling security checks on access to resources such as processes, files, and networks. The LSM framework itself does not implement specific security policies; instead, it provides a general framework for hook insertion points. Specific security policies are implemented by individual LSM modules, such as SELinux, AppArmor, Smack, and TOMOYO.

[0044] Specifically, the LSM framework provides security hooks on the following critical paths, including:

[0045] 1) Process operations: fork, exec, ptrace, capable, etc.;

[0046] 2) File operations: inode_permission, file_permission, sb_mount, sb_remount, etc.;

[0047] 3) Network operations: inet_conn_request, socket_bind, netfilter, etc.;

[0048] 4) Memory management: mmap_addr, mmap_file, post_alloc, etc.;

[0049] Each LSM module adds its own hook functions to the global security_hook_heads linked list (i.e., the hook linked list of the native security module framework) during initialization. When the kernel performs security checks, it traverses this linked list and calls all registered hook functions in turn.

[0050] However, LSM modules in related technologies (such as SELinux and AppArmor) need to be statically configured during kernel compilation. This means the code for these security modules is directly compiled into the kernel image, or its inclusion is determined during the kernel build phase via the CONFIG option. This static mounting method makes enabling and changing security modules heavily reliant on kernel recompilation, preventing the dynamic loading or unloading of specific security check logic based on operational needs during system runtime. Furthermore, security modules are deeply coupled with internal kernel data structures and function signatures. Whenever a kernel version upgrade introduces API changes, the security modules must adapt synchronously, resulting in high maintenance costs and complex version branch management. In addition, the LSM framework itself does not support registering new security hook types at runtime. Third-party security vendors cannot independently add new security checkpoints without modifying the kernel source code, and their release cycle is severely limited by the kernel community's merge cycle, making it difficult to meet the rapid iteration needs of enterprise-level security products.

[0051] Although the Kernel Module (KO) mechanism allows for the loading and unloading of kernel code at runtime, and some research in related technologies has attempted to achieve dynamic security monitoring by hijacking existing LSM hooks, registering character devices to provide user-mode interfaces, or inserting probe points into kernel trace points based on eBPF, these solutions have significant drawbacks: hijacking existing hooks can only cover existing hook points and cannot insert new security checks on paths where the kernel does not provide LSM hooks; eBPF programs are limited by strict verification mechanisms and cannot modify the kernel state. More importantly, existing kernel modules only perform basic symbol resolution and dependency checks during loading, lacking compatibility verification of function pointer types in the module and the target kernel path interface signature, and cannot detect type inconsistencies such as function signature mismatches or parameter structure changes, which can easily lead to runtime kernel crashes; at the same time, the differences in ABI between different kernel versions make it difficult to guarantee symbol version compatibility, and existing dynamic solutions are independent and lack a unified security module registration, scheduling, and unloading mechanism, making it difficult to guarantee coordinated operation and safe resource release among multiple modules.

[0052] It is worth noting that the Linux kernel introduced the BTF (BPF Type Format) type metadata format in version 5.4. This format records the complete type information of kernel data structures in a standardized way, including member names, types and offsets of structures and unions, enumeration definitions, function prototypes, and pointer and type aliases. Adding BTF information to kernel modules during compilation has become standard practice. This allows the runtime to query the complete definition of any kernel type based on the BTF segment carried by the module, providing a technical basis for strict type verification of function prototypes during the module loading phase. However, related technologies have not yet effectively utilized this mechanism to solve the type security and version compatibility issues of dynamically secure modules.

[0053] In summary, the relevant technologies cannot simultaneously address runtime dynamic expansion and type safety verification, resulting in issues such as insufficient flexibility, strong version coupling, lack of unified lifecycle management, and high runtime stability risks.

[0054] To address the aforementioned issues, this application provides a solution: an extended security module framework (eLSM). eLSM is an independent security module implemented based on the original LSM, and it is also mounted via built-in during kernel compilation. However, unlike LSM, eLSM supports dynamic mounting of security hooks during kernel runtime via the KO module. Furthermore, it utilizes the BTF feature provided by the kernel's BPF subsystem to rigorously verify the prototypes of the mounted user-space security hook functions before loading, preventing runtime kernel crashes caused by mismatches between user-space designed hook functions and target eLSM hook prototypes. A detailed explanation follows.

[0055] According to an embodiment of this application, a method embodiment for extending a security hook is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0056] The methods and embodiments provided in this application can be executed on mobile terminals, computer terminals, or similar computing devices. Figure 1 A hardware block diagram of a computer terminal (or electronic device) for implementing a security hook extension method is shown. Figure 1 As shown, the computer terminal 10 (or electronic device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0057] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or electronic device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0058] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the security hook extension method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the aforementioned security hook extension method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0059] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0060] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10 (or electronic device).

[0061] Under the above operating environment, this application provides a method for extending a security hook. Figure 2 This is a schematic diagram of a method flow for extending a security hook according to an embodiment of this application, as shown below. Figure 2 As shown, the method includes the following steps:

[0062] Step S202: Construct an extended security module framework and allocate an independent hook registry for the extended security module framework. The extended security module framework is a module that is statically registered to the security check path of the native security module framework during the kernel initialization phase.

[0063] Step S204: In response to the kernel module loading event, obtain the type information of the hook function to be registered in the kernel module corresponding to the kernel module loading event. The kernel module loading event is used to represent the loading request of the external security capability module to the kernel space, and the type information is used to represent the interface signature of the hook function and the type definition of the associated data structure.

[0064] Step S206: Compare the type information with the standard prototype of the hook function defined in the extended security module framework. The compatibility comparison is used to determine whether the type information and the standard prototype are type compatible.

[0065] Step S208: If the type information is determined to be type compatible with the standard prototype, the hook function is written into the hook registry so that the extended security module framework can call the hook function in the hook registry when the native security module framework triggers a security check.

[0066] Through the above steps, by deploying an extended security module framework as a dynamic access intermediary in the kernel security check path, and relying on an independent hook registry to achieve on-demand mounting of external security capability modules, and by performing pre-compile-time type metadata verification on the hook function interface signature during the loading phase, the goal of achieving runtime dynamic extension of security hooks without recompiling the kernel is achieved. At the same time, the risk of interface type mismatch is intercepted in advance. This solves the technical problem that the lack of runtime dynamic extension capability and corresponding type security verification mechanism of the native security module framework makes it impossible for external security capability modules to be flexibly accessed on demand and prone to kernel crashes due to interface type mismatch.

[0067] The method for extending the security hook in steps S202 to S208 of the embodiments of this application will be further described below.

[0068] Figure 3 This is a schematic diagram of a system architecture for a runtime security hook extension scheme based on BTF type verification, provided in an embodiment of this application. Figure 3As shown, this architecture spans both user space and Linux kernel space. In user space, the security module management tool loads the security module KO (i.e., kernel module) carrying BTF type information and security hook functions into the kernel using the insmod command. In kernel space, the eLSM framework (i.e., extended security module framework) serves as the core component, with a built-in hook scheduler, eLSM initialization module, BTF prototype verification engine, lifecycle manager, and independent hook registry. When the security module KO is loaded, its BTF type information is sent to the BTF prototype verification engine for function prototype extraction and verification. After verification, the security hook functions are registered to the hook registry. The eLSM initialization module adds the hook registry to the security_hook_heads global hook list of the underlying LSM framework (i.e., native security module framework). Subsequently, when the kernel triggers a security check, the hook scheduler iterates through and calls the security hook functions in the hook registry, while the lifecycle manager is responsible for safely removing the corresponding hooks from the hook registry when the module is unloaded, thereby realizing dynamic expansion and full lifecycle management of runtime security capabilities.

[0069] The process steps executed in this architecture are as follows: Figure 4 As shown, the main process includes four stages: eLSM framework initialization, security module loading and verification, runtime hook scheduling, and module unloading. First, after the eLSM framework completes initialization during kernel startup, it is statically registered to the native LSM framework and creates an independent hook registry. When a security module KO is loaded, eLSM receives the module loading notification, locates and extracts the hook function prototype of the BTF information segment in the KO, adds it to the hook registry after the BTF prototype verification passes, and refuses to register if the verification fails and returns a loading failure. During runtime, after the kernel triggers the security hook call, the eLSM hook scheduler traverses the registry and calls all registered security hook functions, finally returning the security check result. When a security module KO is unloaded, eLSM receives the unloading notification, removes all hooks of the module from the registry, and releases related resources.

[0070] The following is a further detailed explanation of the above process steps. First, the specific steps for initializing and registering the eLSM framework are as follows.

[0071] In some embodiments of this application, constructing an extended security module framework and allocating an independent hook registry for the extended security module framework includes: during the kernel startup phase, registering the extended security module framework itself to the hook list of the native security module framework by calling the initialization function of the extended security module framework, wherein the hook list is used to record the hook functions of each security module registered in the native security module framework; creating an independent hook registry in the kernel space, wherein the hook registry and the hook list are physically isolated from each other, and the hook registry is used to store the hook functions of external security capability modules; and constructing and maintaining a hook standard prototype definition table, wherein the hook standard prototype definition table is used to record the standard prototypes of the hook functions supported by the extended security module framework.

[0072] In this embodiment, the aforementioned extended security module framework, namely the eLSM framework, is a special security module implemented based on the native LSM framework (Linux Security Module). Figure 5 As shown, the initialization of the eLSM framework is triggered by the security_init() call chain during the kernel startup phase, and registration is completed by calling the eLSM initialization function elsm_init(). At this time, eLSM does not exist as a loadable kernel module (KO), but is compiled together with other parts of the kernel and embedded into the kernel image in a built-in manner, thereby ensuring that it is deployed early in the kernel initialization process.

[0073] Specifically, such as Figure 5 As shown, the specific process of registering the extended security module framework itself to the hook list of the native security module framework includes: the eLSM initialization function first allocates and initializes the elsm_core core structure, then creates an independent hook registry (i.e., the elsm_hook_entry list), and initializes read-write locks and atomic counters to ensure subsequent concurrency safety; next, eLSM builds and maintains the hook standard prototype definition table (i.e., the elsm_hook_def table), which records the standard interface signatures of all security hook types supported by eLSM; then, a sysfs management interface is created, and eLSM's own callback functions are registered to the security_hook_heads list (i.e., the hook list) of the native LSM framework; finally, the / sys / kernel / elsm / interface is exported, initialization is completed, and the system enters a ready state waiting for KO loading.

[0074] It's important to note that the aforementioned hook list (security_hook_heads) is a global linked list maintained by the native LSM framework, used to record hook functions statically registered with various security modules (such as SELinux, AppArmor, etc.) within the native LSM framework. The independent hook registry (elsm_hook_entry list), on the other hand, is a separate, physically isolated linked list structure created independently in kernel space by the eLSM framework. This registry is specifically designed to store hook functions dynamically registered by external security capability modules (KOs provided by third-party security vendors) that have passed subsequent BTF verification. This physical isolation allows eLSM to function as a static mount point on the native LSM framework, appearing externally as a regular module of the native LSM and accepting calls from the native framework. Internally, however, it manages dynamically expanded third-party hooks through an independent registry, avoiding direct modification of the native LSM framework's internal data structures, thus ensuring the stability and compatibility of the native framework.

[0075] Furthermore, the aforementioned hook standard prototype definition table (elsm_hook_def table) is a core data structure pre-configured during the eLSM framework's initialization phase. It records the standard prototypes of various security hooks supported by eLSM. For example, for file operation hooks, this table predefines the number of parameters, parameter types (such as struct file, int, etc.), return value type, and associated data structure type definitions for the standard interface. When an external security module (KO) is loaded, eLSM extracts the interface signature of the hook function to be registered from the BTF information carried by the KO and compares it item by item with the standard prototypes in the elsm_hook_def table to determine type compatibility. This standard prototype definition table serves as both the eLSM framework's access specification for external modules and the comparison benchmark for the subsequent BTF prototype verification engine.

[0076] After completing the initialization of eLSM, it can respond to the kernel module (KO module) load event and obtain the type information (BTF information) of the hook functions to be registered in the kernel module corresponding to the kernel module load event, as follows.

[0077] In some embodiments of this application, in response to a kernel module loading event, obtaining the type information of the hook function to be registered in the kernel module corresponding to the kernel module loading event includes: when the extended security module framework receives the kernel module loading event, locating the metadata section in the kernel module, wherein the metadata section is used to record the hook registration information to be registered with the extended security module framework; when the metadata section in the kernel module is located, parsing the hook registration information in the metadata section, wherein the hook registration information includes at least one of the following: hook function symbol name, hook function pointer; locating the type metadata segment carried in the kernel module, and according to the hook function symbol name in the hook registration information, querying and extracting the interface signature and type definition of the associated data structure of the corresponding hook function in the type metadata segment to obtain the type information of the hook function, wherein the type metadata segment is generated during the kernel module compilation stage and is used to record the type description information of the data structure of all functions in the kernel module.

[0078] Specifically, the security module (KO) (kernel module) needs to include BTF type information during compilation. The Linux kernel build system (Kbuild) supports generating BTF information for kernel modules; this can be achieved simply by adding compilation options to the module's Makefile. Specifically, the security module KO can enable BTF information generation in its Makefile configuration: by setting the `-g` compilation flag for each source file (such as `hook.o`, `policy.o`, and `manager.o`) to retain debugging information, and configuring `KBUILD_CFLAGS` to enable the separation of function and data segments; based on this, the `pahole` tool in the kernel build toolchain will automatically extract type data from the DWARF debugging information, generate BTF type information, and append it to the KO file.

[0079] The compiled security module KO file (.ko) contains multiple sections, such as... Figure 6 As shown, .text is machine code, .data is initialized data, .rodata is read-only data, and the .BTF section is the BTF type information generated by pahole. .BTF.ext is BTF auxiliary data (such as line information). The above type metadata segments correspond to this .BTF section. In addition, the KO file also contains a custom _elsm_hooks section (metadata section), which is used to record the hook registration information to be registered with eLSM (Extended Security Module Framework), including the hook function symbol name and hook function pointer.

[0080] When the security module KO is loaded, the loading process of the eLSM framework is as follows: Figure 7As shown, when user space triggers a kernel module loading event via insmod or modprobe, the eLSM framework receives a MODULE_STATE_COMING notification through the registered module loading notification chain. Subsequently, the eLSM framework first determines whether the KO contains a __elsm_hooks section (i.e., a metadata section). If not, the module is ignored (because it is not an eLSM secure module). If it does, the __elsm_hooks section is parsed to extract hook function pointers and names (i.e., hook registration information). Next, the eLSM framework obtains the KO's .BTF section information (i.e., the type metadata segment) and, based on the extracted hook function symbol names, queries and extracts the interface signature (parameter type, number of parameters, return type) and type definitions of associated data structures (such as structfile, struct inode, etc.) of the corresponding hook function from the .BTF section, ultimately summarizing the type information.

[0081] It's important to note that the type metadata segment (.BTF section) is standardized type metadata generated by the pahole tool from DWARF debugging information during the kernel module compilation phase. It records complete type descriptions of all functions and data structures within the kernel module, including member names, types, and offsets of structures and unions, enumeration types, function prototypes, pointers, and type aliases. The process of searching the type metadata segment based on the hook function symbol name can be implemented using the `btf_find_by_name_kind()` interface. If a function is inlined due to compilation optimization and BTF information cannot be found, it is directly rejected from loading, thus preventing hook functions without type information from entering subsequent verification stages. This design moves type safety verification to the module loading stage, fundamentally avoiding the risk of runtime kernel crashes caused by interface signature mismatches.

[0082] After obtaining the type information of the hook function to be registered, the eLSM framework needs to further verify whether the type information is consistent with the interface specification expected by the kernel. This is the core part of type safety verification, which will be introduced in detail below.

[0083] In some embodiments of this application, the type information includes at least one of the following: the number of parameters, the type identifier of each parameter, and the type identifier of the return value. Comparing the type information with the standard prototype of the hook function defined in the extended security module framework includes: obtaining the standard prototype corresponding to the hook function symbol name in the hook registration information from the hook standard prototype definition table pre-configured in the extended security module framework; comparing whether the number of parameters in the type information is the same as the number of parameters in the standard prototype, and if the number of parameters is the same, continuing to compare the type identifier of each parameter in the type information with the type identifier of each parameter in the standard prototype one by one to determine whether the type identifiers of the parameters are compatible; if the type identifiers of all parameters are compatible, continuing to compare the type identifier of the return value in the type information with the type identifier of the return value in the standard prototype one by one to determine whether the type identifiers of the return values ​​are compatible; if the type identifiers of all return values ​​are compatible, determining that the type information and the standard prototype are type compatible.

[0084] Specifically, such as Figure 8 As shown, the eLSM framework first locates the hook function to be verified (such as hook_fn) from the KO's BTF information using btf_fd, obtains its BTF_FUNC type information (name='hook_fn_name'), and then obtains the function's BTF_FUNC_PROTO type, i.e., the complete parameter list definition, through btf_type_func_proto(). Subsequently, it iterates through the parameter list, extracts the type ID of each parameter, and thus summarizes the above type information. At the same time, the eLSM framework can also obtain the standard prototype corresponding to the hook function symbol name (hook_fn_name) from the pre-configured hook standard prototype definition table (i.e., the elsm_hook_def table). This standard prototype also defines the number of parameters, the type ID of each parameter, and the return value type ID of the hook function in BTF format.

[0085] Then, compatibility comparison can be performed: First, check if the number of parameters matches: If the number of parameters in the hook function in KO is inconsistent with the standard prototype, it directly returns "parameter count mismatch" and determines that the verification failed; if the number of parameters is consistent, it enters the parameter type identifier comparison stage; when comparing the parameter type identifiers one by one, the eLSM framework obtains the type ID of the kernel standard prototype and compares it with the parameter type ID extracted from KO to determine whether the parameter type identifiers are compatible (i.e., determine whether the kernel BTF type ID == KO BTF type ID). If the type of any parameter is still incompatible after comparison, it returns "parameter type mismatch" and determines that the verification failed; when the type identifiers of all parameters are determined to be compatible, the eLSM framework continues to compare the type identifier of the return value. If the return value type does not match, it returns "return type mismatch"; if the return value type matches, it finally determines that "BTF prototype verification passed", that is, the type information is compatible with the standard prototype.

[0086] Through the above process, the eLSM framework completes strict verification of hook function interface signatures during the module loading phase, intercepting all potential risks such as incorrect parameter quantity, mismatched parameter types, and inconsistent return value types before loading, effectively avoiding runtime kernel crashes caused by "incorrect product".

[0087] Furthermore, it should be noted that due to the existence of various type wrapping mechanisms in the BTF type system, such as type aliases (typedef), type qualifiers (const, volatile), and pointer types, two semantically equivalent types may have different BTF type IDs. For example, `const struct file` and `struct file` are compatible in the LSM hook interface, but their type IDs are different in BTF. Therefore, we cannot rely solely on simple type identifier comparison; instead, we must employ a recursive resolution strategy to peel off the type wrappers layer by layer, ultimately comparing the consistency of the underlying basic types. Based on this, in the embodiments of this application, the eLSM framework uses recursive comparison logic to perform a deep compatibility comparison when determining whether type identifiers are compatible, to ensure that the hook functions of external security capability modules fully match the requirements of the kernel security check path at the interface level, as detailed below.

[0088] In some embodiments of this application, determining whether type identifiers are mutually compatible includes: if the type identifiers in the type information are the same as those in the standard prototype, determining that the type identifiers are mutually compatible; if the type identifiers in the type information are different from those in the standard prototype, parsing the first type category of the type identifiers in the type information and the second type category of the type identifiers in the standard prototype; if the first type category and the second type category are different, determining that the type identifiers in the type information and the type identifiers in the standard prototype are incompatible; if the first type category and the second type category are the same, performing a differential comparison based on the essential characteristics of the type category, wherein, if the type category is a type with a packaging layer, the type information and the type packaging in the standard prototype are peeled off layer by layer, and the compatibility judgment of the type identifiers is recursively performed on the peeled bottom type; if the type category is a composite category with members, comparing the compatibility of the member specifications and member types in the type information and the standard prototype; if the type category is an atomic type, determining whether it is compatible by comparing whether the essential characteristics of the type information and the standard prototype are consistent.

[0089] Specifically, such as Figure 9 As shown, when determining whether type identifiers are compatible, a direct type ID matching check is first performed: comparing the type identifier in the type information (e.g., type_id_a) with the type identifier in the standard prototype (e.g., type_id_b). If the type identifiers are the same, the types are completely identical, and the type identifiers are directly determined to be compatible; this is the fastest matching path. If the type identifiers are different, the type categories (i.e., BTF kind) of both are parsed separately to obtain the first type category and the second type category; if the two type categories are not the same (e.g., one is a structure, and the other is a basic type), the type identifiers are directly determined to be incompatible, and the comparison is terminated.

[0090] If the first type category and the second type category are the same, a differential comparison is performed based on the essential characteristics of the type category. For types with wrapper layers (including type qualifiers (const / volatile), type aliases (typedef), pointer types, etc.), a layer-by-layer peeling strategy is adopted: if the type category is a const or volatile qualifier, the underlying type is extracted and the underlying types are recursively compared; if it is a typedef alias, the underlying type it points to is parsed and then recursively compared; if it is a pointer type, it is determined whether both are pointers, and then the types pointed to by the pointers are recursively compared. Through this layer-by-layer de-wrapping method, types that are semantically equivalent despite different wrappers can be correctly identified.

[0091] For composite categories with members (such as structures or unions), it is necessary to compare the number of members and the type of each member. This is a complex recursive process that iterates through all members. For example, if both types are arrays, the number of array elements is compared first, and then the element types are recursively compared. For atomic types (i.e., basic types such as int, long, void, etc.), the basic type IDs (i.e., encoding method and bit width) are directly compared. If the basic type definitions are the same, they are considered compatible; otherwise, they are considered incompatible. All the above comparison paths eventually converge to the recursive termination condition of "types are exactly the same, return match" or "return mismatch".

[0092] Through the recursive comparison logic described above, the eLSM framework can accurately identify interface type compatibility during the security module loading phase, avoiding misjudgments caused by const qualifiers, typedef aliases, or differences in pointer hierarchy. It also intercepts the risk of type incompatibility before loading, preventing runtime kernel crashes. Since the depth of kernel type definitions is usually limited (generally no more than 10 levels), the worst-case time complexity of this recursive comparison is O(n), and the actual performance overhead is controllable.

[0093] Once the extended security module framework completes type compatibility comparison and determines type compatibility, it triggers the hook mounting process, registering the security hook function in its internal registry. Specifically, memory is allocated for the hook registration node for the hook function to be registered, and the field information of the hook registration node is filled, including: hook type identifier, hook function pointer, and pointer to the kernel module to which it belongs; a write lock is acquired for the read-write lock corresponding to the hook registry to ensure that no other thread is currently modifying the hook registry; under the protection of the write lock, the hook registration node is inserted into the hook linked list corresponding to the hook type identifier in the registration order; the write lock is released, and the hook function becomes publicly visible, completing the mounting.

[0094] After registration, the eLSM hook scheduler is responsible for dispatching calls when kernel security checks are triggered, with the call order being the order in which security modules are registered. The specific call flow of runtime security hooks is as follows.

[0095] In some embodiments of this application, the method further includes: when the native security module framework triggers a security check, transferring control and security check context parameters to the extended security module framework by calling a callback function of the extended security module framework; the extended security module framework enters a read protection zone and begins lock-free traversal of the linked list in the hook registry corresponding to the hook type corresponding to the security check context parameters, wherein the read protection zone is used to ensure that the view of the hook registry remains consistent during the traversal; according to the registration order, each hook function in the linked list is called sequentially, and the security check context parameters are passed to the called hook function so that the hook function performs a security check based on the security check context parameters; when all hook functions in the linked list have been called or the call flow has been short-circuited and terminated, the method exits the read protection zone and returns the final security determination result to the native security module framework.

[0096] Specifically, when the native security module framework (i.e., the LSM framework) triggers a security check, such as when an application initiates a file open operation or the kernel VFS layer calls security_file_permission(), the native LSM framework first traverses its security_hook_heads global hook list, finds the statically registered eLSM framework (extended security module framework) callback function, and passes control and security check context parameters (such as file object, access mode, etc.) to the eLSM framework.

[0097] like Figure 10 As shown, after receiving control, the eLSM framework enters the read protection zone (i.e., the RCU read-side critical section) and begins lock-free traversal of the linked lists in the hook registry corresponding to the hook types specified in the security check context parameters. The read protection zone is implemented through the kernel RCU (Read-Copy-Update) synchronization mechanism. Its core function is to ensure that the view of the hook registry remains consistent during traversal: even if other threads are registering or deregistering hooks for security modules, the currently traversing thread still sees a stable snapshot before the operation, preventing dangling pointers or inconsistent data. This mechanism effectively solves the race condition problem where other threads simultaneously modify the hook list while hook functions are being dispatched and scheduled.

[0098] Subsequently, the eLSM framework calls the hook functions of security module A, security module B, etc., sequentially according to the registration order of each module in the hook chain, and passes the security check context parameter to the called hook function. Each hook function then executes independent security check logic based on this parameter. The eLSM framework uses the RCU mechanism to ensure concurrency safety, while supplementing it with read-write locks to ensure mutual exclusion and synchronization of registry modifications: read operations (hook dispatch) are performed without locks under RCU protection, while write operations (registration / deregistration) are serialized through read-write locks, thus balancing runtime performance and data consistency.

[0099] During the call, if any hook function returns an access denied result, the eLSM framework immediately short-circuit and terminates subsequent calls, returning the denial result directly. If all hook functions return permission, the process continues until all hook functions in the linked list have been called. Finally, the eLSM framework exits the read protection zone and returns the security decision (permission or denial) to the native security module framework, which then continues the execution of subsequent kernel paths or terminates the current operation.

[0100] Through the above design, the eLSM framework can achieve unified scheduling and concurrent security management of multiple third-party security modules without modifying any code of the native LSM framework: the read path is lock-free and zero-blocking, ensuring high performance of the security check path; the write path is mutually exclusive, ensuring data consistency when multiple modules are dynamically registered / deregistered; and the short-circuit mechanism avoids unnecessary computational overhead, enabling the system to quickly respond to the judgment results of security policies.

[0101] In this embodiment, when user space triggers kernel module unloading via the rmmod command, the eLSM framework can receive a MODULE_STATE_GOING notification (kernel module unloading event) through a registered module unloading notification link. This event indicates that the kernel module is about to be removed from the kernel space. The specific security hook unloading process during KO unloading is as follows.

[0102] In some embodiments of this application, the method further includes: in response to a kernel module uninstallation event, acquiring a write lock on the read-write lock corresponding to the hook registry to ensure that no other thread is modifying the hook registry, wherein the kernel module uninstallation event is used to indicate that the kernel module is about to be removed from the kernel space; under the protection of the write lock, traversing the hook registry to locate the hook function registration node in the hook registry that belongs to the kernel module uninstallation event; removing the located hook function registration node from the hook registry and releasing the write lock; synchronously waiting for all read operations that have entered the read protection zone to exit, and releasing the memory resources occupied by the registration node after ensuring that no other thread is referencing the removed hook function registration node, thereby completing the safe uninstallation of the kernel module.

[0103] Specifically, such as Figure 11 As shown, the eLSM framework first obtains the structure pointer of the module to be uninstalled, and then obtains the write lock of the read-write lock corresponding to the hook registry to ensure that no other thread is currently modifying the hook registry, thereby guaranteeing the atomicity of subsequent traversal and removal operations.

[0104] Under write lock protection, the eLSM framework traverses the hook registry (i.e., the elsm_hook_entry linked list), checking each entry to see if it belongs to the kernel module to be uninstalled. If the current entry does not belong to the module, it is skipped and the next entry is checked; if the current entry belongs to the module, the hook function registration node (i.e., the elsm_hook_entry structure) is immediately removed from the hook registry, preventing the hook function from participating in subsequent security checks and dispatches. After removing all nodes belonging to the module, the write lock is released, allowing other threads to continue accessing or modifying the hook registry.

[0105] Subsequently, the eLSM framework enters the resource safe release phase. For each removed hook registration node, the eLSM framework performs a synchronous wait for all in-transit calls to that hook to complete, i.e., synchronously waits for all read operations that have entered the read protection zone to exit. This can be achieved using synchronization primitives such as `synchronize_rcu()`, ensuring that all threads currently traversing the hook registry and calling the hook function within the RCU read-side critical section have exited, and no thread is still referencing the removed node. After confirming that no other thread is referencing it, the eLSM framework releases the memory resources occupied by the hook function registration node (i.e., the `elsm_hook_entry` memory), finally updates the statistics, and completes the unloading.

[0106] Through the above process, the eLSM framework can achieve secure unloading of security modules: write locks ensure mutual exclusion of registry modifications, avoiding data competition when multiple threads uninstall or register simultaneously; the synchronous wait mechanism ensures that removed hook functions will not be referenced by the currently executing security check path, thereby eliminating dangling pointer access after memory release, minimizing the risk of kernel crashes and resource leaks, and ensuring the long-term stability of the system.

[0107] This application proposes a two-layer security hook extension mechanism, forming two core technical protection points: First, the extended security module framework (eLSM) is statically registered to the security check path of the native security module framework (LSM) during kernel initialization. Simultaneously, it maintains an independent hook registry (elsm_hook_entry list) physically isolated from the hook list (security_hook_heads) of the native LSM framework, and implements a concurrent security mechanism based on RCU and read-write locks, thereby supporting dynamic registration, ordered distribution, and secure unloading of runtime security hooks. Second, a prototype verification engine based on BTF type information is introduced during the module loading phase. This engine extracts the type information of the hook functions to be registered from the kernel module (security module KO), performs compatibility comparison with the pre-defined hook standard prototype definition table (elsm_hook_def table), and uses a recursive parsing strategy to peel off type wrappers such as const, typedef, and pointers layer by layer to compare the underlying basic types, thus completing cross-kernel version type security verification before loading.

[0108] Through the aforementioned architecture and verification mechanism, on the one hand, security modules can be dynamically loaded and unloaded at runtime without recompiling the kernel. Third-party vendors can independently release security module knockouts (KOs) without being limited by the number of native hooks. Simultaneously, the risk of kernel crashes caused by function signature mismatches is shifted from runtime to loading time. Recursive type compatibility handling avoids type wrapping misjudgments and supports automatic adaptation across kernel versions. On the other hand, unified lifecycle management, the synchronize_rcu() synchronous wait mechanism, and the sysfs monitoring interface ensure memory safety and operational stability in multi-module concurrent scenarios. As an extension of the native LSM framework, this solution does not modify any of its code and can coexist with existing modules such as SELinux and AppArmor. Security modules can also choose to register with eLSM or use the traditional method. Furthermore, the design of the lock-free RCU read path and one-time verification at loading time ensures controllable runtime performance overhead and supports short-circuit calls in the registration order to further improve efficiency.

[0109] In addition, this application also considers several alternative solutions to verify the optimality of the technical solution. Among them, the verification method based on function pointer signatures compares the function signature digest (such as MD5 hash value) hard-coded in the security module. Although it does not require BTF support and has a fast verification speed, it requires manual maintenance of signature data, cannot detect type incompatibility issues such as changes in structure members, and is not automated enough in handling cross-kernel version compatibility. The verification method based on kernel version whitelist controls loading by maintaining a whitelist of verified security module KOs and kernel versions. Although it is simple to implement and has high security, it requires re-verification and updating of the whitelist with each kernel version upgrade, which cannot support the rapid iteration of third-party security vendors, and the whitelist maintenance cost is high and there is a risk of tampering. The method based on compile-time static verification uses the __copy_over mechanism of the kernel build system or compiler plugins to perform type checking during the compilation stage. Although it can detect mismatch problems in advance and does not require runtime parsing overhead, it requires specifying the target kernel version at compile time, has poor universality, and cannot perform checks on modules released in the form of pre-compiled KOs. In comparison, this application preferably adopts the BTF type verification scheme, which utilizes the BTF type metadata format natively supported by the kernel. It does not require additional modification to the kernel source code or build system, and can automatically adapt to type changes in different kernel versions at runtime, combining accuracy, universality and automation.

[0110] According to an embodiment of this application, an embodiment of a safety hook extension device is also provided. Figure 12 This is a schematic diagram of a safety hook extension device provided according to an embodiment of this application. Figure 12 As shown, the device includes:

[0111] The extended framework establishment module 120 is used to build the extended security module framework and allocate an independent hook registry for the extended security module framework. The extended security module framework is a module that is statically registered to the security check path of the native security module framework during the kernel initialization phase.

[0112] The type information acquisition module 122 is used to respond to the kernel module loading event and acquire the type information of the hook function to be registered in the kernel module corresponding to the kernel module loading event. The kernel module loading event is used to represent the loading request of the external security capability module to the kernel space, and the type information is used to represent the interface signature of the hook function and the type definition of the associated data structure.

[0113] The information compatibility verification module 124 is used to perform a compatibility comparison between type information and the standard prototype of hook functions defined in the extended security module framework. The compatibility comparison is used to determine whether the type information and the standard prototype are type compatible.

[0114] Hook registration writing module 126 is used to write hook functions into the hook registry when the type information is type compatible with the standard prototype, so that the extended security module framework can call the hook functions in the hook registry when the native security module framework triggers a security check.

[0115] Optionally, constructing an extended security module framework and allocating a separate hook registry for it includes: during kernel startup, registering the extended security module framework itself to the hook list of the native security module framework by calling its initialization function, wherein the hook list records the hook functions of each security module registered in the native security module framework; creating a separate hook registry in kernel space, wherein the hook registry and the hook list are physically isolated from each other, and the hook registry stores the hook functions of external security capability modules; and constructing and maintaining a hook standard prototype definition table, wherein the hook standard prototype definition table records the standard prototypes of the hook functions supported by the extended security module framework.

[0116] Optionally, in response to a kernel module loading event, obtaining the type information of the hook functions to be registered in the kernel module corresponding to the kernel module loading event includes: when the extended security module framework receives a kernel module loading event, locating the metadata section in the kernel module, wherein the metadata section is used to record the hook registration information to be registered with the extended security module framework; when the metadata section in the kernel module is located, parsing the hook registration information in the metadata section, wherein the hook registration information includes at least one of the following: hook function symbol name, hook function pointer; locating the type metadata segment carried in the kernel module, and based on the hook function symbol name in the hook registration information, querying and extracting the interface signature and type definition of the associated data structure of the corresponding hook function in the type metadata segment to obtain the type information of the hook function, wherein the type metadata segment is generated during the kernel module compilation stage and is used to record the type description information of the data structures of all functions in the kernel module.

[0117] Optionally, the type information includes at least one of the following: the number of parameters, the type identifier of each parameter, and the type identifier of the return value. Comparing the type information with the standard prototype of the hook function defined in the extended security module framework includes: obtaining the standard prototype corresponding to the hook function symbol name in the hook registration information from the hook standard prototype definition table pre-configured in the extended security module framework; comparing whether the number of parameters in the type information is the same as the number of parameters in the standard prototype, and if the number of parameters is the same, continuing to compare the type identifier of each parameter in the type information with the type identifier of each parameter in the standard prototype one by one to determine whether the type identifiers of the parameters are compatible; if the type identifiers of all parameters are compatible, continuing to compare the type identifier of the return value in the type information with the type identifier of the return value in the standard prototype one by one to determine whether the type identifiers of the return values ​​are compatible; if the type identifiers of all return values ​​are compatible, determining that the type information and the standard prototype are type compatible.

[0118] Optionally, determining whether type identifiers are compatible includes: if the type identifiers in the type information are the same as those in the standard prototype, determining that the type identifiers are compatible; if the type identifiers in the type information are different from those in the standard prototype, parsing the first type category of the type identifiers in the type information and the second type category of the type identifiers in the standard prototype; if the first type category and the second type category are different, determining that the type identifiers in the type information and the type identifiers in the standard prototype are incompatible; if the first type category and the second type category are the same, performing a differential comparison based on the essential characteristics of the type category, wherein, if the type category is a type with a wrapping hierarchy, the type information and the type wrapping in the standard prototype are peeled off layer by layer, and the compatibility judgment of the type identifiers is recursively performed on the bottom type after peeling; if the type category is a composite category with members, comparing the compatibility of the member specifications and member types in the type information and the standard prototype; if the type category is an atomic type, determining whether it is compatible by comparing whether the essential characteristics of the type information and the standard prototype are consistent.

[0119] Optionally, the security hook extension device is further configured to: when the native security module framework triggers a security check, transfer control and security check context parameters to the extended security module framework by calling the callback function of the extended security module framework; the extended security module framework enters the read protection zone and begins lock-free traversal of the linked list in the hook registry corresponding to the hook type corresponding to the security check context parameters, wherein the read protection zone is used to ensure that the view of the hook registry remains consistent during the traversal; according to the registration order, each hook function in the linked list is called sequentially, and the security check context parameters are passed to the called hook function so that the hook function can perform a security check based on the security check context parameters; when all hook functions in the linked list have been called or the call flow has been short-circuited and terminated, the device exits the read protection zone and returns the final security determination result to the native security module framework.

[0120] Optionally, the security hook extension device is also used to: in response to a kernel module uninstallation event, acquire a write lock on the read-write lock corresponding to the hook registry to ensure that no other thread is modifying the hook registry, wherein the kernel module uninstallation event indicates that the kernel module is about to be removed from the kernel space; under the protection of the write lock, traverse the hook registry to locate the hook function registration node of the kernel module corresponding to the kernel module uninstallation event in the hook registry; remove the located hook function registration node from the hook registry and release the write lock; synchronously wait for all read operations that have entered the read protection zone to exit, and release the memory resources occupied by the registration node after ensuring that no other thread is referencing the removed hook function registration node, thus completing the safe uninstallation of the kernel module.

[0121] It should be noted that each module in the above-mentioned security hook extension device can be a program module (e.g., a set of program instructions to implement a certain function) or a hardware module. For the latter, it can be manifested in the following forms, but is not limited to them: each of the above modules is manifested as a processor, or the functions of each of the above modules are implemented by a processor.

[0122] It should be noted that the safety hook extension device provided in this embodiment can be used to perform... Figure 2 The security hook extension method shown above is also applicable to the embodiments of this application, and will not be repeated here.

[0123] This application embodiment also provides a non-volatile storage medium, which includes a stored computer program. The device containing the non-volatile storage medium executes the following security hook extension method by running the computer program: constructing an extended security module framework and allocating an independent hook registry for the extended security module framework, wherein the extended security module framework is a module statically registered to the security check path of the native security module framework during kernel initialization; responding to a kernel module loading event, obtaining the type information of the hook functions to be registered in the kernel module corresponding to the kernel module loading event, wherein the kernel module loading event is used to characterize the loading request of an external security capability module to the kernel space, and the type information is used to characterize the interface signature and associated data structure type definition of the hook function; performing a compatibility comparison between the type information and the standard prototype of the hook function defined in the extended security module framework, wherein the compatibility comparison is used to determine whether the type information and the standard prototype are type compatible; if the type information and the standard prototype are determined to be type compatible, writing the hook function into the hook registry so that the extended security module framework can call the hook function in the hook registry when the native security module framework triggers a security check.

[0124] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the security hook extension method in various embodiments of this application: constructing an extended security module framework and allocating an independent hook registry for the extended security module framework, wherein the extended security module framework is a module statically registered to the security check path of the native security module framework during the kernel initialization phase; responding to a kernel module loading event, obtaining the type information of the hook functions to be registered in the kernel module corresponding to the kernel module loading event, wherein the kernel module loading event is used to characterize the loading request of an external security capability module to the kernel space, and the type information is used to characterize the interface signature and associated data structure type definition of the hook function; performing a compatibility comparison between the type information and the standard prototype of the hook function defined in the extended security module framework, wherein the compatibility comparison is used to determine whether the type information and the standard prototype are type compatible; if the type information and the standard prototype are determined to be type compatible, writing the hook function into the hook registry so that the extended security module framework can call the hook function in the hook registry when the native security module framework triggers a security check.

[0125] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0126] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0127] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between units or modules may be electrical or other forms.

[0128] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0129] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0130] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0131] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for extending a safety hook, characterized in that, include: An extended security module framework is constructed, and an independent hook registry is allocated to the extended security module framework, wherein the extended security module framework is a module that is statically registered to the security check path of the native security module framework during the kernel initialization phase; The process of constructing an extended security module framework and allocating an independent hook registry for the extended security module framework includes: during the kernel startup phase, registering the extended security module framework itself to the hook list of the native security module framework by calling the initialization function of the extended security module framework, wherein the hook list is used to record the hook functions of each security module registered in the native security module framework; creating an independent hook registry in the kernel space, wherein the hook registry and the hook list are physically isolated from each other, and the hook registry is used to store the hook functions of external security capability modules; and constructing and maintaining a hook standard prototype definition table, wherein the hook standard prototype definition table is used to record the standard prototypes of the hook functions supported by the extended security module framework. In response to a kernel module loading event, the type information of the hook function to be registered in the kernel module corresponding to the kernel module loading event is obtained. The kernel module loading event is used to characterize the loading request of an external security capability module to the kernel space, and the type information is used to characterize the interface signature and type definition of the associated data structure of the hook function. The type information is compared with the standard prototype of the hook function defined in the extended security module framework, wherein the compatibility comparison is used to determine whether the type information and the standard prototype are type compatible; If the type information is determined to be type compatible with the standard prototype, the hook function is written into the hook registry so that the extended security module framework can call the hook function in the hook registry when the native security module framework triggers a security check.

2. The safety hook extension method according to claim 1, characterized in that, In response to a kernel module loading event, the type information of the hook functions to be registered in the kernel module corresponding to the kernel module loading event is obtained, including: When the extended security module framework receives the kernel module load event, it locates the metadata section in the kernel module, wherein the metadata section is used to record hook registration information to be registered with the extended security module framework; If the metadata section in the kernel module is located, the hook registration information in the metadata section is parsed, wherein the hook registration information includes at least one of the following: hook function symbol name, hook function pointer; Locate the type metadata segment carried in the kernel module, and based on the hook function symbol name in the hook registration information, query and extract the interface signature and type definition of the associated data structure of the corresponding hook function in the type metadata segment to obtain the type information of the hook function. The type metadata segment is generated during the kernel module compilation stage and is used to record the type description information of the data structure of all functions in the kernel module.

3. The safety hook extension method according to claim 2, characterized in that, The type information includes at least one of the following: the number of parameters, the type identifier of each parameter, and the type identifier of the return value; the compatibility comparison of the type information with the standard prototype of the hook function defined in the extended security module framework includes: From the hook standard prototype definition table pre-configured in the extended security module framework, obtain the standard prototype corresponding to the hook function symbol name in the hook registration information; Compare the number of parameters in the type information with the number of parameters in the standard prototype. If the number of parameters is the same, continue to compare the type identifier of each parameter in the type information with the type identifier of each parameter in the standard prototype one by one to determine whether the type identifiers of the parameters are compatible with each other. If all the type identifiers of the parameters are compatible, continue to compare the type identifiers of the return values ​​in the type information with the type identifiers of the return values ​​in the standard prototype one by one to determine whether the type identifiers of the return values ​​are compatible with each other; If all return values ​​are compatible in terms of type identifiers, then the type information is determined to be type compatible with the standard prototype.

4. The safety hook extension method according to claim 3, characterized in that, Determining whether type identifiers are compatible includes: If the type identifier in the type information is the same as the type identifier in the standard prototype, the type identifiers are determined to be compatible. If the type identifier in the type information is different from the type identifier in the standard prototype, the first type category of the type identifier in the type information and the second type category of the type identifier in the standard prototype are parsed. If the first type category and the second type category are different, it is determined that the type identifier in the type information is incompatible with the type identifier in the standard prototype; When the first type category and the second type category are the same, a differential comparison is performed based on the essential characteristics of the type category. Specifically, when the type category is a type with a packaging hierarchy, the type information and the type packaging in the standard prototype are stripped layer by layer, and the compatibility judgment of the type identifier is recursively performed on the stripped bottom type. When the type category is a composite category with members, the compatibility of the member specifications and member types in the type information and the standard prototype is compared. When the type category is an atomic type, compatibility is determined by comparing whether the type essence in the type information and the standard prototype is consistent.

5. The safety hook extension method according to claim 1, characterized in that, The method further includes: When the native security module framework triggers a security check, control and security check context parameters are passed to the extended security module framework by calling its callback function. The extended security module framework enters the read protection zone and begins lock-free traversal of the linked list in the hook registry corresponding to the hook type corresponding to the security check context parameter. The read protection zone is used to ensure that the view of the hook registry remains consistent during the traversal. According to the registration order, each hook function in the linked list is called sequentially, and the security check context parameter is passed to the called hook function so that the hook function can perform a security check based on the security check context parameter; Once all hook function calls in the linked list have been completed or the call flow has been short-circuited and terminated, the read protection zone is exited, and the final security determination result is returned to the native security module framework.

6. The safety hook extension method according to claim 5, characterized in that, The method further includes: In response to a kernel module uninstallation event, a write lock is acquired for the read-write lock corresponding to the hook registry to ensure that no other thread is modifying the hook registry. The kernel module uninstallation event is used to indicate that the kernel module is about to be removed from the kernel space. Under the protection of the write lock, the hook registry is traversed to locate the hook function registration node of the kernel module corresponding to the kernel module uninstallation event in the hook registry; Remove the located hook function registration node from the hook registry and release the write lock; Synchronously wait for all read operations that have entered the read protection zone to exit. If no other thread is referencing the removed hook function registration node, release the memory resources occupied by the registration node and complete the safe unloading of the kernel module.

7. A safety hook extension device, characterized in that, include: An extension framework establishment module is used to build an extension security module framework and allocate an independent hook registry for the extension security module framework, wherein the extension security module framework is a module that is statically registered to the security check path of the native security module framework during the kernel initialization phase; The process of constructing an extended security module framework and allocating an independent hook registry for the extended security module framework includes: during the kernel startup phase, registering the extended security module framework itself to the hook list of the native security module framework by calling the initialization function of the extended security module framework, wherein the hook list is used to record the hook functions of each security module registered in the native security module framework; creating an independent hook registry in the kernel space, wherein the hook registry and the hook list are physically isolated from each other, and the hook registry is used to store the hook functions of external security capability modules; and constructing and maintaining a hook standard prototype definition table, wherein the hook standard prototype definition table is used to record the standard prototypes of the hook functions supported by the extended security module framework. The type information acquisition module is used to respond to a kernel module loading event and acquire the type information of the hook function to be registered in the kernel module corresponding to the kernel module loading event. The kernel module loading event is used to represent the loading request of the external security capability module to the kernel space, and the type information is used to represent the interface signature and type definition of the associated data structure of the hook function. An information compatibility verification module is used to perform a compatibility comparison between the type information and the standard prototype of the hook function defined in the extended security module framework, wherein the compatibility comparison is used to determine whether the type information and the standard prototype are type compatible; The hook registration writing module is used to write the hook function into the hook registry when it is determined that the type information is compatible with the standard prototype, so that the extended security module framework can call the hook function in the hook registry when the native security module framework triggers a security check.

8. An electronic device, characterized in that, include: A memory and a processor, the processor being configured to run a program stored in the memory, wherein the program, when running, executes the security hook extension method according to any one of claims 1 to 6.

9. A non-volatile storage medium, characterized in that, The non-volatile storage medium includes a stored computer program, wherein the device containing the non-volatile storage medium executes the security hook extension method according to any one of claims 1 to 6 by running the computer program.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the security hook extension method according to any one of claims 1 to 6.

Images