A hybrid secure virtualization method for cross-platform operating systems

Abstract

The application belongs to the technical field of computer system software, and particularly relates to a hybrid security virtualization method of a cross-platform operating system, which is realized based on a semi-virtualization system architecture; the semi-virtualization system architecture comprises a front-end driver layer, a back-end device layer and a transmission layer; a virtual queue is created by the front-end driver layer and is used for shared memory of data transmission; wherein the back-end device layer obtains an I / O request submitted by the front-end driver layer through the shared memory. The application can complete the interaction process between front-end devices and back-end devices by using a common framework and a standard interface protocol, so that a set of interfaces can be defined for each device to avoid the same work logic of different virtual machines, and the virtual machine monitors of different back-ends can be independently developed to avoid the same implementation mode and reduce the compatibility problems caused by cross-platforms.

Description

Technical Field

[0001] This invention belongs to the technical field of computer system software, specifically relating to a hybrid secure virtualization method for cross-platform operating systems. Background Technology

[0002] In computing's physical resources, peripheral resources are limited. To meet the needs of multiple guest operating systems, the virtual machine monitor (VM) must reuse these limited external resources through I / O virtualization. The VM intercepts guest operating systems' access requests to I / O devices and then simulates real hardware through software. The I / O device virtualization method uses paravirtualization, which, with the assistance of underlying hardware, performs some unnecessary virtualization instructions through hardware. The hypervisor only needs to handle the virtualization of a portion of these instructions. This requires the cooperation of the guest operating systems. The guest implements the front-end drivers for different devices, while the hypervisor cooperates with the guest to implement the corresponding back-end drivers. This interaction mechanism enables an efficient virtualization process. However, the working logic of different guest front-end devices is largely similar, and the implementation of the back-end hypervisor is also largely similar, typically defining a separate interface for each device or using different frameworks. This fails to meet requirements for efficient development and strong compatibility. Summary of the Invention

[0003] In view of this, in order to solve the compatibility and development efficiency problems caused by cross-platform operating systems and various Hypervisor virtualization devices, this invention provides a hybrid secure virtualization method for cross-platform operating systems. It is based on a general framework and standard interfaces (protocols) to complete the interaction, which solves the problem of non-compatibility between various Hypervisor virtualization devices after cross-platform integration, and improves the development efficiency and compatibility of guest operating systems.

[0004] To achieve the above-mentioned technical objectives, the specific technical solution adopted by the present invention is as follows:

[0005] A hybrid secure virtualization method for cross-platform operating systems, the virtualization method being implemented based on a paravirtualization system architecture; the paravirtualization system architecture includes: The front-end driver layer consists of drivers for the virtio emulation devices inside the virtual machine. These drivers are used to discover virtio devices, receive requests from inside the virtual machine, and communicate with the virtio emulation devices according to the virtio protocol. The backend device layer is used to simulate virtio backend devices, specifically: processing requests from virtual machines according to the virtio protocol; A transport layer is located between the front-end driver layer and the back-end device layer; the transport layer is used to support data communication between the virtual machine and the Hypervisor virtual device; the transport layer implements data transmission between the front-end driver layer and the back-end device layer based on a virtual queue. Wherein: the virtual queue is created by the front-end driver layer and is used as shared memory for data transmission; the back-end device layer obtains I / O requests submitted by the front-end driver layer through the shared memory.

[0006] Furthermore, the semi-virtualized system architecture uses a front-end and back-end communication mechanism, runs the driver in a virtual machine, and interacts with the back-end Hypervisor virtual device through a virtual queue.

[0007] Furthermore, the virtual queue is implemented through vring, which is a circular buffer shared between the virtual machine and the backend device; vring consists of three parts: a descriptor table, an available ring, and a used ring.

[0008] Furthermore, the descriptor table is used to store associated descriptors, with each descriptor recording a description of the buffer; Furthermore, the ring can be used to store the descriptor table provided by the front-end driver to the back-end device, and the descriptor table can be used by the back-end device layer. The used ring is used to store descriptor tables that have been processed by the backend processing program in the backend device layer but have not yet been fed back to the frontend driver layer.

