Equipment driving method and device and equipment

Abstract

The embodiment of the invention provides an equipment driving method and device and equipment, the method is applied to a virtual machine management module, and the method comprises the following steps: receiving a first request sent by a first virtual machine; wherein the first request is used for requesting to drive first hardware equipment; under the condition that the first request meets a first condition, forwarding the first request to a second virtual machine; receiving a first response returned by the second virtual machine, wherein the first response carries a result that the second virtual machine drives the first hardware equipment based on the first request; and under the condition that the first response meets a second condition, forwarding the first response to the first virtual machine.

Description

Technical Field

[0001] The present application relates to but is not limited to the field of virtual machine technology, and in particular to a device driver method, apparatus, and device. Background Art

[0002] Full virtualization and paravirtualization are two different virtualization technologies. The operating system running in a full virtualization scenario does not need to be modified, and does not know that it is running on a virtual machine. Therefore, when accessing device registers, it needs to fall into the virtual machine management module, which drives the real physical device. In a paravirtualization scenario, through virtual input / output (Virtio) and other similar technologies, the device is abstracted at the business layer, and the virtual machine management module drives the real device to implement business support. For both solutions, more and more device driver codes will be added to the virtual machine management module, and security vulnerabilities in the driver code will affect the security of the virtual machine management module. Summary of the invention

[0003] The embodiments of the present application provide a device driving method, apparatus, and device, which are beneficial to improving the security of a virtual machine management module.

[0004] The technical solution of the embodiment of the present application is implemented as follows:

[0005] In a first aspect, an embodiment of the present application provides a device driving method, which is applied to a virtual machine management module, and the method includes: receiving a first request sent by a first virtual machine; wherein the first request is used to request driving a first hardware device; if the first request meets a first condition, forwarding the first request to a second virtual machine; receiving a first response returned by the second virtual machine, the first response carrying a result of the second virtual machine driving the first hardware device based on the first request; if the first response meets a second condition, forwarding the first response to the first virtual machine.

[0006] In a second aspect, an embodiment of the present application provides a device driver method, which is applied to a second virtual machine, and the method includes: receiving a first request from a first virtual machine forwarded by a virtual machine management module; wherein the first request is used to request driving a first hardware device; based on the first request, driving the first hardware device through a device driver code of the first hardware device to obtain a first response; the device driver code is integrated on the second virtual machine; and the first response is sent to the virtual machine management module.

[0007] In a second aspect, an embodiment of the present application provides a device driving method, the method comprising: a virtual machine management module receives a first request sent by a first virtual machine; wherein the first request is used to request driving a first hardware device; the virtual machine management module forwards the first request to a second virtual machine if the first request meets a first condition; the second virtual machine drives the first hardware device based on the first request through the device driver code of the first hardware device to obtain a first response; the device driver code is integrated on the second virtual machine; the second virtual machine sends the first response to the virtual machine management module; and the virtual machine management module forwards the first response to the first virtual machine if the first response meets the second condition.

[0008] In a fourth aspect, an embodiment of the present application provides a device driver apparatus, the apparatus comprising: a first virtual machine, configured to: send a first request to a virtual machine management module; wherein the first request is used to request driving a first hardware device; receive a first response from a second virtual machine forwarded by the virtual machine management module, the first response carrying a result of the second virtual machine driving the first hardware device based on the first request; a second virtual machine, configured to: based on the first request, drive the first hardware device through a device driver code of the first hardware device to obtain a first response; the device driver code is integrated on the second virtual machine; send the first response to the virtual machine management module; the virtual machine management module is configured to: forward the first request to the second virtual machine if the first request satisfies a first condition; and forward the first response to the first virtual machine if the first response satisfies a second condition.

[0009] In a fifth aspect, an embodiment of the present application provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program that can be run on the processor, and when the processor executes the program, the method described in the first aspect is implemented, or when the processor executes the program, the method described in the second aspect is implemented, or when the processor executes the program, the method described in the third aspect is implemented.

[0010] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and are not intended to limit the technical solutions of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The drawings herein are incorporated into the specification and constitute a part of the specification. These drawings illustrate embodiments consistent with the present application and are used together with the specification to illustrate the technical solution of the present application. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0012] The flowcharts shown in the accompanying drawings are only exemplary and do not necessarily include all the contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps can be decomposed, and some operations / steps can be combined or partially combined, so the actual execution order may change according to actual conditions.

[0013] Figure 1 A schematic diagram of an implementation of a device driver method provided in this application;

[0014] Figure 2 A schematic diagram of an implementation process of a device driver method provided in an embodiment of the present application Figure 1 ;

[0015] Figure 3 A schematic diagram of an implementation process of a device driver method provided in an embodiment of the present application Figure 2 ;

[0016] Figure 4 A schematic diagram of an implementation process of a device driver method provided in an embodiment of the present application Figure 3 ;

[0017] Figure 5 A schematic diagram of an implementation process of a device driver method provided in an embodiment of the present application Figure 4 ;

