System security protection method and device, electronic equipment and storage medium

Abstract

The invention provides a system security protection method and device, electronic equipment and a storage medium, and relates to the technical field of network security. The method comprises the following steps: monitoring a client based on a configuration rule of a preset virtual machine control structure, and determining an event type and an instruction for triggering an event when monitoring that the client triggers a virtual machine exit event; determining a reason for triggering the virtual machine to exit the event based on the event type, the instruction and the configuration rule; when the reason is that the client executes the system call entry instruction, redirecting the read-write operation of the instruction on the target register to a preset corresponding shadow register; when the read-write operation is to read a system call kernel entry address, determining a file operation request of the client based on a system call number and parameters associated with a system call entry instruction; a file path of the file operation request is redirected to a file filtering module in a kernel mode of the client, and the control right of the central processing unit is returned to the client, so that the client sends the file operation request to the kernel mode of the client.

Description

Technical Field

[0001] This disclosure relates to the field of network security technology, specifically to a system security protection method, device, electronic device, and storage medium. Background Technology

[0002] Information security is a hot topic of current social concern. Researching system security hardening technologies under information security is of great significance for mitigating security threats faced by systems and ensuring their secure operation. However, conventional security detection methods in related technologies are easily deceived or bypassed. How to propose a system security protection method to improve the reliability of system security protection is an urgent problem to be solved. Summary of the Invention

[0003] This disclosure aims to at least partially address one of the technical problems in the related art.

[0004] The first aspect of this disclosure proposes a system security protection method, which is executed by a virtual machine monitor and includes: The client is monitored based on the configuration rules of the preset virtual machine control structure. When the client triggers a virtual machine exit event, the event type and instruction that triggered the event are determined. The configuration rules include an exception bitmap and register MSR read / write bitmaps. Based on the event type, the instruction, and the configuration rules, determine the reason for triggering the virtual machine exit event; If the reason is that the client executes a system call entry instruction, the read / write operation of the instruction targeting the target register is redirected to a preset corresponding shadow register; When the read / write operation is to read the kernel entry address of the system call, the file operation request of the client is determined based on the system call number and parameters associated with the system call entry instruction; The file path of the file operation request is redirected to the file filtering module in the client kernel mode, and the central processing unit control is returned to the client so that the client sends the file operation request into its own kernel mode.

[0005] A second aspect of this disclosure provides a system security protection method, which is executed by the client kernel mode and includes: Upon receiving a file operation request from the current client, a corresponding Input / Output Request Packet (IRP) is generated based on the file operation request, and the IRP request packet is sent to the file filtering module to determine the operation type and target file of the IRP request packet. Determine whether the target file is encrypted, and obtain a determination result; Based on the operation type and the determination result, the IRP request packet is processed to complete the operation on the target file.

[0006] A third aspect of this disclosure provides a system security protection device, which is configured in a virtual machine monitor and includes: The first processing module is used to monitor the client machine based on the configuration rules of the preset virtual machine control structure, and when the client machine triggers a virtual machine exit event, it determines the event type and instruction that triggered the event. The configuration rules include an exception bitmap and a register MSR read / write bitmap. The first determining module is used to determine the reason for triggering the virtual machine exit event based on the event type, the instruction, and the configuration rules; The second processing module is used to redirect the read / write operation of the target register to a preset corresponding shadow register when the reason is that the client executes a system call entry instruction. The second determining module is used to determine the client's file operation request based on the system call number and parameters associated with the system call entry instruction when the read / write operation is reading the kernel entry address of the system call. The third processing module is used to redirect the file path of the file operation request to the file filtering module in the client kernel mode, and return the central processing unit control to the client so that the client sends the file operation request into its own kernel mode.

[0007] A fourth aspect of this disclosure provides a system security protection device configured in the guest kernel mode, comprising: The fourth processing module is used to receive a file operation request sent by the current client, generate a corresponding Input / Output Request Packet (IRP) based on the file operation request, and send the IRP request packet to the file filtering module so that the file filtering module can determine the operation type of the IRP request packet and the target file of the operation. The third determining module is used to determine whether the target file is encrypted and obtain a determination result; The fifth processing module is used to process the IRP request packet based on the operation type and the determination result to complete the operation on the target file.

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

[0009] A sixth aspect of this disclosure provides a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are configured to cause the computer to perform the method described in the above embodiments.

[0010] A seventh aspect of this disclosure provides a computer program product including a computer program that, when executed by a processor, implements the methods described in the above embodiments.

[0011] The system security protection methods, devices, electronic equipment, and storage media provided in this disclosure have the following beneficial effects: In this embodiment, the client machine is first monitored based on the configuration rules of a preset virtual machine control structure. If a client machine triggers a virtual machine exit event, the event type and instruction that triggered the event are determined. Based on the event type, instruction, and configuration rules, the cause of the virtual machine exit event is determined. If the cause is that the client machine executes a system call entry instruction, the read / write operation of the instruction targeting the target register is redirected to a preset corresponding shadow register. If the read / write operation is to read the kernel entry address of the system call, the client machine's file operation request is determined based on the system call number and parameters associated with the system call entry instruction. Finally, the file path of the file operation request is redirected to the file filtering module in the client machine's kernel mode, and control of the central processing unit is returned to the client machine, allowing the client machine to send the file operation request into its own kernel mode. This effectively prevents client machine operations from bypassing system security protection by tampering with the values ​​of specific registers, improving the reliability of system security protection.

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

[0013] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein: Figure 1 A schematic flowchart illustrating a system security protection method provided in an embodiment of this disclosure; Figure 2 This is a flowchart illustrating a system security protection method provided in an embodiment of the present disclosure; Figure 3This is a flowchart illustrating a system security protection method provided in an embodiment of the present disclosure; Figure 4 This is a flowchart illustrating a system security protection method provided in an embodiment of the present disclosure; Figure 5 This is a flowchart illustrating a system security protection method provided in an embodiment of the present disclosure; Figure 6 This is a schematic diagram of the structure of the security protection system of the system security protection method proposed in this disclosure; Figure 7 This is a schematic diagram illustrating the interaction between the user-mode module and the kernel-mode module of the security protection system proposed in this disclosure. Figure 8 This is a flowchart illustrating the system security protection method proposed in this disclosure; Figure 9 This is a schematic diagram of the system security protection device provided in the embodiments of this disclosure; Figure 10 This is a schematic diagram of the system security protection device provided in the embodiments of this disclosure; Figure 11 A schematic block diagram of an example electronic device that can be used to implement embodiments of the present disclosure is shown. Detailed Implementation

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

[0015] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0016] It should be noted that 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, data stored, data displayed, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the laws, regulations and standards of the country and region, and corresponding operation portals are provided for users to choose to authorize or refuse.

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

[0018] Figure 1 This is a flowchart illustrating a system security protection method provided in an embodiment of the present disclosure.

[0019] like Figure 1 As shown, the system security protection method is executed by the virtual machine monitor and may include the following steps: Step 101: Monitor the guest machine based on the configuration rules of the preset virtual machine control structure, and determine the event type and instruction that triggered the event when the guest machine triggers a virtual machine exit event.

[0020] The configuration rules include an exception bitmap and register MSR read / write bitmaps.

[0021] The virtual machine monitor may also be called a "Virtual Machine Monitor" or "VMM", and this disclosure does not limit it to that.

[0022] The virtual machine control structure can also be called "Virtual Machine Control Structure", "VMCS", etc., and this disclosure does not limit it.

[0023] The configuration rules can be used to define the logic for virtual machine state switching, and can be set according to actual needs. These rules may include, but are not limited to, exception bitmaps and register MSR read / write bitmaps; this disclosure does not limit their scope.

[0024] The virtual machine exit event may be referred to as "Virtual Machine Exit Event", "VMEXITEvent", "VMEXIT", etc., and this disclosure does not limit it.

[0025] The event type can be determined based on the actual situation. For example, the event type can be an exception type, or the execution of a sensitive instruction such as a system call entry instruction, or the access to a specific register such as the MSR register, etc. This disclosure does not limit this.

