Monitoring method, apparatus and computing device for hyper invocation

Abstract

This application provides a method, apparatus, and computing device for monitoring supercalls. In an embodiment, when a virtual machine (VM) invokes a supercall from kernel mode, first information is captured from kernel mode via user mode. This first information is information generated by the supercall during the VM's invocation of the supercall. Based on this first information, first state information of the VM is determined. This first state information is the state information generated by the VM during the supercall's invocation. The supercall is then monitored based on the first state information and the first information. This avoids increasing kernel overhead and the attack surface, and eliminates the need for hardware isolation, thus avoiding increased protection costs for supercalls. Furthermore, monitoring the supercall based on the VM's state changes during the invocation improves the comprehensiveness of supercall monitoring.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus and computing device for monitoring super-calls. Background Technology

[0002] Hypercalls are a communication and management mechanism in virtualization environments, used for privileged requests and interactions between virtual machines (VMs) and the hypervisor. With the development of virtualization technology, virtualization platform vulnerabilities are also increasing. Among these vulnerabilities, those caused by hypercalls account for a significant proportion. Therefore, monitoring hypercalls is necessary to ensure the security of virtualization platforms.

[0003] Currently, related technologies monitor hypercalls by refactoring the virtual machine monitor or by using hardware isolation.

[0004] However, refactoring the virtual machine monitor requires modifications to the kernel, adding complex logic that increases kernel overhead and expands the attack surface for external attacks. Furthermore, hardware isolation increases protection costs. Summary of the Invention

[0005] This application provides a method, apparatus, and computing device for monitoring hypercalls, enabling monitoring without modifying the kernel. This avoids increasing kernel overhead and the attack surface, and eliminates the need for hardware isolation, thus reducing the cost of hypercall protection. Furthermore, by monitoring hypercalls based on changes in the VM's state during invocation, the comprehensiveness of hypercall monitoring is improved.

[0006] In a first aspect, embodiments of this application provide a method for monitoring super-calls, including:

[0007] When a virtual machine (VM) makes a super call to the kernel, the first information is captured from the kernel through the user space. The first information is the information generated by the super call during the VM's super call process.

[0008] Based on the first information, the first state information of the VM is determined. The first state information is the state information generated by the VM during the process of calling hypercall.

[0009] Based on the first state information and the first information, the super call is monitored.

[0010] According to this scheme, some information, namely "first information," is generated during the invocation of a super call. This first information is captured from the kernel space by the user space, and based on this first information, the state information generated by the VM during the super call is determined. Thus, monitoring of the super call is achieved based on the first information and the first state information. This allows for monitoring of the super call without modifying the kernel space, avoiding increased kernel overhead and preventing an increase in the attack surface. Furthermore, monitoring of the super call can be achieved without hardware isolation, avoiding increased protection costs for the super call. In addition, this scheme monitors the super call based on the VM's state changes during the super call, improving the comprehensiveness of super call monitoring.

[0011] In one possible implementation, hooks are deployed in kernel mode to capture initial information from kernel mode via user mode, including:

[0012] The first information is captured from the hook in user mode.

[0013] In this way, by attaching the hook to the kernel mode, monitoring of super calls can be achieved without modifying the kernel mode or performing hardware isolation. This avoids increasing kernel overhead, increasing the attack surface of the kernel from the outside, and increasing the protection cost of super calls.

[0014] In one possible implementation, the first information includes a timestamp indicating when the super call began, and based on this first information, the first state information of the VM is determined, including:

[0015] Determine the time window, where the time includes the timestamp. The first state information is the state information of the VM that falls within the time window from among its multiple state information.

[0016] Thus, by retrieving partial status information from a large amount of status data through a time window for super-call anomaly monitoring, computational resources can be saved and the efficiency of super-call monitoring can be improved. The length of the time window is determined iteratively and configured into the system, achieving an optimal balance between monitoring accuracy and monitoring time.

[0017] In one possible implementation, super calls are monitored based on the first state information and the first information, including:

[0018] Based on the VM's initial state information, determine whether the VM is abnormal;

[0019] In the event of a VM malfunction, determine whether the super call is abnormal based on the initial information.

[0020] Thus, the monitoring of super calls not only covers the monitoring of super call anomalies, but also includes changes in the VM state, thereby ensuring the comprehensiveness and accuracy of super call monitoring.

[0021] In one possible implementation, the first information includes the call number of the super call, and based on the first information, determining whether the super call is abnormal includes:

[0022] Determine whether the supercall is abnormal based on the supercall call number.

[0023] In one possible implementation, the first information includes the process identifier of the super call, and based on the first information, determining whether the super call is abnormal includes:

[0024] The frequency of super calls is determined based on the process identifier of the super call;

[0025] Determine if the super call is abnormal based on the call frequency.

[0026] In one possible implementation, determining whether the VM is abnormal is based on the VM's state information, including:

[0027] The first state information is sampled to obtain the second state information;

[0028] Information is reconstructed using the second state information to obtain the third state information. The length of the time window for the third state information is the same as the length of the time window for the first state information.

[0029] Based on the third state information and the first state information, determine whether the VM is abnormal.

[0030] In this way, by reconstructing the information, the super call can be monitored based on the changes in the VM's state when invoking the super call, thereby improving the comprehensiveness of super call monitoring.