[0018] Figure 6 A schematic diagram of an implementation process of a device driver method provided in an embodiment of the present application Figure 5 ;

[0019] Figure 7 A schematic diagram of the structure of a device driver provided in an embodiment of the present application;

[0020] Figure 8 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0021] In order to make the purpose, technical solutions and advantages of the present application clearer, the technical solutions of the present application are further elaborated in detail below in conjunction with the drawings and embodiments. The described embodiments should not be regarded as limiting the present application. All other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present application.

[0022] In the following description, reference is made to “some embodiments”, which describe a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0023] It should be pointed out that the terms "first\second\third" involved in the embodiments of the present application are merely to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged in a specific order or sequence where permitted, so that the embodiments of the present application described here can be implemented in an order other than that illustrated or described here.

[0024] It will be understood by those skilled in the art that, unless otherwise defined, all terms (including technical terms and scientific terms) used herein have the same meaning as the general understanding of those skilled in the art in the field to which the embodiments of the present application belong. It should also be understood that terms such as those defined in general dictionaries should be understood to have meanings consistent with the meanings in the context of the prior art, and will not be interpreted with idealized or overly formal meanings unless specifically defined as here.

[0025] (1) Virtual Machine Management Module (Hypervisor)

[0026] Hypervisor is a software based on computer hardware platform (it can be system software or application software) that allows multiple operating systems to run in parallel on a hardware platform. Its main function is to isolate and virtualize computing resources so that a physical server can run multiple independent operating systems as if they were on separate servers. Specifically, the work of Hypervisor includes virtualizing hardware resources, virtualizing operating systems, resource allocation and scheduling, security isolation, and monitoring and management. Hypervisor is also used to create or run virtual machine (VM) software, firmware or hardware.

[0027] (2) Virtualized Input / Output (Virtio)

[0028] Virtio is an I / O (input / output) virtualization standard for virtualization platforms. Its main goal is to provide a general, high-performance I / O virtualization solution to make communication between virtual machines and host systems more efficient.

[0029] (3) Virtual Machine (VM)

[0030] A virtual machine can simulate several PCs on one computer. Each PC can run a separate operating system without interfering with each other. It is possible to run several operating systems "simultaneously" on one computer and connect these operating systems into a network.

[0031] (4) Quick EMUlator (Qemu)

[0032] QEMU can simulate processors of multiple architectures, such as x86, ARM, MIPS, etc., which allows users to run operating systems and applications based on different architectures on their computers.

[0033] QEMU can simulate various hardware devices, such as hard disks, network adapters, graphics cards, sound cards, etc., to provide a complete hardware environment for virtual machines.

[0034] QEMU supports two virtualization modes: full virtualization and paravirtualization. In full virtualization mode, QEMU runs virtual machines by simulating hardware devices, while in paravirtualization mode, QEMU uses specific virtualization technologies (such as KVM and Para-Virtualization in Xen) to improve performance.

[0035] QEMU is often used together with the Linux kernel-based open source virtualization technology (Kernel-based Virtual Machine, KVM) to provide a high-performance virtualization solution. KVM is a module of the Linux kernel that allows the Linux kernel to run directly as a hypervisor, while QEMU is used as a user space tool to manage and interact with virtual machines. In this combination, QEMU is responsible for simulating hardware devices and providing user interfaces, while KVM is responsible for the actual virtualization work, such as CPU and memory virtualization.

[0036] (5)Host

[0037] In computer science and virtualization, "Host" usually refers to a physical computer or server that provides a virtualized environment or runs an operating system and applications. In virtualization technology, "Host" refers to a physical machine that runs virtualization software (such as Hypervisor), which is responsible for managing and allocating resources to virtual machines (VMs) running on it.

[0038] The host is a computer or server with actual physical hardware (such as CPU, memory, storage devices, network interfaces, etc.). Virtualization software (such as KVM, VMware ESXi, Hyper-V, etc.) is installed on the host. These software can simulate multiple virtual computer environments, so that each virtual machine thinks that it has a complete set of hardware resources. The host manages and allocates its physical resources (such as CPU time slices, memory space, disk space, network bandwidth, etc.) to each virtual machine through virtualization software. This resource allocation ensures isolation between virtual machines and allows the host to use resources efficiently.

[0039] The host usually also runs a management platform or management tool to monitor the status and performance of the virtual machines and to create, configure, and migrate virtual machines.

[0040] In a virtualized environment, the "host" corresponds to the "guest virtual machine". The guest virtual machine is a virtual computer environment running on the host. It has its own operating system and applications, but all hardware resources are provided by the host through virtualization software.

[0041] (6)HVC

[0042] HVC is a privileged instruction used to send requests from a lower privilege level (such as the kernel state of the Guest OS) to a higher privilege level (such as the Hypervisor) in a virtualized environment. These requests may include sensitive operations such as memory management, device simulation, and performance monitoring, which require the Hypervisor to execute or coordinate.