[0026] The instructions can be determined based on the actual situation. For example, the instructions can be system call entry instructions such as INT2EH, SYSENTER, or SYSCALL, etc., and this disclosure does not limit them. Thus, by using virtual machine-related monitoring, the operation monitoring of INT2EH, SYSENTER, and SYSCALL is carried out, ensuring the comprehensiveness of the monitoring, while ensuring that malicious software in the system cannot interfere with the monitoring.

[0027] MSR stands for Model Specific Register, which is a set of special registers customized for a specific processor model. It does not belong to the category of general-purpose registers. The definition and function of MSR may differ for different architectures and models of central processing units. It can be set according to actual needs, and this disclosure does not limit it.

[0028] In some embodiments, the process of generating configuration rules for the virtual machine control structure may include: during the initialization of the virtual machine control structure, setting the values ​​associated with the exception numbers of GP exceptions and UD exceptions in the exception bitmap to a second value, wherein the second value is used to characterize intercepting the corresponding operation and triggering a virtual machine exit event; setting the values ​​associated with the MSR numbers of the storage carriers of kernel-mode code segment selectors in the MSR read bitmap and MSR write bitmap to a second value; and setting the values ​​associated with the MSR numbers of the extended function master switch registers in the high MSR read bitmap and high MSR write bitmap to a second value.

[0029] GP stands for General Protection.

[0030] UD stands for Undefined Opcode.

[0031] The exception number for GP is 0xD, and the exception number for UD is 0x6.

[0032] The specific form of the second value can be preset according to actual needs. For example, the second value can be the number "1", and this disclosure does not limit it.

[0033] The storage carrier for the kernel-mode code segment selector may also be referred to as "IA32_SYSENTER_CS", etc., and this disclosure does not limit it.

[0034] The MSR number of the storage carrier for the kernel-mode code segment selector is 0x174.

[0035] The extended function master switch register may also be called "IA32_EFER", etc., and this disclosure does not limit it.

[0036] The MSR number of the extended function master switch register is 0xC0000080.

[0037] In other words, for example, the values ​​of bits 0xD and 0x6 in the exception bitmap can be set to 1, and the value of bit 0x174 in the MSR read bitmap and MSR write bitmap can be set to 1. Since the read / write trap control bit for MSRs with numbers starting with C is in the high MSR bitmap, and the address of the high MSR bitmap is the MSR bitmap plus 1024, bit 0x80 in the high MSR read bitmap and high MSR write bitmap can be set to 1.

[0038] Therefore, the client is monitored through the configuration rules of the virtual machine control structure. When the client executes the behavior in the configuration rules, a virtual machine exit event will be triggered.

[0039] Step 102: Determine the reason for triggering the virtual machine exit event based on the event type, command, and configuration rules.

[0040] In this disclosure, after determining the event type and instruction, the reason for triggering the virtual machine exit event is determined based on the event type, instruction, and configuration rules. This allows for tracing back to the root cause and performing subsequent system security protection processing based on the root cause, thereby improving the accuracy and reliability of system security protection.

[0041] For example, the reason that triggers a virtual machine exit event could be the execution of a system call entry instruction or access to a specific register, etc., and this disclosure does not limit it.

[0042] Step 103: If the cause is that the client is executing a system call entry instruction, redirect the read / write operation of the instruction on the target register to the preset corresponding shadow register.

[0043] The destination register can be determined according to the actual situation. For example, when the system call entry instruction is INT 2EH, the destination register can be the IDTR register. By reading this register, the interrupt descriptor table in memory can be located. When the system call entry instruction is SYSENTER, the destination register can be the MSR register. By reading this register, the kernel-mode code segment selector can be obtained, and so on. This disclosure does not limit this.

[0044] The shadow register can be a copy of the registers generated by the virtual machine monitor.

[0045] In some embodiments, the data acquisition process in the shadow register proposed in this disclosure may include: acquiring data from at least one register among the Interrupt Descriptor Table Register (IDTR) and the MSR register, and storing it in the corresponding shadow register; setting the size of the Interrupt Descriptor Table (IDT) in the IDTR register to a preset size; and setting the kernel-mode code segment selector and the system call entry instruction enable flag in the MSR register to a first value, wherein the first value is used to characterize at least one of the invalid selector and the disabled corresponding system call entry instruction.

[0046] IDTR is short for Interrupt Descriptor Table Register.

[0047] IDT stands for Interrupt Descriptor Table.

[0048] The preset size can be set according to actual needs. For example, the preset size can be 359. In order to ensure that INT2EH triggers the GP exception, the value of the IDTR size limit field is one less than the total number of bytes in the IDT table. The limit value of 359 means that the total size of the IDT table is 360 bytes, and the IDT is only 360 bytes.

[0049] The system call entry instruction enable flag can also be called "System Call Enable", "SCE", etc., and this disclosure does not limit it.

[0050] The specific implementation of the first value can be set according to actual needs. For example, the first value can be the number "0", and this disclosure does not limit it.

[0051] In some embodiments, the contents of the IDTR can be obtained using the SIDT instruction and stored in the shadow IDTR. The size limit of the IDT table in the IDTR can be changed to 359 using the LIDT instruction. This disclosure does not limit this.

[0052] In other words, by setting the kernel-mode code segment selector in the MSR register and the system call entry instruction enable flag to the first value, a GP exception will be triggered when the central processing unit accesses the selector because the selector is invalid, or a UD exception will be triggered when the guest executes the system call entry instruction SYSENTER or SYSCALL, thereby triggering a virtual machine exit event. This can effectively prevent bypassing or deception in system security protection.

[0053] In some embodiments, when redirecting read / write operations on a target register to a preset corresponding shadow register, the operation redirection can be performed by calling the processing function corresponding to the system call entry instruction.

[0054] The specific structure of the processing function can be preset according to actual needs, and this disclosure does not limit it.

[0055] In some embodiments, processing functions corresponding to GP exceptions, UD exceptions, MSR read events, and MSR write events can be pre-set, thereby enabling fine-grained processing of different reasons that trigger virtual machine exit events and improving efficiency.

[0056] In some embodiments, a function simulating the INT instruction function can be pre-configured. Thus, when the GP exception handling function is called, if the system call entry instruction is INT 2EH and the interrupt service number is not a system call service number, the function simulating the INT instruction function can be called to simulate normal INT instruction execution, allowing the client machine to continue execution.

[0057] In some embodiments, LIDT and SIDT instruction monitoring functions can be pre-configured to monitor LIDT and SIDT instructions and improve the comprehensiveness of system security protection. Specific monitoring functions can be set according to actual needs, and this disclosure does not limit them.

[0058] LIDT stands for Load Interrupt Descriptor Table Register.

[0059] SIDT stands for Store Interrupt Descriptor Table Register.

[0060] In some embodiments, functions simulating the SYSENTER and SYSRET commands can be pre-configured. The specific function structure can be set according to actual needs, and this disclosure does not limit it.

[0061] For example, when the VMM monitors and intercepts the SYSENTER command, it is necessary to simulate the normal behavior of the SYSENTER command. The specific simulation steps are as follows, where the following content is only an example and is not limited here: Save and clear relevant flags: Clear the virtual 8086 mode flag by setting the virtual 8086 mode bit (bit 17) in the guest register flags (RFLAGS) to 0, ensuring that the CPU is in protected mode or long mode; clear the interrupt enable flag by setting bit 9 of the guest RFLAGS register to 0, ensuring that the system call processing is not interfered with by interrupts; Set up a new stack and instruction pointer, determine the CPU operating mode, and determine whether the guest is in extended operating mode; Set the code segment descriptor: Set the segment selector, obtain the original IA32_SYSENTER_CS value from the shadow MSR, and ensure that the selector points to the correct descriptor table entry; Set the segment base address, set the code segment base address to 0, and make the linear address equal to the offset address to simplify address calculation; Set the segment limit, set the code segment limit to 0xFFFFF (1MB-1). Set the segment access permission attribute; Set stack segment descriptor: Set stack segment selector, setting it to the code segment selector plus 8; Set stack segment base address, setting it to 0; Set stack segment limit; Configure the client state to make it appear as if SYSENTER has been executed normally; Return to the client and jump to the actual system call handler.