[0031] In one possible implementation, super calls are monitored based on the first state information and the first information, including:

[0032] The first state information and the first information are input into the pre-trained anomaly analysis model. The anomaly analysis model analyzes the first state information to determine whether the super call is abnormal.

[0033] The anomaly analysis model is trained using sample state information, sample information, and label information. Sample state information is the state information generated by the VM when it calls the super call. Sample information is the information generated by the super call when the VM calls the super call. Label information is used to indicate whether the super call is abnormal and the reason for the VM's abnormality when the super call is abnormal.

[0034] In this way, by monitoring the state changes of the VM when invoking the super call, the comprehensiveness of super call monitoring can be improved.

[0035] Secondly, embodiments of this application provide a monitoring device for super-calling, comprising:

[0036] The acquisition module is used to capture first information from kernel mode through user mode when the virtual machine (VM) makes a super call to kernel mode. The first information is the information generated by the super call during the VM's super call process.

[0037] The determination module is used to determine the first state information of the VM based on the first information. The first state information is the state information generated by the VM during the process of calling hypercall.

[0038] The monitoring module is used to monitor the super call based on the first state information and the first information.

[0039] According to this scheme, some information, namely "first information," is generated during the invocation of a super call. This first information is captured from the kernel space by the user space, and based on this first information, the state information generated by the VM during the super call is determined. Thus, monitoring of the super call is achieved based on the first information and the first state information. This allows for monitoring of the super call without modifying the kernel space, avoiding increased kernel overhead and preventing an increase in the attack surface. Furthermore, monitoring of the super call can be achieved without hardware isolation, avoiding increased protection costs for the super call. In addition, this scheme monitors the super call based on the VM's state changes during the super call, improving the comprehensiveness of super call monitoring.

[0040] In one possible implementation, a hook is mounted in kernel mode, and the acquisition module is used to capture initial information from the hook via user mode.

[0041] In this way, by attaching the hook to the kernel mode, monitoring of super calls can be achieved without modifying the kernel mode or performing hardware isolation. This avoids increasing kernel overhead, increasing the attack surface of the kernel from the outside, and increasing the protection cost of super calls.

[0042] In one possible implementation, the first information includes the timestamp of when the super call begins, the determination module determines the time window, the time within the time window includes the timestamp, and the first state information is the state information within the time window from among the multiple state information of the VM.

[0043] Thus, by retrieving partial status information from a large amount of status data through a time window for super-call anomaly monitoring, computational resources can be saved and the efficiency of super-call monitoring can be improved. The length of the time window is determined iteratively and configured into the system, achieving an optimal balance between monitoring accuracy and monitoring time.

[0044] In one possible implementation, the monitoring module is used to determine whether the VM is abnormal based on the VM's initial state information;

[0045] In the event of a VM malfunction, determine whether the super call is abnormal based on the initial information.

[0046] Thus, the monitoring of super calls not only covers the monitoring of super call anomalies, but also includes changes in the VM state, thereby ensuring the comprehensiveness and accuracy of super call monitoring.

[0047] In one possible implementation, the first information includes the super call's call number, and the monitoring module is used to determine whether the super call is abnormal based on the super call's call number.

[0048] In one possible implementation, the first information includes the process identifier of the super call, which the monitoring module uses to:

[0049] The frequency of super calls is determined based on the process identifier of the super call;

[0050] Determine if the super call is abnormal based on the call frequency.

[0051] In one possible implementation, the monitoring module is used for:

[0052] The first state information is sampled to obtain the second state information;

[0053] Information is reconstructed using the second state information to obtain the third state information. The length of the time window for the third state information is the same as the length of the time window for the first state information.

[0054] Based on the third state information and the first state information, determine whether the VM is abnormal.

[0055] In this way, by reconstructing the information, the super call can be monitored based on the changes in the VM's state when invoking the super call, thereby improving the comprehensiveness of super call monitoring.

[0056] In one possible implementation, the monitoring module is used for:

[0057] The first state information and the first information are input into the pre-trained anomaly analysis model. The anomaly analysis model analyzes the first state information to determine whether the super call is abnormal.

[0058] The anomaly analysis model is trained using sample state information, sample information, and label information. Sample state information is the state information generated by the VM when it calls the super call. Sample information is the information generated by the super call when the VM calls the super call. Label information is used to indicate whether the super call is abnormal and the reason for the VM's abnormality when the super call is abnormal.

[0059] In this way, by monitoring the state changes of the VM when invoking the super call, the comprehensiveness of super call monitoring can be improved.

[0060] Thirdly, embodiments of this application provide a computing device, including: at least one memory for storing a program; and at least one processor for executing the program stored in the memory, wherein when the program stored in the memory is executed, the processor is used to execute the method provided in the first aspect.

[0061] Fourthly, embodiments of this application provide a computing device cluster, including at least one computing device, each computing device including a processor and a memory;

[0062] The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the cluster of computing devices to perform the method provided in the first aspect or any possible implementation thereof.

[0063] Fifthly, embodiments of this application provide a monitoring device for hypercalls, characterized in that the device executes computer program instructions to perform the methods provided in the first aspect or any possible implementation thereof. Exemplarily, the device may be a chip or a processor.