[0043] When a virtual machine executes an HVC instruction, an exception is generated for the hypervisor. The CPU will suspend the execution of the virtual machine and jump to the hypervisor's exception handler. The hypervisor performs the corresponding operation based on the parameters and context of the HVC instruction and returns the result to the virtual machine.

[0044] HVC instructions provide a trusted communication channel to ensure that sensitive operations are only performed by trusted entities (i.e., the Hypervisor). This helps maintain the security and isolation of the virtualized environment and prevents unauthorized access and data leakage between virtual machines.

[0045] (7) Security level

[0046] Security levels are a set of exception levels defined in the ARM architecture, which represent different privileges and access rights, allowing the processor to respond to exceptions in different ways under different circumstances. The following is a detailed understanding of the four levels EL0-EL3:

[0047] EL0 is an unprivileged mode: it is mainly used to run user space applications. At this level, the processor's access to system resources is strictly restricted to ensure the stability and security of the application.

[0048] EL0 is the lowest exception level, and applications usually run at this level and cannot directly access or modify the underlying hardware or system resources.

[0049] EL1 is a privileged mode: mainly used to run the operating system kernel and drivers. At this level, the processor has higher permissions and can access more system resources.

[0050] EL1 is the level at which the operating system runs, and the operating system kernel ensures system stability and performance by managing these resources. EL1 can handle exceptions and interrupts from EL0 (user space) and execute the corresponding handlers.

[0051] EL2 is the virtualization monitor level: it is specifically used to run virtualization monitors (such as Hypervisors), which are the control layer of virtual machines. At this level, the processor can monitor and manage the operation of virtual machines to ensure the isolation and security between them. EL2 allows the virtualization monitor to control and manage the behavior of EL1 (operating system) and EL0 (user space), thereby realizing the core functions of virtualization technology.

[0052] EL3 is the secure monitoring mode: usually used to execute firmware or security gateway related code, it is the highest level of the CPU. At this level, the processor has the highest permissions and can perform the most sensitive and critical tasks, such as secure boot, firmware updates, etc. EL3 is also used to switch between Normal World and Secure World to ensure the security of sensitive data and operations.

[0053] (8) Normal World

[0054] Normal World usually refers to the combination of non-secure state and non-secure physical address space. It is the "normal" environment of the CPU, used to run regular applications, operating system kernels, etc.

[0055] In the Normal World, applications and the operating system kernel run at lower privilege levels (such as EL0 and EL1), and access to system resources is subject to certain restrictions.

[0056] The code and data of the Normal World can be accessed and modified by privileged software (such as the Hypervisor or operating system kernel), so there is a certain security risk.

[0057] The address space isolation of Normal World is usually implemented based on the paging mechanism of MMU (memory management unit).

[0058] (9) Secure World

[0059] Secure World is one of the main features of the ARM TrustZone architecture, which provides a secure execution environment isolated from NormalWorld. Secure World includes components such as secure operating system, secure monitor, cryptographic interface, secure storage and trusted applications.

[0060] The Secure World runs at a higher privilege level (such as EL3) and has higher security and isolation than the Normal World.

[0061] In the Secure World, sensitive data and critical operations (such as storage and access of encryption keys) are protected to prevent access by privileged software or external attackers. Switching between the Secure World and the Normal World is achieved through the Secure Monitor, which acts as a gateway between the two worlds. The address space of the Secure World is completely isolated from the Normal World.

[0062] In a related art, Figure 1 As shown, the driver code is integrated into Hypervisor 102. The virtual machine 101 sends an instruction requesting to drive the device, and Hypervisor 102 implements the driving of the corresponding device based on the device driver code integrated by itself. Among them, the virtual machine 101 includes: a real device driver (Real device driver) and a virtual device driver (Virtio device driver). Among them, the real device driver refers to the driver that directly controls and manages the physical hardware device. These drivers are part of the operating system kernel, and they are responsible for converting the operating system's requests into instructions that the hardware can understand, thereby realizing the control of the hardware device. The virtual device driver is a driver designed specifically for the Virtio virtualization standard. Virtio is a virtualization standard that allows efficient data transmission between virtual machines and physical hosts.

[0063] However, this technology integrates the real device driver code into the Hypervisor. When the vulnerabilities in the device driver code are exploited, the security in the Hypervisor will be destroyed, thereby destroying the security of the virtual machine.

[0064] In another related technology, Qemu performs device emulation based on the host and interacts with the device. However, the security of the interaction between the virtual machine and the device depends on the host, which reduces the credibility.

[0065] The present application embodiment provides a device driving method. Figure 2A schematic diagram of an implementation process of a device driver method provided in an embodiment of the present application Figure 1 ,like Figure 2 As shown, the method is applied to a virtual machine management module, and the method includes the following steps 201 to 204:

[0066] Step 201, receiving a first request sent by a first virtual machine; wherein the first request is used to request to drive a first hardware device;

[0067] Step 202: forward the first request to the second virtual machine if the first request satisfies the first condition;

