CN105701400A - Virtual machine platform safety control method and device - Google Patents

Abstract

The present application provides an embodiment of a security control method for a virtual machine platform. In this embodiment, a service virtual machine is divided into multiple minimum sub-service virtual machines, and several minimum sub-service virtual machines are combined to obtain at least two sub-service virtual machines. The connection between the user virtual machine and the service virtual machine is established according to the service call request of the user virtual machine, and after sub-service virtual machines are divided, the sub-service virtual machines are used to provide virtual services for the user virtual machine. It can be seen that, in this embodiment, the service virtual machine is divided into multiple sub-service virtual machines, and the sub-service virtual machines independently provide virtual services. From the perspective of trusted computing base, the separated sub-service virtual machine does not belong to the trusted computing base of the virtual machine platform, which reduces the trusted computing base and attack surface of the virtual machine platform, and realizes the user virtual machine and sub-service Two-way isolation between virtual machines improves the security of the virtual machine platform. The application also provides a security control device for a virtual machine platform.

Description

Security control method and device for a virtual machine platform

technical field

The present application relates to the field of virtual machine technology, in particular to a method and device for controlling security of a virtual machine platform.

Background technique

A virtual machine platform is a computer platform using virtualization technology. Among them, the virtualization technology is a resource management technology, which can simulate multiple hardware physical resources of a computer, such as a processor and a memory manager, for use by multiple operating systems. Although a virtual machine is not a real hardware resource, programs running on a virtual machine are like running on a real computer.

It should be noted that security is an important consideration of the virtual machine platform. However, the trusted computing base and attack surface of the current virtual machine platform are large, resulting in low security.

Contents of the invention

In view of this, the present application provides a security control method for a virtual machine platform to solve the technical problems in the prior art that the trusted computing base and attack surface of the virtual machine platform are large and the security is low. In addition, the present application also provides a security control device for a virtual machine platform to ensure the practical application and realization of the method.

In order to achieve said purpose, the technical scheme provided by the application is as follows:

The first aspect of the present application provides a security control method for a virtual machine platform, including:

Determine the service virtual machine in the virtual machine platform;

According to the minimum granularity separation algorithm, divide the service virtual machine into a plurality of minimum sub-service virtual machines; wherein, the services provided by each of the minimum sub-service virtual machines do not overlap;

Merging several minimum sub-service virtual machines according to preset merging rules to obtain at least two sub-service virtual machines; wherein each of the sub-service virtual machines independently provides virtual services;

When receiving a service invocation request from a user virtual machine in the virtual platform, in each of the sub-service virtual machines, determine a target sub-service virtual machine corresponding to the service invocation request;

Establishing a first connection with the target sub-service virtual machine and a second connection with the user virtual machine, the first connection and the second connection are used for the target sub-service virtual machine to virtualize for the user The virtual machine provides virtual services to ensure the two-way isolation between user virtual machines and sub-service virtual machines.

A second aspect of the present application provides a security control device for a virtual machine platform, the device comprising:

A service domain determination module, configured to determine the service virtual machine in the virtual machine platform;

The minimum virtual machine division module is configured to divide the service virtual machine into multiple sub-service virtual machines with the smallest service granularity according to the minimum granularity separation algorithm; wherein, the services provided by each of the minimum sub-service virtual machines do not overlap;

The smallest virtual machine merging module is used to merge several smallest sub-service virtual machines according to preset merging rules to obtain at least two sub-service virtual machines; wherein, each of the sub-service virtual machines independently provides virtual services;

A service request module, configured to, when receiving a service invocation request from a user virtual machine in the virtual platform, determine a target sub-service virtual machine corresponding to the service invocation request among each of the sub-service virtual machines;

A connection establishment module, configured to establish a first connection with the target sub-service virtual machine and a second connection with the user virtual machine, the first connection and the second connection are used for the target sub-service virtual machine The machine provides a virtual service for the user virtual machine, so as to realize bidirectional isolation between the user virtual machine and the sub-service virtual machine.