[0064] In one example, the device may include a processor that may be coupled to memory, read instructions from the memory, and execute, according to the instructions, the methods provided in the first aspect or any possible implementation thereof. The memory may be integrated into the chip or processor, or it may be independent of the chip or processor.

[0065] In a sixth aspect, embodiments of this application provide a computer storage medium storing instructions that, when executed on a computer, cause the computer to perform the method provided in the first aspect or any possible implementation thereof.

[0066] In a seventh aspect, embodiments of this application provide a computer program product containing instructions that, when executed on a computer, cause the computer to perform the method provided in the first aspect or any possible implementation thereof. Attached Figure Description

[0067] Figure 1a This is a system architecture diagram of a monitoring method for executing hypercalls provided in an embodiment of this application;

[0068] Figure 1b This is a schematic diagram of the flowchart of a hypercall monitoring method provided in an embodiment of this application;

[0069] Figure 2 This is a flowchart illustrating a hypercall monitoring method provided in an embodiment of this application;

[0070] Figure 3 This is a schematic diagram of the flowchart of a super-call monitoring method provided in an embodiment of this application;

[0071] Figure 4 This is an exemplary schematic diagram of a hypercall monitoring method provided in an embodiment of this application;

[0072] Figure 5 This is a flowchart illustrating a hypocall anomaly monitoring method provided in an embodiment of this application;

[0073] Figure 6 This is a schematic diagram of the structure of a super-call monitoring device provided in an embodiment of this application;

[0074] Figure 7 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application;

[0075] Figure 8 This is a schematic diagram of another computing device cluster structure provided in an embodiment of this application;

[0076] Figure 9 This is a schematic diagram of another computing device cluster provided in the embodiments of this application. Detailed Implementation

[0077] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0078] First, the terms used in the embodiments of this application will be explained in detail.

[0079] Kernel mode: Also known as kernel mode, supervisor mode, or privileged mode. Kernel mode is the operating mode in which the operating system kernel runs. Code running in this mode has unrestricted access to system storage and external devices. In kernel mode, the operating system has the highest privileges and can access all system resources, including memory, CPU, and hardware devices. The operating system can execute privileged instructions in kernel mode, such as stopping the processor, changing mode bits, and initiating I / O operations. Furthermore, critical tasks such as system calls, interrupt handling, and exception handling are also performed in kernel mode. The main function of kernel mode is to protect system security and stability, preventing applications from abusing and damaging system resources. By restricting applications to access only limited resources and requesting services through system calls, it ensures stable system operation.

[0080] User mode, also known as non-privileged mode or user space, refers to the running state of ordinary applications. In this state, applications can only access limited resources and request services from the operating system through system calls. In user mode, application permissions are strictly limited; they cannot execute privileged instructions or directly access operating system data and programs. Each process runs in its own user space and is not allowed to access the user space of other programs. The design of user mode helps enhance system security. Because applications run in user mode, they cannot directly access or modify data and programs in kernel mode, thus reducing the risk of system crashes or malicious attacks. In user mode, applications typically can only access their allocated memory space and other limited resources. If they need to access more resources or perform privileged operations, the application must request them from the operating system through system calls.

[0081] Kernel-based Virtual Machine (KVM): KVM allows multiple isolated virtual machines to run on a single physical host, each running an independent operating system. KVM transforms the kernel into a virtualization hypervisor, combining hardware virtualization technology and the kernel's virtualization module to create a virtualization layer. This divides the physical server into multiple virtual machines and provides a virtualized environment for each, thereby achieving resource sharing and isolation.

[0082] Hypercall: An interface or mechanism used by the guest operating system or within a virtual machine to communicate with a virtual machine monitor. It allows the virtual machine to request privileged operations or acquire resources from the virtual machine monitor. These operations may include configuring virtual devices, managing memory, and accessing input / output devices. Hypercall provides a standardized way for virtual machines to communicate with the virtual machine monitor to request privileged operations or acquire necessary resources.

[0083] Virtualization technology has become a core technology of cloud computing infrastructure, widely applied in various fields of cloud computing, such as Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). In the IaaS field, virtualization technology is used to create, manage, and schedule virtual machines, providing flexible resource configuration and elastic scaling capabilities. Hypercall is a communication and management mechanism in a virtualization environment used for privileged operation requests and interactions between virtual machines (VMs) and the hypervisor. With the development of virtualization technology, virtualization platform vulnerabilities continue to increase. Among these vulnerabilities, those caused by hypercalls account for a significant proportion. As the complexity and openness of virtualization systems increase, hypervisors face numerous security challenges, such as an expanded attack surface, increased attack windows, and vulnerabilities in single-point security protection.

[0084] For example, some users exploit hypercalls to launch Denial of Service (DoS) attacks. Under such attacks, attackers can rapidly consume system resources, such as the Central Processing Unit (CPU) and memory, by sending a large number of hypercall requests, thus rendering the virtualized environment unavailable and impacting system stability and performance. Related technologies have proposed an innovative protection mechanism: Hyperthreats. Hyperthreats can counter hypercall-based DoS attacks. However, hypercall-based attacks come in many types, and Hyperthreats can only protect against DoS attacks, failing to provide effective protection against other types of attacks. Therefore, the Hyperthreats protection mechanism cannot comprehensively detect and defend against all types of hypercall-based attacks; its protection target is limited.