[0062] In some embodiments, functions that simulate the SYSCALL, SYSRET, and SYSRETQ instructions can be pre-configured. The specific functions can be set according to actual needs, and this disclosure does not limit them.

[0063] Step 104: If the read / write operation is to read the kernel entry address of the system call, determine the client's file operation request based on the system call number and parameters associated with the system call entry instruction.

[0064] The file operation request can be initiated by an application process in the client machine. It can be a read operation request or a write operation request, etc. The specific settings can be configured according to actual needs, and this disclosure does not limit it.

[0065] The system call number and parameters serve as the medium for interaction between the client's user-mode program and kernel-mode. The system call number informs the kernel of the function to be executed, and the parameters pass the input or output data required for that function. The specifics can be determined based on the actual situation, and this disclosure does not impose any limitations on them.

[0066] In this disclosure, when the read / write operation is to read the kernel entry address of the system call, it can be determined that the current client's behavior is to operate on the kernel-mode file. At this time, the client's file operation request can be determined based on the system call number and parameters associated with the system call entry instruction.

[0067] Step 105: Redirect the file path of the file operation request to the file filtering module in the guest kernel mode, and return control of the central processing unit to the guest, so that the guest sends the file operation request into its own kernel mode.

[0068] The file filtering module can be installed in kernel mode as a driver. When loaded, it is responsible for mounting all file systems and volume devices to be monitored. The specific content to be mounted can be configured according to actual needs, and this disclosure does not limit it.

[0069] The central processing unit can also be called "Central Processing Unit" or "CPU", but this disclosure does not limit it.

[0070] In this disclosure, since the current file operation request involves operations on a file in kernel mode, to ensure system security, the file path of the file operation request can be redirected to the file filtering module in the guest kernel mode before the file operation is performed. The file filtering module processes the request, thereby improving data security. Then, the virtual machine monitor returns control of the central processing unit to the guest machine, allowing the guest machine to send the file operation request into its own kernel mode.

[0071] In this embodiment, the guest machine is first monitored based on the configuration rules of a preset virtual machine control structure. When a guest machine triggers a virtual machine exit event, the event type and instruction that triggered the event are determined. Based on the event type, instruction, and configuration rules, the reason for triggering the virtual machine exit event is determined. If the reason is that the guest machine executes a system call entry instruction, the read / write operation of the instruction targeting the target register is redirected to a preset corresponding shadow register. If the read / write operation is reading the kernel entry address of the system call, the guest machine's file operation request is determined based on the system call number and parameters associated with the system call entry instruction. Finally, the file path of the file operation request is redirected to the file filtering module in the guest machine's kernel state, and control of the central processing unit is returned to the guest machine, allowing the guest machine to send the file operation request into its own kernel state. Thus, by using the configuration rules of the preset virtual machine control structure and the virtual machine monitor to monitor the guest machine's behavior, a virtual machine exit event is triggered when the guest machine executes a system call entry instruction. The read / write operation of a specific register is redirected to the shadow register, effectively preventing the guest machine from bypassing system security protection by tampering with the value of a specific register, thereby improving the reliability of system security protection.

[0072] Figure 2 This is a schematic flowchart illustrating a system security protection method provided in an embodiment of the present disclosure.

[0073] like Figure 2 As shown, the system security protection method, implemented by the virtual machine monitor, may include the following steps: Step 201: Monitor the guest machine based on the configuration rules of the preset virtual machine control structure, and when the guest machine triggers a virtual machine exit event, call the dispatch function of the virtual machine exit event to determine the event type that triggered the event.

[0074] The dispatch function can route requests or events to corresponding specific processing functions based on preset conditions. It can also be called a "Dispatch Function", "Routing Function", "Scheduling Function", "Route Function", etc., and this disclosure does not limit it to these terms.

[0075] In some embodiments, to enhance the finer-grained processing of operations that trigger virtual machine exit events, dispatch functions for exceptions, LIDT instructions, SIDT instructions, MSR read events, and MSR write events can be added to the dispatch function for virtual machine exit events, and dispatch functions for GP exceptions and UD exceptions can be added to the dispatch function for exceptions.

[0076] In this disclosure, when a virtual machine exit event is detected by a guest machine, the dispatch function for the virtual machine exit event is called to read the special fields in the virtual machine control structure and determine the event type that triggered the event.

[0077] The dedicated fields may include main judgment fields and auxiliary subdivision fields. The main judgment fields can be used to determine the general category of the event, such as exception triggering, while the auxiliary subdivision fields can be used to determine the specific event type, such as GP exception. This disclosure does not limit the specific details of the event.

[0078] By identifying the type of event that triggers the event and processing it in a refined manner, we can avoid confusion in subsequent processing logic and improve efficiency and reliability.

[0079] Step 202: If the event type is an instruction execution related event type, read the instruction pointer value corresponding to the guest machine when the virtual machine exit event is triggered, and determine the instruction that triggered the event.

[0080] The types of instruction execution-related events can be determined based on the actual situation. For example, the virtual machine exit event may be triggered by the execution of sensitive instructions such as system call entry instructions, or by the execution of LIDT or SIDT instructions, etc. This disclosure does not limit this.

[0081] When a guest machine triggers a virtual machine exit event, the CPU automatically saves the guest machine's current instruction pointer register value to the VMCS. At this time, the instruction that triggered the event can be determined by reading the instruction pointer value. The instruction pointer register can also be called "RIP", "R Extended Instruction Pointer", etc., and can be set according to actual needs. This disclosure does not limit it.

[0082] Step 203: Call the event dispatch function to obtain the client's context information.

[0083] The context information includes at least one of the following: registers, memory, and privilege level.

[0084] The registers included in the context information may include the instruction pointer register and general-purpose registers such as RAX and EAX, etc. The specific settings can be made according to actual needs, and this disclosure does not limit them.

[0085] In this disclosure, after determining the event type that triggers the virtual machine exit event, the specific reason for the exit event is further determined by calling the dispatch function of that event type. At this point, the context information of the guest machine can be obtained first to provide a data basis for determining the specific reason.

[0086] Step 204: Based on the context information and configuration rules, determine the reason for triggering the virtual machine exit event.

[0087] In this disclosure, the reason for triggering the virtual machine exit event is determined based on context information and configuration rules, thereby enabling efficient, accurate, and logically clear system security protection.

[0088] Step 205: If the cause is that the client is executing a system call entry instruction, redirect the read / write operation of the instruction on the target register to the preset corresponding shadow register.

[0089] Step 206: If the read / write operation is to read the kernel entry address of the system call, determine the client's file operation request based on the system call number and parameters associated with the system call entry instruction.

[0090] Step 207: Redirect the file path of the file operation request to the file filtering module in the guest kernel mode, and return control of the central processing unit to the guest, so that the guest sends the file operation request into its own kernel mode.

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

[0092] In this embodiment, the client machine is first monitored based on the configuration rules of the preset virtual machine control structure. When the client machine triggers a virtual machine exit event, the dispatch function for the virtual machine exit event is called to determine the event type that triggered the event. Then, if the event type is an instruction execution related event type, the instruction pointer value corresponding to the client machine when the virtual machine exit event is triggered is read to determine the instruction that triggered the event. The dispatch function for the event type is then called to obtain the client machine's context information. Based on the context information and configuration rules, the reason for triggering the virtual machine exit event is determined. If the reason is that the client machine executes a system call entry instruction, the read / write operation of the instruction targeting the target register is redirected to the preset corresponding shadow register. Finally, if the read / write operation is reading the kernel entry address of the system call, the client machine's file operation request is determined based on the system call number and parameters associated with the system call entry instruction. The file path of the file operation request is redirected to the file filtering module in the client machine's kernel mode, and the control of the central processing unit is returned to the client machine so that the client machine sends the file operation request into its own kernel mode. Therefore, when a virtual machine exit event is detected by a guest machine, the type of the event is determined by calling the event dispatch function, and the specific reason for the exit event is determined based on the dispatch function associated with the event type. This allows for efficient and accurate subsequent system security protection processes, improving the efficiency and reliability of system security protection methods.

[0093] Figure 3 This is a schematic flowchart illustrating a system security protection method provided in an embodiment of the present disclosure.