As can be seen from the above, the embodiment of the security control method for the virtual machine platform provided by the present application is used to enhance the security of the virtual machine platform, wherein the virtual machine platform includes a service virtual machine, and first divides the service virtual machine into A plurality of minimum sub-service virtual machines, combining several minimum sub-service virtual machines to obtain at least two sub-service virtual machines, and then establishing a connection with the user virtual machine and the service virtual machine according to the service call request of the user virtual machine, thereby realizing After the sub-virtual server machines are divided, the divided sub-service virtual machines are used to provide virtual services for user virtual machines. It can be seen that, in this embodiment, the service virtual machine is divided into multiple sub-service virtual machines, and each sub-service virtual machine independently provides virtual services. From the perspective of the trusted computing base, the separated sub-service virtual machines do not belong to the trusted computing base of the virtual machine platform, so this embodiment reduces the trusted computing base and attack surface of the virtual machine platform, and realizes The two-way isolation between user virtual machines and sub-service virtual machines improves the security of the virtual machine platform.

Of course, implementing any product of the present application does not necessarily need to achieve all the above-mentioned advantages at the same time.

Description of drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings that need to be used in the description of the embodiments or the prior art. Obviously, the accompanying drawings in the following description are only It is an embodiment of the present application, and those skilled in the art can also obtain other drawings according to the provided drawings without creative work.

FIG. 1 is a flow chart of Embodiment 1 of a security control method for a virtual machine platform provided by the present application;

Fig. 2 is the schematic diagram of the virtual machine platform provided by the present application;

FIG. 3 is a flow chart of Embodiment 2 of the security control method for the virtual machine platform provided by the present application;

FIG. 4 is a schematic diagram of a hypercall provided by the present application;

FIG. 5 is a schematic diagram of the separation of the service virtual machine provided by the present application;

FIG. 6 is a schematic structural diagram of Embodiment 1 of a security control device for a virtual machine platform provided by the present application;

FIG. 7 is a schematic structural diagram of Embodiment 2 of a security control device for a virtual machine platform provided by the present application.

detailed description

The following will clearly and completely describe the technical solutions in the embodiments of the application with reference to the drawings in the embodiments of the application. Apparently, the described embodiments are only some of the embodiments of the application, not all of them. Based on the embodiments in this application, all other embodiments obtained by persons of ordinary skill in the art without making creative efforts belong to the scope of protection of this application.

Referring to FIG. 1 , it shows the flow of Embodiment 1 of the security control method for a virtual machine platform provided by the present application. As shown in FIG. 1 , this embodiment may include step S101 to step S105.

Step S101: Determine the service virtual machine in the virtual machine platform.

Wherein, this embodiment is used to control the safe operation of the virtual machine platform. An example of the virtual machine platform is shown in FIG. 2 , which specifically includes: a service virtual machine, a user virtual machine, and a monitor. It should be noted that Embodiment 1 is applied to a monitor, so that the monitor can realize the function of controlling the safe operation of the virtual machine platform.

Wherein, the virtual machine platform shown in FIG. 2 may be Xen. Xen is a system virtual machine based on open source code, which can simultaneously run multiple operating system instances on a single physical machine. Xen includes a service virtual machine, and the service virtual machine may be called a service domain, or a management virtual machine (Domain0), or further referred to as Dom0 for short. In addition, Xen also includes a supervisory program (Hypervisor), which runs between the physical hardware device and the operating system, and can virtualize the physical hardware device into a virtual hardware resource used by multiple virtual machines.

The service virtual machine, as an extension of the hypervisor, can provide virtual services such as system management services and I/O resource virtualization. Specifically, the service virtual machine has hardware input and output devices and native drivers for these devices, which can be considered as a device driver domain. The user virtual machine does not have a physical hardware device, and it implements access to the physical hardware device by applying for services from the service virtual machine.

The service virtual machine carries many types of services, such as storage service, network service, and graphics card, etc., resulting in low security of the service virtual machine. Specifically, each service is provided by the same service virtual machine. If there is a problem with the service virtual machine, all services cannot be called, and the security is low. From the perspective of Trusted Computing Base, the service virtual machine as a whole becomes part of the TCB (Trusted Computing Base, Trusted Computing Base) of the virtual machine platform, resulting in a relatively large and bloated TCB of the virtual machine platform, a huge attack surface, and low security .