[0085] For example, modifying the kernel can be used to perform security verification on hypercalls, thereby effectively controlling and monitoring hypercall requests and preventing unauthorized access and malicious operations. However, modifying the kernel adds complex logic, increasing kernel overhead and expanding the attack surface for external attacks.

[0086] Based on this, embodiments of this application provide a hypercall monitoring method, apparatus, computing device, and computer storage medium. In this method, some information, namely first information, is generated during the hypercall invocation process. The first information is captured from the kernel space through user space, thereby determining the state information generated by the VM during the hypercall invocation based on the first information. Thus, hypercall monitoring is achieved based on the first information and the first state information. This allows hypercall monitoring without modifying the kernel space, avoiding increased kernel overhead and preventing an increase in the attack surface to the kernel. Furthermore, hypercall monitoring can be achieved without hardware isolation, avoiding increased hypercall protection costs. In addition, this solution monitors hypercalls based on the VM's state changes during hypercall invocation, improving the comprehensiveness of hypercall monitoring.

[0087] First, the system architecture used to execute the hypercall monitoring method is described in detail.

[0088] Figure 1a This is a schematic diagram of the architecture of a hypercall monitoring system provided in an embodiment of this application. Figure 1a As shown, the hypercall monitoring system provided in this embodiment includes a virtualization layer 11, a user space 12, and a kernel space 13. The virtualization layer 11 includes multiple virtual machines (VMs), such as... Figure 1a VM1 to VM shown n Kernel mode 13 includes KVM. The VM is used to execute tasks required by the system. During task execution, the VM may require certain privileged operations. Since the VM cannot perform privileged operations in a non-privileged domain, a hypercall is called, causing the VM to exit and system control to switch from the VM to the KVM to complete these operations. For example, privileged operations include creating or destroying partitions, configuring virtual devices, and setting memory mappings. In this embodiment, Figure 1a The system shown can be deployed in computing devices, such as computers, servers, and host machines. This application does not specifically limit the scope of the embodiments in this regard.

[0089] Specifically, with Figure 1aThe system shown is deployed on a host as an example, such as Figure 1b As shown, KVM can listen for and capture hypercalls initiated by the VM. Based on the hypercall information, KVM determines the corresponding handler function. KVM executes the handler function to complete the operation requested by the VM. The host monitors the hypercall based on the hypercall information.

[0090] In this embodiment, to avoid modifying the kernel to monitor hypercalls, when a hypercall is invoked by the VM, it is monitored in user space. For example, the hypercall is traced in user space to obtain hypercall-related information from the kernel, and then monitored in user space based on this information. In this way, hypercalls can be monitored without modifying the kernel, avoiding increased kernel overhead and preventing an increase in the attack surface.

[0091] based on Figure 1a The system architecture shown provides a detailed description of the hypercall monitoring method provided in this application embodiment.

[0092] Figure 2 Figure 1 is a flowchart illustrating a hypercall monitoring method provided in an embodiment of this application. As shown in Figure 1, the hypercall monitoring method provided in this embodiment includes the following steps S201 to S203.

[0093] S201, In the case of the VM calling hypercall to the kernel mode, the first information is captured from the kernel mode through the user mode. The first information is the information generated by hypercall during the VM calling hypercall.

[0094] When a virtual machine invokes a hypercall, to avoid modifying the kernel to monitor the hypercall, it is necessary to capture initial information from the kernel space via user space. This initial information is generated during the execution of the hypercall in kernel space, such as the timestamp when the hypercall execution begins, the hypercall's call number (nr), and the hypercall's process identifier (PID). The hypercall's PID is a numerical identifier indicating a process. In this embodiment, the process initiating the hypercall is the VM, so the PID can also identify the VM that called the hypercall. The hypercall's call number is a unique identifier used to distinguish hypercall operations.

[0095] In some embodiments, such as Figure 3 As shown, user space uses Extended Berkeley Packet Filter (eBPF) technology to deploy tracepoints in kernel space to obtain initial information. For example, as... Figure 3 and Figure 4 As shown, the tracing point can be a hook function, which is then attached to KVM using eBPF technology. Figure 4 As shown, after receiving a hypercall in kernel mode, it performs hypercall processing, thereby generating the first piece of information. User mode can capture this first piece of information through hooks. Figure 4 In step 1, the first piece of information is that the PID of the hypercall is PID2 and the timestamp is T.

[0096] S202, Based on the first information, determine the first state information of the VM. The first state information is the state information generated by the VM during the process of calling hypercall.

[0097] During hypercall execution, VM state changes are crucial information for hypercall monitoring. Therefore, it is necessary to determine the VM's initial state information over a period of time. This initial state information includes CPU utilization, memory utilization, network receive rate, and network send rate, among others.

[0098] In some embodiments, since there are multiple VMs in the system, and VMs can trigger a large number of hypercalls in a short period of time, the system can generate first state information for each VM during different hypercall calls. For example, the system generates first state information based on the PID corresponding to the VM. For example, the system can generate a state information table. The state information table stores information in key-value pairs. The key in the state information table is the PID corresponding to the VM when it calls the hypercall, and the value is the first state information of the VM. Thus, when we obtain the first information, we match the first state information corresponding to that PID from the state information table based on the PID in the first information. For example, the state information table is shown in Table 1, including PID1, PID2, and PID3. The first state information corresponding to PID1 is state information A, the first state information corresponding to PID2 is state information B, and the first state information corresponding to PID3 is state information C. Since the PID in the first information is PID1, the first state information of the VM is state information A.