[0068] Step 203: receiving a first response returned by the second virtual machine, where the first response carries a result of the second virtual machine driving the first hardware device based on the first request;

[0069] Step 204: forward the first response to the first virtual machine if the first response meets the second condition.

[0070] It can be understood that in the embodiment of the present application, for the driving of the device, the first virtual machine sends a first request to drive the device, and the first request sent is forwarded to the second virtual machine through the virtual machine management module when the first condition is met, and the second virtual machine drives the device, and then forwards the driving result of the device to the first virtual machine through the virtual machine management module, thereby completing the driving of the device; rather than the virtual machine management module driving the device. In this way, the device driver code is integrated on the second virtual machine, rather than on the virtual machine management module, which is beneficial to reduce the impact of the device driver code on the security of the virtual machine management module and the entire virtualization platform; and in the case of a vulnerability in the device driver code, the impact is limited to the second virtual machine, thereby improving the recoverability of the system where the first virtual machine is located.

[0071] The following describes further optional implementations and related terms of each of the above steps.

[0072] In step 201, a first request sent by a first virtual machine is received; wherein the first request is used to request to drive a first hardware device.

[0073] It should be understood that in the embodiment of the present application, there is no limitation on the first virtual machine, the first request, and the first hardware device.

[0074] In some embodiments, the first virtual machine sends the first request to the hypervisor by triggering an exception. As a possible implementation, in the ARMv8 architecture, the virtual machine uses an HVC (Hypervisor Call) instruction to trigger an exception for the hypervisor, thereby sending the first request to the hypervisor.

[0075] In other embodiments, the first virtual machine sends the first request to the hypervisor by calling HVC. As a possible implementation, the virtual machine initiates the HVC call by executing a specific instruction or system call. The call includes the content of the request and the identifier of the hypervisor service to be called.

[0076] In some further embodiments, the first virtual machine may also send the first request in the following manner:

[0077] (1) The hypervisor provides a set of special system calls (called hypercalls), and the virtual machine executes these hypercalls to request the hypervisor to perform specific operations. Hypercall execution is usually more efficient than traditional system calls because they are passed directly between the virtual machine and the hypervisor without going through the host operating system.

[0078] (2) The virtual machine requests the Hypervisor's service by triggering an interrupt.

[0079] (3) In I / O virtualization, a virtual machine sends an input / output (I / O) request to the Hypervisor, which forwards it to the second virtual machine. The second virtual machine executes the driver for the physical hardware or simulated hardware device based on the I / O request and returns the driver result to the first virtual machine through the Hypervisor.

[0080] In step 202, if the first request satisfies the first condition, the first request is forwarded to the second virtual machine.

[0081] In some embodiments, if the first request satisfies the first condition and the second condition, the first request is forwarded to the second virtual machine.

[0082] In some other embodiments, the first request is forwarded to the second virtual machine, so that the second virtual machine drives the first hardware device based on the first request when the first request satisfies the first condition.

[0083] In some embodiments, the first condition is that the first hardware device requested to be driven by the first request is a device in a preset list.

[0084] It should be understood that in the embodiment of the present application, the preset list and the devices in the preset list are not limited. As a possible implementation, the preset list is a whitelist; the devices in the preset list include: devices corresponding to device driver codes that are not sensitive to performance.

[0085] It can be understood that in the embodiment of the present application, the driver code of the performance-insensitive device is integrated on the second virtual machine, thereby reducing the number of driver codes integrated on the virtual machine management module. This is beneficial to reducing the impact of the device driver code on the security of the virtual machine management module and the entire virtualization platform; and in the event that there is a vulnerability in the device driver code integrated in the second virtual machine, the impact is limited to the second virtual machine, thereby improving the recoverability of the system where the first virtual machine is located.

[0086] In some embodiments, the above-mentioned "performance-insensitive devices" can be understood as hardware devices that have little impact on system performance, or even if there is some compromise in performance, it will not have a significant negative impact on the overall system operation. In other words, after the first request is forwarded by the virtual machine management module, the second virtual machine drives the hardware device based on the first request, and forwards the driving result to the first virtual machine via the virtual machine management module, which will not have a significant negative impact on the operation of the overall system, that is, the call of the hardware device is not sensitive to delay and will not affect the user experience.

[0087] In some embodiments, when it is determined that the first request passes the security verification, it is determined that the first request satisfies the second condition. The security verification includes: request type verification, request resource requirement assessment, system load and security considerations, request history and trend analysis, and log auditing.

[0088] It can be understood that in the embodiment of the present application, when it is determined that the first request passes the security verification, the first request is forwarded to the second virtual machine, which is beneficial to ensure that the second virtual machine will not affect the security of the second virtual machine when executing the first request.

[0089] In some embodiments, the method also includes: pausing the execution of the first request by the first virtual machine, and starting the execution of the first request by the second virtual machine, so that the second virtual machine drives the first hardware device based on the first request; pausing the execution of the first request by the second virtual machine, and resuming the execution of the first request by the first virtual machine, and forwarding the first response to the first virtual machine.