In order to improve this point, the monitor (ServiceVisor) provided in this application divides the service virtual machine, that is, divides the service virtual machine into multiple sub-service virtual machines, and the multiple sub-service virtual machines are independent of each other and provide virtual services respectively. In other words, each sub-service virtual machine contains all resources required to provide services by itself, and does not need to invoke other sub-service virtual machines when providing virtual services. The specific division method is as follows in steps S102 and S103.

Step S102: Divide the service virtual machine into multiple minimum sub-service virtual machines according to the minimum granularity separation algorithm; wherein, the services provided by each minimum sub-service virtual machine do not overlap.

Among them, the minimum granularity separation algorithm is used to divide an object into sub-objects of the smallest unit. In this application, the minimum granularity algorithm is used to divide the service virtual machine into the smallest unit of sub-service virtual machines. The smallest unit is reflected in the fact that there is no intersection between the services provided by each sub-service virtual machine and the service granularity is the smallest.

For example, using the minimum granularity separation algorithm, the service virtual machine is separated into three sub-service virtual machines, namely network virtual machine, storage virtual machine and log virtual machine, which are used to provide network service, storage service and log service respectively. However, a network virtual machine cannot provide any storage and log services; a storage virtual machine cannot provide any network and log services; and a log virtual machine cannot provide any network and storage services. Of course, the three sub-service virtual machines in this example are just examples. In practical applications, the separated sub-service virtual machines are not limited to the three sub-service virtual machines. Other numbers of sub-service virtual machines can also be used. Can be other types.

In this separation method, the separated sub-service virtual machines provide a single service, and the crash of any sub-service virtual machine will not affect other sub-service virtual machines, so the security of the virtual platform is relatively high.

Step S103: Merge several smallest sub-service virtual machines according to preset merging rules to obtain at least two sub-service virtual machines; wherein each sub-service virtual machine independently provides virtual services.

Wherein, the preset merging rule is a preset rule, which includes the smallest sub-service virtual machine for merging. It should be noted that the minimum sub-service virtual machine is a sub-service virtual machine separated according to the minimum separation algorithm.

For example, the default merging rule is to merge the log virtual machine and the storage virtual machine, wherein the log virtual machine and the storage virtual machine are the smallest sub-service virtual machines.

Of course, the minimum sub-service virtual machines for merging are not limited to two, and may be any number set according to actual conditions. However, it should be noted that the number of sub-service virtual machines after merging is at least two, so as to ensure that the service virtual machine is separated into multiple sub-service virtual machines.

The preset merge rules need to meet the security policy. That is to say, the merged sub-service virtual machine meets the security requirements of the virtual machine platform application scenario. For example, the virtual machine platform is applied in a network environment and can be accessed by external devices. The network environment requires the security of stored data, therefore, network virtual machines cannot be combined with storage virtual machines.

Step S104: When receiving a service invocation request from a user virtual machine in the virtual platform, among each sub-service virtual machine, determine a target sub-service virtual machine corresponding to the service invocation request.

Wherein, the monitor can realize isolation between divided sub-service virtual machines and user virtual machines, thereby further improving the security of the virtual machine platform.

As shown in Figure 2, the virtual machine platform includes not only service virtual machines, but also user virtual machines. The operation of the user virtual machine needs to use the virtual service provided by the service virtual machine, such as using the network service provided by the service virtual machine.

When the monitor receives the service invocation request sent by the user virtual machine, the monitor determines the sub-service virtual machine corresponding to the service invocation request type among multiple sub-service virtual machines according to the type of the service invocation request. For the convenience of description, The determined sub-service virtual machine is called a target sub-service virtual machine. For example, if a user virtual machine wants to request a network service, the target sub-service virtual machine determined by the monitor is a network virtual machine.

Step S105: Establish a first connection with the target sub-service virtual machine and a second connection with the user virtual machine, the first connection and the second connection are used for the target sub-service virtual machine to provide virtual services for the user virtual machine.