[0009] Furthermore, the method for data communication between the front-end driver layer and the back-end device layer includes the following steps: S101: When the virtual machine needs to send a request to the backend device layer, after preparing the data, put the data descriptor table into the availability ring, and then write the configuration notification to the backend device layer. S102: The backend device layer reads request information from the available ring and reads data from the shared memory; S103: After the backend device completes the request, it stores the response status in the used ring; the frontend driver layer obtains the request completion information from the used ring and retrieves the request data. Furthermore, in the backend device layer, each device is configured with the required number of virtual queues according to its needs; the frontend driver layer initiates a request to the backend device layer through the descriptor table pointed to by the available ring; the backend device layer parses the driver request from the frontend driver layer through the available ring, and then provides the driver of the frontend driver layer with the processed result of the request request through the used ring.

[0010] Furthermore, the device is configured based on a first driver on the first platform and a second driver on the second platform; when the device is extended from the first platform to the second platform, the semi-virtualized system architecture upgrades the first driver to the second driver in the second platform.

[0011] The beneficial effects of this invention are as follows: This invention completes the interaction based on a general framework and standard interfaces (protocols), which solves the problem of incompatibility between various Hypervisor virtualization devices after cross-platform integration, and improves the development efficiency and compatibility of guest operating systems. Attached Figure Description

[0012] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 shows the VIRTIO semi-virtualization system architecture; Figure 2 shows the VIRTIO protocol architecture; Figure 3 shows the VIRTIO data transmission flow; Figure 4 shows the data flow of the descriptor table; Figure 5 is a diagram of the virtual network data flow; Figure 6 is a flowchart of the data sending and receiving process of the virtual network interface card (NIC) device. Detailed Implementation

[0014] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0015] The following specific examples illustrate the implementation of this disclosure. Those skilled in the art can easily understand other advantages and effects of this disclosure from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. This disclosure can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this disclosure. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0016] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using other structures and / or functionalities besides one or more of the aspects set forth herein.

[0017] It should also be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this disclosure. The drawings only show the components related to this disclosure and are not drawn according to the number, shape and size of the components in actual implementation. In actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0018] Furthermore, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that the described aspects can be practiced without these specific details.

[0019] In one embodiment of the present invention, a hybrid secure virtualization method for cross-platform operating systems is proposed, such as... Figures 1-6 As shown, the virtualization method is implemented based on a semi-virtualized system architecture; the semi-virtualized system architecture includes: The front-end driver layer consists of drivers for the virtio emulation devices inside the virtual machine. These drivers are used to discover virtio devices, receive requests from inside the virtual machine, and communicate with the virtio emulation devices according to the virtio protocol. The backend device layer is used to simulate virtio backend devices, specifically: processing requests from virtual machines according to the virtio protocol; A transport layer is located between the front-end driver layer and the back-end device layer; the transport layer is used to support data communication between the virtual machine and the Hypervisor virtual device; the transport layer implements data transmission between the front-end driver layer and the back-end device layer based on a virtual queue. Wherein: the virtual queue is created by the front-end driver layer and is used as shared memory for data transmission; the back-end device layer obtains I / O requests submitted by the front-end driver layer through the shared memory.

[0020] In this embodiment, the semi-virtualized system architecture uses a front-end and back-end communication mechanism, runs the driver in a virtual machine, and interacts with the back-end Hypervisor virtual device through a virtual queue.

[0021] In this embodiment, the virtual queue is implemented through vring, which is a circular buffer shared between the virtual machine and the backend device; vring consists of three parts: descriptor table, available ring, and used ring.

[0022] In this embodiment, the descriptor table is used to store associated descriptors, and each descriptor records a description of the buffer; In this embodiment, the available ring can be used to store the descriptor table provided by the front-end driver to the back-end device, and the descriptor table can be used by the back-end device layer. In this embodiment, the used ring is used to store the descriptor table that has been processed by the backend processing program in the backend device layer but has not yet been fed back to the frontend driver layer.

[0023] In this embodiment, the method for data communication between the front-end driver layer and the back-end device layer includes the following steps: S101: When the virtual machine needs to send a request to the backend device layer, after preparing the data, put the data descriptor table into the availability ring, and then write the configuration notification to the backend device layer. S102: The backend device layer reads request information from the available ring and reads data from the shared memory; S103: After the backend device completes the request, it stores the response status in the used ring; the frontend driver layer obtains the request completion information from the used ring and retrieves the request data. In this embodiment, in the backend device layer, each device configures the required number of virtual queues according to its needs; the frontend driver layer initiates a request to the backend device layer through the descriptor table pointed to by the available ring; the backend device layer parses the driver request from the frontend driver layer through the available ring, and then the backend device layer provides the driver of the frontend driver layer with the processed result of the request request through the used ring.