[0099] Table 1

[0100] PID First status information PID1 Status Information A PID2 Status Information B PID3 Status information C

[0101] In some embodiments, to save computing resources and improve the efficiency of hypercall monitoring, partial information can be extracted from the VM's state information for analysis based on the length of the time window, thereby monitoring hypercalls. The length of the time window can achieve an optimal balance between detection accuracy and detection time. As one possible implementation, the length of the time window is pre-configured. In this application embodiment, different time window lengths can be set for different hypercalls, such as... Figure 3 The window shown is Window 1, Window 2, Window n, etc.

[0102] Specifically, the first state information is determined from the VM's state information based on the timestamp and the length of the time window in the first information. The first state information includes the VM's state information at the timestamp. For example, such as... Figure 4 As shown, in the first information, the PID of the hypercall is PID2. From the status information table, the status information corresponding to PID2 can be determined as B. The preset time window length is L. After matching status information B, status information B1 is determined from status information B based on the time window length L and the timestamp T. The time window length of status information B1 is L, and status information B1 includes the status information at timestamp T.

[0103] S203, monitor the hypercall based on the first state information and the first information.

[0104] By analyzing the initial state information of the VM, hypercalls can be monitored. Thus, this embodiment of the application can obtain hypercall information without modifying the kernel, thereby determining the VM's state information based on the hypercall information and monitoring hypercalls, avoiding increased kernel overhead and minimizing external attack surfaces on the kernel.

[0105] In some embodiments, in S203, monitoring the hypercall specifically includes monitoring whether the hypercall is abnormal. Specifically, as... Figure 5 As shown, monitoring whether a hypercall is abnormal includes the following steps S501 to S506.

[0106] S501, sample the first state information to obtain the second state information.

[0107] In this embodiment of the application, the second state information can be obtained by randomly sampling the first state information using a compressed sensing algorithm.

[0108] In some embodiments, before sampling the first state information, in order to reduce the number of data reconstruction failures, the first state information can be preprocessed, for example, normalized or regularized.

[0109] S502, the second state information is reconstructed according to the length of the preset time window to obtain the third state information.

[0110] In this embodiment, third state information is obtained by reconstructing the second state information. The reconstruction algorithm can be a compressed sensing algorithm, an expectation-maximization algorithm, a multiple imputation algorithm, etc. Various reconstruction algorithms are available, and the appropriate one can be selected based on the specific circumstances. This embodiment does not specifically limit the reconstruction algorithm used.

[0111] S503, determine whether the third state information has been successfully reconstructed. If yes, execute S504; otherwise, execute S501.

[0112] According to the optimization algorithm, it is determined whether the third state information has been successfully reconstructed. Specifically, if the length of the time window for the third state information is the same as the length of the time window for the first state information, the third state information is successfully reconstructed. If the length of the time window for the third state information is different from the length of the time window for the first state information, the sampling rate is adjusted, and the first state information is resampled until the third state information is successfully reconstructed. For example, as shown... Figure 3 and Figure 4 As shown, after determining state information B1, state information B1 is sampled and reconstructed until state information B2 with a time window length of L is obtained. Figure 3 As shown, in the case of successful reconstruction, the user space monitors whether the hypercall is abnormal.

[0113] S504: Based on the first and third state information, determine whether the VM has encountered an error. If so, execute S505 or S506.

[0114] In this embodiment, if the difference between the first state information and the third state information is significant, then the VM is determined to be abnormal. As one possible implementation, the Euclidean distance between the third state information and the first state information is calculated. To avoid the Euclidean distance being dominated by information at a single timestamp, an anomaly score is calculated based on the harmonic mean of the Euclidean distance. It is then determined whether the anomaly score is greater than a score threshold; if the anomaly threshold is greater than the score threshold, the VM is determined to be abnormal.

[0115] S505: Based on the hypercall's PID, determine if the hypercall's call frequency is too high. If so, determine that the hypercall is abnormal.

[0116] Based on the hypercall's PID, the hypercall's call frequency can be counted. If the hypercall's call frequency is greater than a preset frequency threshold, the hypercall is determined to be abnormal.

[0117] S506, based on the hypercall's NR, determine whether the hypercall was processed normally. If so, determine that the hypercall is abnormal.

[0118] For example, such as Figure 4 As shown, the difference between status information B1 and status information B2 determines whether the VM is abnormal. In the case of a VM abnormality, the abnormality of the hypercall is determined based on the hypercall's call frequency and / or nr.

[0119] For example, the value of nr can be used to determine whether a hypercall is processed normally, and thus whether the hypercall is abnormal. For instance, when nr = 5, the hypercall is processed normally by the system, therefore, the hypercall is not abnormal. When nr is not equal to 5, the hypercall is not processed normally by the system, therefore, the hypercall is abnormal.