[0090] In the embodiment of the present application, "pausing the execution of the first request by the first virtual machine" can be understood as pausing the first process used by the first virtual machine to execute the first request; "starting the execution of the first request by the second virtual machine" can be understood as executing the first request in the second process of the second virtual machine; "pausing the execution of the first request by the second virtual machine" can be understood as pausing the second process used by the second virtual machine to execute the first request; and "resuming the execution of the first request by the first virtual machine" can be understood as resuming the first process used by the first virtual machine to execute the first request.

[0091] In step 203, a first response returned by the second virtual machine is received, where the first response carries a result of the second virtual machine driving the first hardware device based on the first request.

[0092] In step 204, if the first response satisfies the second condition, the first response is forwarded to the first virtual machine.

[0093] In some embodiments, when it is determined that the first response passes the security verification, it is determined that the first response satisfies the second condition.

[0094] It should be understood that in the embodiments of the present application, there is no limitation on security verification. In some embodiments, security verification includes: data integrity verification carried by the first response, identity verification of the first response, etc.

[0095] It can be understood that in the embodiment of the present application, when it is determined that the first response passes the security verification, the first response is forwarded to the first virtual machine. This is beneficial to ensure the data security of the first virtual machine when there is a security threat in the first response.

[0096] In some embodiments, the method also includes receiving first information sent by the second virtual machine; wherein the first information includes information generated by the second virtual machine performing a first processing based on the first signal sent by the first hardware device; and forwarding the first information to the first virtual machine if the first information satisfies a second condition.

[0097] It should be understood that in the embodiments of the present application, the first information, the first signal, and the first processing are not limited. In some embodiments, the first signal includes: an interrupt signal sent by the first hardware device to the second virtual machine; the first processing includes: processing performed by the second virtual machine based on the interrupt signal, for example: saving the data information stored in the address carried by the first signal, shielding the interrupt and / or enabling the interrupt, clearing the interrupt status register, etc.

[0098] In some embodiments, the first information includes: information characterizing the interrupt type, data information stored in the address carried by the first signal, information characterizing masking interrupts and / or enabling interrupts, and information characterizing clearing an interrupt status register.

[0099] It can be understood that in the embodiment of the present application, the device code for processing the interrupt signal is integrated on the second virtual machine, and the second virtual machine performs the first processing based on the interrupt signal, rather than being integrated on the virtual machine management module. This is beneficial to reduce the impact of the device code for processing the interrupt signal on the security of the virtual machine management module and the entire virtualization platform; and in the event that there is a vulnerability in the device code for processing the interrupt signal, the impact will be controlled in the second virtual machine, thereby improving the recoverability of the system where the first virtual machine is located.

[0100] In some embodiments, receiving the first information sent by the second virtual machine includes: enabling the second function to receive the first information through the third process; wherein the second function is used to switch the fourth process to the third process; the first information is sent by the second virtual machine through the fourth process; and the third process is the process by which the virtual machine receives the first information.

[0101] The present application embodiment provides a device driving method. Figure 3 A schematic diagram of an implementation process of a device driver method provided in an embodiment of the present application Figure 2 ,like Figure 3 As shown, the method is applied to the second virtual machine, and the method includes the following steps 301 to 303:

[0102] Step 301, receiving a first request from a first virtual machine forwarded by a virtual machine management module; wherein the first request is used to request to drive a first hardware device;

[0103] Step 302: Based on the first request, the first hardware device is driven by the device driver code of the first hardware device to obtain a first response; the device driver code is integrated on the second virtual machine;

[0104] Step 303: Send the first response to the virtual machine management module.

[0105] It can be understood that in the embodiment of the present application, for the driving of the device, the second virtual machine implements the driving of the device based on the first request forwarded by the virtual machine management module, and then forwards the driving result of the device to the first virtual machine through the virtual machine management module, thereby completing the driving of the device; rather than the virtual machine management module implementing the driving of the device. In this way, the device driver code of the hardware device that can be driven by the second virtual machine is integrated on the second virtual machine, rather than on the virtual machine management module, which is beneficial to reduce the impact of the device driver code on the security of the virtual machine management module and the entire virtualization platform; and in the case that there is a vulnerability in the device driver code of the hardware device that can be driven by the second virtual machine, the impact is limited to the second virtual machine, thereby improving the recoverability of the system where the first virtual machine is located.

[0106] In some embodiments, Figure 4A schematic diagram of an implementation process of a device driver method provided in an embodiment of the present application Figure 3 , the method is applied to the second virtual machine, such as Figure 4 As shown, the method further includes the following steps 401 to 403:

[0107] Step 401, receiving an interrupt signal sent by a first hardware device;

[0108] Step 402, performing a first process based on the interrupt signal to obtain a process result;

[0109] Step 403: determine first information according to the processing result, and send the first information to the virtual machine management module.