Wherein, the monitor may establish two connections, which are respectively connections with the target sub-service virtual machine and the user virtual machine, which are respectively referred to as a first connection and a second connection for ease of description. The data sent by the user virtual machine to the target sub-service virtual machine is sent to the monitor, and the monitor forwards the data to the target sub-service virtual machine. Similarly, the data sent by the target sub-service virtual machine to the user virtual machine is also forwarded by the monitor.

In the prior art, the user virtual machine directly sends a service call request to the service virtual machine. However, in this application, the service virtual machine is divided into multiple sub-service virtual machines, and the user virtual machine does not directly interact with the sub-service virtual machines. , but forwarded to the monitor, realizing the two-way isolation between the sub-service virtual machine and the user virtual machine, so that the security of the virtual machine platform can be further improved.

It can be seen from the above technical solutions that the embodiment of the security control method for the virtual machine platform provided by the present application is used to control the security of the virtual machine platform, wherein the virtual machine platform includes a service virtual machine, and the service virtual machine is first separated according to the minimum granularity separation algorithm. The machine is divided into multiple minimum sub-service virtual machines, and several minimum sub-service virtual machines are combined to obtain at least two sub-service virtual machines, and then the connection between the user virtual machine and the service virtual machine is established according to the service call request of the user virtual machine , so as to achieve the purpose of providing virtual services for user virtual machines by using the divided sub-service virtual machines after dividing the sub-virtual server machines. It can be seen that, in this embodiment, the service virtual machine is divided into multiple sub-service virtual machines, and each sub-service virtual machine independently provides virtual services. From the perspective of the trusted computing base, the separated sub-service virtual machines do not belong to the trusted computing base of the virtual machine platform, so this embodiment reduces the trusted computing base and attack surface of the virtual machine platform, thus improving the virtual machine platform. machine platform security.

To put it simply, this embodiment separates various services integrated on the same service virtual machine and distributes them on different sub-service virtual machines, so as to avoid the situation that all services are affected due to a failure of a service virtual machine. Therefore, the security of the virtual machine platform is improved.

The service type provided by the service virtual machine is determined by the configuration file. The specific process of dividing the service virtual machine can be: obtain the configuration file of the service virtual machine, obtain various types of services provided by the service virtual machine from the configuration file, and divide the multiple Each type of service is divided into multiple service collections.

Specifically, each type of service can be used as a service set, or multiple types of services can be used as a service set, and at least two service sets can be obtained after division. A respective configuration file is generated for each service collection, and a respective sub-service virtual machine is created for each service collection according to the configuration file.

Of course, in practical applications, some separated sub-service virtual machines are not frequently used, and the above separation method may cause waste of resources. Therefore, the present application may also shut down or merge some of the separated sub-service virtual machines, specifically as follows in steps A1 and A2.

Step A1: If a certain sub-service virtual machine is in a standby state, shut down a certain sub-service virtual machine.

Wherein, after the monitor separates the sub-service virtual machines, each sub-service virtual machine may be started. Wherein, after some sub-service virtual machines are started, they may not be frequently used, and at this time, the sub-service virtual machines are considered to be in a standby state.

The manner in which the sub-service virtual machine provides the service is that the sub-service virtual machine sends service data to the service request object. Therefore, the manner of determining that the sub-service virtual machine is in the standby state may be that the monitor obtains the service data sent by the sub-service virtual machine, and if the amount of service data sent is less than a certain threshold, the sub-service virtual machine may be considered to be in the standby state.

If it is detected that a sub-service virtual machine is in a standby state, the sub-service virtual machine is shut down. Of course, if the sub-service virtual machine is in a standby state, step A2 may also be performed.

Step A2: If a certain sub-service virtual machine is in a standby state, merge the certain sub-service virtual machine with other sub-service virtual machines.

Wherein, the monitor may shut down the sub-service virtual machine to release resources occupied by the sub-service virtual machine. Alternatively, the monitor may merge the sub-service virtual machine with other sub-service virtual machines, and provide the resources occupied by the sub-service virtual machine for use by other sub-service virtual machines. It should be noted that the merged sub-service virtual machine becomes a sub-service virtual machine.

For example, if the network virtual machine is in a standby state, the network virtual machine may be shut down, or the network virtual machine and the log virtual machine may be merged.