[0094] like Figure 3 As shown, the system's security protection method is executed in the client kernel mode and may include the following steps: Step 301: Receive the file operation request sent by the current client, generate the corresponding Input / Output Request Packet (IRP) based on the file operation request, and send the IRP request packet to the file filtering module so that the file filtering module can determine the operation type of the IRP request packet and the target file of the operation.

[0095] IRP stands for Input / Output Request Packet.

[0096] It should be noted that the file operation requests sent by the client received in kernel mode are operation requests monitored by the virtual machine monitor. The specific implementation can be found in the relevant descriptions in the above embodiments of this disclosure, and will not be repeated here.

[0097] In this disclosure, after receiving a file operation request from a client, the kernel can analyze the I / O operation type (read, write, create, etc.), target device, and other information of the request through system services, and send a request to the I / O manager. After receiving the request, the I / O manager is responsible for allocating memory for the IRP structure, initializing the core fields of the IRP (such as operation type, parameters, target device pointer, etc.), and generating the corresponding IRP request packet.

[0098] Wherein, I / O is short for Input / Output.

[0099] The specific implementation of the file filtering module can be found in the relevant descriptions of the above embodiments in this disclosure, and will not be repeated here.

[0100] The operation type can be reading a file or writing a file, etc., and the specific type can be determined according to the actual situation. This disclosure does not limit this type of operation.

[0101] The target file can be the file that the file operation request requires.

[0102] In some embodiments, after receiving an IRP request packet, the file filtering module can also parse the IRP request packet to determine the process initiating the file operation and the target file to be operated on. Then, through preset process suffix access control rules, it can determine whether the process can operate on the target file, that is, whether the process can access the file with that suffix or the file in that file path, to determine whether the file operation is compliant, thereby effectively avoiding malicious operations and improving system security.

[0103] Step 302: Determine whether the target file is encrypted and obtain the result.

[0104] In this disclosure, to ensure system data security, the file filtering module can first determine whether the target file is encrypted after receiving the IRP request packet, and obtain a determination result.

[0105] It should be noted that the specific implementation method for determining whether a file is encrypted can be set according to actual needs, and this disclosure does not limit it.

[0106] For example, in some embodiments, when determining whether a target file is encrypted, it can first be determined whether the target file has an encryption identifier. If an encryption identifier exists, the target file is determined to be encrypted. Alternatively, if no encryption identifier exists, the target file is matched against a preset encryption policy. If the target file matches the encryption policy, an encryption function is called to encrypt the target file, thus determining that the target file is encrypted.

[0107] The encryption identifier can be used to indicate whether a file is encrypted. Its specific form can be set according to actual needs, and this disclosure does not limit it.

[0108] For example, in some embodiments, the encryption identifier can be in a preset file encryption information structure, and this disclosure does not limit this.

[0109] In other words, if the file filtering module calls a function to check whether a file is encrypted, and successfully obtains the file encryption information structure associated with the target file and the value of the encryption flag field in the structure is a preset value (such as 0x00000001), it can be determined that the file is encrypted. If the file encryption information structure is not obtained, or if the encryption flag field in the obtained file encryption information structure is a value indicating that it is not encrypted (such as 0), it can be determined that the file is not encrypted.

[0110] The encryption strategy, in particular, is used to determine whether a target file needs to be encrypted, and it can be set according to actual needs. For example, the encryption strategy can specify the file extension and / or file path of the files to be encrypted, etc., which are not limited in this disclosure.

[0111] It should be noted that the encryption policy file can be stored in the system root directory, and the specific settings can be configured according to actual needs. This disclosure does not impose any restrictions on this.

[0112] In other words, when matching a target file with an encryption policy, it can be determined whether the encryption policy contains the target file's suffix or file path. If it does, the target file is determined to match the encryption policy.

[0113] The specific structure of the encryption function can be set according to actual needs, and this disclosure does not limit it.

[0114] In some embodiments, the file encryption information structure can be created by calling the file encryption setting function, and its attributes can be set to system and hidden. If encryption is not required, the existing file encryption information structure can be deleted. This disclosure does not limit this.

[0115] In some embodiments, even if no encryption identifier exists and the target file does not match the encryption policy, it can still be determined that the target file is not encrypted. This disclosure does not limit this.

[0116] Step 303: Based on the operation type and the determined result, process the IRP request packet to complete the operation on the target file.

[0117] In this disclosure, IRP request packets are processed based on the operation type and the determined result to complete the operation on the target file, thereby enabling file operations safely and reliably and improving data security.

[0118] In some embodiments, after completing the operation on the target file, the operation result can also be returned to the application process that initiated the current file operation request.

[0119] In this embodiment, a file operation request sent by the current client is first received. A corresponding Input / Output Request (IRP) packet is generated based on the file operation request and sent to the file filtering module. The file filtering module determines the operation type and target file of the IRP request packet, then determines whether the target file is encrypted, and obtains a determination result. Finally, based on the operation type and the determination result, the IRP request packet is processed to complete the operation on the target file. Therefore, by using the file filtering module to process IRP requests for file operation requests monitored by the virtual machine monitor, it effectively prevents file operation requests from bypassing or deceiving system security monitoring, further enhancing the reliability of system security protection.

[0120] Figure 4 This is a schematic flowchart illustrating a system security protection method provided in an embodiment of the present disclosure.

[0121] like Figure 4 As shown, the system's security protection method is executed in the client kernel mode and may include the following steps: Step 401: Upon receiving a file operation request from the current client, generate a corresponding Input / Output Request Packet (IRP) based on the file operation request, and send the IRP request packet to the file filtering module to determine the operation type and target file of the IRP request packet.

[0122] Step 402: Determine whether the target file is encrypted and obtain the result.

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

[0124] Step 403: If the operation type is a read operation and the result is determined to be target file encryption, the IRP request packet is sent to the file system driver. The driver is used to call the dispatch function corresponding to the IRP read request, read the encrypted data of the target file from the ciphertext cache of the double-buffered structure associated with the target file, decrypt it, and write it into the buffer associated with the IRP request packet.

[0125] The file system driver can also be called "File System Driver", "FSD", etc., and this disclosure does not limit it.

[0126] The specific structure of the dispatch function corresponding to the IRP read request can be preset according to actual needs, and this disclosure does not limit it.

[0127] It should be noted that different IRP request operation types correspond to different dispatch functions.

[0128] The dual-buffer structure can include a plaintext cache and a ciphertext cache. Each file with encryption / decryption identifier corresponds to a dual-buffer structure, one plaintext cache and one ciphertext cache. It can return response data or other information based on a request, and can choose whether to retrieve data directly from the cache or read it from the disk. This disclosure does not limit this.

[0129] Therefore, for a file, two caches, plaintext cache and ciphertext cache, can be provided in the dual-caching structure. When the first file open request is intercepted, a cache structure is allocated for the file, and the pointer of the structure is stored in the hash structure corresponding to the opened file. Then, this structure is maintained and used to interact with the disk. In the dispatch function corresponding to the IRP read request, all IRP read requests are read from the dual cache, thereby realizing dual caching.

[0130] In this disclosure, when the operation type is a read operation and the result is determined to be target file encryption, it can be determined that the current IRP request is a request to read confidential files. In order to ensure data security, the IRP request packet can be sent to the file system driver, and the dispatch function corresponding to the IRP read request can be called by the driver to read the encrypted data of the target file from the ciphertext cache of the double-buffered structure associated with the target file and decrypt it. The decrypted data is then written to the buffer associated with the IRP request packet.

[0131] Step 404: If reading data from the ciphertext cache fails, the data of the target file is read from the disk using a double-buffered structure, stored in the ciphertext cache of the double-buffered structure, and then decrypted and stored in the plaintext cache of the double-buffered structure.

[0132] In this disclosure, in the event of failure to read data from the encrypted cache, data of the target file is read from the disk using a dual-cache structure, thereby reducing disk I / O operations, extending disk lifespan, and ensuring data security.

[0133] In this disclosure, after reading data from a target file from the disk using a double-buffered structure, the data is stored in the ciphertext cache of the double-buffered structure, so that subsequent data for the target file can be read directly from the double-buffered structure, thereby improving efficiency.

