Security detection method, security loading method, device, storage medium and program product
By deploying a virtual machine in the kernel for just-in-time compilation, the problem of long security testing time and high cost caused by traditional static compilation is solved. This enables efficient and flexible security testing and updates, avoids system restarts, and improves the efficiency and flexibility of security testing.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- ALIBABA CLOUD COMPUTING CO LTD
- Filing Date
- 2026-03-23
- Publication Date
- 2026-04-21
AI Technical Summary
Traditional solutions compile security policy logic into the kernel using static compilation, which results in long security detection times, high costs, and the need to restart the system when updating, making it difficult to meet the needs of efficient security detection.
Policy scripts are written using a scripting language and then deployed in the kernel as virtual machines for just-in-time compilation. The virtual machines compile and execute the policy scripts provided by user-mode processes, avoiding the static compilation of security policy logic into the kernel. Security detection is performed through kernel-mode just-in-time compilation.
It improves security detection efficiency, reduces detection costs and barriers, enables flexible updates of security policy logic and security detection without restarting the system, and enhances the system's update efficiency and flexibility.
Smart Images

Figure CN121902141A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of security protection technology, and in particular to a security detection method, a security loading method, a device, a storage medium, and a program product. Background Technology
[0002] As the most fundamental part of the operating system, the kernel plays a very important role in protecting core system resources, preventing unauthorized access, and resisting malicious code attacks, thus ensuring the integrity, confidentiality, and availability of the system.
[0003] Taking the Linux kernel as an example, the Linux kernel typically runs a security module (an access control framework) and has multiple checkpoints set up on critical paths in the kernel, such as file access, network communication, and process scheduling.
[0004] In traditional solutions, security policy logic is typically compiled into the kernel in a statically compiled form. When performing security checks, if the kernel detects and executes a kernel operation corresponding to a certain detection point, it will call the security module, which will then execute the statically compiled code to detect the kernel operation.
[0005] However, this static compilation method often requires modifying the kernel code, making it difficult to meet the requirements of efficient security detection. Summary of the Invention
[0006] This application provides a security detection method, a security loading method, a device, a storage medium, and a program product to solve the problem that traditional solutions, which use static compilation to compile security policy logic into the kernel, cannot meet the requirements for efficient security detection, thereby improving security detection efficiency.
[0007] In a first aspect, this application provides a security detection method applied to a security module, the security module running in the kernel; the kernel has multiple detection points, and the method includes: In response to a callback request triggered at any detection point, the target policy object hit by the detection point is determined; the target policy object is obtained by encapsulating a policy script and its correspondence with the detection point; the policy script is provided by a user-space process and compiled using a virtual machine in the kernel; the correspondence is obtained by the virtual machine parsing the policy script; The policy script is executed using the virtual machine to detect the kernel operations corresponding to the detection points; Obtain the detection results returned by the virtual machine.
[0008] Secondly, this application provides a security detection method applied to a virtual machine, wherein the virtual machine runs in a kernel, the kernel runs a security module, and multiple detection points are set, the method comprising: In response to the call request of the security module, a target policy object is determined; the target policy object is the policy object that hits the detection point when the security module responds to a callback request triggered at any detection point; the target policy object is obtained by encapsulating a policy script and its correspondence with the detection point; the policy script is provided by a user-space process and compiled using the virtual machine; the correspondence is obtained by the virtual machine parsing the policy script. The strategy script is executed to detect the kernel operations corresponding to the detection points; The detection results are then fed back to the security module.
[0009] Thirdly, this application provides a secure loading method applied to a kernel, wherein the kernel runs a security module and has multiple detection points, the method comprising: Retrieve the policy script written by the user-space process; The virtual machine in the kernel is invoked to compile the policy script and parse it to obtain the correspondence between the policy script and the detection point; Based on the compiled policy script and its correspondence with the detection points, a policy object is encapsulated and generated. The policy object is used as the target policy object for the detection point when the security module responds to the callback request triggered by the detection point. The policy script is used to execute in the virtual machine to detect the kernel operation corresponding to the detection point and to feed back the detection result to the security module.
[0010] Fourthly, this application provides a secure recording method applied to a virtual machine, wherein the virtual machine runs in a kernel, the kernel runs a security module and has multiple detection points, and the method includes: In response to the kernel's call request, a policy script is determined; the policy script is written by a user-space process. The strategy script is compiled and parsed to obtain the correspondence between the strategy script and the detection points; The compiled policy script and its corresponding relationship are fed back to the kernel, so that the kernel can encapsulate and generate a policy object based on the compiled policy script and its correspondence with the detection point. The policy object is used as the target policy object for the detection point when the security module responds to the callback request triggered by the detection point. The policy script is used to execute in the virtual machine to detect the kernel operation corresponding to the detection point and feed back the detection result to the security module.
[0011] Fifthly, this application provides a computing device, including a processing component and a storage component; The storage component stores a computer program; the computer program is invoked and executed by the processing component to implement the security detection method as described in either the first or second aspect, or the security loading method as described in either the third or fourth aspect.
[0012] In a sixth aspect, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processing component, implements the security detection method as described in either the first or second aspect, or the security loading method as described in either the third or fourth aspect.
[0013] In a seventh aspect, this application provides a computer program product, including a computer program or instructions, which, when executed by a processing component, implement the security detection method as described in either the first or second aspect, or the security loading method as described in either the third or fourth aspect.
[0014] In this embodiment, the security module running in the kernel can respond to a callback request triggered by any detection point set in the kernel and determine the target policy object hit by that detection point. The target policy object can be obtained by encapsulating a policy script and its correspondence with the detection point. The policy script can be provided by a user-space process and compiled using a virtual machine deployed in the kernel. The correspondence can be obtained by the virtual machine parsing the policy script. The security module can use the virtual machine deployed in the kernel to execute the policy script in the target policy object to detect the kernel operation corresponding to the detection point that triggered the callback request, obtain the detection result fed back by the virtual machine, and then perform security processing on the kernel operation based on the detection result.
[0015] By employing a scripting language to write policy scripts and deploying a virtual machine in the kernel that supports the compilation and execution of these policy scripts, this embodiment utilizes kernel-mode just-in-time (JIT) compilation. The virtual machine compiles and executes the policy scripts provided by user-mode processes. Compared to traditional solutions that statically compile security policy logic into the kernel and have the security module execute the statically compiled code, this embodiment eliminates the need for static compilation of security policy logic into the kernel. Therefore, no kernel code modification is required, solving the problem of long security detection times, improving security detection efficiency, and reducing security detection costs and barriers to entry. Furthermore, when updating security policy logic, only the policy script needs to be rewritten, and the virtual machine in the kernel compiles and executes the rewritten policy script provided by user-mode processes. This eliminates the need to statically compile the security policy logic into the kernel, modify the kernel code, restart the system, and interrupt system operation, further improving the efficiency and flexibility of security detection updates while reducing update costs.
[0016] These or other aspects of this application will become more apparent from the description of the following embodiments. Attached Figure Description
[0017] 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: Figure 1 A flowchart of one embodiment of a secure loading method provided in this application is shown; Figure 2 A flowchart of another embodiment of a secure loading method provided in this application is shown; Figure 3 A flowchart of one embodiment of a security detection method provided in this application is shown; Figure 4 A flowchart of another embodiment of a security detection method provided in this application is shown; Figure 5a A schematic diagram of an operating system in a practical application is shown; Figure 5b This diagram illustrates a secure loading method in a practical application. Figure 5c A schematic diagram of a security detection in a practical application is shown; Figure 6 This invention provides a schematic diagram of the structure of one embodiment of a safety loading device. Figure 7A schematic diagram of another embodiment of a safety loading device provided in this application is shown; Figure 8 This paper shows a schematic diagram of the structure of one embodiment of a security detection device provided in this application; Figure 9 A schematic diagram of another embodiment of a security detection device provided in this application is shown; Figure 10 A schematic diagram of a computing device in a practical application is shown. Detailed Implementation
[0018] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0019] It should be noted that, in the cases involving user information in the embodiments of this application, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in the embodiments of this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse. In addition, the various models involved in this application (including but not limited to language models or large models) comply with relevant laws and standards.
[0020] Additionally, it should be noted that when user interaction operations or triggering operations are involved in the embodiments of this application, these operations include, but are not limited to, various interaction methods such as touch operations, gesture operations, voice operations, head movement operations, and eye movement operations. Touch operations include, but are not limited to, click operations, double-click operations, long-press operations, swipe operations, pinch operations, or mouse hover operations. Swipe operations include, but are not limited to, straight-line swipes and curved-line swipes.
[0021] The technical solution of this application is applicable to the field of security protection, especially the field of kernel security protection. To facilitate a better understanding of the technical solution of this application, the terms used in the embodiments of this application are explained below: Kernel: The most fundamental part of the operating system, it is the core of the operating system, providing the most basic functions of the operating system and forming the basis for the operation of the operating system. It is responsible for managing system processes, memory, device drivers, files and network systems, and determines the performance and stability of the system.
[0022] Kernel Space and User Space: In an operating system, virtual memory is typically divided into two blocks: kernel space and user space. The kernel and drivers run in kernel space, while user programs run in user space, and their direct access to hardware resources is restricted. Kernel space and user space generally communicate through system calls.
[0023] Security module: An access control framework that runs on the kernel.
[0024] Checkpoints: These are set on critical kernel paths, such as file access, network communication, and process scheduling. When the kernel detects and executes a kernel operation corresponding to a checkpoint, it calls a security module to perform appropriate control processing on that kernel operation. Based on security modules and multiple checkpoints, the kernel can implement Mandatory Access Control (MAC). Taking the Linux operating system as an example, the security module can be a Linux Security Module (LSM) running on the Linux kernel, and the checkpoints can be specifically set by the Linux security module.
[0025] As described in the background section, in traditional solutions, security policy logic is typically compiled into the kernel in a statically compiled form. During security testing, the security module executes the statically compiled code to test the kernel operations and obtain the test results.
[0026] However, this static compilation method often requires modifying the kernel code, especially when security policy logic is updated. This requires recompiling the kernel and restarting the operating system, which is time-consuming, costly, and can interrupt system operation.
[0027] To address the aforementioned technical problems, the inventors have proposed a technical solution, comprising: a security module running in the kernel responding to a callback request triggered by any detection point, determining the target policy object hit by the detection point; the target policy object being encapsulated based on a policy script and its correspondence with the detection point; the policy script being provided by a user-mode process and compiled using a virtual machine in the kernel; the correspondence being obtained by the virtual machine parsing the policy script; the policy script being executed using the virtual machine to detect the kernel operation corresponding to the detection point; and obtaining the detection result fed back by the virtual machine.
[0028] By employing a scripting language to write policy scripts and deploying a virtual machine in the kernel that supports the compilation and execution of these policy scripts, this embodiment utilizes kernel-mode just-in-time (JIT) compilation. The virtual machine compiles and executes the policy scripts provided by user-mode processes. Compared to traditional solutions that statically compile security policy logic into the kernel and have the security module execute the statically compiled code, this embodiment eliminates the need for static compilation of security policy logic into the kernel. Therefore, no kernel code modification is required, solving the problem of long security detection times, improving security detection efficiency, and reducing security detection costs and barriers to entry. Furthermore, when updating security policy logic, only the policy script needs to be rewritten, and the virtual machine in the kernel compiles and executes the rewritten policy script provided by user-mode processes. This eliminates the need to statically compile the security policy logic into the kernel, modify the kernel code, restart the system, and interrupt system operation, further improving the efficiency and flexibility of security detection updates while reducing update costs.
[0029] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0030] Figure 1 This is a flowchart of an embodiment of a secure loading method provided in this application. The technical solution of this embodiment can be applied to the kernel, in which a security module runs and multiple detection points are set. Figure 1 The safe loading method shown may include the following steps: 101: Obtain the policy script provided by the user-mode process.
[0031] In this embodiment, the policy script may include security policy logic functions written in a scripting language. The policy script may include at least one security policy logic function defined for at least one detection point. Each security policy logic function is used to perform detection on the kernel operation corresponding to its corresponding detection point according to the corresponding security policy logic.
[0032] Policy scripts can be provided by user-space processes running in user space in response to user write operations. Specifically, the kernel can provide a user-space file interface, which can include write handling functions. These functions can be used to listen for write operations triggered by user-space processes, and the user-space file interface can be used to retrieve policy scripts written by the user in a specified file provided by the user space.
[0033] To improve kernel security, optionally, when a write operation triggered by a user-space process is detected, it can be determined whether the user-space process has the necessary permissions. If it does, the policy script it provides is retrieved. Otherwise, the retrieval of the policy script is denied, and a corresponding warning message is output.
[0034] By performing permission verification on the user-mode processes that provide policy scripts, it is ensured that only user-mode processes with the required permissions can provide policy scripts to update the kernel's security policy logic. This prevents any user-mode process from updating the security policy logic, improves the rationality of loading the kernel's security policy logic, and enhances kernel security.
[0035] 102: Call the virtual machine in the kernel to compile the policy script and parse it to obtain the correspondence between the policy script and the detection points.
[0036] The policy script provided by the user-space process can be the source code of the policy script, or it can be in text form. After compiling the source code, the intermediate code form of the policy script, such as bytecode, can be obtained.
[0037] In this embodiment, the kernel may contain virtual machines, and multiple virtual machine instances corresponding to those virtual machines may be running. Specifically, the first virtual machine instance may be invoked to compile the policy script and parse it to obtain the correspondence between the policy script and the detection points. The first virtual machine instance may be any virtual machine instance or any virtual machine instance in an idle state.
[0038] Optionally, the above method may further include: Based on the number of policy scripts compiled for each of the multiple virtual machine instances, the virtual machine instance with a number of policy scripts compiled less than the preset number of compilations is designated as the first virtual machine instance in an idle state.
[0039] To improve the compilation efficiency of the source code, a compiler can optionally be deployed in the kernel. Specifically, the compiler can be invoked by a virtual machine to compile the policy script, obtain the intermediate code corresponding to the policy script, and then the virtual machine can be used to parse the intermediate code to obtain the correspondence between the policy script and the detection points.
[0040] To further enhance kernel security, policy scripts can be validated. Optionally, before compiling the policy scripts, the above methods may further include: Save the strategy script and validate it.
[0041] Based on this, compiling the policy script by calling the virtual machine in the kernel can include: If the verification passes, the virtual machine in the kernel is invoked to compile the policy script; The above methods may also include: If the verification fails or the parsing fails, an error message will be displayed.
[0042] This could involve performing lexical and syntactic checks on the source code of the strategy script, such as checking for spelling errors in variable names, improper use of symbols, or missing statement structures, like missing keywords.
[0043] If the verification passes, the code can be compiled to obtain intermediate code. A virtual machine is then called to parse this intermediate code, revealing the mapping between the policy script and the detection points. Otherwise, the security loading process can end, and a corresponding message can be output and sent back to the user. This message could be something like: "The source code contains errors; please modify it."
[0044] Optionally, parsing the correspondence between the policy script and the detection points may include: The compiled policy script is run in a virtual machine to obtain the correspondence between the policy script and the detection points.
[0045] This allows you to set the runtime environment for the compiled policy script in a virtual machine, thereby simulating the execution of the compiled policy script and obtaining the simulation results.
[0046] As described above, the policy script includes at least one security policy logic function defined for at least one detection point. If the simulation runs successfully, the simulation results can include the correspondence between the policy script and the detection points, confirming successful parsing and allowing direct acquisition of the correspondence between the simulated policy script and the detection points. Optionally, the simulation results may also include metadata about the policy script, which may include information such as the name of the security policy logic and the version identifier of the policy script; this application does not impose any limitations on this.
[0047] If the simulation fails and the simulation results do not include the above correspondence, it can be determined that the parsing failed. The safe loading process can be terminated, and the corresponding prompt message can be output and fed back to the user. The prompt message may be, for example, "Intermediate code parsing failed."
[0048] To improve the rationality of storage, alternatively, temporary memory can be allocated to store the policy script, and the temporary memory can be released if the verification fails or the parsing fails.
[0049] To further enhance the flexibility of secure loading, the policy script can optionally be written in a lightweight scripting language. Specifically, the virtual machine can provide a runtime environment for the lightweight scripting language and support its compilation. Optionally, the compiler can support the compilation of the lightweight scripting language, and the virtual machine can provide a runtime environment for the intermediate code compiled from the lightweight scripting language.
[0050] In a practical application, the policy script can be written using the Lua scripting language (a lightweight and efficient scripting language). The compiler can be a Lua compiler, supporting the compilation of Lua scripts to obtain bytecode. The virtual machine can be a Lua virtual machine, providing a runtime environment for the compiled bytecode, supporting the execution of the bytecode, and parsing to obtain the correspondence between the policy script and the detection points.
[0051] By employing a lightweight scripting language to write policy scripts, compared to the complex declarative language used in traditional static compilation methods, the solution in this application can describe security policy logic with complex conditional judgments such as nested if-else statements and loop processing, greatly lowering the security detection threshold and improving the flexibility of security detection. Furthermore, compared to instruction set-based programming, the solution in this application can perform deep string parsing, achieving complex attack signature matching without strictly limiting the number of instructions or stack space size, and without prohibiting complex loop logic, further improving the flexibility of security detection.
[0052] 103: Based on the compiled strategy script and its correspondence with the detection points, a strategy object is encapsulated and generated.
[0053] Specifically, the kernel can allocate a structure to store the compiled policy script (intermediate code of the policy script, such as bytecode) and the correspondence between the policy script and the detection points, thereby obtaining a policy object.
[0054] Optionally, a policy object can be obtained by storing the compiled policy script, the correspondence between the policy script and the detection points, and the policy script's metadata into the structure.
[0055] The encapsulated policy object can be used as the target policy object for a detection point when the security module responds to a callback request triggered by the detection point. The policy script can be executed in the virtual machine to detect the kernel operation corresponding to the detection point and feed the detection result back to the security module. The specific security detection process will be described in detail in subsequent embodiments and will not be repeated here.
[0056] Optionally, the encapsulated policy object can be saved to a preset data structure, such as a linked list, array, or tree structure, so that when performing kernel security detection, the security module can respond to the callback request triggered by the detection point and search for the target policy object hit by the detection point from the preset data structure.
[0057] In this embodiment, the kernel can obtain the policy script provided by the user-space process, specifically the source code of the policy script, and call the virtual machine deployed in the kernel to compile the policy script, obtaining the compiled policy script, i.e., the intermediate code of the policy script, such as bytecode, and parsing to obtain the correspondence between the policy script and the detection points set in the kernel. Based on the compiled policy script and its correspondence with the detection points, it can be encapsulated into a policy object. The encapsulated policy object can be used as the target policy object of the detection point that triggered the callback request when the security module running in the kernel responds to the callback request. The policy script can be executed in the virtual machine to detect the kernel operation corresponding to the detection point that triggered the callback request and feed back the detection result to the security module.
[0058] By employing a scripting language to write policy scripts and deploying a virtual machine in the kernel that supports the compilation and execution of these policy scripts, this embodiment utilizes kernel-mode just-in-time (JIT) compilation. The virtual machine compiles and executes the policy scripts provided by user-mode processes. Compared to traditional solutions that statically compile security policy logic into the kernel and have the security module execute the statically compiled code, this embodiment eliminates the need for static compilation of security policy logic into the kernel. Therefore, no kernel code modification is required, solving the problem of long security detection times, improving security detection efficiency, and reducing security detection costs and barriers to entry. Furthermore, when updating security policy logic, only the policy script needs to be rewritten, and the virtual machine in the kernel compiles and executes the rewritten policy script provided by user-mode processes. This eliminates the need to statically compile the security policy logic into the kernel, modify the kernel code, restart the system, and interrupt system operation, further improving the efficiency and flexibility of security detection updates while reducing update costs.
[0059] To improve the efficiency of determining subsequent target policy objects, a bitmap can be used to store the correspondence between policy scripts and detection points. This correspondence can include at least one detection point defined by the policy script. Therefore, in some embodiments, the encapsulation and generation of policy objects based on the compiled policy script and its correspondence with detection points can include: The values of the bits corresponding to at least one detection point defined in the strategy script are set to the first preset value, and the values of the bits corresponding to the remaining detection points (excluding at least one detection point) are set to the second preset value, so as to obtain the detection bitmap corresponding to the strategy script. Based on the compiled strategy script and its corresponding detection bitmap, a strategy object is generated.
[0060] The detection bitmap can be used to determine the detection point that triggers the callback request when the value of the bit at the corresponding detection point of the strategy object is a first preset value.
[0061] In this embodiment, the detection bitmap may include multiple detection points set in the kernel and the bit values corresponding to each detection point. Among these multiple detection points, the bit values corresponding to at least one detection point defined by the strategy script are all first preset values, such as 1, and the bit values corresponding to the remaining detection points are all second preset values, such as 0.
[0062] For example, if there are m detection points in the kernel, and a certain policy script defines n detection points (n < m), then in the detection bitmap corresponding to the policy script, the bits corresponding to the n detection points are all 1, and the bits corresponding to the mn detection points are all 0.
[0063] During subsequent kernel security checks, the detection bitmap can be used to determine if the policy object has hit the detection point that triggers the callback request when the value of the bit at the corresponding detection point is the first preset value; otherwise, it can be determined that the policy object has not hit the detection point that triggers the callback request, thereby improving the efficiency of determining the target policy object.
[0064] By storing the correspondence between the policy script and the detection points in the form of a bitmap, the value of the bit of at least one detection point defined by the policy script is set to a first preset value, and the value of the bit of the remaining detection points is set to a second preset value, so as to improve the efficiency of subsequent determination of target policy objects and thus improve the efficiency of kernel security detection.
[0065] To further improve the efficiency of determining subsequent target policy objects, a linked list can be used to store the policy objects. In some embodiments, the above method may further include: Acquire the lock resource of the target linked list; The strategy object is inserted into the target list using lock resources; the target list can be used to determine whether any strategy object hits the checkpoint that triggers the callback request. Release the lock resource.
[0066] The target list can include multiple policy objects, which are inserted into the target list sequentially. Lock resources are used to ensure that only a single policy object is inserted into the target list at a time, avoiding confusion caused by simultaneous insertion of multiple policy objects and improving the rationality of policy object storage.
[0067] During subsequent kernel security checks, the target list can be used to traverse multiple policy objects sequentially to determine whether any policy object hits the detection point that triggers the callback request.
[0068] By using a linked list to store policy objects, the rationality of policy object storage is improved. When determining the target policy object that triggers the callback request, multiple policy objects in the linked list can be traversed sequentially, which further improves the efficiency of determining the target policy object and the efficiency of kernel security detection.
[0069] Optionally, the technical solution of this application can support the deletion of strategy objects in the target linked list. Based on this, the above method may further include: In response to a policy object deletion request sent by a user-space process, after the policy script in the policy object to be deleted has finished executing, the policy object to be deleted is removed from the target list and the target list is updated.
[0070] The policy object deletion request may include the policy object's identification information. The policy object corresponding to the identification information can be found in the target list and used as the policy object to be deleted.
[0071] If the policy script in the policy object to be deleted is not in the execution state, the policy object can be directly deleted from the target list. If it is in the execution state, deletion can be performed after the policy script has finished executing.
[0072] Taking the Linux kernel as an example, when the policy script is in the execution state, the policy object to be deleted can be removed from the target list, its status is marked as "to be deleted", and it enters the grace period (the stage of waiting for all virtual machines that may be executing the policy script to exit the read critical section, which is the core concept of the RCU mechanism (Read-Copy-Update, a high-efficiency synchronization mechanism)). After ensuring that all virtual machines that may be executing the policy script have exited the read critical section, the memory resources and space occupied by the policy object are released, and the deletion process is completed.
[0073] After a strategy object to be deleted is deleted, there is no need to move the remaining strategy objects. Only the pointers of one or more remaining strategy objects need to be adjusted. For example, the `next` pointer of the previous strategy object can be adjusted to point to the next strategy object, and so on. The update process of the target linked list is consistent with the linked list update implementation in traditional schemes, and this application does not impose any restrictions on it.
[0074] By deleting the corresponding policy object after the policy script finishes execution, the problem of concurrent competition (i.e., when one virtual machine is executing the policy script in the policy object, another virtual machine attempts to release the memory resources of the policy object) is avoided when the security policy logic is updated. This ensures that the security policy logic is updated smoothly and stably, thereby achieving true "hot update". It enables fast hot loading and lossless hot unloading of policy objects, which greatly improves the operating system's response speed and operational flexibility in the face of sudden security threats.
[0075] As can be seen from one or more of the above embodiments, a virtual machine is deployed in the kernel of this application embodiment. To further improve kernel security and the efficiency of secure loading and detection, in some embodiments, the above method may further include: Deploy virtual machines in the kernel, trimming at least one execution function that meets the execution conditions, and the virtual machines are set up with at least one isolation environment; Run multiple virtual machine instances corresponding to the virtual machine.
[0076] The execution function that meets the execution conditions may include, for example, execution functions related to the user-mode execution environment or execution functions related to kernel-restricted access environments, which can be configured according to actual needs. At least one execution function can be pruned to retain virtual machines that are related to the kernel-mode execution environment and only support access in kernel-allowed environments.
[0077] The number of isolation environments can be set according to actual needs; for example, two isolation environments can be set up. The tasks executed in different isolation environments are independent of each other.
[0078] Based on this, calling the virtual machine in the kernel to compile the policy script and parse it to obtain the correspondence between the policy script and the detection points can include: The first virtual machine instance among multiple virtual machine instances is invoked to compile the policy script in an isolated environment and parse it to obtain the correspondence between the policy script and the detection points.
[0079] Specifically, the first virtual machine instance can be invoked to compile the policy script in an idle, isolated environment, and the correspondence between the policy script and the detection points can be obtained by parsing.
[0080] By deploying virtual machines in the kernel with at least one execution function that meets the execution conditions removed, redundant execution functions in the virtual machines are reduced while access to kernel-restricted environments is avoided, further improving kernel security. Furthermore, by setting up at least one isolated environment in the virtual machine, at least one task can be executed simultaneously in a single virtual machine instance, and different execution tasks are independent of each other, further improving the efficiency of secure loading and detection.
[0081] The above one or more embodiments describe the process of secure kernel loading. In practical applications, when the kernel detects and executes a kernel operation corresponding to a certain detection point, it can also call back the security module to perform security checks. Therefore, in some embodiments, the above method may further include: When a kernel operation corresponding to any detection point is detected, a callback request is sent to the security module. This callback request is used to trigger the determination of the target policy object that the detection point has hit. The policy script in the target policy object is executed by the virtual machine to detect the kernel operation. The detection result is fed back to the security module by the virtual machine.
[0082] The specific safety testing process will be described in subsequent embodiments and will not be repeated here.
[0083] Figure 2 This is a flowchart illustrating another embodiment of the secure loading method provided in this application. The technical solution of this embodiment can be applied to a virtual machine deployed in the kernel, specifically, it can be the first virtual machine instance among multiple virtual machine instances running in the kernel. A security module also runs in the kernel, and multiple detection points are set. Figure 2 The safe loading method shown may include the following steps: 201: In response to a kernel call request, determine the policy script.
[0084] The policy script can be provided by a user-space process, and the policy script can be source code.
[0085] 202: Compile the strategy script and parse it to obtain the correspondence between the strategy script and the detection points.
[0086] During compilation, optionally, a compiler deployed in the kernel can be invoked to compile the policy script. The compiled policy script can be intermediate code, such as bytecode.
[0087] During the parsing process, the intermediate code of the compiled policy script can be parsed. Specifically, the runtime environment of this intermediate code can be set up in a virtual machine, and the intermediate code can be simulated and run in the runtime environment, outputting the simulation results containing the correspondence between the policy script and the detection points.
[0088] Optionally, if the virtual machine includes multiple isolated environments, the intermediate code can be set up in any of the idle isolated environments, and the intermediate code can be simulated and run in the runtime environment.
[0089] 203: The compiled policy script and its corresponding relationships are fed back to the kernel, so that the kernel can encapsulate and generate policy objects based on the compiled policy script and its correspondence with the detection points.
[0090] The encapsulated policy object can be used as the target policy object of the detection point that triggered the callback request when the security module responds to the callback request triggered by the detection point; the policy script can be executed in the virtual machine to detect the kernel operation corresponding to the detection point that triggered the callback request and feed the detection result back to the security module.
[0091] In this embodiment, the virtual machine deployed in the kernel can respond to kernel call requests, determine the policy script from the user-space process (specifically, the source code of the policy script), compile the policy script to obtain the compiled policy script (i.e., the intermediate code, such as bytecode), and parse the policy script to obtain the correspondence between the policy script and the detection points set in the kernel. The compiled policy script and its correspondence are then fed back to the kernel, which uses this information to encapsulate and generate a policy object. This encapsulated policy object can be used by the security module running in the kernel when it responds to a callback request triggered by a detection point. The policy script can then be executed in the virtual machine to detect the kernel operations corresponding to the detection point that triggered the callback request and feed the detection results back to the security module.
[0092] By employing a scripting language to write policy scripts and deploying a virtual machine in the kernel that supports the compilation and execution of these policy scripts, this embodiment utilizes kernel-mode just-in-time (JIT) compilation. The virtual machine compiles and executes the policy scripts provided by user-mode processes. Compared to traditional solutions that statically compile security policy logic into the kernel and have the security module execute the statically compiled code, this embodiment eliminates the need for static compilation of security policy logic into the kernel. Therefore, no kernel code modification is required, solving the problem of long security detection times, improving security detection efficiency, and reducing security detection costs and barriers to entry. Furthermore, when updating security policy logic, only the policy script needs to be rewritten, and the virtual machine in the kernel compiles and executes the rewritten policy script provided by user-mode processes. This eliminates the need to statically compile the security policy logic into the kernel, modify the kernel code, restart the system, and interrupt system operation, further improving the efficiency and flexibility of security detection updates while reducing update costs.
[0093] Figure 3 This is a flowchart of an embodiment of a security detection method provided in this application. The technical solution of this embodiment can be applied to a security module that runs in the kernel, where a virtual machine is deployed and multiple detection points are set. Figure 3 The security testing method shown may include the following steps: 301: In response to a callback request triggered at any detection point, determine the target policy object that was hit at that detection point.
[0094] The target policy object is obtained by encapsulating the policy script and its correspondence with the detection points; the policy script is provided by the user-space process and compiled using the virtual machine in the kernel; the correspondence is obtained by the virtual machine parsing the policy script.
[0095] The policy object can include intermediate code, such as bytecode, of the policy script. This intermediate code can be obtained by compiling the source code provided by the user-mode process within the kernel. The specific compilation and encapsulation process is detailed in... Figure 1 The examples shown have already been described.
[0096] Optionally, the encapsulated policy object can be saved to a preset data structure, such as a linked list, array, or tree structure. Based on this, the security module can specifically search for the target policy object that the detection point hits, from a preset data structure containing multiple policy objects, according to the corresponding relationships between the multiple policy objects. The target policy object can include one or more.
[0097] 302: Use a virtual machine to execute policy scripts to detect kernel operations corresponding to detection points.
[0098] The policy script may include at least one security policy logic function defined for at least one detection point.
[0099] Based on this, a virtual machine deployed in the kernel can be used to execute at least one security policy logic function in the policy script of the target policy object that corresponds to the detection point, so as to detect the kernel operation corresponding to the detection point according to the corresponding security policy logic.
[0100] Specifically, the intermediate code of the policy script, such as bytecode, can be loaded into a virtual machine. The runtime environment of this intermediate code can be set, and relevant parameters for the kernel operation can be passed in. This allows the virtual machine to call at least one security policy logic function within the runtime environment, and based on these parameters, the kernel operation can be detected. For example, when the kernel operation is an access operation to a kernel object, the relevant parameters can include the kernel object's identification information, access address, etc., without restriction.
[0101] 303: Get the detection results returned by the virtual machine.
[0102] The target policy object hit by the detection point can include one or more.
[0103] Optionally, obtaining the detection results returned by the virtual machine may include: Obtain the detection results corresponding to one or more target policy objects fed back by the virtual machine.
[0104] The above methods may also include: Based on the detection results corresponding to one or more target policy objects, the kernel operation is processed for security.
[0105] In a practical application, kernel operations may include access operations on kernel objects, and the detection results returned by the virtual machine may include denying or allowing access.
[0106] Optionally, when the detection point hits multiple target policy objects, the security processing of the kernel operation based on the detection results corresponding to one or more target policy objects may include: Based on the detection results corresponding to multiple target policy objects, if any detection result indicates that access is prohibited, access to the kernel object is prohibited; otherwise, access to the kernel object is permitted.
[0107] When multiple target policy objects are detected at a detection point, the detection results corresponding to each target policy object are obtained. Access to the kernel object is only allowed when all multiple detection results indicate that access is permitted. If any detection result indicates that access is prohibited, access to the kernel object is prohibited. This "one-vote veto" principle further improves the security of kernel access.
[0108] Optionally, if the target policy object hit by the detection point includes only one, and the detection result corresponding to the target policy object is "access prohibited", then access to the kernel object is prohibited; otherwise, access to the kernel object is allowed.
[0109] In this embodiment, the security module running in the kernel can respond to callback requests triggered by any detection point set in the kernel and determine the target policy object hit by that detection point. This target policy object can be obtained by encapsulating a policy script and its correspondence with the detection point. The policy script can be provided by a user-space process and compiled using a virtual machine deployed in the kernel. The correspondence can be obtained by the virtual machine parsing the policy script. The security module can use the virtual machine deployed in the kernel to execute the policy script in the target policy object to detect the kernel operation corresponding to the detection point that triggered the callback request, obtain the detection results fed back by the virtual machine, and then perform security processing on the kernel operation based on the detection results.
[0110] By employing a scripting language to write policy scripts and deploying a virtual machine in the kernel that supports the compilation and execution of these policy scripts, this embodiment utilizes kernel-mode just-in-time (JIT) compilation. The virtual machine compiles and executes the policy scripts provided by user-mode processes. Compared to traditional solutions that statically compile security policy logic into the kernel and have the security module execute the statically compiled code, this embodiment eliminates the need for static compilation of security policy logic into the kernel. Therefore, no kernel code modification is required, solving the problem of long security detection times, improving security detection efficiency, and reducing security detection costs and barriers to entry. Furthermore, when updating security policy logic, only the policy script needs to be rewritten, and the virtual machine in the kernel compiles and executes the rewritten policy script provided by user-mode processes. This eliminates the need to statically compile the security policy logic into the kernel, modify the kernel code, restart the system, and interrupt system operation, further improving the efficiency and flexibility of security detection updates while reducing update costs.
[0111] In some embodiments, the target policy object is obtained by encapsulating the policy script and its correspondence with the detection point, and then inserted into the target linked list. Based on this, determining the target policy object that the detection point has hit may include: For any policy object in the target list, determine whether the policy object hits the detection point based on the corresponding relationship in the policy object; If the policy object hits the detection point, the policy object that hits the detection point will be used as the target policy object.
[0112] In this embodiment, the target linked list may include multiple policy objects inserted sequentially. The security module can traverse the target linked list and determine whether the current policy object hits the detection point based on the correspondence of the current policy objects. Specifically, the correspondence may include at least one detection point defined by the policy object. Therefore, it can be determined whether the at least one defined detection point includes the detection point that triggers the callback request. If it does, it is determined that the policy object hits the detection point; otherwise, it is determined that the policy object does not hit the detection point.
[0113] If the current policy object hits the detection point, the current policy object is used as the target policy object, and the policy script of the current policy object is executed by the virtual machine to detect kernel operations.
[0114] If the current policy object does not hit the detection point, continue traversing the next policy object in the target list until the traversal ends, and determine one or more target policy objects that have hit the target.
[0115] By using a linked list to store policy objects, the rationality of policy object storage is improved. Thus, during security testing, the security module can traverse multiple policy objects in the target linked list, further improving the efficiency of determining the target policy object, and thereby improving the efficiency of kernel security testing.
[0116] In some embodiments, the correspondence between policy scripts and detection points is saved in the detection bitmap corresponding to the policy script. The policy object is specifically obtained by encapsulating the policy script and its corresponding detection bitmap. The detection bitmap includes bits corresponding to multiple detection points, and the values of the bits are determined based on at least one detection point defined in the policy script. Therefore, determining whether a policy object hits a detection point based on the correspondence in the policy object can include: Based on the detection bitmap in the strategy object, if the value of the bit corresponding to the detection point is the first preset value, it is determined that the strategy object has hit the detection point.
[0117] In this embodiment, the detection bitmap may include multiple detection points set in the kernel and the bit values corresponding to each detection point. Among these multiple detection points, the bit values corresponding to at least one detection point defined by the strategy script are all first preset values, such as 1, and the bit values corresponding to the remaining detection points are all second preset values, such as 0.
[0118] The security module can traverse the target linked list, and based on the detection bitmap in the current policy object, determine that the policy object has hit the detection point when the value of the bit corresponding to the detection point is 1. The current policy object is then used as the target policy object, and the policy script of the current policy object is executed by the virtual machine to detect kernel operations.
[0119] Otherwise, if the policy object does not hit the detection point, continue traversing the next policy object in the target list until the traversal ends, and determine one or more target policy objects that have hit the target.
[0120] By storing the correspondence between policy scripts and detection points in the form of a bitmap, the value of the bit at at least one detection point defined in the policy script is set to a first preset value, and the values of the bits at the remaining detection points are set to a second preset value. Thus, during security detection, the security module can traverse multiple policy objects in the target linked list. Only policy objects whose bit position corresponding to the detection point in the detection bitmap is set to the first preset value will be used as target policy objects and scheduled to be executed in the virtual machine. This greatly reduces the overhead of invalid virtual machine calls and further improves the efficiency of determining target policy objects and the efficiency of kernel security detection.
[0121] In some embodiments, multiple virtual machine instances corresponding to virtual machines run in the kernel, and the policy script can be compiled from the first virtual machine instance among the multiple virtual machine instances. Based on this, executing the policy script using a virtual machine to detect kernel operations corresponding to detection points can include: The second virtual machine instance among multiple virtual machine instances is used to execute a policy script to detect the kernel operations corresponding to the detection points.
[0122] The second virtual machine instance can be any one of multiple virtual machine instances or any virtual machine instance that is in an idle state.
[0123] Optionally, the above method may further include: Based on the number of policy scripts executed for each of the multiple virtual machine instances, virtual machine instances whose number of policy scripts executed is less than the preset number are designated as the second virtual machine instances in an idle state.
[0124] By utilizing a second virtual machine instance that is in an idle state to execute policy scripts, kernel detection efficiency is further improved.
[0125] Optionally, any virtual machine instance may include at least one isolated environment. Based on this, using a second virtual machine instance among multiple virtual machine instances, executing the policy script may include: Execute policy scripts in an isolated environment using a second virtual machine instance among multiple virtual machine instances.
[0126] Specifically, a second virtual machine instance can be used to execute policy scripts in an idle, isolated environment. This idle, isolated environment can refer to an environment where the number of policy script executions is less than a preset number. This further improves kernel detection efficiency.
[0127] In a practical application, multiple virtual machine instances can include virtual machine instances corresponding to different types of kernel execution contexts. A kernel execution context refers to the environment in which the kernel code runs. Kernel execution contexts can include two types: process context (which can sleep) and interrupt / softIRQ context (which cannot sleep).
[0128] Based on this, in some embodiments, using a second virtual machine instance among multiple virtual machine instances to execute the policy script to detect the kernel operation corresponding to the detection point may include: When the kernel execution context is the first type of execution context, the policy script is executed using the second virtual machine instance corresponding to the first type of execution context among multiple virtual machine instances to detect the kernel operation corresponding to the detection point; When the kernel execution context is a type II execution context, the policy script is executed using the second virtual machine instance corresponding to the type II execution context among multiple virtual machine instances to detect the kernel operation corresponding to the detection point.
[0129] Optionally, when the kernel's execution context is a first-type execution context, a policy script can be executed using a second virtual machine instance corresponding to the first-type execution context and currently in an idle state to detect the kernel operation corresponding to the detection point. When the kernel's execution context is a second-type execution context, a policy script can be executed using a second virtual machine instance corresponding to the second-type execution context and currently in an idle state to detect the kernel operation corresponding to the detection point. For example, when the first-type execution context is a process context, the second-type execution context can be an interrupt / soft interrupt context; when the first-type execution context is an interrupt / soft interrupt context, the second-type execution context can be a process context.
[0130] By selecting the appropriate virtual machine instance to execute the policy script based on the type of kernel execution context, concurrency conflicts and deadlocks are avoided, thereby improving the rationality of virtual machine instance execution of security checks.
[0131] Figure 4 This is a flowchart illustrating another embodiment of the security detection method provided in this application. The technical solution of this embodiment can be applied to deploying virtual machines in the kernel, specifically, it can be the second virtual machine instance among multiple virtual machine instances running in the kernel. A security module also runs in the kernel and multiple detection points are set. Figure 4 The security testing method shown may include the following steps: 401: In response to a call request from a security module, determine the target policy object.
[0132] The target policy object is the policy object that the security module matches when a callback request is triggered by any detection point. The target policy object can be obtained by encapsulating a policy script and its mapping to detection points. The policy script can be provided by a user-space process and compiled using a virtual machine. The mapping can be obtained by the virtual machine parsing the policy script.
[0133] 402: Execute the policy script to detect the kernel operation corresponding to the detection point.
[0134] The policy object can include intermediate code, such as bytecode, of the policy script. This intermediate code can be obtained by compiling the source code provided by the user-mode process within the kernel. The specific compilation and encapsulation process is detailed in... Figure 1 The examples shown have already been described.
[0135] Specifically, the virtual machine can load intermediate code, such as bytecode, of the policy script and set up the runtime environment for this intermediate code. Within this runtime environment, it can call at least one security policy logic function to detect the kernel operation based on the relevant parameters of the kernel operation. For example, when the kernel operation is an access operation to a kernel object, the relevant parameters can include the kernel object's identification information, access address, etc., without restriction.
[0136] 403: The detection results are fed back to the security module.
[0137] In this embodiment, the virtual machine deployed in the kernel can determine the target policy object in response to a call request from a security module running in the kernel. The target policy object is the policy object that the security module matches when a callback request is triggered at any detection point. The target policy object can be obtained by encapsulating a policy script and its correspondence with detection points. The policy script can be provided by a user-space process and compiled using the virtual machine. The correspondence can be obtained by the virtual machine parsing the policy script. The virtual machine can execute the policy script in the target policy object to detect the kernel operation corresponding to the detection point and feed the detection result back to the security module.
[0138] By employing a scripting language to write policy scripts and deploying a virtual machine in the kernel that supports the compilation and execution of these policy scripts, this embodiment utilizes kernel-mode just-in-time (JIT) compilation. The virtual machine compiles and executes the policy scripts provided by user-mode processes. Compared to traditional solutions that statically compile security policy logic into the kernel and have the security module execute the statically compiled code, this embodiment eliminates the need for static compilation of security policy logic into the kernel. Therefore, no kernel code modification is required, solving the problem of long security detection times, improving security detection efficiency, and reducing security detection costs and barriers to entry. Furthermore, when updating security policy logic, only the policy script needs to be rewritten, and the virtual machine in the kernel compiles and executes the rewritten policy script provided by user-mode processes. This eliminates the need to statically compile the security policy logic into the kernel, modify the kernel code, restart the system, and interrupt system operation, further improving the efficiency and flexibility of security detection updates while reducing update costs.
[0139] It should be noted that some processes described in the above embodiments and accompanying drawings include multiple operations appearing in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear in this document, or they may be executed in parallel. The operation numbers, such as 101, 102, etc., are merely used to distinguish different operations and do not represent any execution order. Furthermore, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should also be noted that the descriptions such as "first" and "second" in this document are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.
[0140] Figure 5a This is a schematic diagram of the structure of an operating system in a practical application. For example... Figure 5a As shown, in operating system 50, virtual memory is divided into two blocks: user space and kernel space. User-mode processes run in user space, while kernel 501 and its drivers (not shown in the diagram) run in kernel space. Kernel space and user space communicate through system calls.
[0141] The kernel 501 runs a security module 5011, which deploys a virtual machine and runs multiple virtual machine instances 5012 corresponding to that virtual machine. Multiple detection points are set on critical paths in the kernel, such as file access, network communication, and process scheduling (not shown in the figure).
[0142] During the secure loading phase, kernel 501 can obtain the source code of the policy script provided by the user-mode process through system calls, compile the source code using the first virtual machine instance, and parse the correspondence between the policy script and the detection points. Based on the compiled policy script, i.e. the intermediate code of the policy script, such as bytecode, and the correspondence, a policy object is encapsulated and inserted into the target linked list 5013.
[0143] During the security detection phase, when kernel 501 detects and executes a kernel operation corresponding to a certain detection point, it calls security module 5011 to perform corresponding control processing on that kernel operation. Security module 5011 can respond to the callback request triggered by that detection point, search for the target policy object that the detection point hits in the target linked list 5013, execute the policy script in the target policy object using the second virtual machine instance to detect the kernel operation corresponding to that detection point, obtain the detection result returned by the second virtual machine instance, and perform security processing on the kernel operation based on the detection result.
[0144] Figure 5b This is a diagram illustrating secure loading in a practical application. For example... Figure 5bAs shown, kernel 501 obtains the source code of the policy script provided by the user-mode process through the user-mode file interface (not shown in the figure), and uses the idle first virtual machine instance to call the kernel-mode compiler to compile the source code (step 51). During the compilation process, the lexical and syntactic properties of the source code are checked. If the check passes, the bytecode of the policy script is obtained (step 52). If the check fails, the security loading process ends (step 55).
[0145] Kernel 501 uses the idle first virtual machine instance to simulate running bytecode (step 53). If the simulation runs successfully, it parses and obtains the correspondence between the policy script and the detection point (step 54). If the simulation fails, the security loading process ends (step 55). Kernel 501 encapsulates and generates a policy object based on the bytecode and the correspondence (step 56), and inserts the policy object into the target linked list (step 57).
[0146] By employing a scripting language to write policy scripts and deploying a virtual machine in the kernel that supports the compilation and execution of these policy scripts, this embodiment utilizes kernel-mode just-in-time (JIT) compilation. The virtual machine compiles and executes the policy scripts provided by user-mode processes. Compared to traditional solutions that statically compile security policy logic into the kernel and have the security module execute the statically compiled code, this embodiment eliminates the need for static compilation of security policy logic into the kernel. Therefore, no kernel code modification is required, solving the problem of long security detection times, improving security detection efficiency, and reducing security detection costs and barriers to entry. Furthermore, when updating security policy logic, only the policy script needs to be rewritten, and the virtual machine in the kernel compiles and executes the rewritten policy script provided by user-mode processes. This eliminates the need to statically compile the security policy logic into the kernel, modify the kernel code, restart the system, and interrupt system operation, further improving the efficiency and flexibility of security detection updates while reducing update costs.
[0147] Furthermore, by employing kernel-mode just-in-time (JIT) compilation during the secure loading phase, the source code of the scripting language provided by the user-mode process is compiled. During compilation, lexical and syntactic checks are performed on the source code to ensure that the code loaded into the kernel is structurally valid, eliminating the risk of maliciously constructed binary code attacking the kernel and further enhancing kernel security. Moreover, by utilizing the virtual machine to execute intermediate code during the security detection phase, the executableness of the policy script encapsulated in the target policy object is ensured, providing comprehensive technical support for the security module to perform secure processing of kernel operations based on the detection results fed back by the virtual machine.
[0148] In a practical application, the policy script can be written using the Lua scripting language. The compiler can be a Lua compiler, supporting the compilation of Lua scripts to obtain bytecode. The virtual machine can be a Lua virtual machine, providing a runtime environment for the compiled bytecode, supporting the execution of the bytecode, and parsing to obtain the correspondence between the policy script and the detection points.
[0149] By employing a lightweight scripting language to write policy scripts, compared to using complex declarative languages, the solution in this application can describe security policy logic with complex conditional judgments such as nested if-else statements and loop processing, further lowering the security detection threshold and improving the flexibility of security detection. Furthermore, compared to instruction set-based programming, the solution in this application can perform deep string parsing, achieving complex attack signature matching without strictly limiting the number of instructions or stack space size, and without prohibiting complex loop logic, further improving the flexibility of security detection.
[0150] Figure 5c This is a schematic diagram of a security detection method in a practical application. For example... Figure 5c As shown, the security module running in the kernel responds to a callback request triggered by any detection point, such as detection point A, among multiple detection points set by the kernel (step 61). It traverses the target linked list and determines whether the bit of detection point A in the detection bitmap of the current policy object is set to 1 (step 63). If so, it takes the current policy object as the target policy object and uses the second virtual machine instance to execute the policy script in the target policy object to detect the kernel operation corresponding to detection point A (step 64) and obtains the detection result fed back by the second virtual machine instance (step 65).
[0151] Taking kernel operations as an example of accessing kernel objects, the security module determines whether the detection result is "access prohibited" (step 66). If yes, it records the detection result (access prohibited) (step 67). If no, it determines whether the target linked list has been traversed (step 62). If the traversal has not ended, it continues to judge the detection bitmap of the next policy object. If no, the traversal ends, and the detection results are summarized (step 68). Based on the detection results of all target policy objects that hit detection point A, if any detection result is "access prohibited," the security module prohibits the access operation; otherwise, it allows the access operation.
[0152] Figure 6 This application provides a schematic diagram of the structure of an embodiment of a safe loading device, which may include the following units: The first acquisition unit 601 is used to acquire the policy script provided by the user-mode process; The first calling unit 602 is used to call the virtual machine in the kernel to compile the policy script and parse it to obtain the correspondence between the policy script and the detection points; The encapsulation unit 603 is used to encapsulate and generate a policy object based on the compiled policy script and its correspondence with the detection points. The policy object is used as the target policy object for the detection point when the security module responds to the callback request triggered by the detection point. The policy script is used to execute in the virtual machine to detect the kernel operation corresponding to the detection point and to feed back the detection result to the security module.
[0153] In some embodiments, the correspondence between the strategy script and the detection point includes at least one detection point defined by the strategy script; the encapsulation unit 603 is specifically used to set the bit values corresponding to the at least one detection point defined by the strategy script to a first preset value, and to set the bit values corresponding to the remaining detection points (excluding at least one detection point) among the multiple detection points to a second preset value, so as to obtain a detection bitmap corresponding to the strategy script; based on the compiled strategy script and the corresponding detection bitmap, a strategy object is encapsulated and generated; the detection bitmap is used to determine that the strategy object hits a detection point when the bit value of the detection point corresponding to the strategy object is the first preset value.
[0154] In some embodiments, the apparatus may further include: a writing unit for acquiring lock resources of a target linked list; inserting a policy object into the target linked list using the writing resources; the target linked list being used to determine whether any policy object hits a detection point; and releasing the lock resources. The deletion unit is used to respond to a policy object deletion request sent by a user-mode process. After the policy script in the policy object to be deleted finishes execution, the policy object to be deleted is removed from the target list and the target list is updated.
[0155] In some embodiments, the apparatus may further include: a deployment unit for deploying in the kernel a virtual machine that has at least one execution function that meets the execution conditions, wherein the virtual machine is provided with at least one isolation environment; A runtime unit is used to run multiple virtual machine instances corresponding to a virtual machine. The first calling unit 602 is specifically used to call the first virtual machine instance among multiple virtual machine instances, compile the policy script in an isolated environment, and parse to obtain the correspondence between the policy script and the detection points.
[0156] In some embodiments, the apparatus may further include: a verification unit for storing the policy script and verifying the policy script; The first calling unit 602, if the verification passes, is specifically used to call the virtual machine in the kernel to compile the policy script; The device may also include an output unit for outputting a prompt message in the event of a failed verification or parsing failure.
[0157] In some embodiments, the apparatus may further include: a callback unit, configured to detect a kernel operation corresponding to a detection point, initiate a callback request to a security module, the callback request being used to trigger the determination of a target policy object to which the detection point is hit, the policy script in the target policy object being executed by a virtual machine to detect the kernel operation, and the detection result being fed back to the security module by the virtual machine.
[0158] Figure 6 The aforementioned safety loading device can perform Figure 1 The implementation principle and technical effects of the secure loading method described in the illustrated embodiments will not be repeated here. The specific methods by which each unit in the secure loading device performs its operations have been described in detail in the embodiments related to this method, and will not be elaborated upon here.
[0159] Figure 7 This is a schematic diagram of another embodiment of a safe loading device provided in this application. The device may include the following units: The first determining unit 701 is used to determine the policy script in response to a kernel call request; the policy script is provided by a user-mode process. Compilation unit 702 is used to compile the strategy script and parse it to obtain the correspondence between the strategy script and the detection points; The first feedback unit 703 is used to feed back the compiled policy script and its corresponding relationship to the kernel, so that the kernel can encapsulate and generate a policy object based on the compiled policy script and its correspondence with the detection point. The policy object is used as the target policy object for the detection point when the security module responds to the callback request triggered by the detection point. The policy script is used to execute in the virtual machine to detect the kernel operation corresponding to the detection point and feed back the detection result to the security module.
[0160] Figure 7 The aforementioned safety loading device can perform Figure 2 The implementation principle and technical effects of the secure loading method described in the illustrated embodiments will not be repeated here. The specific methods by which each unit in the secure loading device performs its operations have been described in detail in the embodiments related to this method, and will not be elaborated upon here.
[0161] Figure 8 This application provides a schematic diagram of the structure of a security detection device according to one embodiment. The device may include the following units: The second determining unit 801 is used to determine the target policy object hit by the detection point in response to a callback request triggered by any detection point; the target policy object is obtained by encapsulating the policy script and its correspondence with the detection point; the policy script is provided by the user-mode process and compiled using the virtual machine in the kernel; the correspondence is obtained by the virtual machine parsing the policy script; The second calling unit 802 is used to execute a policy script using a virtual machine to detect kernel operations corresponding to the detection point; The second acquisition unit 803 is used to acquire the detection results fed back by the virtual machine.
[0162] In some embodiments, the target policy object is obtained by encapsulating the policy script and its correspondence with the detection points and then inserting it into the target linked list; The second determining unit 801 is specifically used to determine whether a strategy object hits a detection point for any strategy object in the target linked list based on the correspondence in the strategy object; if the strategy object hits a detection point, the strategy object that hits the detection point is taken as the target strategy object.
[0163] In some embodiments, the correspondence is saved to the detection bitmap corresponding to the strategy script, and the strategy object is obtained by encapsulating the strategy script and the corresponding detection bitmap; the detection bitmap includes bits corresponding to multiple detection points respectively; the value of the bits is determined according to at least one detection point defined in the strategy script; The second determining unit 801 is specifically used to determine that the strategy object has hit a detection point when the value of the bit at the corresponding detection point is a first preset value, based on the detection bitmap in the strategy object; and is also used to determine that the strategy object has not hit a detection point when the value of the bit at the corresponding detection point is a second preset value, based on the detection bitmap in the strategy object.
[0164] In some embodiments, multiple virtual machine instances corresponding to virtual machines run in the kernel; the policy script is specifically compiled from the first virtual machine instance among the multiple virtual machine instances. The second calling unit 802 is specifically used to execute a policy script using the second virtual machine instance among multiple virtual machine instances to detect the kernel operation corresponding to the detection point.
[0165] In some embodiments, the multiple virtual machine instances include virtual machine instances with different execution contexts corresponding to different kernel types; The second calling unit 802 is specifically used to execute a policy script to detect the kernel operation corresponding to the detection point when the kernel execution context is a first type of execution context, using the second virtual machine instance corresponding to the first type of execution context among multiple virtual machine instances; and to execute a policy script to detect the kernel operation corresponding to the detection point when the kernel execution context is a second type of execution context, using the second virtual machine instance corresponding to the second type of execution context among multiple virtual machine instances.
[0166] In some embodiments, any virtual machine instance includes at least one isolated environment; The second invocation unit 802 is specifically used to execute a policy script in an isolated environment using a second virtual machine instance among multiple virtual machine instances.
[0167] In some embodiments, the target policy object of the detection point hit includes one or more; the apparatus may further include: The processing unit is used to perform security processing on kernel operations based on the detection results corresponding to one or more target policy objects.
[0168] Figure 8 The aforementioned safety detection device can perform Figure 3 The implementation principle and technical effects of the security detection method described in the illustrated embodiments will not be repeated here. The specific methods by which each unit in the security detection device performs its operations have been described in detail in the embodiments related to this method, and will not be elaborated upon here.
[0169] Figure 9 This application provides a schematic diagram of the structure of a security detection device according to one embodiment. The device may include the following units: The third determining unit 901 is used to determine the target policy object in response to the call request of the security module. The target policy object is the policy object that hits the detection point when the security module responds to the callback request triggered by any detection point. The target policy object is obtained by encapsulating the policy script and its correspondence with the detection point. The policy script is provided by the user-space process and compiled by the virtual machine. The correspondence is obtained by the virtual machine parsing the policy script. Execution unit 902 is used to execute policy scripts to detect kernel operations corresponding to detection points; The second feedback unit 903 is used to feed back the detection results to the security module.
[0170] Figure 9 The aforementioned safety detection device can perform Figure 4The implementation principle and technical effects of the security detection method described in the illustrated embodiments will not be repeated here. The specific methods by which each unit in the security detection device performs its operations have been described in detail in the embodiments related to this method, and will not be elaborated upon here.
[0171] Figure 10 This is a schematic diagram of the structure of one embodiment of a computing device provided in this application. Figure 10 As shown, in practical applications, the computing device may include a storage component 1001 and a processing component 1002. In one practical application, the computing device may be a physical device in a cloud computing scenario.
[0172] Cloud computing is one of the fastest-growing trends in computer technology, involving the provision of managed services over a network. A cloud computing environment provides computing and storage resources as a service to end users. End users can request processing from the provided services. The processing capacity of a service is typically limited by the configured resources. Cloud computing is a service delivery model designed to enable on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing power, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and deployed with minimal management effort or interaction with the service provider.
[0173] It should be understood that although this application includes a detailed description of cloud computing, the implementation of the teachings described herein is not limited to a cloud computing environment. Rather, embodiments of this application can be implemented in conjunction with any other type of computing environment now known or developed hereafter.
[0174] Storage component 1001 is used to store computer programs and can be configured to store various other data to support operation on a computing device. Examples of this data include instructions for any application or method used to operate on the computing device, data structures, contact data, phone book data, messages, pictures, videos, etc.
[0175] Processing component 1002, coupled to storage component 1001, is used to execute computer programs in storage component 1001 for implementing, etc. Figure 1 The safe loading method shown, or Figure 2 The safe loading method shown, or Figure 3 The safety testing method shown, or Figure 4 The safety testing method shown.
[0176] Furthermore, such as Figure 10 As shown, the computing device may also include other components such as a communication component 1003, a display component 1004, a power supply component 1005, and an audio component 1006. Figure 10The diagram only shows some components and does not mean that the computing device includes only these components. Figure 10 The components shown. Additionally... Figure 10 The components within the dashed box are optional, not mandatory, and their specific requirements depend on the product form of the computing device. The computing device in this embodiment can be a desktop computer, laptop computer, smartphone, or IoT (Internet of Things) device, or a server-side device such as a conventional server, cloud server, or server array. If the computing device in this embodiment is implemented as a desktop computer, laptop computer, or smartphone, it may include... Figure 10 The components within the dashed box; if the computing device in this embodiment is implemented as a conventional server, cloud server, or server array, etc., then it may not include... Figure 10 The component within the dashed box.
[0177] The processing component described above includes one or more processors to execute computer instructions to complete all or part of the steps in the method described above. Alternatively, the processing component may be implemented as one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the method described above.
[0178] The aforementioned storage components can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.
[0179] The aforementioned communication component is configured to facilitate wired or wireless communication between the device housing the communication component and other devices. The device housing the communication component can access wireless networks based on communication standards, such as mobile communication networks, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel.
[0180] The aforementioned display components may include a screen, which may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen can be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors can sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.
[0181] The aforementioned power supply components provide power to various components within the device in which they reside. These power supply components may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to the device in which they reside.
[0182] The aforementioned audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.
[0183] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement the steps in the above-described method embodiments. The computer-readable storage medium includes volatile or non-volatile components, or a combination thereof, and can be removable or non-removable. Examples of computer-readable storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), flash memory or other memory technologies, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium. Accordingly, this application also provides a computer program product, which includes a computer program or instructions that, when executed by a processor, cause the processor to implement the steps in the above method embodiments. It should be understood that each step or combination of steps in the above method flow can be implemented by the computer program or instructions. Furthermore, these computer programs or instructions can be applied to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device, enabling the processor of the general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to function as an apparatus for implementing the corresponding functions in the above method embodiments.
[0184] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.
[0185] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.
[0186] Finally, it should be noted that the above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.
Claims
1. A security detection method, characterized in that, The method is applied to a security module that runs in the kernel; the kernel has multiple detection points, and the method includes: In response to a callback request triggered at any detection point, the target policy object hit by the detection point is determined; the target policy object is obtained by encapsulating a policy script and its correspondence with the detection point; the policy script is provided by a user-space process and compiled using a virtual machine in the kernel; the correspondence is obtained by the virtual machine parsing the policy script; The policy script is executed using the virtual machine to detect the kernel operations corresponding to the detection points; Obtain the detection results returned by the virtual machine.
2. The method according to claim 1, characterized in that, The target policy object is obtained by encapsulating the policy script and its correspondence with the detection points, and then inserted into the target linked list. The target policy object that the detection point hit includes: For any policy object in the target list, determine whether the policy object hits the detection point based on the correspondence in the policy object; If the policy object hits the detection point, the policy object that hits the detection point will be taken as the target policy object.
3. The method according to claim 2, characterized in that, The correspondence is saved to the detection bitmap corresponding to the strategy script. The strategy object is obtained by encapsulating the strategy script and its corresponding detection bitmap. The detection bitmap includes bits that correspond to the plurality of detection points. The value of the bit is determined based on at least one detection point defined by the strategy script; The step of determining whether the strategy object hits the detection point based on the correspondence in the strategy object includes: Based on the detection bitmap in the strategy object, if the value of the bit corresponding to the detection point is a first preset value, it is determined that the strategy object hits the detection point. The method further includes: Based on the detection bitmap in the strategy object, if the value of the bit corresponding to the detection point is a second preset value, it is determined that the strategy object has not hit the detection point.
4. The method according to claim 1, characterized in that, The kernel runs multiple virtual machine instances corresponding to the virtual machine; the policy script is specifically compiled from the first virtual machine instance among the multiple virtual machine instances. The step of using the virtual machine to execute the policy script to detect the kernel operation corresponding to the detection point includes: The policy script is executed using the second virtual machine instance among the plurality of virtual machine instances to detect the kernel operation corresponding to the detection point.
5. The method according to claim 4, characterized in that, The plurality of virtual machine instances include virtual machine instances corresponding to different types of execution contexts of the kernel; The step of using the second virtual machine instance among the plurality of virtual machine instances to execute the policy script to detect the kernel operation corresponding to the detection point includes: When the kernel's execution context is a first type of execution context, the policy script is executed using the second virtual machine instance corresponding to the first type of execution context among the plurality of virtual machine instances to detect the kernel operation corresponding to the detection point; When the kernel's execution context is a second type of execution context, the policy script is executed using the second virtual machine instance corresponding to the second type of execution context among the plurality of virtual machine instances to detect the kernel operation corresponding to the detection point.
6. The method according to claim 4, characterized in that, Each virtual machine instance includes at least one isolated environment; the step of executing the policy script using a second virtual machine instance from the plurality of virtual machine instances includes: The policy script is executed in an isolated environment using a second virtual machine instance among the plurality of virtual machine instances.
7. The method according to claim 1, characterized in that, The target policy object hit by the detection point includes one or more, and the method further includes: Based on the detection results corresponding to one or more target policy objects, the kernel operation is subjected to security processing.
8. The method according to claim 7, characterized in that, The kernel operations include access operations to kernel objects; the target policy objects hit by the detection point include multiple objects. The security processing of the kernel operation based on the detection results corresponding to one or more target policy objects includes: Based on the detection results corresponding to multiple target policy objects, if any detection result prohibits the access operation, access to the kernel object is prohibited; otherwise, access to the kernel object is permitted.
9. The method according to any one of claims 1 to 8, characterized in that, The strategy script is written in a lightweight scripting language, and the virtual machine is used to provide the runtime environment for the lightweight scripting language and support the compilation of the lightweight scripting language.
10. A security detection method, characterized in that, Applied to a virtual machine, the virtual machine running in a kernel, the kernel running a security module and having multiple detection points set up, the method includes: In response to the call request of the security module, a target policy object is determined; the target policy object is the policy object that hits the detection point when the security module responds to a callback request triggered at any detection point; the target policy object is obtained by encapsulating a policy script and its correspondence with the detection point; the policy script is provided by a user-space process and compiled using the virtual machine; the correspondence is obtained by the virtual machine parsing the policy script. The strategy script is executed to detect the kernel operations corresponding to the detection points; The detection results are then fed back to the security module.
11. A secure loading method, characterized in that, Applied to a kernel that runs a security module and has multiple detection points, the method includes: Obtain the policy script provided by the user-space process; The virtual machine in the kernel is invoked to compile the policy script and parse it to obtain the correspondence between the policy script and the detection point; Based on the compiled policy script and its correspondence with the detection points, a policy object is encapsulated and generated. The policy object is used as the target policy object for the detection point when the security module responds to the callback request triggered by the detection point. The policy script is executed in the virtual machine to detect the kernel operation corresponding to the detection point and feed the detection result back to the security module.
12. The method according to claim 11, characterized in that, The correspondence between the strategy script and the detection point includes at least one detection point defined by the strategy script; the process of encapsulating and generating a strategy object based on the compiled strategy script and its correspondence with the detection point includes: The values of the bits corresponding to at least one detection point defined in the strategy script are set to a first preset value, and the values of the bits corresponding to the remaining detection points other than the at least one detection point are set to a second preset value, so as to obtain the detection bitmap corresponding to the strategy script. Based on the compiled strategy script and the corresponding detection bitmap, a strategy object is generated; the detection bitmap is used to determine that the strategy object hits the detection point when the value of the bit corresponding to the detection point in the strategy object is a first preset value.
13. The method according to claim 11, characterized in that, Also includes: Acquire the lock resource of the target linked list; The strategy object is inserted into the target linked list using the lock resource; The target linked list is used to determine whether any policy object hits the detection point; Release the lock resource; The method further includes: In response to a policy object deletion request sent by the user-mode process, after the policy script in the policy object to be deleted has finished executing, the policy object to be deleted is deleted from the target list, and the target list is updated.
14. The method according to claim 11, characterized in that, Also includes: Deploy virtual machines in the kernel, removing at least one execution function that meets the execution conditions, and the virtual machines are provided with at least one isolation environment; Run multiple virtual machine instances corresponding to the virtual machine; The step of calling the virtual machine in the kernel to compile the policy script and parse it to obtain the correspondence between the policy script and the detection points includes: The first virtual machine instance among the plurality of virtual machine instances is invoked to compile the policy script in an isolated environment, and the correspondence between the policy script and the detection point is obtained by parsing.
15. The method according to claim 11, characterized in that, Also includes: Save the policy script and verify the policy script; The step of calling the virtual machine in the kernel to compile the policy script includes: If the verification passes, the virtual machine in the kernel is invoked to compile the policy script; The method further includes: If the verification fails or the parsing fails, an error message will be displayed.
16. The method according to any one of claims 11 to 15, characterized in that, Also includes: In response to the detection of a kernel operation corresponding to the detection point, a callback request is sent to the security module. The callback request is used to trigger the determination of the target policy object to which the detection point is hit. The policy script in the target policy object is executed by the virtual machine to detect the kernel operation. The detection result is fed back to the security module by the virtual machine.
17. A secure loading method, characterized in that, Applied to a virtual machine, the virtual machine running in a kernel, the kernel running a security module and having multiple detection points set up, the method includes: In response to the kernel's call request, a policy script is determined; the policy script is provided by a user-space process. The strategy script is compiled and parsed to obtain the correspondence between the strategy script and the detection points; The compiled policy script and its corresponding relationship are fed back to the kernel, so that the kernel can encapsulate and generate a policy object based on the compiled policy script and its correspondence with the detection point. The policy object is used as the target policy object for the detection point when the security module responds to the callback request triggered by the detection point. The policy script is used to execute in the virtual machine to detect the kernel operation corresponding to the detection point and feed back the detection result to the security module.
18. A computing device, characterized in that, This includes processing components and storage components; The storage component stores a computer program; the computer program is invoked and executed by the processing component to implement the security detection method as described in any one of claims 1 to 9, or the security detection method as described in claim 10, or the security loading method as described in any one of claims 11 to 16, or the security loading method as described in claim 17.
19. A computer-readable storage medium, characterized in that, It stores a computer program, which, when executed by a processing component, implements the security detection method as described in any one of claims 1 to 9, or the security detection method as described in claim 10, or the security loading method as described in any one of claims 11 to 16, or the security loading method as described in claim 17.
20. A computer program product, characterized in that, Includes a computer program or instructions that, when executed by a processing component, implement the security detection method as described in any one of claims 1 to 9, or the security detection method as described in claim 10, or the security loading method as described in any one of claims 11 to 16, or the security loading method as described in claim 17.
Citation Information
Patent Citations
Multi-strategy integration based mandatory access control method
CN104112089A
Method and device for detecting vulnerability of kernel based on virtual machine
CN106778242A
Android system kernel security detection method and device
CN108171061A
Kernel security detection method, apparatus and equipment, and storage medium
CN111259386A
System security detection method and device, electronic equipment, medium and product
CN113688358A