The virtual machine platform includes multiple virtual machines, and the virtual machines cannot directly access physical resources other than the virtual machine, including the hypervisor itself. However, the virtual machine can apply for various services from the hypervisor through hypercalls (Hypercalls). A hypercall is like a system call in an operating system through which a hypervisor provides various services to individual virtual machines.

The plurality of sub-service virtual machines divided by this application, together with the user virtual machines, can all be used as the virtual machines for the above-mentioned application hypercall. These virtual machines do not have permission control, and can send hypercalls at will to call various types of physical resources. Therefore, the hypercall sent by the virtual machine may apply for physical resources beyond its own functions. In this case, it is necessary to control the permission of the hypercall of the virtual machine.

Specifically, refer to FIG. 3 , which shows the flow of Embodiment 2 of the security control method for a virtual machine platform. On the basis of Embodiment 1 of the above-mentioned security control method for a virtual machine platform, step S106 and step S107 may also be included. It should be noted that steps S101 to S105 in this embodiment are the same as steps S101 to S105 in FIG. 1 above, and will not be repeated here, only steps S106 and S107 will be described.

Step S106: When a hypercall request is detected, determine whether the invoking virtual machine sending the hypercall request has the corresponding authority; if so, execute step S107.

Wherein, the monitor may receive a hypercall request, which is sent by each virtual machine in the virtual machine platform, which may be a user virtual machine or a sub-service virtual machine. For ease of description, the virtual machine that sends the hypercall may be referred to as the calling virtual machine.

It is judged whether the invoking virtual machine has the authority to send the hypercall request, and if so, step S107 is executed. If not, reject the hypercall request of the invoking virtual machine.

Step S107: Provide the calling virtual machine with a service corresponding to the hypercall request.

The above solutions can be described in conjunction with the hypercall example shown in FIG. 4 .

As shown in FIG. 4 , DomS ₁ and DomS _m are service virtual machines, and DomU ₁ and DomU _m are user virtual machines. These virtual machines are subjects for sending hypercall requests, that is, calling virtual machines.

The access control point 1 can receive different types of hypercall requests (hypercalls) sent by the calling virtual machine, but after the judgment of the access control point 1, only the hypercall request corresponding to the function of the calling virtual machine will be accepted. Sent to Access Control Point 2. The access control point 2 performs follow-up security control on the hypercall request. The follow-up security control includes the access control decision implemented by the Flask security module, etc. The security control of the access control point 2 is a prior art and will not be described here.

The above solution is based on the principle of least privilege, and realizes the security control requirements of the virtual machine platform.

In practical applications, a specific manner of dividing service virtual machines can be referred to in FIG. 5 . As shown in Figure 5, the service virtual machine Dom0 can be divided into the following sub-service virtual machines:

(1) Device Model Domain (DeviceModelDomain): The device model is an important part of Xen hardware virtualization. It runs as a process in the user space of Dom0 and is responsible for providing IO device simulation for HVM (hardware virtual machine). The main reasons for separating it from Dom0 are: 1) Poor isolation. Since each HVM corresponds to a device model daemon process in Dom0, the IO isolation problem between HVMs becomes an isolation between two processes. Isolation problem, however, the isolation between processes is weak, and the crash of one process may cause the crash of another process, therefore, the isolation between HVMs cannot be guaranteed; 2) The performance is low, and the device model daemon is in Dom0 Being scheduled as a process, it is obvious that it cannot respond to HVM's request for IO operations in a timely manner, resulting in reduced performance of HVM; 3) Higher privileges, because the device model provides IO device simulation for HVM, so it has higher access to hardware devices, etc. Access rights, if it is attacked by malware, will cause greater harm. It is separated from Dom0 to form a mini device model domain, and one HVM corresponds to one device model domain, thus solving the above problems.

(2) Network virtual machine (NetWorkDomain): The network device located in Dom0 provides network services for customer virtual machines. The main reasons for separating it from Dom0 are: 1) The network driver is relatively large and vulnerable to network traffic. Malicious user's attack, if it crashes or is attacked, may lead to the collapse of Dom0, and then lead to the collapse of the entire virtual machine system; Network requests cannot be processed in time, especially when multiple clients access requests at the same time, this problem is particularly obvious.