[0120] In other embodiments, hypercalls can also be monitored using a pre-trained anomaly analysis model. Specifically, in S203, the first state information and the first information are input into the pre-trained anomaly analysis model. The anomaly analysis model analyzes the first state information to determine whether the hypercall is abnormal. The anomaly analysis model is trained using sample state information, sample information, and label information. The sample state information is the state information generated by the VM when calling the hypercall; the sample information is the information generated when executing the hypercall; and the label information is used to indicate whether the hypercall is abnormal and, if so, the reason for the hypercall's abnormality.

[0121] In some other embodiments, the malfunction of the virtual machine (VM) is determined by comparing changes at two points in time within a time window. For example, the magnitude of the change in CPU utilization between two points in time can be used to determine if the VM is malfunctioning. Similarly, the magnitude of the change in memory utilization between two points in time can be used to determine if the VM is malfunctioning.

[0122] In the case of a hypercall exception, determine that the VM exception was caused by the hypercall exception.

[0123] Based on the same concept as the embodiments of the method in this application, this application also provides a super-call monitoring device. The super-call monitoring device includes several modules, each module being used to execute various steps in the super-call monitoring method provided in this application. The division of modules is not limited here. Those skilled in the art will clearly understand that in practical applications, the various steps in the super-call monitoring method provided in this application can be assigned to different modules as needed, that is, the internal structure of the device can be divided into different modules to complete all or part of the functions described above. The modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more modules can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the modules in the above device can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0124] For example, the super-call monitoring device is used to execute the super-call monitoring method provided in the embodiments of this application. Figure 6 This is a schematic diagram of the super-call monitoring device provided in an embodiment of this application. Figure 6As shown in the embodiment of this application, the monitoring device for super-calling includes:

[0125] The acquisition module 601 is used to capture first information from the kernel mode through the user mode when the virtual machine VM calls hypercall to the kernel mode. The first information is the information generated by hypercall during the VM's hypercall process.

[0126] The determining module 602 is used to determine the first state information of the VM based on the first information. The first state information is the state information generated by the VM during the process of calling hypercall.

[0127] The monitoring module 603 is used to monitor the hypercall based on the first status information and the first information.

[0128] According to this scheme, some information, namely "first information," is generated during the hypercall invocation process. This first information is captured from kernel space by user space, and based on it, the state information generated by the VM during the hypercall invocation is determined. Thus, monitoring of the hypercall is achieved based on the first information and the first state information. This allows for hypercall monitoring without modifying kernel space, avoiding increased kernel overhead and preventing the expansion of the attack surface. Furthermore, hypercall monitoring can be achieved without hardware isolation, avoiding increased protection costs. In addition, this scheme monitors hypercalls based on the VM's state changes during hypercall invocation, improving the comprehensiveness of hypercall monitoring.

[0129] In one possible implementation, a hook is mounted in kernel mode, and the acquisition module is used to capture initial information from the hook via user mode.

[0130] In this way, by attaching the hook to the kernel mode, hypercall monitoring can be achieved without modifying the kernel mode or performing hardware isolation. This avoids increasing kernel overhead, increasing the attack surface of the kernel from the outside, and increasing the protection cost of hypercalls.

[0131] In one possible implementation, the first information includes the timestamp of when the hypercall begins execution, the determination module determines the time window, the time within the time window includes the timestamp, and the first state information is the state information within the time window from among multiple state information of the VM.

[0132] Thus, by extracting partial state information from a large amount of state data based on a time window for hypercall anomaly monitoring, computational resources can be saved and the efficiency of hypercall monitoring can be improved. The length of the time window is determined iteratively and configured into the system, achieving an optimal balance between monitoring accuracy and monitoring time.

[0133] In one possible implementation, the monitoring module is used to determine whether the VM is abnormal based on the VM's initial state information;

[0134] In the event of a VM malfunction, determine whether the hypercall is malfunctioning based on the initial information.

[0135] Thus, the monitoring of hypercalls not only covers the monitoring of hypercall anomalies, but also includes changes in the VM state, thereby ensuring the comprehensiveness and accuracy of hypercall monitoring.

[0136] In one possible implementation, the first information includes the hypercall's call number, and the monitoring module is used to determine whether the hypercall is abnormal based on the hypercall's call number.

[0137] In one possible implementation, the first information includes the hypercall's process identifier, which the monitoring module uses to:

[0138] The hypercall call frequency is determined based on the hypercall process identifier;

[0139] Determine if the hypercall is abnormal based on the call frequency.

[0140] In one possible implementation, the monitoring module is used for:

[0141] The first state information is sampled to obtain the second state information;

[0142] Information is reconstructed using the second state information to obtain the third state information. The length of the time window for the third state information is the same as the length of the time window for the first state information.

[0143] Based on the third state information and the first state information, determine whether the VM is abnormal.

[0144] In this way, by reconstructing the information, the hypercall can be monitored based on the state changes of the VM when calling the hypercall, thereby improving the comprehensiveness of hypercall monitoring.

[0145] In one possible implementation, the monitoring module is used for:

[0146] The first state information and the first information are input into the pre-trained anomaly analysis model. The anomaly analysis model analyzes the first state information to determine whether the hypercall is abnormal.

[0147] The anomaly analysis model is trained using sample state information, sample information, and label information. Sample state information is the state information generated by the VM when it calls the hypercall. Sample information is the information generated by the hypercall when the VM calls the hypercall. Label information is used to indicate whether the hypercall is abnormal and the reason why the VM is abnormal when the hypercall is abnormal.