[0134] In some embodiments, when reading data from a target file from a disk using a dual-caching structure, IRP requests can be grouped and aligned, that is, the starting offset and length of the read request are rounded up / down according to the block size required by the underlying storage medium and encryption algorithm to re-acquire the data.

[0135] Step 405: Return to the step of calling the dispatch function to read data, and write the read data into the buffer associated with the IRP request packet.

[0136] In this disclosure, after reading the target file data from the disk using a dual-buffer structure, the dispatch function is called again to read the corresponding data from the plaintext cache, and the read data is written to the buffer associated with the IRP request packet. This improves the efficiency and reliability of system security protection while ensuring data security.

[0137] In some embodiments, if reading data from the target file from the disk using a dual-caching structure fails and historical data of the target file exists in the plaintext cache, the historical data can be written to the buffer of the IRP request packet. This ensures that even if the update fails, the application can still obtain potentially outdated but usable data, thus preventing process crashes.

[0138] The reasons for data read failure can be determined based on the actual situation. For example, it could be a disk error, media removal, invalid decryption key, etc., and this disclosure does not limit the reasons.

[0139] In some embodiments, when the buffer data of the IRP request packet reaches the pre-read condition, an asynchronous IRP read request is initiated using the file filtering module. Starting from the end position of the data reading of the IRP request packet, the encrypted data of the subsequent preset number of data blocks in the target file is read and stored in the double buffer structure.

[0140] The read-ahead condition can be set according to actual needs. For example, the read-ahead condition can be that the system predicts that after the current read request, there is a high probability that it will continue to read subsequent data sequentially. The read-ahead condition is usually based on access pattern heuristics, that is, the data read by the current read request and the previous request in the file are continuous, etc. This disclosure does not limit this.

[0141] The preset quantity can be set according to actual needs, and this disclosure does not limit it.

[0142] Therefore, by using a high-performance dual-caching mechanism with transparent encryption and decryption, data is intelligently pre-read and decrypted, and the encrypted and decrypted files are stored in two caches in memory. This not only avoids the problem of uncontrollable system caching, but also allows the system to create pre-read data into the cache, reducing the return time of requests and effectively improving the overall system efficiency.

[0143] In some embodiments, after the read data is written to the buffer associated with the IRP request packet, a read completion routine can be triggered by the file system driver. The read completion routine decrypts the confidential data and then hands control over to the manager. The manager completes the data copying of the user address control and hands control over to the caller, thus completing the operation.

[0144] In some embodiments, when the operation type is a read operation and the result is that the target file is not encrypted, the dispatch function corresponding to the IRP read request can be called by the file system driver to read the data of the target file from the plaintext cache of the double-buffered structure associated with the target file and write it into the buffer associated with the IRP request packet.

[0145] In this embodiment, a file operation request sent by the current client is first received. Based on the file operation request, a corresponding Input / Output Request Packet (IRP) is generated and sent to a file filtering module. The file filtering module determines the operation type and target file of the IRP request packet, and then determines whether the target file is encrypted. If the operation type is a read operation and the result indicates that the target file is encrypted, the IRP request packet is sent to the file system driver. The driver calls the dispatch function corresponding to the IRP read request to read the data of the target file from the ciphertext cache of the double-buffered structure associated with the target file, decrypts it, and writes it to the buffer associated with the IRP request packet. Alternatively, if reading data from the ciphertext cache fails, the target file data is read from the disk using the double-buffered structure, stored in the ciphertext cache of the double-buffered structure, decrypted, and stored in the plaintext cache. The process then returns to execute the step of calling the dispatch function to read data, and the read data is written to the buffer associated with the IRP request packet. Therefore, after determining the operation type and target file of the file operation request, data is read from the double-buffered structure corresponding to the target file by calling the dispatch function of the corresponding IRP read request. This effectively avoids I / O interaction with the disk and improves read efficiency. Furthermore, the interaction with the disk through the double-buffered structure enhances data security.

[0146] Figure 5 This is a schematic flowchart illustrating a system security protection method provided in an embodiment of the present disclosure.

[0147] like Figure 5 As shown, the system's security protection method is executed in the client kernel mode and may include the following steps: Step 501: Upon receiving a file operation request from the current client, generate a corresponding Input / Output Request Packet (IRP) based on the file operation request, and send the IRP request packet to the file filtering module to determine the operation type and target file of the IRP request packet.

[0148] Step 502: Determine whether the target file is encrypted and obtain the result.

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

[0150] Step 503: When the operation type is a write operation and the target file is encrypted, the file filtering module is used to encrypt the data to be written in the buffer associated with the IRP request packet to obtain the IRP request packet after data encryption.

[0151] In some embodiments, when encrypting the data to be written in the buffer associated with the IRP request packet, the data can be read first, then the encryption function can be called to encrypt the data, and then the encrypted data can be used to update and replace the original data in the buffer, thereby realizing the encryption of the data to be written in the buffer. This disclosure does not limit this.

[0152] Step 504: Send the encrypted IRP request packet to the file system driver so that the file system driver can send the IRP request packet to the underlying driver for data writing.

[0153] The underlying driver can be the device where the target file of the IRP request packet is located.

[0154] In this disclosure, after receiving an IRP request packet, the file system driver can analyze the IRP request packet, determine the target underlying driver device to which it should be sent, and then send it to the corresponding driver for data writing.

[0155] Step 505: After the data writing is completed, the underlying driver writes the writing result into the IRP request and returns it to the file system driver, so that the file system driver returns the writing result to the process corresponding to the file operation request through the input / output manager.

[0156] The write result can be determined based on the actual situation. For example, it can be either a successful write or a failed write; this disclosure does not limit this.

[0157] The specific implementation of the written result can be set according to actual needs. For example, it can be written into the IRP request packet in the form of a status value, and this disclosure does not limit this.

[0158] Here, "process" can refer to an application process.

[0159] For example, in some embodiments, after the write result is written to the IRP request and returned to the file system driver, the file system driver can trigger a write completion routine to post-process the IRP request and hand control over to the manager. The manager then passes the status value to the user process and returns control to the caller, and the encryption operation is complete.

[0160] The post-processing of IRP requests can be configured according to actual needs. For example, post-processing may include, but is not limited to, updating the IRP status from "processing" to "processing result", clearing temporary resources, and supplementing result information, etc. This disclosure does not limit this.

[0161] In this embodiment, a file operation request from the current client is first received. A corresponding Input / Output Request (IRP) packet is generated based on the file operation request and sent to a file filtering module. The file filtering module determines the operation type and target file of the IRP request packet, then determines whether the target file is encrypted. If the operation type is a write operation and the target file is encrypted, the file filtering module encrypts the data to be written in the buffer associated with the IRP request packet, obtaining an encrypted IRP request packet. This encrypted IRP request packet is then sent to the file system driver, which forwards it to the underlying driver for data writing. Finally, after the data writing is complete, the underlying driver writes the writing result into the IRP request and returns it to the file system driver, allowing the file system driver to return the writing result to the process corresponding to the file operation request via the input / output manager. Therefore, when the file operation request is for writing a confidential file, the file filtering module encrypts the data to be written and sends it to the file system driver to complete the data writing, thereby improving the reliability of system security while ensuring data security.

[0162] The following is combined with Figure 6 The structure of the security protection system corresponding to the system security protection method proposed in this disclosure is illustrated with an example. Figure 6 This is a schematic diagram of the security protection system of the system security protection method proposed in this disclosure. As shown in Figure 6, it is merely an example and is not intended to be limiting.

[0163] like Figure 6 As shown, the security protection system 600 may include: a virtual machine monitor 601, a user mode module 602, and a kernel mode module 603.

[0164] The user mode module 602 includes, but is not limited to, the encryption / decryption folder creation module 6021, the process suffix access control module 6022, the auxiliary thread module 6023, and the user notification module 6024.

[0165] Among them, the kernel mode module 603 includes, but is not limited to, the process suffix access control maintenance module 6031, the file filtering module 6032, the encryption / decryption module 6033, the dual cache maintenance module 6034, and the prefetch disk module 6035.