[0024] The device is configured based on a first driver on the first platform and a second driver on the second platform; when the device is extended from the first platform to the second platform, the semi-virtualized system architecture upgrades the first driver to the second driver in the second platform.

[0025] The virtualization method involved in this embodiment includes a semi-virtualized I / O device virtualization method, a communication framework and programming interface between upper-layer applications and various Hypervisor virtualization devices, and a virtio transport protocol. The system architecture is illustrated below. Figure 1 As shown, the transmission protocol architecture is as follows Figure 2 As shown.

[0026] This embodiment proposes an I / O paravirtualization solution—VIRTIO. It abstracts a set of general-purpose I / O devices in a paravirtualized hypervisor and designs a set of general-purpose I / O device virtualization programs. VIRTIO provides a communication framework and programming interface between upper-layer applications and various hypervisor virtualization devices (KVM, Xen, VMware), which can reduce compatibility issues caused by cross-platform compatibility and improve driver development efficiency. A technical solution for a hybrid secure virtualization method for cross-platform operating systems includes: 1. VirtIO protocol architecture Based on the data transmission process, this invention adopts a three-layer protocol architecture: front-end driver, transport layer, and back-end device, with the following structural relationship: Figure 2 As shown, each layer is composed of the following components: Front-end driver: refers to the driver corresponding to the virtio emulation device inside the virtual machine. Its main function is to discover virtio devices, receive requests from inside the virtual machine, and communicate with virtio devices according to the virtio protocol. Transport layer: Located between the front-end driver and the back-end device, it supports data communication between the virtual machine and the Hypervisor virtual device. The virtio transport layer uses virtual methods to transmit data. The virtual queue is a shared memory created by the virtio virtual machine front-end driver for data transmission. The back-end processing program obtains I / O requests submitted by the front-end device through this shared memory. Backend devices: The main functions of backend devices can be divided into two parts: one is to simulate virtio backend devices, and the other is to process requests sent from the virtual machine according to the virtio protocol.

[0027] 2. virtio data structure virtio uses a front-end / back-end communication mechanism, running the virtio device driver within the virtual machine and interacting with the back-end Hypervisor virtual device through the virtio virtual queue. The virtio virtual queue is implemented using a vring, which is a circular buffer shared between the virtual machine and the back-end device. The vring consists of three parts: a descriptor table, an available ring, and a used ring.

[0028] Descriptor table: Used to store some associated descriptors, each descriptor records a description of the buffer; Available ring: Used to store descriptors provided by the front-end driver to the back-end device, and these descriptors can be used by the back-end device; Used ring: Used to store descriptors that have been processed by the backend handler but have not yet been fed back to the frontend driver.

[0029] When a virtual machine needs to send a request to a backend device, it must prepare the data, place the data descriptor in the Available Ring, and write the configuration to notify the backend device. Then, the backend device can read the request information from the Available Ring and retrieve the data from shared memory. After the backend device completes the request, it stores the response status in the Used Ring, and the frontend driver can then obtain the request completion information and retrieve the requested data from the Used Ring. The data transmission process is as follows: Figure 3 As shown.

[0030] The mechanism for bulk transfers on virtual devices is called a virtqueue. Each device can have zero or more virtqueues. The Virtio driver initiates a request to the virtio device through the descriptor ring pointed to by the available ring. The virtio device parses the driver's request through the available ring, and then provides the driver with the processed result of the request through the used ring.

[0031] Descriptor Table The descriptor table refers to the buffer of the device that the driver is using.

[0032] struct vring_desc { / Address (guest-physical). / UINT64 addr; / Length. / UINT32 len; / The flags are as indicated above. / UINT16 flags; / We chain unused descriptors via this, too / UINT16 next; }; addr: The physical address of Guest.

[0033] len: The length of the buffer.

[0034] next: All buffers are linked together through next to form a descriptor table.

[0035] The flag values ​​include: VRING_DESC_F_NEXT: Indicates whether the next field of the current buffer is valid, and indirectly indicates whether the current buffer is the last in the buffer list; VRING_DESC_F_WRITE: Indicates whether the current buffer is read-only or write-only; VRING_DESC_F_INDIRECT: Indicates that this buffer contains a list of buffer descriptors. Each descriptor describes a buffer that is either read-only or write-only to the device, but the descriptor chain can contain both readable and writable buffers.