(3) Device Driver Domain (DeviceDriverDomain): This domain mainly manages peripherals for the virtual system, and provides peripheral services for other user domains at the same time. The necessity of its existence lies in: 1) When adding a new dedicated peripheral, if the peripheral driver is loaded into the original Dom0 kernel, the Dom0 kernel space may be unstable or directly crashed due to the instability or error of the driver; 2 ) to enhance the isolation between virtual machines, the device-related domain and the device-independent domain can be isolated through the device driver domain, and at the same time, the access rights of peripherals can be controlled more flexibly.

(4) Monitor information storage virtual machine (XenStoreServiceDomian): XenStore is a hierarchical inter-domain shared storage system in the Xen virtual machine system that stores information such as virtual machine configuration and status in the form of key-value pairs. It is mainly maintained by Dom0 . Since Xenstore is the storage center of the state information of all service domains and user domains in the entire virtual machine system, and the virtualization of all components or modules in the system depends on it, its security and performance directly affect the security of the entire system and performance. In the Xen architecture, XenStore runs in Dom0 in the form of a process, and communicates with other virtual machines in the form of a shared memory ring, and the management of the full life cycle of the virtual machine depends on the support of XenStore, so its It is vulnerable to attacks such as denial of service.

(5) Virtual machine information storage virtual machine (StorageDomain): store images and data of other service domains and user domains, and ensure their integrity and confidentiality.

(6) System boot virtual machine (SystemBootDomain): guide the entire virtual machine system and create related service domains.

(7) Log service virtual machine (LogServiceDomain): Record the behavior and logs of other service domains or user domains, and audit the information at the same time to provide security reports for administrators.

(8) Migration service virtual machine (MigrationServiceDomain): This service domain provides services for migrating user domains. Because it can map the memory of other user domains, in order to ensure the security of the system, it only needs to migrate user domains when the system needs to migrate. Let the service domain run.

(9) Virtual Domain Build Virtual Machine (VirtualDomainBuildDomain): This domain mainly provides services for booting virtual domain startup. Because it can map user domain memory and provide initial startup information for virtual domains, it has high privileges, so it Separating Dom0 and using Mini-OS to host the service can effectively reduce the trusted computing base of the entire virtual machine system, and at the same time enable more fine-grained control of its privileged operations.

(10) External device configuration management virtual machine (PCIConfigureManagerDomain): mainly responsible for managing and configuring PCI devices when the virtual machine system starts, and providing PCI configuration support for the next step of service domain separation.

(11) Monitor management tool virtual machine (ToolDomain): mainly provides an interface for users to manage virtual domains of users.

In addition, two supplementary explanations are made on the technical solutions in this application.

(1) XenStore only records the relevant configuration information that the user domain depends on ServiceVisor (monitor) and the monitor depends on the service domain (service virtual machine), and both the user domain (user virtual machine) and the service domain can only pass XenStore to obtain the configuration information they need. Therefore, in the virtual machine platform provided by this application, ServiceVisor, the user domain, and the service domain can see each other, but the user domain and the service domain do not know the existence of each other, that is, from the perspective of the user domain, it cannot tell whether its operating environment is The Xen virtual machine platform is also the SecXen virtual machine platform. It ensures the trouble-free migration of virtual machines between SecXen and Xen, and isolates the attack flow between the service domain and the user domain, thus realizing the two-way shielding of the service domain and the user domain.

(2) The monitor mainly coordinates the relationship between the sub-service virtual machine and the user virtual machine, and coordinates the relationship between the sub-service virtual machine and the Hypervisor.

The following is an introduction to the security control device and the virtual machine platform of the virtual machine platform provided by this application. It should be noted that, for the description of the security control device and the virtual machine platform of the virtual machine platform, reference can be made to the security control of the virtual machine platform provided above. method, which will not be described in detail below.

It should be noted that the security control device of the virtual machine platform is the aforementioned monitor.

Referring to FIG. 6 , it shows the structure of Embodiment 1 of the security control device for the virtual machine platform. As shown in FIG. 6, the security control device of the virtual machine platform may include: a service domain determination module 601, a minimum virtual machine division module 602, a minimum virtual machine merging module 603, a service request module 604, and a connection establishment module 605; wherein:

A service domain determining module 601, configured to determine a service virtual machine in a virtual machine platform;

The minimum virtual machine division module 602 is configured to divide the service virtual machine into multiple minimum sub-service virtual machines according to the minimum granularity separation algorithm; wherein, the services provided by each minimum sub-service virtual machine do not overlap;

The smallest virtual machine merging module 603 is configured to merge several smallest sub-service virtual machines according to preset merging rules to obtain at least two sub-service virtual machines; wherein, each sub-service virtual machine independently provides virtual services;

The service request module 604 is configured to determine the target sub-service virtual machine corresponding to the service invocation request in each sub-service virtual machine when receiving a service invocation request from a user virtual machine in the virtual platform;

The connection establishment module 605 is configured to establish a first connection with the target sub-service virtual machine and a second connection with the user virtual machine, the first connection and the second connection are used for the target sub-service virtual machine to provide virtual services for the user virtual machine.

It can be seen from the above that the minimum virtual machine division module 602 in the security control device of the virtual machine platform divides the service virtual machine into multiple minimum sub-service virtual machines according to the minimum granularity separation algorithm, and the minimum virtual machine merging module 603 divides several minimum sub-service virtual machines Machines are combined to obtain at least two sub-service virtual machines, and the service request module 604 and connection establishment module 605 can establish a connection with the user virtual machine and the service virtual machine according to the service call request of the user virtual machine, so as to realize the division of sub-virtual services After the virtual machine is installed, the purpose of providing virtual services for the user virtual machine is to use the divided sub-service virtual machine. It can be seen that, in this embodiment, the service virtual machine is divided into multiple sub-service virtual machines, and each sub-service virtual machine independently provides virtual services. From the perspective of the trusted computing base, the separated sub-service virtual machines do not belong to the trusted computing base of the virtual machine platform, so this embodiment reduces the trusted computing base of the virtual machine platform, thereby improving the reliability of the virtual machine platform. safety.

To put it simply, this embodiment separates various services integrated on the same service virtual machine and distributes them on different sub-service virtual machines, so as to prevent all services from being affected due to problems in the service virtual machine, thereby improving virtual machine platform security.

Specifically, the security control device of the virtual machine platform may further include: a sub-virtual machine closing module or a sub-virtual machine merging module, or both.

The sub-virtual machine shutdown module is used to shut down a sub-service virtual machine if a sub-service virtual machine is in a standby state;

The sub-virtual machine merging module is configured to merge a sub-service virtual machine with other sub-service virtual machines if a sub-service virtual machine is in a standby state.

Corresponding to Embodiment 2 of the above-mentioned security control method for a virtual machine platform, the present application provides a second embodiment of a security control device for a virtual machine platform. As shown in FIG. 7, on the basis of Embodiment 1 of the security control device of the virtual machine platform in this embodiment, the device may further include: a hypercall request module 606 and a hypercall service module 607; wherein:

The hypercall request module 606 is used to determine whether the calling virtual machine sending the hypercall request has corresponding authority when a hypercall request is detected; if so, trigger the hypercall service module;

The hypercall service module 607 is configured to provide the calling virtual machine with a service corresponding to the hypercall request.

Specifically, in the security control device of the virtual machine platform, each sub-service virtual machine is respectively:

Device model virtual machine, network virtual machine, device driver virtual machine, monitor information storage virtual machine, virtual machine information storage virtual machine, system boot virtual machine, log service virtual machine, migration service virtual machine, virtual domain construction virtual machine, external The device configuration management virtual machine and the monitor management tool virtual machine.

It should be noted that each embodiment in this specification is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. For the same and similar parts in each embodiment, refer to each other, that is, Can.

It should also be noted that in this article, relational terms such as first and second etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply that these entities or operations Any such actual relationship or order exists between. Furthermore, the term "comprises", "comprises" or any other variation thereof is intended to cover a non-exclusive inclusion such that a process, method, article, or apparatus comprising a set of elements includes not only those elements, but also includes elements not expressly listed. other elements of or also include elements inherent in such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising a" does not preclude the presence of additional same elements in a process, method, article or apparatus comprising the aforementioned element.