[0148] In this way, by monitoring the hypercall based on the state changes of the VM when calling the hypercall, the comprehensiveness of hypercall monitoring can be improved.

[0149] Based on the same concept as the method embodiments of this application, embodiments of this application also provide a computing device. This computing device can be a server, host, etc.

[0150] Figure 7 This is a schematic diagram of the hardware structure of a computing device 700 provided in an embodiment of this application.

[0151] like Figure 7 As shown, the computing device 700 includes a chip 701, a memory 702, a communication interface 703, and a bus 704. The chip 701, memory 702, and communication interface 703 are connected to each other via the bus 704. The chip 701, memory 702, and communication interface 703 can also be connected using other connection methods besides the bus 704.

[0152] The memory 702 can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), flash memory, optical storage, hard disk, etc.

[0153] Chip 701 can be the aforementioned System-on-a-Chip (SOC), which may include a processor and a connector. The processor can be a general-purpose processor. A general-purpose processor can be a processor that performs specific steps and / or operations by reading and executing contents stored in memory (e.g., memory 702). For example, a general-purpose processor can be a central processing unit (CPU). Chip 701 may include at least one circuit to perform... Figure 2 or Figure 5 All or part of the steps of the method provided in the illustrated embodiments.

[0154] The communication interface 703 includes input / output (I / O) interfaces, physical interfaces, and logical interfaces for interconnecting devices within the computing device 700, as well as interfaces for interconnecting the computing device 700 with other devices (such as other computing devices or user equipment). The physical interface can be an Ethernet interface, a fiber optic interface, an ATM interface, etc.

[0155] The bus 704 can be any type of communication bus used to interconnect the chip 701, memory 702 and communication interface 703, such as a system bus.

[0156] The aforementioned devices can be disposed on separate chips, or at least partially or entirely on the same chip. Whether to dispose of the devices independently on different chips or integrate them on one or more chips often depends on the needs of the product design. This application does not limit the specific implementation of the aforementioned devices.

[0157] Figure 7 The computing device 700 shown is merely exemplary. In the implementation process, the computing device 700 may also include other components, which will not be listed one by one in this article.

[0158] based on Figure 2 In addition to the method shown, this application also provides a computing device cluster.

[0159] Figure 8 This application provides a computing device cluster 800. For example... Figure 8 As shown, the computing device cluster includes at least one computing device 700. The memory 702 of one or more computing devices 700 in the computing device cluster may store the same memory for executing... Figure 2The instructions for the method are shown. The acquisition module 601, determination module 602, and monitoring module 603 in the monitoring device of the super-call can be deployed on a single computing device 700 or distributed across multiple computing devices 700. In the distributed deployment scenario, the acquisition module 601 can be deployed on a single computing device or distributed across multiple computing devices 700; similarly, the determination module 602 and monitoring module 603 can also be deployed on a single computing device 700 or distributed across multiple computing devices 700.

[0160] The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0161] In some possible implementations, the memory 702 of one or more computing devices 700 in the computing device cluster may also store memory for execution. Figure 2 The instructions of the method shown are partial. In other words, a combination of one or more computing devices 700 can coexist for executing... Figure 2 The instructions for the method shown.

[0162] It should be noted that the memory 702 in different computing devices 700 within the computing device cluster can store different instructions, each for execution. Figure 5 The illustrated device performs some of its functions. Specifically, the instructions stored in the memory 702 of different computing devices 700 can implement... Figure 5 The function of one or more modules in the device shown.

[0163] In some possible implementations, one or more computing devices in a computing device cluster can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc. Figure 9 One possible implementation is shown. For example... Figure 9 As shown, two computing devices 700A and 700B are connected via a network. Specifically, they are connected to the network through communication interfaces in each computing device. In this possible implementation, the memory 702 in computing device 700A stores instructions for implementing the functions of the acquisition module 601. Meanwhile, the memory 702 in computing device 700B stores instructions for implementing the functions of the determination module 602 and the monitoring module 603.

[0164] It should be understood that Figure 9 The functions of the computing device 700A shown can also be performed by multiple computing devices 700. Similarly, the functions of the computing device 700B can also be performed by multiple computing devices 700.

[0165] In addition to the methods, apparatus, and computing devices described above, embodiments of this application may also provide a computer program product, comprising computer program instructions. When executed by a processor, these computer program instructions cause the processor to perform the steps of the methods in the various embodiments of this application described in the "Method" section of this specification. The computer program product may be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this application. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The computer program code may be in source code form, object code form, executable file, or some intermediate form. The computer program code may be executed entirely on a user's computing device, partially on a user's computing device, as a standalone software package, partially on a user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0166] Furthermore, embodiments of this application may also provide a computer-readable storage medium storing computer program instructions thereon, which, when executed by a processor, cause the processor to perform the steps of the display control method according to various embodiments of this disclosure as described in the "Method" section above. The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may include, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, 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 device, magnetic storage device, or any suitable combination thereof. It should be noted that the content contained in the computer-readable medium may be appropriately added to or subtracted according to the requirements of legislation and patent practice in a jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, a computer-readable medium may not include electrical carrier signals and telecommunication signals.