[0110] It can be understood that in the embodiment of the present application, the device code for processing the interrupt signal is integrated on the second virtual machine, and the second virtual machine performs the first processing based on the interrupt signal, rather than being integrated on the virtual machine management module, and the virtual machine management module performs the first processing based on the interrupt signal. In this way, it is beneficial to reduce the impact of the device code for processing the interrupt signal on the security of the virtual machine management module and the entire virtualization platform; and in the event that there is a vulnerability in the device code for processing the interrupt signal, the impact will be controlled in the second virtual machine, thereby improving the recoverability of the system where the first virtual machine is located.

[0111] The present application embodiment provides a device driving method. Figure 5 A schematic diagram of an implementation process of a device driver method provided in an embodiment of the present application Figure 4 ,like Figure 5 As shown, the method includes the following steps 501 to 505:

[0112] Step 501: The virtual machine management module receives a first request sent by a first virtual machine; wherein the first request is used to request to drive a first hardware device;

[0113] Step 502: The virtual machine management module forwards the first request to the second virtual machine if the first request satisfies the first condition;

[0114] Step 503: Based on the first request, the second virtual machine drives the first hardware device through the device driver code of the first hardware device to obtain a first response; the device driver code of the first hardware device is integrated on the second virtual machine;

[0115] Step 504, the second virtual machine sends the first response to the virtual machine management module;

[0116] Step 505: The virtual machine management module forwards the first response to the first virtual machine if the first response meets the second condition.

[0117] It can be understood that in the embodiment of the present application, for the driving of the device, the first virtual machine sends a first request to drive the device, and the first request sent is forwarded to the second virtual machine through the virtual machine management module when the first condition is met, and the second virtual machine drives the device, and then forwards the driving result of the device to the first virtual machine through the virtual machine management module, thereby completing the driving of the device; rather than the virtual machine management module driving the device. In this way, the device driver code is integrated on the second virtual machine, rather than on the virtual machine management module, which is beneficial to reduce the impact of the device driver code on the security of the virtual machine management module and the entire virtualization platform; and in the case of a vulnerability in the device driver code, the impact is limited to the second virtual machine, thereby improving the recoverability of the system where the first virtual machine is located.

[0118] The following describes an exemplary application of the processing method provided in the embodiments of the present application in a practical scenario.

[0119] An embodiment of the present application provides a device driver method, in which performance-insensitive device driver code is stripped from a Hypervisor and carried by an independent virtual machine (ie, an example of a second virtual machine).

[0120] In some embodiments, a device driver running in a business virtual machine (i.e., an example of the first virtual machine) enters the Hypervisor through an exception or HVC, and the exception handling process in the Hypervisor detects a request for a function of a specific device (i.e., an example of the first hardware device) (i.e., an example of the first request), and switches the virtual machine context of the corresponding device driver virtual machine (i.e., an example of the second virtual machine) found, then switches to EL1 and starts running the device driver virtual machine; runs the device driver code in the device virtual machine for function access (i.e., executes the first request); after the device driver function is completed, falls into the Hypervisor through HVC, switches the virtual machine context, and then returns to the business virtual machine.

[0121] In some embodiments, the method also includes: when a physical device (i.e., an example of a first hardware device) reports an interrupt, the interrupt is first routed to a device driver virtual machine for related processing (i.e., an example of a first processing), and then returned to the business virtual machine through a Hypervisor.

[0122] Figure 6 A schematic diagram of an implementation process of a device driver method provided in an embodiment of the present application Figure 5 ,like Figure 6As shown, the first virtual machine 101 sends a first request, and the virtual machine management module 102 forwards the first request to the second virtual machine 601 when the first request meets the first condition. The second virtual machine 601 integrates a device driver code. The second virtual machine 601 drives the first hardware device 602 through the device driver code of the first hardware device 602 based on the first request forwarded by the virtual machine management module 102, obtains a first response, and sends the first response to the virtual machine management module 102. When the first response meets the second condition, the virtual machine management module 102 forwards the first response to the first virtual machine 101. Among them, the virtual switch (VMswitch) is a component running inside the Hypervisor, which is responsible for processing network communications between virtual machines and communications between virtual machines and external physical networks.

[0123] In some embodiments, the second virtual machine 601 receives an interrupt signal sent by the first hardware device 602, and the second virtual machine 601 performs a first process based on the interrupt signal to obtain first information, and forwards the first information to the first virtual machine 101 through the virtual machine management module 102. Among them, the first virtual machine 101, the virtual machine management module 102 and the second virtual machine 601 all work in the normal world (i.e., Normal World), and the virtual machine management module 102 forwards the first request, the first response and the first information through its internal virtual machine switching unit (VMswitch).

[0124] It can be understood that in an embodiment of the present application, qualified device driver code, such as performance-insensitive device driver code, is stripped from the Hypervisor and carried by an independent virtual machine, while the Hypervisor returns to the virtual machine management role; this is beneficial to reducing the impact of the device driver code on the security of the Hypervisor and the entire virtualization platform; and when there is a vulnerability in the device driver code, the affected device is limited to the device driver virtual machine, thereby improving the recoverability of the system.