[0166] Among them, module 6021, which creates encrypted / decrypted folders, is responsible for creating folders with encryption / decryption identifiers. Process suffix access control module 6022: This module is used to manage the access relationship between processes and their corresponding file types. A process can open multiple types of files, and a file can also be opened by multiple different applications. Auxiliary Thread Module 6023: This module receives information from the driver layer and hands it over to the application layer client for processing. If a prompt dialog box is needed to remind the user, it will pop up so that the user can perform the corresponding operation. Process suffix access control maintenance module 6031: This module maintains process suffix access control rules, which are provided for the file filtering startup module to query. It also receives messages from the user layer such as adding, updating, and deleting rules. File filtering module 6032: When the driver is loaded, this module is responsible for mounting all file systems to be monitored and all volume devices. After successful mounting, it receives the IRP passed from the object manager and then calls the corresponding IRP dispatch function to process it according to the different types of IRP. Encryption / decryption module 6033: This module performs corresponding encryption and decryption processing on the transmitted data; Dual-Cache Maintenance Module 6034: This module maintains a dual-cache structure for each file with encryption / decryption identifiers, consisting of a plaintext cache and a ciphertext cache. It receives read IRP requests and returns response data or other information based on the requests. The module will choose whether to retrieve data directly from the cache or read it from the disk itself, depending on the situation.

[0167] Disk prefetching module 6035: This module is initiated by a thread from the dual cache module. It is used to read the requested data from the disk in advance, perform corresponding encryption and decryption operations according to the encryption and decryption module, and then return the data to the dual cache module for storage in the dual cache. The module needs to establish an IRP to request the disk according to the request.

[0168] It should be noted that the user-mode module 602 can run in user mode as an application, while the kernel-mode module 603 can run in kernel mode as a driver.

[0169] like Figure 6 The system shown illustrates the relationship between the virtual machine monitor (VM) and other modules as follows: The VM intercepts underlying system calls, effectively preventing bypass of security checks; it serves as the basic monitoring layer. The file filtering module intercepts and forwards file operation IRPs, and the VM monitor ensures this is not bypassed. The encryption / decryption module performs real-time file encryption and decryption, relying on the VM monitor to ensure all read and write operations are intercepted. The dual-buffer maintenance module caches plaintext and ciphertext to improve performance; it operates securely under VM monitor monitoring. The process suffix access control module performs policy matching and access control, with the VM monitor providing the necessary data. The user-mode module pre-configures policies and facilitates user interaction; the VM monitor ensures policies take effect.

[0170] It should be noted that the interaction between the modules in user mode module 602 and kernel mode module 603 can be as follows: Figure 7 As shown, Figure 7 This is a schematic diagram illustrating the interaction between the user-mode module and the kernel-mode module of the security protection system proposed in this disclosure.

[0171] like Figure 7 As shown, in some embodiments, after obtaining a new access rule (which may be sent by the process suffix access control module 704), the auxiliary thread module 703 sends it to the process suffix access control maintenance module 705 in the kernel mode module so that the module 705 can update it and return the processing result of the new access rule to the control module 704, which then returns the processing result to the user notification module 702.

[0172] In some embodiments, the auxiliary thread module 703 may also return messages received from the driver layer to the user notification module 702.

[0173] In some embodiments, the encryption / decryption folder creation module 701 can create a folder with an encryption identifier for files that need to be encrypted, recording which files in the volume are encrypted. This folder can be created during operating system startup and the loading of the file filtering driver module, before all file encryption / decryption operations begin, creating it in the earliest stage of system startup. It can filter encryption / decryption behavior; before a file is accessed, the file filtering module calls module 701 to check if the file is encrypted. If it is not encrypted but meets the policy, the encryption process is triggered. Module 701 can notify the user that module 703 has returned the processing result, i.e., the encryption result.

[0174] In some embodiments, the file filtering module 706 may send a query request to the process suffix access control maintenance module 705 to query file access control rules. Then, module 705 returns the query results to module 706 so that the file filtering module 706 can check the current file operation request and determine whether it is a compliant access.

[0175] In some embodiments, the file filtering module 706 may send other capture information to the auxiliary thread module 703. The other capture information can be set according to actual needs, and this disclosure does not limit it.

[0176] In some embodiments, when the file operation is a write operation, the file filtering module 706 can send a write encryption request to the encryption / decryption module 707, which will encrypt the data and then return the encrypted data to the file filtering module 706.

[0177] In some embodiments, when the file operation is a read operation, the file filtering module 706 can send a read request to the double buffer maintenance module 708 to read data, and the double buffer maintenance module 708 returns the read result to the file filtering module 706.

[0178] In some embodiments, after reading encrypted data from the disk, the dual-buffer maintenance module 708 can send a decryption request to the encryption / decryption module 707 to decrypt the read encrypted data, and then the encryption / decryption module 707 returns the decrypted data to the dual-buffer maintenance module 708.

[0179] In some embodiments, if the current IRP request buffer meets the pre-read condition, the dual cache maintenance module 708 can create a pre-read thread in the pre-read disk module to pre-read the data on the disk.

[0180] In some embodiments, the pre-read disk module 709 may send a decryption request to the encryption / decryption module 707, and the encryption / decryption module 707 may return the decrypted data.

[0181] It should be noted that when applying the system security protection method proposed in this disclosure, the specific usage process of each module can be set according to actual needs, and may include, but is not limited to, the interaction between some modules or the interaction between all modules. This disclosure does not limit this.

[0182] Furthermore, in some embodiments, the file filtering module 706 can send other disk requests to the file system driver in kernel mode, and then the file system driver returns the request result. Other disk requests can be set according to actual needs, and this disclosure does not limit them.

[0183] Furthermore, in some embodiments, the dual cache maintenance module 708 can directly send a disk read request to the file system driver, and then the file system driver returns the read data.

[0184] The following is combined with Figure 8 The process of implementing the system security protection method proposed in this disclosure based on the above system is illustrated with an example. Figure 8 This is a flowchart illustrating the system security protection method proposed in this disclosure. Among them, Figure 8 The process shown is for illustrative purposes only; the specific process can be determined according to actual needs, and no restrictions are imposed here.

[0185] like Figure 8As shown, the preprocessing steps of this system's security method are as follows: First, an encryption / decryption folder is created in the user-mode module, and an encryption policy is set to obtain the encryption policy file. Then, file access control rules are set in the process suffix range control module. When a process initiates a file operation, the client executes a system call entry instruction, triggering a virtual machine exit event. The virtual machine monitoring layer, i.e., the monitor, intercepts and monitors this operation. Then, the path of the operation is redirected to the file filtering module, which determines whether the file is encrypted and whether the access request is compliant. If compliant and the file is encrypted, the corresponding data is retrieved from the ciphertext cache of the double-cache maintenance module associated with the file, and decrypted using the encryption / decryption module, returning the plaintext to the process. Alternatively, if the file is not encrypted, but matches the encryption policy file, the encryption / decryption module encrypts the file and reads the corresponding data from the plaintext cache of the double-cache structure associated with the file, returning it to the process.

[0186] It should be noted that, Figure 8 The specific implementation methods of each process shown can be referred to the relevant descriptions in the above embodiments of this disclosure, and will not be repeated here.

[0187] Therefore, by taking process behavior as the starting point, and based on the fact that all process operations on the file system must go through the system file driver, a file filtering module is used to obtain the process's modifications to the file system, and a multi-level process behavior detection and information integrity security protection method is implemented. This achieves fine-grained filtering of process operations on the file system and ensures the integrity of the file system.

[0188] To achieve the above embodiments, this disclosure also proposes a system security protection device.

[0189] Figure 9 This is a schematic diagram of the system security protection device provided in the embodiments of this disclosure.