[0167] The method steps in the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can reside in an ASIC.

[0168] It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application. It should be understood that in the embodiments of this application, the order of the process numbers does not imply the order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0169] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of this application.

Claims

1. A method for monitoring super-calls, characterized in that, include: When a virtual machine (VM) invokes a super call in kernel mode, first information is captured from the kernel mode in user mode. The first information is the information generated by the super call during the VM's invocation of the super call. Based on the first information, the first state information of the VM is determined. The first state information is the state information generated by the VM during the process of the VM calling the super call. Based on the first status information and the first information, the super call is monitored.

2. The method according to claim 1, characterized in that, The kernel mode is deployed with hooks, and the capture of the first information from the kernel mode via user mode includes: The first information is captured from the hook through the user state.

3. The method according to claim 1 or 2, characterized in that, The first information includes a timestamp indicating when the super call began. Based on the first information, the first state information of the VM is determined, including: A time window is determined, wherein the time within the time window includes the timestamp, and the first state information is the state information of the VM that is located within the time window from among multiple state information.

4. The method according to any one of claims 1-3, characterized in that, The step of monitoring the super call based on the first status information and the first information includes: Based on the first state information of the VM, determine whether the VM is abnormal; In the event of a VM malfunction, the super call is determined to be abnormal based on the first information.

5. The method according to claim 4, characterized in that, The first information includes the call number of the super call, and determining whether the super call is abnormal based on the first information includes: Based on the call number of the super call, determine whether the super call is abnormal.

6. The method according to claim 4, characterized in that, The first information includes the process identifier of the super call, and determining whether the super call is abnormal based on the first information includes: The frequency of the super call is determined based on the process identifier of the super call; Based on the call frequency, determine whether the super call is abnormal.

7. The method according to any one of claims 4-6, characterized in that, The step of determining whether the VM is abnormal based on the VM's status information includes: The first state information is sampled to obtain the second state information; The third state information is obtained by reconstructing information using the second state information, and the length of the time window of the third state information is the same as the length of the time window of the first state information. Based on the third state information and the first state information, determine whether the VM is abnormal.

8. The method according to claim 1, characterized in that, The step of monitoring the super call based on the first status information and the first information includes: The first state information and the first information are input into a pre-trained anomaly analysis model, which analyzes the first state information to determine whether the super call is abnormal. The anomaly analysis model is trained using sample state information, sample information, and label information. The sample state information is the state information generated by the VM when it calls the super call. The sample information is the information generated by the super call when the VM calls the super call. The label information is used to indicate whether the super call is abnormal and the reason for the VM's abnormality when the super call is abnormal.

9. A monitoring device for super-calling, characterized in that, include: The acquisition module is used to capture first information from the kernel mode through the user mode when the virtual machine (VM) calls a super call to the kernel mode. The first information is the information generated by the super call during the process of the VM calling the super call. The determining module is configured to determine the first state information of the VM based on the first information, wherein the first state information is the state information generated by the VM during the process of the VM calling the super call; The monitoring module is used to monitor the super call based on the first status information and the first information.

10. The apparatus according to claim 9, characterized in that, The kernel mode is equipped with a hook, and the acquisition module is used to capture the first information from the hook through the user mode.

11. The apparatus according to claim 9 or 10, characterized in that, The first information includes the timestamp at which the super call begins execution, and the determination module determines a time window, the time within the time window including the timestamp, and the first status information is the status information of the VM that is located within the time window among multiple status information of the VM.

12. The apparatus according to any one of claims 9-11, characterized in that, The monitoring module is used to determine whether the VM is abnormal based on the first state information of the VM; In the event of a VM malfunction, the super call is determined to be abnormal based on the first information.

13. The apparatus according to claim 12, characterized in that, The first information includes the call number of the super call, and the monitoring module is used to determine whether the super call is abnormal based on the call number of the super call.

14. The apparatus according to claim 12, characterized in that, The first information includes the process identifier of the super call, and the monitoring module is used for: The frequency of the super call is determined based on the process identifier of the super call; Based on the call frequency, determine whether the super call is abnormal.

15. The apparatus according to any one of claims 12-14, characterized in that, The monitoring module is used for: The first state information is sampled to obtain the second state information; The third state information is obtained by reconstructing information using the second state information, and the length of the time window of the third state information is the same as the length of the time window of the first state information. Based on the third state information and the first state information, determine whether the VM is abnormal.

16. The apparatus according to claim 12, characterized in that, The monitoring module is used for: The first state information and the first information are input into a pre-trained anomaly analysis model, which analyzes the first state information to determine whether the super call is abnormal. The anomaly analysis model is trained using sample state information, sample information, and label information. The sample state information is the state information generated by the VM when it calls the super call. The sample information is the information generated by the super call when the VM calls the super call. The label information is used to indicate whether the super call is abnormal and the reason for the VM's abnormality if the super call is abnormal.

17. A computing device, characterized in that, include: Memory, used to store executable code; A processor, when executing the executable code, implements the method of any one of claims 1-8.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed in a computer, causes the computer to perform the method described in any one of claims 1-8.

19. A computer program product containing instructions, characterized in that, When the instructions are executed on a computer, the computer causes the computer to perform the method as described in any one of claims 1-8.

Images