[0036] Available Ring A ring pointer can be used to point to the descriptor provided by the Guest to the device, which points to the head of a linked list of descriptors.

[0037] struct vring_avail { UINT16 flags; UINT16 idx; UINT16 ring[ / queue size / ]; / / UINT16 used_event; }; The driver provides buffers to the device using available rings. Each ring entry points to the head of a descriptor chain, which is written only by the driver and read by the device.

[0038] The idx field indicates the position in the ring where the driver will place the next descriptor entry (modulo the queue size), i.e., the position of the next descriptor entry, which starts from 0 and increments.

[0039] Used Ring The buffer that has been used by the device (Host) using the ring pointer.

[0040] struct vring_used { UINT16 flags; UINT16 idx; struct vring_used_elem ring[ / queue size / ]; / / UINT16 avail_event; }; struct vring_used_elem { / Index of start of used descriptor chain. / UINT32 id; / Total length of the descriptor chain which was used (written to) / UINT32 len; }; The used ring is where the device returns to the buffers after use. It is only written to by the device and read by the driver. The flag is used by the device to tell the guest not to trigger a kick operation when adding a buffer to the available ring again. Each entry in the ring is a pair: id represents the head entry of the descriptor chain describing the buffer, which is consistent with the entry previously written by the guest to the available ring; len represents the total number of bytes written to the buffer; and the idx field indicates the position in the ring where the driver will place the next descriptor entry (modulo the queue size), starting from 0.

[0041] 3. Design and Implementation For front-end driver operations, the first step is to process the virtual queue. The driver must initialize the device in the following order: A. Reset the device; B. Set the ACKNOWLEDGE status bit: The guest OS has taken notice of the device; C. Set driver status bits: The guest OS knows how to drive the device; D. Read the device characteristic bits and write a subset of the characteristic bits that are understood by the OS and the device driver. During this step, the driver can read the device-specific configuration space fields to check if it supports the device before receiving it; E. Set the FEATURES_OK status bit. After this step, the driver will prevent it from receiving new feature bits; F. Reread the device status to confirm that the FEATURES_OK bit is still set; otherwise, the device cannot support our feature subset and the device is unavailable. G. Perform device-specific installation, including the discovery of device virtual queues, optional frontbus installation, reading and potentially writing the device's virtio configuration space, and the layout of the virtual queues; H. Set the DRIVER_OK status bit. At this point, the device is active.

[0042] If any of these steps fail, the driver should set the FAILED status bit to indicate that it has abandoned the device, at which point the driver will prevent further initialization. The driver cannot notify the device until DRIVER_OK is set.

[0043] Backend device operations can be divided into two parts: providing new buffers to the device; and processing existing buffers on the device. The steps for requesting buffers from the device are as follows: A. Add the buffer to the Descriptor table; B. Update the available ring; C. Update idx; D. Notify the device.

[0044] The driver processes used buffers on the device. For example, the simplest virtio network device has two virtual queues: a transmit virtual queue and a receive virtual queue. The driver adds outgoing packets to the transmit queue and then releases them when they are used. Similarly, future buffers are added to the receive queue and processed when they are used.

[0045] The implementation of this invention in a typical scenario of an embedded partitioned multi-core operating system is as follows: The virtio-console design follows a general flow: First, the transmit Vring needs to be initialized, including the virtual queue (virtqueue). Then, read and write operations on the device's register bank are performed. Next, the receive Vring is initialized. This completes the initialization of the virtio data structure. The front-end driver then passes data into the descriptor chain and notifies the back-end device that data has been sent. When there is no data transmission, the descriptors are recycled, and the other device performs operations on the incoming data.

[0046] 1) Initialize virtio, select the virtqueue index, write it to the Queue Select register, complete the initialization of vring, read the queue size register to obtain the available number of virtqueues, and allocate physical memory; 2) Pass the data to be sent by the front-end driver into the descriptor chain; 3) Notify the backend device that the frontend driver has sent data; 4) The backend device reads the data in the descriptor table until it reaches the last position in the used queue, reclaims the descriptor, and then cleans up the descriptor table. 5) The data sending process of the backend device is the same.