[0190] like Figure 9 As shown, the system security protection device 900, configured in the virtual machine monitor, includes: The first processing module 901 is used to monitor the guest machine based on the configuration rules of the preset virtual machine control structure, and when the guest machine triggers a virtual machine exit event, it determines the event type and instruction that triggered the event. The configuration rules include an exception bitmap and a register MSR read / write bitmap. The first determining module 902 is used to determine the reason for triggering the virtual machine exit event based on the event type, command, and configuration rules; The second processing module 903 is used to redirect the read / write operation of the target register to a preset corresponding shadow register when the cause is that the client executes a system call entry instruction. The second determining module 904 is used to determine the client's file operation request based on the system call number and parameters associated with the system call entry instruction when the read / write operation is to read the kernel entry address of the system call. The third processing module 905 is used to redirect the file path of the file operation request to the file filtering module in the guest kernel mode, and return the control of the central processing unit to the guest, so that the guest can send the file operation request into its own kernel mode.

[0191] In one possible implementation of this disclosure, the first processing module 901 is specifically used for: If a guest triggers a virtual machine exit event, the event dispatch function is called to determine the event type that triggered the event. When the event type is an instruction execution related event type, read the instruction pointer value corresponding to the guest machine when the virtual machine exit event is triggered, and determine the instruction that triggered the event.

[0192] In one possible implementation of this disclosure, the first determining module 902 is specifically used for: Call the event type dispatch function to obtain the client's context information, which includes at least one of the following: registers, memory, and privilege level. Based on context information and configuration rules, determine the reason for triggering the virtual machine exit event.

[0193] In one possible implementation of this disclosure, the device 900 further includes: Add a module (not shown in the figure) to add dispatch functions for exceptions, interrupt descriptor table loading instructions (LIDT), interrupt descriptor table reading instructions (SIDT), MSR read events, and MSR write events to the dispatch function of virtual machine exit events; The aforementioned additional module (not shown in the figure) is also used to add dispatch functions for the General Protection Exception (GP) and the Undefined Opcode Exception (UD) in the exception dispatch function.

[0194] In one possible implementation of this disclosure, the device 900 further includes: The acquisition module (not shown in the figure) is used to acquire data from at least one of the interrupt descriptor table registers IDTR and MSR registers and store it in the corresponding shadow register. The configuration module (not shown in the figure) is used to set the size of the Interrupt Descriptor Table (IDT) in the IDTR register to a preset size; The aforementioned setting module (not shown in the figure) is used to set the kernel-mode code segment selector and the system call entry instruction enable flag in the MSR register to a first value, wherein the first value is used to represent at least one of the invalid selector and the corresponding system call entry instruction being disabled.

[0195] In one possible implementation of this disclosure, the first processing module 901 is further configured to: During the initialization of the virtual machine control structure, the values ​​associated with the exception numbers of GP exceptions and UD exceptions in the exception bitmap are set to the second value. The second value is used to indicate that the corresponding operation is intercepted and the virtual machine exit event is triggered. Set the value associated with the MSR number of the storage carrier of the kernel-mode code segment selector in the MSR read bitmap and MSR write bitmap to the second value; Set the value associated with the MSR number of the extended function master switch register in the high MSR read bitmap and high MSR write bitmap to the second value.

[0196] The functions and specific implementation principles of the modules described in this embodiment can be found in the above method embodiments, and will not be repeated here.

[0197] In this embodiment, the guest machine is first monitored based on the configuration rules of a preset virtual machine control structure. When a guest machine triggers a virtual machine exit event, the event type and instruction that triggered the event are determined. Based on the event type, instruction, and configuration rules, the reason for triggering the virtual machine exit event is determined. If the reason is that the guest machine executes a system call entry instruction, the read / write operation of the instruction targeting the target register is redirected to a preset corresponding shadow register. If the read / write operation is reading the kernel entry address of the system call, the guest machine's file operation request is determined based on the system call number and parameters associated with the system call entry instruction. Finally, the file path of the file operation request is redirected to the file filtering module in the guest machine's kernel state, and control of the central processing unit is returned to the guest machine, allowing the guest machine to send the file operation request into its own kernel state. Thus, by using the configuration rules of the preset virtual machine control structure and the virtual machine monitor to monitor the guest machine's behavior, a virtual machine exit event is triggered when the guest machine executes a system call entry instruction. The read / write operation of a specific register is redirected to the shadow register, effectively preventing the guest machine from bypassing system security protection by tampering with the value of a specific register, thereby improving the reliability of system security protection.

[0198] Figure 10 This is a schematic diagram of the system security protection device provided in the embodiments of this disclosure.

[0199] like Figure 10 As shown, the system security protection device 1000, configured in the client kernel mode, includes: The fourth processing module 1001 is used to receive the file operation request sent by the current client, generate the corresponding input / output request packet (IRP request packet) based on the file operation request, and send the IRP request packet to the file filtering module so that the file filtering module can determine the operation type of the IRP request packet and the target file of the operation. The third determination module 1002 is used to determine whether the target file is encrypted and obtain the determination result; The fifth processing module 1003 is used to process the IRP request packet based on the operation type and the determined result in order to complete the operation on the target file.

[0200] In one possible implementation of this disclosure, the third determining module 1002 is specifically used for: Determine whether the target file is encrypted and obtain the result, including: Determine if the target file contains an encryption identifier; If an encryption identifier is present, the target file is determined to be encrypted; If no encryption identifier exists, the target file is matched against the preset encryption policy. If the target file matches the encryption policy, the encryption function is called to encrypt the target file, thus confirming that the target file is encrypted.

[0201] In one possible implementation of this disclosure, the fifth processing module 1003 is specifically used for: When the operation type is a read operation and the result is determined to be that the target file is encrypted, the IRP request packet is sent to the file system driver. The driver is used to call the dispatch function corresponding to the IRP read request to read the data of the target file from the ciphertext cache of the double-buffered structure associated with the target file and write it into the buffer associated with the IRP request packet. In the event that reading data from the ciphertext cache fails, the data of the target file is read from the disk using a double-buffered structure, stored in the ciphertext cache, and then decrypted and stored in the plaintext cache of the double-buffered structure. Return to the step of calling the dispatch function to read data, and write the read data into the buffer associated with the IRP request packet.

[0202] In one possible implementation of this disclosure, the device 1000 further includes: The first writing module (not shown in the figure) is used to write historical data into the buffer of the IRP request packet when it fails to read data from the target file from the disk using the double-buffered structure and historical data of the target file exists in the plaintext buffer.

[0203] In one possible implementation of this disclosure, the device 1000 further includes: The second writing module (not shown in the figure) initiates an asynchronous IRP read request using the file filtering module when the buffer data of the IRP request packet reaches the pre-read condition. Starting from the end position of the data reading of the IRP request packet, it reads the encrypted data of the subsequent preset number of data blocks in the target file and stores them into the double buffer structure.

[0204] In one possible implementation of this disclosure, the fifth processing module 1003 is specifically used for: When the operation type is write operation and the target file is encrypted, the file filtering module is used to encrypt the data to be written in the buffer associated with the IRP request packet to obtain the IRP request packet after data encryption. The encrypted IRP request packet is sent to the file system driver, so that the file system driver sends the IRP request packet to the underlying driver for data writing. After the data is written, the underlying driver writes the write result into the IRP request and returns it to the file system driver, so that the file system driver can return the write result to the process corresponding to the file operation request through the input / output manager.

[0205] The functions and specific implementation principles of the modules described in this embodiment can be found in the above method embodiments, and will not be repeated here.

[0206] In this embodiment, a file operation request sent by the current client is first received. A corresponding Input / Output Request (IRP) packet is generated based on the file operation request and sent to the file filtering module. The file filtering module determines the operation type and target file of the IRP request packet, then determines whether the target file is encrypted, and obtains a determination result. Finally, based on the operation type and the determination result, the IRP request packet is processed to complete the operation on the target file. Therefore, by using the file filtering module to process IRP requests for file operation requests monitored by the virtual machine monitor, it effectively prevents file operation requests from bypassing or deceiving system security monitoring, further enhancing the reliability of system security protection.

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

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

[0209] like Figure 11 As shown, device 1100 includes a computing unit 1101, which can perform various appropriate actions and processes according to a computer program stored in read-only memory (ROM) 1102 or a computer program loaded into random access memory (RAM) 1103 from storage unit 1108. The RAM 1103 may also store various programs and data required for the operation of device 1100. The computing unit 1101, ROM 1102, and RAM 1103 are interconnected via bus 1104. Input / output (I / O) interface 1105 is also connected to bus 1104.

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