The above description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the application. Therefore, the present application will not be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims (8)

1. A security control method for a virtual machine platform, comprising: Determine the service virtual machine in the virtual machine platform; According to the minimum granularity separation algorithm, divide the service virtual machine into a plurality of minimum sub-service virtual machines; wherein, the services provided by each of the minimum sub-service virtual machines do not have an intersection and the service granularity is the smallest; Merging several minimum sub-service virtual machines according to preset merging rules to obtain at least two sub-service virtual machines; wherein each of the sub-service virtual machines independently provides virtual services; When receiving a service invocation request from a user virtual machine in the virtual platform, in each of the sub-service virtual machines, determine a target sub-service virtual machine corresponding to the service invocation request; Establishing a first connection with the target sub-service virtual machine and a second connection with the user virtual machine, the first connection and the second connection are used for the target sub-service virtual machine to virtualize for the user The virtual machine provides virtual services to realize two-way isolation between user virtual machines and sub-service virtual machines. 2. The security control method of the virtual machine platform according to claim 1, further comprising: If a certain sub-service virtual machine is in a standby state, shutting down the certain sub-service virtual machine; or, If a certain sub-service virtual machine is in a standby state, the certain sub-service virtual machine is merged with other sub-service virtual machines. 3. The security control method of the virtual machine platform according to claim 1, further comprising: When a hypercall request is detected, it is judged whether the calling virtual machine sending the hypercall request has corresponding authority; If so, provide the calling virtual machine with a service corresponding to the hypercall request. 4. the security control method of virtual machine platform according to claim 1, is characterized in that, each described sub-service virtual machine is respectively: Device model virtual machine, network virtual machine, device driver virtual machine, monitor information storage virtual machine, virtual machine information storage virtual machine, system boot virtual machine, log service virtual machine, migration service virtual machine, virtual domain construction virtual machine, external The device configuration management virtual machine and the monitor management tool virtual machine. 5. A security control device for a virtual machine platform, characterized in that the device comprises: A service domain determination module, configured to determine the service virtual machine in the virtual machine platform; The minimum virtual machine division module is configured to divide the service virtual machine into a plurality of minimum sub-service virtual machines according to the minimum granularity separation algorithm; wherein, the services provided by each of the minimum sub-service virtual machines do not have intersection and the service granularity is the smallest ; The smallest virtual machine merging module is used to merge several smallest sub-service virtual machines according to preset merging rules to obtain at least two sub-service virtual machines; wherein, each of the sub-service virtual machines independently provides virtual services; A service request module, configured to, when receiving a service invocation request from a user virtual machine in the virtual platform, determine a target sub-service virtual machine corresponding to the service invocation request among each of the sub-service virtual machines; A connection establishment module, configured to establish a first connection with the target sub-service virtual machine and a second connection with the user virtual machine, the first connection and the second connection are used for the target sub-service virtual machine The machine provides a virtual service for the user virtual machine, so as to realize bidirectional isolation between the user virtual machine and the sub-service virtual machine. 6. The security control device for a virtual machine platform according to claim 5, further comprising: a sub-virtual machine closing module and/or a sub-virtual machine merging module; A sub-virtual machine shutdown module, configured to shut down a certain sub-service virtual machine if the sub-service virtual machine is in a standby state; The sub-virtual machine merging module is configured to merge a certain sub-service virtual machine with other sub-service virtual machines if the sub-service virtual machine is in a standby state. 7. The security control device of the virtual machine platform according to claim 5, further comprising: The hypercall request module is used to determine whether the calling virtual machine that sends the hypercall request has the corresponding authority when a hypercall request is detected; if so, trigger the hypercall service module; The hypercall service module is configured to provide the calling virtual machine with a service corresponding to the hypercall request. 8. The security control device of a virtual machine platform according to claim 5, wherein each of the sub-service virtual machines is: Device model virtual machine, network virtual machine, device driver virtual machine, monitor information storage virtual machine, virtual machine information storage virtual machine, system boot virtual machine, log service virtual machine, migration service virtual machine, virtual domain construction virtual machine, external The device configuration management virtual machine and the monitor management tool virtual machine.