[0125] It should be noted that although the steps of the method in the present application are described in a specific order in the drawings, this does not require or imply that the steps must be performed in this specific order, or that all the steps shown must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be decomposed into multiple steps, etc.; or, steps in different embodiments may be combined into a new technical solution.

[0126] Based on the foregoing embodiments, an embodiment of the present application provides a device driver, which includes the modules included and the units included in the modules, which can be implemented by a processor; of course, it can also be implemented by a specific logic circuit; in the implementation process, the processor can be an AI acceleration engine (such as NPU, etc.), GPU, central processing unit (CPU), microprocessor (MPU), digital signal processor (DSP) or field programmable gate array (FPGA), etc.

[0127] Figure 7 A schematic diagram of the structure of a device driver provided in an embodiment of the present application is shown in FIG. Figure 7 As shown, the device driver 70 includes a first virtual machine 701, a second virtual machine 702 and a virtual machine management module 703, wherein:

[0128] The first virtual machine 701 is configured to: send a first request to the virtual machine management module; wherein the first request is used to request to drive the first hardware device; receive a first response from the second virtual machine forwarded by the virtual machine management module, wherein the first response carries a result of the second virtual machine driving the first hardware device based on the first request;

[0129] The second virtual machine 702 is configured to: based on the first request, drive the first hardware device through the device driver code of the first hardware device to obtain a first response; integrate the device driver code on the second virtual machine; and send the first response to the virtual machine management module;

[0130] The virtual machine management module 703 is configured to: forward the first request to the second virtual machine if the first request meets the first condition; and forward the first response to the first virtual machine if the first response meets the second condition.

[0131] In some embodiments, the virtual machine management module 703 is configured to: suspend the execution of the first request by the first virtual machine, and start the execution of the first request by the second virtual machine, so that the second virtual machine drives the first hardware device based on the first request; suspend the execution of the first request by the second virtual machine, and resume the execution of the first request by the first virtual machine, and forward the first response to the first virtual machine.

[0132] In some embodiments, the virtual machine management module 703 is configured to: receive first information sent by the second virtual machine; wherein the first information includes information generated by the second virtual machine performing a first processing based on a first signal sent by the first hardware device; and forward the first information to the first virtual machine if the first information satisfies a second condition.

[0133] In some embodiments, the first condition is that the first hardware device requested to be driven by the first request is a device in a preset list.

[0134] In some embodiments, the virtual machine management module 703 is configured to: determine that the first response satisfies the second condition when it is determined that the first response passes the security verification.

[0135] In some embodiments, the second virtual machine 702 is configured to receive a first request from the first virtual machine forwarded by the virtual machine management module.

[0136] In some embodiments, the second virtual machine 702 is configured to: receive an interrupt signal sent by the first hardware device; perform a first process based on the interrupt signal to obtain a process result; determine first information based on the process result, and send the first information to the virtual machine management module.

[0137] The description of the above device embodiment is similar to the description of the above method embodiment, and has similar beneficial effects as the method embodiment. For technical details not disclosed in the device embodiment of the present application, please refer to the description of the method embodiment of the present application for understanding.

[0138] It should be noted that the division of modules in the embodiments of the present application is schematic and is only a logical function division. There may be other division methods in actual implementation. In addition, each functional unit in each embodiment of the present application may be integrated into a processing unit, or may exist physically alone, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of a software functional unit. It may also be implemented in the form of a combination of software and hardware.

[0139] It should be noted that in the embodiment of the present application, if the above method is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the embodiment of the present application can be essentially or partly embodied in the form of a software product that contributes to the relevant technology. The computer software product is stored in a storage medium, including several instructions to enable an electronic device to execute all or part of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a U disk, a mobile hard disk, a read-only memory (ROM), a magnetic disk or an optical disk. In this way, the embodiment of the present application is not limited to any specific combination of hardware and software.

[0140] An embodiment of the present application provides an electronic device, Figure 8 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application is shown in FIG. Figure 8As shown, the electronic device 80 includes a memory 801 and a processor 802. The memory 801 stores a computer program that can be run on the processor 802. When the processor 802 executes the program, the steps in the method provided in the above embodiment are implemented.

[0141] It should be noted that the memory 801 is configured to store instructions and applications executable by the processor 802, and can also cache data to be processed or processed by the processor 802 and various modules in the electronic device 80, which can be implemented through flash memory (FLASH) or random access memory (Random Access Memory, RAM).

[0142] An embodiment of the present application provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the steps in the method provided in the above embodiment are implemented.

[0143] An embodiment of the present application provides a computer program product including instructions, which, when executed on a computer, enables the computer to execute the steps of the method provided in the above method embodiment.