[0211] The computing unit 1101 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 1101 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 1101 performs the various methods and processes described above, such as system security protection methods. For example, in some embodiments, the system security protection method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 1108. In some embodiments, part or all of the computer program may be loaded and / or installed on device 1100 via ROM 1102 and / or communication unit 1109. When the computer program is loaded into RAM 1103 and executed by the computing unit 1101, one or more steps of the system security protection method described above may be performed. Alternatively, in other embodiments, the computing unit 1101 may be configured to perform system security protection methods by any other suitable means (e.g., by means of firmware).

[0212] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

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

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

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

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

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

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

[0219] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this disclosure, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified. In the description of this disclosure, the words "if" and "suppose" as used may be interpreted as "when," "when," "in response to determination," or "in the circumstances."

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

Claims

1. A system security protection method, characterized in that, The method is executed by the virtual machine monitor and includes: The client is monitored based on the configuration rules of the preset virtual machine control structure. When the client triggers a virtual machine exit event, the event type and instruction that triggered the event are determined. The configuration rules include an exception bitmap and register MSR read / write bitmaps. Based on the event type, the instruction, and the configuration rules, determine the reason for triggering the virtual machine exit event; If the reason is that the client executes a system call entry instruction, the read / write operation of the instruction targeting the target register is redirected to a preset corresponding shadow register; When the read / write operation is to read the kernel entry address of the system call, the file operation request of the client is determined based on the system call number and parameters associated with the system call entry instruction; The file path of the file operation request is redirected to the file filtering module in the client kernel mode, and the central processing unit control is returned to the client so that the client sends the file operation request into its own kernel mode.

2. The method as described in claim 1, characterized in that, When a virtual machine exit event is detected by the client, determining the event type and the instruction that triggered the event includes: If the client triggers a virtual machine exit event, the dispatch function for the virtual machine exit event is called to determine the event type that triggered the event; If the event type is an instruction execution related event type, read the instruction pointer value corresponding to the guest machine when the virtual machine exit event is triggered, and determine the instruction that triggered the event.

3. The method as described in claim 2, characterized in that, The process of determining the reason for triggering the virtual machine exit event based on the event type, the instruction, and the configuration rules includes: Invoke the dispatch function of the event type to obtain the context information of the client, wherein the context information includes at least one of registers, memory, and privilege level; Based on the context information and the configuration rules, the reason for triggering the virtual machine exit event is determined.

4. The method as described in claim 1, characterized in that, The method further includes: Add dispatch functions for exceptions, interrupt descriptor table loading instructions (LIDT), interrupt descriptor table reading instructions (SIDT), MSR read events, and MSR write events to the dispatch function for the virtual machine exit event; Add dispatch functions for the General Protection Exception (GP) and the Undefined Opcode Exception (UD) to the exception dispatch function.

5. The method as described in claim 1, characterized in that, The method further includes: Retrieve data from at least one of the Interrupt Descriptor Table Register (IDTR) and the MSR register, and store it in the corresponding shadow register; Set the size of the Interrupt Descriptor Table (IDT) in the IDTR register to a preset size; Set the kernel-mode code segment selector and the system call entry instruction enable flag in the MSR register to a first value, wherein the first value is used to characterize at least one of the invalid selector and the corresponding system call entry instruction.

6. The method as described in claim 1, characterized in that, The process of generating the configuration rules for the virtual machine control structure includes: During the initialization process of the virtual machine control structure, the value associated with the exception number of the GP exception and the UD exception in the exception bitmap is set to a second value, wherein the second value is used to represent intercepting the corresponding operation and triggering the virtual machine exit event; Set the value associated with the MSR number of the storage carrier of the kernel-mode code segment selector in the MSR read bitmap and MSR write bitmap to the second value; Set the value associated with the MSR number of the extended function master switch register in the high MSR read bitmap and high MSR write bitmap to the second value.

7. A system security protection method, characterized in that, The method is executed in the guest kernel mode and includes: Upon receiving a file operation request from the current client, a corresponding Input / Output Request Packet (IRP) is generated based on the file operation request, and the IRP request packet is sent to the file filtering module to determine the operation type and target file of the IRP request packet. Determine whether the target file is encrypted, and obtain a determination result; Based on the operation type and the determination result, the IRP request packet is processed to complete the operation on the target file.

8. The method as described in claim 7, characterized in that, The process of determining whether the target file has been encrypted and obtaining the determination result includes: Determine whether the target file contains an encryption identifier; If an encryption identifier is present, the target file is determined to be encrypted; If no encryption identifier exists, the target file is matched with a preset encryption policy. If the target file matches the encryption policy, an encryption function is called to encrypt the target file, thus confirming that the target file is encrypted.

9. The method as described in claim 8, characterized in that, The process of processing the IRP request packet based on the operation type and the determination result to complete the operation on the target file includes: When the operation type is a read operation and the determination result is that the target file is encrypted, the IRP request packet is sent to the file system driver. The driver is used to call the dispatch function corresponding to the IRP read request to read the data of the target file from the ciphertext cache of the double-buffered structure associated with the target file, decrypt it, and write it into the buffer associated with the IRP request packet. In the event that reading data from the ciphertext cache fails, the data of the target file is read from the disk using the dual-cache structure, stored in the ciphertext cache, and then decrypted and stored in the plaintext cache of the dual-cache structure. Return to the step of calling the dispatch function to read data, and write the read data into the buffer associated with the IRP request packet.

10. The method as described in claim 9, characterized in that, The method further includes: If reading data from the target file from the disk using the dual-caching structure fails, and historical data of the target file exists in the plaintext cache, the historical data is written into the buffer of the IRP request packet.

11. The method as described in claim 9, characterized in that, The method further includes: When the buffer data of the IRP request packet reaches the pre-read condition, the file filtering module initiates an asynchronous IRP read request. Starting from the end position of the data reading of the IRP request packet, the encrypted data of the subsequent preset number of data blocks in the target file is read and stored in the dual-buffer structure.

12. The method as described in claim 7, characterized in that, The process of processing the IRP request packet based on the operation type and the determination result to complete the operation on the target file includes: When the operation type is a write operation and the target file is encrypted, the file filtering module is used to encrypt the data to be written in the buffer associated with the IRP request packet to obtain the IRP request packet after data encryption. The encrypted IRP request packet is sent to the file system driver, so that the file system driver sends the IRP request packet to the underlying driver for data writing. After the data writing is completed, the underlying driver writes the writing result into the IRP request and returns it to the file system driver, so that the file system driver returns the writing result to the process corresponding to the file operation request through the input / output manager.

13. A system safety protection device, characterized in that, The device is configured in a virtual machine monitor and includes: The first processing module is used to monitor the client machine based on the configuration rules of the preset virtual machine control structure, and when the client machine triggers a virtual machine exit event, it determines the event type and instruction that triggered the event. The configuration rules include an exception bitmap and a register MSR read / write bitmap. The first determining module is used to determine the reason for triggering the virtual machine exit event based on the event type, the instruction, and the configuration rules; The second processing module is used to redirect the read / write operation of the target register to a preset corresponding shadow register when the reason is that the client executes a system call entry instruction. The second determining module is used to determine the client's file operation request based on the system call number and parameters associated with the system call entry instruction when the read / write operation is reading the kernel entry address of the system call. The third processing module is used to redirect the file path of the file operation request to the file filtering module in the client kernel mode, and return the central processing unit control to the client so that the client sends the file operation request into its own kernel mode.

14. A system safety protection device, characterized in that, The device is configured in the client kernel mode and includes: The fourth processing module is used to receive a file operation request sent by the current client, generate a corresponding Input / Output Request Packet (IRP) based on the file operation request, and send the IRP request packet to the file filtering module so that the file filtering module can determine the operation type of the IRP request packet and the target file of the operation. The third determining module is used to determine whether the target file is encrypted and obtain a determination result; The fifth processing module is used to process the IRP request packet based on the operation type and the determination result to complete the operation on the target file.

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

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

17. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method according to any one of claims 1-12.

Images