[0047] virtio-net design: 1) Initialize the virtual network adapter, including obtaining the target machine's network IP address, target machine's network port number, and target machine's network MAC address, and checking whether the configuration parameters are valid; 2) Assemble UDP Ethernet frames, obtain the address of the target machine's data packet buffer, write the protocol to the device, and complete the following tasks: fill in the target MAC and target IP, assemble IP datagrams and assemble UDP datagrams, etc. Then, first enable the CPU interrupt, then send the Ethernet frame, write a data packet to the network device, and finally enable the CPU interrupt again. 3) Read the protocol of the device, read new Ethernet data frames from the Ethernet device, first disable CPU interrupts, then call the driver layer interface to receive data packets in a loop, read a data packet from the network device, then enable CPU interrupts, and receive the corresponding type of data packet according to the frame type (ARP data packet and IP data packet). After receiving each data packet, first disable CPU interrupts, then send the data packet, and then enable CPU interrupts again. 4) Pass the data to be sent into the descriptor table in the form of a linked list to notify the device driver that the data has been sent; 5) The device receives data until the last element of the used queue, then performs a cleanup operation on the descriptor table and reclaims the data.

[0048] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.

Claims

1. A hybrid secure virtualization method for cross-platform operating systems, characterized in that, The virtualization method is implemented based on a semi-virtualized system architecture; the semi-virtualized system architecture includes: The front-end driver layer consists of drivers for the virtio emulation devices inside the virtual machine. These drivers are used to discover virtio devices, receive requests from inside the virtual machine, and communicate with the virtio emulation devices according to the virtio protocol. The backend device layer is used to simulate virtio backend devices, specifically: processing requests from virtual machines according to the virtio protocol; A transport layer is located between the front-end driver layer and the back-end device layer; the transport layer is used to support data communication between the virtual machine and the Hypervisor virtual device; the transport layer implements data transmission between the front-end driver layer and the back-end device layer based on a virtual queue. Wherein: the virtual queue is created by the front-end driver layer and is used for shared memory for data transmission; the back-end device layer obtains I / O requests submitted by the front-end driver layer through the shared memory; The device is configured based on a first driver on the first platform and a second driver on the second platform; when the device is extended from the first platform to the second platform, the semi-virtualized system architecture upgrades the first driver to the second driver in the second platform.

2. The hybrid secure virtualization method for cross-platform operating systems according to claim 1, characterized in that, The semi-virtualized system architecture uses a front-end and back-end communication mechanism, runs the driver in a virtual machine, and interacts with the back-end Hypervisor virtual device through a virtual queue.

3. The hybrid secure virtualization method for cross-platform operating systems according to claim 2, characterized in that, The virtual queue is implemented through vring, which is a circular buffer shared between the virtual machine and the backend device. Vring consists of three parts: a descriptor table, an available ring, and a used ring.

4. The hybrid secure virtualization method for cross-platform operating systems according to claim 3, characterized in that, The descriptor table is used to store associated descriptors, with each descriptor recording a description of the buffer.

5. The hybrid secure virtualization method for cross-platform operating systems according to claim 4, characterized in that, The available ring can be used to store the descriptor table provided by the front-end driver to the back-end device, and the descriptor table can be used by the back-end device layer; The used ring is used to store descriptor tables that have been processed by the backend processing program in the backend device layer but have not yet been fed back to the frontend driver layer.

6. The hybrid secure virtualization method for cross-platform operating systems according to claim 5, characterized in that, The method for data communication between the front-end driver layer and the back-end device layer includes the following steps: S101: When the virtual machine needs to send a request to the backend device layer, after preparing the data, put the data descriptor table into the availability ring, and then write the configuration notification to the backend device layer. S102: The backend device layer reads request information from the available ring and reads data from the shared memory; S103: After the backend device completes the request, it stores the response status in the used ring; the frontend driver layer obtains the request completion information from the used ring and retrieves the request data.

7. The hybrid secure virtualization method for cross-platform operating systems according to claim 6, characterized in that, In the backend device layer, each device is configured with the required number of virtual queues according to its needs; the frontend driver layer initiates a request to the backend device layer through the descriptor table pointed to by the available ring; the backend device layer parses the driver request from the frontend driver layer through the available ring, and then provides the driver of the frontend driver layer with the processed result of the request request through the used ring.

Images