[0144] It should be noted here that the description of the above storage medium and device embodiments is similar to the description of the above method embodiments, and has similar beneficial effects as the method embodiments. For technical details not disclosed in the storage medium, storage medium and device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0145] It should be understood that the "one embodiment" or "an embodiment" or "some embodiments" or "in a possible implementation" or "example" mentioned throughout the specification means that the specific features, structures or characteristics related to the embodiment are included in at least one embodiment of the present application. Therefore, "in one embodiment" or "in an embodiment" or "in some embodiments" or "in a possible implementation" or "example" appearing throughout the specification may not necessarily refer to the same embodiment. In addition, these specific features, structures or characteristics can be combined in one or more embodiments in any suitable manner. It should be understood that in various embodiments of the present application, the size of the sequence number of the above-mentioned processes does not mean 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 embodiment of the present application. The above-mentioned sequence numbers of the embodiments of the present application are only for description and do not represent the advantages and disadvantages of the embodiments. The above description of the various embodiments tends to emphasize the differences between the various embodiments, and the same or similar aspects can be referenced to each other. For the sake of brevity, this article will not repeat them.

[0146] The term "and / or" in this article is only a description of the association relationship of associated objects, indicating that there may be three relationships. For example, object A and / or object B can represent three situations: object A exists alone, object A and object B exist at the same time, and object B exists alone.

[0147] It should be noted that, in this article, the terms "comprise", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise one..." do not exclude the presence of other identical elements in the process, method, article or device including the element. In the several embodiments provided in the present application, it should be understood that the disclosed equipment and devices, etc., can be implemented in other ways. The embodiments described above are merely illustrative. The features disclosed in the several product embodiments provided in the present application can be arbitrarily combined without conflict to obtain new product embodiments.

[0148] The above is only an implementation method of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A device driver method, applied to a virtual machine management module, the method comprising: Receiving a first request sent by a first virtual machine; wherein the first request is used to request to drive a first hardware device; If the first request satisfies a first condition, forwarding the first request to a second virtual machine; receiving a first response returned by the second virtual machine, where the first response carries a result of the second virtual machine driving the first hardware device based on the first request; If the first response satisfies the second condition, forward the first response to the first virtual machine.

2. The method according to claim 1, wherein: The method further comprises: pausing the execution of the first request by the first virtual machine, and starting the execution of the first request by the second virtual machine, so that the second virtual machine drives the first hardware device based on the first request; The execution of the first request by the second virtual machine is suspended, and the execution of the first request by the first virtual machine is resumed, and the first response is forwarded to the first virtual machine.

3. The method according to claim 1, wherein: The method further comprises: Receiving first information sent by the second virtual machine; wherein the first information includes information generated by the second virtual machine performing a first process based on a first signal sent by the first hardware device; If the first information meets the second condition, the first information is forwarded to the first virtual machine.

4. The method according to any one of claims 1 to 3, wherein: The first condition is that the first hardware device requested to be driven by the first request is a device in a preset list.

5. The method according to any one of claims 1 to 3, wherein: In case it is determined that the first response passes the security verification, it is determined that the first response satisfies the second condition.

6. A device driver method, applied to a second virtual machine, the method comprising: Receive a first request from a first virtual machine forwarded by a virtual machine management module; wherein the first request is used to request to drive a first hardware device; Based on the first request, the first hardware device is driven by a device driver code of the first hardware device to obtain a first response; the device driver code is integrated on the second virtual machine; The first response is sent to the virtual machine management module.

7. The method according to claim 6, wherein: The method further comprises: Receiving an interrupt signal sent by the first hardware device; Perform a first process based on the interrupt signal to obtain a process result; Determine first information according to the processing result, and send the first information to the virtual machine management module.

8. A driving method, the method comprising: The virtual machine management module receives a first request sent by a first virtual machine; wherein the first request is used to request to drive a first hardware device; The virtual machine management module forwards the first request to the second virtual machine if the first request satisfies a first condition; The second virtual machine drives the first hardware device based on the first request through the device driver code of the first hardware device to obtain a first response; the device driver code is integrated on the second virtual machine; The second virtual machine sends the first response to the virtual machine management module; The virtual machine management module forwards the first response to the first virtual machine if the first response meets a second condition.

9. A device driving apparatus, the apparatus comprising: The first virtual machine is configured as: Sending a first request to a virtual machine management module; wherein the first request is used to request to drive a first hardware device; receiving a first response from the second virtual machine forwarded by the virtual machine management module, wherein the first response carries a result of the second virtual machine driving the first hardware device based on the first request; The second virtual machine is configured as: Based on the first request, the first hardware device is driven by a device driver code of the first hardware device to obtain the first response; the device driver code is integrated on the second virtual machine; Sending the first response to the virtual machine management module; The virtual machine management module is configured to: If the first request satisfies a first condition, forwarding the first request to the second virtual machine; If the first response satisfies the second condition, forward the first response to the first virtual machine.

10. An electronic device, comprising a memory and a processor, wherein the memory stores a computer program that can be run on the processor, and when the processor executes the program, the method described in any one of claims 1 to 5 is implemented, or when the processor executes the program, the method described in any one of claims 6 to 7 is implemented, or when the processor executes the program, the method described in claim 8 is implemented.

Images