Virtualization system, method and device calling method for trusted execution environment

Abstract

The present invention provides a virtualization system, method and device calling method for a trusted execution environment, the system comprising: a driver virtual host, running in a trusted execution environment TEE, for reusing a shared device driver developed by a general driver framework within the trusted execution environment TEE, so as to provide a shared driver service in the trusted execution environment TEE; at least one driver semi-virtualization module, running in a TEE virtual machine in a rich execution environment REE and / or an executable environment TEE, for calling a shared driver service provided by the driver virtual host, and providing a corresponding device driver service in the rich execution environment REE and / or the TEE virtual machine based on the shared driver service. By using the above system and method, it is possible to avoid repeated development of related device drivers, reduce the complexity of driver development, and reduce the cost of driver development.

Description

Technical Field

[0001] The present invention belongs to the field of operating systems, and in particular relates to a virtualization system and method for a trusted execution environment. Background Art

[0002] This section is intended to provide a background or context to embodiments of the invention that are recited in the claims. No description herein is admitted to be prior art by inclusion in this section.

[0003] Trusted Execution Environment (TEE) technology can provide a trusted execution environment / operating system protected by hardware isolation for smart terminals such as mobile phones.

[0004] Currently, TEE technology has become popular on smartphones and has gradually expanded from mobile phones to automotive electronics, industry terminals and other fields. The industry ecosystem and device types covered by TEE are becoming more and more diverse. How multiple business party TEEs can coexist safely on one device is becoming more and more important. The multi-TEE virtual machine solution based on virtualization technology can well meet the above needs.

[0005] In the prior art, a paravirtualization solution is adopted, see Figure 1 In response to the need for multiple TEE operating systems (TEE OS) to coexist on the same device, a paravirtualization method is used to run multiple TEE OS simultaneously in a hardware isolation environment. TEE virtual machine device drivers (such as GPU, camera, LCD, etc.) call the device driver provided by TEE OS through the paravirtualization module to complete related device operations. However, in the existing paravirtualization solution, the device driver is located in the TEE OS, and the TEE virtual machine calls the device driver provided by TEE OS through the paravirtualization module to complete related device operations. Since the driver reference implementation provided by hardware and chip manufacturers is mainly for Linux-like systems, and the TEE platform driver architecture is quite different from that of Linux-like systems, for devices with higher complexity (such as GPU, camera, LCD, etc.), the workload of developing such device drivers on the TEE platform is very large, which greatly affects the implementation and promotion of this solution. Summary of the invention

[0006] In view of the above problems existing in the prior art, a virtualization system and method for a trusted execution environment are proposed. The above problems can be solved by using this system and method.

[0007] The present invention provides the following solutions.

[0008] In a first aspect, a virtualization system for a trusted execution environment is provided, characterized in that the system includes: a driver virtual host, running in a trusted execution environment TEE, and used to reuse shared device drivers developed by a general driver framework inside the trusted execution environment TEE to provide shared driver services in the trusted execution environment TEE; at least one driver semi-virtualization module, running in a TEE virtual machine in a rich execution environment REE and / or an executable environment TEE, and used to call the shared driver service provided by the driver virtual host, and provide corresponding device driver services in the rich execution environment REE and / or the TEE virtual machine based on the shared driver service.

[0009] In some possible implementations, the virtualization implementation system also includes: a virtual machine secure communication module, which runs in the operating system of the trusted execution environment TEE and is used to provide secure communication services for the virtual driver host and driver paravirtualization module running in the TEE virtual machine.

[0010] In some possible implementations, driving the virtual host also includes: a driver framework layer, which is used to provide device driver basic services compatible with the general driver framework to support the basic operating environment of shared device drivers developed based on the general driver framework; a shared device driver implementation layer, which is used to complete the driver implementation of shared devices developed based on the general driver framework; a shared device driver service layer, which is used to provide shared driver services for the driver semi-virtualization module based on the functions for shared devices provided by the shared device driver implementation layer.

[0011] In some possible implementations, the driving semi-virtualization module also includes: a device driver implementation layer, which is used to call the shared driver service provided by the shared device driver service layer, and provide basic functional support for the corresponding devices in the rich execution environment REE and / or TEE virtual machine based on the shared driver service to complete the driver implementation of the corresponding device; a device driver service layer, which is used to provide corresponding device driver services to the rich execution environment REE and / or TEE virtual machine based on the functional services of the corresponding devices provided by the device driver implementation layer.

[0012] In some possible implementations, the shared driver service includes at least one of the following: GPU, camera, LCD. In some possible implementations, the universal driver framework is a Linux driver framework or other operating system driver framework.

[0013] In a second aspect, a virtualization method for a trusted execution environment is provided, which is applied to a virtualization implementation system such as the first aspect, and the method includes: a driver virtual host running in a trusted execution environment TEE reuses a shared device driver developed by a general driver framework inside the trusted execution environment TEE to provide a shared driver service in the trusted execution environment TEE; at least one driver semi-virtualization module in a TEE virtual machine running in a rich execution environment REE and / or an executable environment TEE calls the shared driver service provided by the driver virtual host, and provides corresponding device driver services in the rich execution environment REE and / or the TEE virtual machine based on the shared driver service.

[0014] In some possible implementations, the method further includes: utilizing a virtual machine secure communication module in an operating system running in a trusted execution environment TEE to provide secure communication services between a virtual driver host and a driver paravirtualization module running in a TEE virtual machine.

[0015] In some possible implementations, the driver virtual host includes a driver framework layer, a shared device driver implementation layer and a shared device driver service layer, and the method also includes: the driver framework layer provides device driver basic services compatible with the general driver framework to support the basic operating environment of the shared device driver developed based on the general driver framework; the shared device driver implementation layer executes the driver implementation of the shared device developed based on the general driver framework; the shared device driver service layer provides shared driver services for the driver semi-virtualization module based on the functions for the shared device provided by the shared device driver implementation layer.

[0016] In some possible implementations, the driver semi-virtualization module includes a device driver implementation layer and a device driver service layer, and the method also includes: the device driver implementation layer calls the shared driver service provided by the shared device driver service layer, and provides basic functional support for the corresponding devices in the rich execution environment REE and / or TEE virtual machine based on the shared driver service to complete the driver implementation of the corresponding device; the device driver service layer provides corresponding device driver services to the rich execution environment REE and / or TEE virtual machine based on the functional services of the corresponding devices provided by the device driver implementation layer.

[0017] In some possible implementations, the shared driver service includes at least one of the following: a GPU, a camera, and an LCD.

[0018] In some possible implementations, the universal driver framework is a Linux driver framework or other operating system driver framework.

[0019] According to a third aspect, a device calling method is provided, which is applied to a virtualization system such as the first aspect, including: a first application running in any TEE virtual machine in a trusted execution environment TEE responds to a target device operation instruction and calls a target device interface provided by a target driver semi-virtualization module running in any TEE virtual machine; the target driver semi-virtualization module converts the target device operation instruction into a target device virtual control instruction and sends it to a driver virtual host running in the trusted execution environment; the driver virtual host converts the target device virtual control instruction into a target device physical control instruction, and converts the target device physical control instruction into a target device hardware control instruction by reusing a shared device driver developed by a general driver framework, thereby realizing operational control of the target device.

[0020] In a possible implementation, the method further includes: the target driver semi-virtualization module sends the target device virtual control instruction to the virtual machine secure communication module in the operating system running in the trusted execution environment TEE; the virtual machine secure communication module forwards the target device virtual control instruction to the driver virtual host.

[0021] In one possible implementation, the target driver semi-virtualization module also includes: a device driver implementation layer and a device driver service layer for the target device, and the method also includes: the device driver service layer obtains the target device operation instruction in response to the call operation of the first application, and sends the target device operation instruction to the device driver implementation layer; the device driver implementation layer converts the target device operation instruction into a corresponding target device virtual control instruction, and sends it to the virtual machine secure communication module in the operating system running in the trusted execution environment TEE.

[0022] In a possible implementation, the driver virtual host also includes: a shared device driver service layer, a shared device driver implementation layer and a driver framework layer corresponding to the target device, and the method also includes: the shared device driver service layer receives the target device virtual control instructions, and sends the target device virtual control instructions to the shared device driver implementation layer; the shared device driver implementation layer converts the target device virtual control instructions into target device physical control instructions, and sends them to the driver framework layer; the driver framework layer converts the target device physical control instructions into target device hardware control instructions, thereby realizing control operations on the target device.

[0023] In a fourth aspect, a device calling method is provided, which is applied to a virtualization system such as the first aspect, and the method includes: a second application running in a rich execution environment REE responds to a target device operation instruction and calls a target device interface provided by a target driver semi-virtualization module running in the rich execution environment REE; the target driver semi-virtualization module converts the target device operation instruction into a target device virtual control instruction, and sends it to a driver virtual host running in a trusted execution environment TEE; the driver virtual host converts the target device virtual control instruction into a target device physical control instruction, and converts the target device physical control instruction into a target device hardware control instruction by reusing a shared device driver developed by a general driver framework, thereby realizing operational control of the target device.

[0024] In one possible implementation, the target driver semi-virtualization module also includes: a device driver implementation layer and a device driver service layer for the target device, and the method also includes: the device driver service layer obtains the target device operation instruction in response to the call operation of the second application, and sends the target device operation instruction to the device driver implementation layer; the device driver implementation layer converts the target device operation instruction into a corresponding target device virtual control instruction, and sends it to the driver virtual host through the environment interaction interface; wherein the environment interaction interface is used to realize information interaction between the rich execution environment REE and the trusted execution environment TEE.

[0025] In a possible implementation, the driver virtual host also includes: a shared device driver service layer, a shared device driver implementation layer and a driver framework layer for at least the target device, and the method also includes: the shared device driver service layer receives the target device virtual control instructions, and sends the target device virtual control instructions to the device driver implementation layer corresponding to the target device; the shared device driver implementation layer converts the target device virtual control instructions into target device physical control instructions, and sends them to the driver framework layer; the driver framework layer converts the target device physical control instructions into target device hardware control instructions, thereby realizing control operations on the target device.

[0026] At least one of the above-mentioned technical solutions adopted in the embodiments of the present application can achieve the following beneficial effects: In this embodiment, a virtualization method based on a driver virtual host is innovatively adopted within the TEE. In the driver virtual host, general device drivers such as the Linux driver framework or other operating system driver frameworks are reused for use by the TEE virtual machine and REE, thereby avoiding repeated development of related device drivers, reducing the complexity of driver development, and reducing the cost of driver development.

[0027] It should be understood that the above description is only an overview of the technical solution of the present invention, so that the technical means of the present invention can be more clearly understood and implemented according to the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are described below by way of example. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] The advantages and benefits described herein and other advantages and benefits will be apparent to those of ordinary skill in the art by reading the detailed description of the exemplary embodiments below. The accompanying drawings are only used for the purpose of illustrating exemplary embodiments and are not to be considered as limiting the present invention. Moreover, the same reference numerals are used throughout the accompanying drawings to represent the same components. In the accompanying drawings:

[0029] Figure 1 is a schematic diagram of a paravirtualization solution according to the prior art;

[0030] Figure 2 A schematic diagram of the structure of a virtualization system for a trusted execution environment according to an embodiment of the present invention;

[0031] Figure 3 A schematic diagram of the structure of a virtualization system for a trusted execution environment according to another embodiment of the present invention;

[0032] Figure 4 A schematic diagram of a flow chart of a virtualization method for a trusted execution environment according to an embodiment of the present invention;

[0033] Figure 5 FIG. 4 is a schematic diagram of the structure of a virtualization device for a trusted execution environment according to another embodiment of the present invention.

[0034] In the drawings, the same or corresponding reference numerals represent the same or corresponding parts. DETAILED DESCRIPTION

[0035] The exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although the exemplary embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.

[0036] In the description of the embodiments of the present application, it should be understood that terms such as "including" or "having" are intended to indicate the presence of features, numbers, steps, behaviors, components, parts, or a combination thereof disclosed in this specification, and are not intended to exclude the possibility of the presence of one or more other features, numbers, steps, behaviors, components, parts, or a combination thereof.

[0037] Unless otherwise specified, “ / ” means or. For example, A / B can mean A or B. The “and / or” in this article is merely a way to describe the association relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone.

[0038] The terms "first", "second", etc. are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Thus, a feature defined as "first", "second", etc. may explicitly or implicitly include one or more of the features. In the description of the embodiments of the present application, unless otherwise specified, "plurality" means two or more.

[0039] All codes in this application are exemplary, and those skilled in the art may think of various modifications based on the programming language used, specific needs, personal habits and other factors without departing from the concept of this application.

[0040] It should also be noted that, in the absence of conflict, the embodiments and features of the embodiments of the present invention can be combined with each other. The present invention will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0041] Figure 2 It is a structural diagram of a virtualization system for a trusted execution environment according to an embodiment of the present application.

[0042] like Figure 2 As shown, the virtualization system is deployed on a terminal including a trusted execution environment TEE and a rich execution environment REE, and the virtualization system may include:

[0043] A driver virtual host 21 runs in a trusted execution environment TEE and is used to reuse a shared device driver developed by a general driver framework within the trusted execution environment TEE to provide a shared driver service in the trusted execution environment TEE;

[0044] At least one driver paravirtualization module 22 runs in a TEE virtual machine in a rich execution environment REE and / or an executable environment TEE, and is used to call a shared driver service provided by a driver virtual host, and use the shared driver service to provide corresponding device driver services in the rich execution environment REE and / or the TEE virtual machine.

[0045] It can be understood that the driver virtual host 21 is a special virtual machine responsible for shared driver implementation within the TEE, and this virtual machine only provides shared driver services. The driver semi-virtualization module 22 can be a module in the TEE virtual machine responsible for specific device driver services, or a module in the rich execution environment REE responsible for specific device driver services.

[0046] The rich execution environment REE may be a rich operating system such as Android, IOS, etc., and this application does not impose any specific limitation on this.

[0047] Shared driver services can be driver services for shared devices. It can be understood that drivers such as GPU, camera, NFC, LCD, etc., which have large amounts of code and complex protocol stacks, can set these peripherals as shared devices and be compatible with complex drivers such as GPU, camera, NFC, LCD, etc. developed by a general driver framework (such as Linux) through a hardware-assisted full virtualization method in the driver virtual host 21.

[0048] In this embodiment, a virtualization method based on a driver virtual host is innovatively adopted within the TEE. In the driver virtual host, general device drivers such as the Linux driver framework or other operating system driver frameworks are reused for use by the TEE virtual machine and REE, thereby avoiding repeated development of related device drivers, reducing the complexity of driver development, and reducing driver development costs.

[0049] Understandably, Figure 2 In the figure, it is shown that one driver paravirtualization module is respectively run in the rich execution environment REE, and two driver paravirtualization modules are respectively run in two TEE virtual machines in the executable environment TEE. However, it is also possible to run one or more driver paravirtualization modules only in the rich execution environment REE, or to run driver paravirtualization modules only in one or more TEE virtual machines in the executable environment TEE, and so on. The present application does not impose a specific limit on the number of driver paravirtualization modules.

[0050] Figure 3 FIG. 1 is a schematic diagram of a virtualization system for a trusted execution environment according to an embodiment of the present application. Figure 2 Based on the illustrated embodiment, the composition of the virtualization system is further described in detail.

[0051] like Figure 3 As shown, in some possible implementations, to achieve secure communication, the virtualization implementation system may also include: a virtual machine secure communication module 23, which runs in the operating system (TEE OS) of the trusted execution environment TEE and is responsible for providing secure communication services for the virtual driver host 21 and the driver paravirtualization module 22 running in the TEE virtual machine.

[0052] In some other possible implementations, the virtual machine secure communication module can also provide secure communication services for communication between several TEE virtual machines in the trusted execution environment TEE.

[0053] In one example, multiple security policies are deployed in the virtual machine secure communication module 23, and whether any two or more virtual machines can communicate securely can be determined based on the security policies. The above security policies can be preset by the developer or set based on the virtual machine status.

[0054] like Figure 3 As shown, in some possible implementations, the driver virtual host 21 may further include a driver framework layer 211, a shared device driver implementation layer 212, and a shared device driver service layer 213, wherein the driver framework layer 211 is used to provide device driver basic services compatible with the general driver framework to support the basic operating environment of the shared device driver developed based on the general driver framework. The shared device driver implementation layer 212 is used to complete the driver implementation of the shared device developed based on the general driver framework. The shared device driver service layer 213 is used to provide shared driver services for the driver semi-virtualization module based on the functions for the shared device provided by the shared device driver implementation layer.

[0055] like Figure 3 As shown, in some possible implementations, the driver semi-virtualization module 22 running in the TEE virtual machine may further include a device driver implementation layer 221 and a device driver service layer 222, wherein the device driver implementation layer 221 is used to call the shared driver service provided by the shared device driver service layer 213 through the virtual machine security communication module 23 implemented in the TEE OS, and provide basic functional support for the corresponding device in the TEE virtual machine based on the shared driver service to complete the driver implementation of the corresponding device. The device driver service layer 222 is used to provide the TEE virtual machine with the corresponding device driver service based on the functional service of the corresponding device provided by the device driver implementation layer 221. As a result, there is no need to repeatedly develop related device drivers in the TEE, and the related functional operations of the shared driver can be used in the TEE virtual machine.

[0056] like Figure 3 As shown, in some other possible implementations, the semi-virtualization module 22 running the driver in the REE may further include a device driver implementation layer 221 and a device driver service layer 222, wherein the device driver implementation layer is used to call the shared driver service provided by the shared device driver service layer 213 through the TEE interface deployed in the REE and the TEE interaction interface deployed in the TEE, and use the shared driver service to provide basic functional support for the corresponding device in the REE to complete the driver implementation of the corresponding device. The device driver service layer 222 is used to provide the corresponding device driver service to the REE based on the functional service of the corresponding device provided by the device driver implementation layer 221. As a result, there is no need to repeatedly develop relevant device drivers in the TEE or REE, and the relevant functional operations of the shared driver can be used in the REE.

[0057] In some possible implementations, the shared driver service is a driver service for a shared device, and the shared device may include at least one of the following: a GPU, a camera, an LCD, etc. In some possible implementations, the universal driver framework is a Linux driver framework or other operating system driver frameworks.

[0058] In the description of this specification, the description with reference to the terms "some possible implementations", "some embodiments", "examples", "specific examples", or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples, unless they are contradictory.

[0059] In addition, in the description of the present invention, “plurality” means at least two, for example, two, three, etc., unless otherwise clearly and specifically defined.

[0060] Based on the same technical concept, an embodiment of the present invention further provides a virtualization method for a trusted execution environment, which is applied to a virtualization implementation system provided by any of the above embodiments. Figure 4 A flowchart of a virtualization method for a trusted execution environment provided by an embodiment of the present invention.

[0061] like Figure 4 As shown, the method 400 includes:

[0062] S401: The driver virtual host running in the trusted execution environment TEE reuses the shared device driver developed by the general driver framework inside the trusted execution environment TEE to provide a shared driver service in the trusted execution environment TEE;

[0063] S402: At least one driver paravirtualization module running in the TEE virtual machine in the rich execution environment REE and / or the executable environment TEE calls the shared driver service provided by the driver virtual host, and provides corresponding device driver services in the rich execution environment REE and / or the TEE virtual machine based on the shared driver service.

[0064] In this embodiment, a virtualization method based on a driver virtual host is innovatively adopted within the TEE. In the driver virtual host, general device drivers such as the Linux driver framework or other operating system driver frameworks are reused for use by the TEE virtual machine and REE, thereby avoiding repeated development of related device drivers, reducing the complexity of driver development, and reducing driver development costs.

[0065] In some possible implementations, the method further includes: utilizing a virtual machine secure communication module in an operating system running in the trusted execution environment TEE to provide secure communication services between the virtual driver host and the driver paravirtualization module running in the TEE virtual machine.

[0066] In some possible implementations, the driver virtual host includes a driver framework layer, a shared device driver implementation layer and a shared device driver service layer, and the method also includes: the driver framework layer provides device driver basic services compatible with the universal driver framework to support the basic operating environment of the shared device driver developed based on the universal driver framework; the shared device driver implementation layer executes the driver implementation of the shared device developed based on the universal driver framework; the shared device driver service layer provides the shared driver service to the driver semi-virtualization module based on the functions for the shared device provided by the shared device driver implementation layer.

[0067] In some possible implementations, the driver semi-virtualization module includes a device driver implementation layer and a device driver service layer, and the method also includes: the device driver implementation layer calls the shared driver service provided by the shared device driver service layer, and provides basic functional support for the corresponding devices in the rich execution environment REE and / or the TEE virtual machine based on the shared driver service to complete the driver implementation of the corresponding device; the device driver service layer provides the corresponding device driver service to the rich execution environment REE and / or the TEE virtual machine based on the functional service of the corresponding device provided by the device driver implementation layer.

[0068] In some possible implementations, the shared drive service includes at least one of the following: a GPU, a camera, and an LCD.

[0069] In some possible implementations, the universal driver framework is a Linux driver framework or other operating system driver framework.

[0070] It should be noted that the virtualization method in the embodiment of the present application can implement the various processes of the embodiment of the aforementioned virtualization system and achieve the same effects and functions, which will not be repeated here.

[0071] In an embodiment of the present application, a device calling method is also provided, which is applied to the virtualization system described in the above embodiment. The method specifically includes: a first application running in any TEE virtual machine in a trusted execution environment TEE responds to a target device operation instruction, and calls a target device interface provided by a target driver semi-virtualization module running in any TEE virtual machine; the target driver semi-virtualization module converts the target device operation instruction into a target device virtual control instruction, and sends it to a driver virtual host running in the trusted execution environment; the driver virtual host converts the target device virtual control instruction into a target device physical control instruction, and converts the target device physical control instruction into a target device hardware control instruction by reusing a shared device driver developed by a general driver framework, thereby realizing operational control of the target device.

[0072] The shared device driver can be a driver for a device with a large amount of code and a complex protocol stack, such as a GPU, camera, NFC, LCD, etc. The target device can be any one or more of the shared devices. The target driver paravirtualization module is a driver paravirtualization module corresponding to the target device, such as a driver paravirtualization module corresponding to a camera device and a driver paravirtualization module corresponding to an NFC device.

[0073] refer to Figure 2 , the first application can be deployed in any TEE virtual machine in the trusted execution environment TEE, which can be any application such as face payment application, NFC payment application, etc. that needs to call the target device. For example, if a TEE virtual machine is a TEE virtual machine corresponding to a payment system (such as UnionPay payment system), then the face payment application and NFC payment application of the payment system can be deployed in the TEE virtual machine. Furthermore, when the face payment application needs to call the camera device, the driver semi-virtualization module corresponding to the camera device can be called in the TEE virtual machine, that is, the target driver semi-virtualization module. The driver semi-virtualization module of the camera device calls the driver virtual host running in the trusted execution environment. As described in the above embodiment, the driver virtual host is a special virtual machine responsible for the shared driver implementation inside the TEE. This virtual machine reuses the shared device driver developed by the general driver framework (such as the Linux driver framework). The shared devices supported by the driver virtual host include the target device. Therefore, the operation control of the target device can be achieved by calling the driver virtual host.

[0074] In a possible implementation, the method further includes: the target driver semi-virtualization module sends the target device virtual control instruction to the virtual machine secure communication module in the operating system running in the trusted execution environment TEE; the virtual machine secure communication module forwards the target device virtual control instruction to the driver virtual host.

[0075] In one possible implementation, the target driver semi-virtualization module also includes: a device driver implementation layer and a device driver service layer for the target device, and the method also includes: the device driver service layer obtains the target device operation instruction in response to the call operation of the first application, and sends the target device operation instruction to the device driver implementation layer; the device driver implementation layer converts the target device operation instruction into a corresponding target device virtual control instruction, and sends it to the virtual machine secure communication module in the operating system running in the trusted execution environment TEE.

[0076] In a possible implementation, the driver virtual host also includes: a shared device driver service layer, a shared device driver implementation layer and a driver framework layer corresponding to the target device, and the method also includes: the shared device driver service layer receives the target device virtual control instructions, and sends the target device virtual control instructions to the shared device driver implementation layer; the shared device driver implementation layer converts the target device virtual control instructions into target device physical control instructions, and sends them to the driver framework layer; the driver framework layer converts the target device physical control instructions into target device hardware control instructions, thereby realizing control operations on the target device.

[0077] In some possible implementations, the universal driver framework is a Linux driver framework or other operating system driver frameworks.

[0078] It should be noted that the device calling method in the embodiment of the present application can implement the various processes of the embodiment of the aforementioned virtualization system and achieve the same effects and functions, which will not be repeated here.

[0079] In one example, the first application is a payment application provided by payment system A, and the target device is a camera device. It is understandable that the payment application may need to call the camera device to obtain the user's real-time facial image to perform facial payment during use. The trusted execution environment TEE may have TEE virtual machines of multiple systems deployed at the same time, such as TEE virtual machine 1 for payment system A and TEE virtual machine 2 for payment system B. At this time, if the payment application of payment system A in TEE virtual machine 1 needs to call the camera device, the camera device interface (API) provided by the camera device driver service layer in the target driver semi-virtualization module (that is, the driver semi-virtualization module for the camera device) in the TEE virtual machine 1 can be called. The camera device driver service layer sends the camera device operation instructions corresponding to the camera interface to the camera device driver implementation layer in the TEE virtual machine. The camera device driver implementation layer in the TEE virtual machine converts the camera device operation instructions into corresponding camera device virtual control instructions and sends them to the virtual machine secure communication module in the TEE OS. The TEE The virtual machine security communication module in the OS forwards the camera device virtual control instructions to the shared device driver service layer in the driver virtual host. The shared device driver service layer sends the camera virtual control instructions to the shared device driver implementation layer. The shared device driver implementation layer converts the camera device virtual control instructions into camera device physical control instructions and sends them to the Linux-like driver framework layer. The Linux-like driver framework layer converts the camera device physical control instructions into camera device hardware control instructions, thereby realizing control of the camera device and data transmission.

[0080] In an embodiment of the present application, another device calling method is also provided, which is applied to the virtualization system as described in the above embodiment, and the method specifically includes: a second application running in a rich execution environment REE responds to a target device operation instruction and calls a target device interface provided by a target driver semi-virtualization module running in the rich execution environment REE; the target driver semi-virtualization module converts the target device operation instruction into a target device virtual control instruction and sends it to a driver virtual host running in a trusted execution environment TEE; the driver virtual host converts the target device virtual control instruction into a target device physical control instruction, and converts the target device physical control instruction into a target device hardware control instruction by reusing a shared device driver developed by a general driver framework, thereby realizing operational control of the target device.

[0081] The shared device driver can be a driver for a device with a large amount of code and a complex protocol stack, such as a GPU, camera, NFC, LCD, etc. The target device can be any one or more of the shared devices. The target driver paravirtualization module is a driver paravirtualization module corresponding to the target device, such as a driver paravirtualization module corresponding to a camera device and a driver paravirtualization module corresponding to an NFC device.

[0082] refer to Figure 2 , the second application runs in the rich execution environment REE, which can be any application program that needs to call the target device, such as a face application. For example, when the face application needs to call a camera device, the driver semi-virtualization module corresponding to the camera device can be called in the REE, that is, the target driver semi-virtualization module. The driver semi-virtualization module of the camera device can call the driver virtual host running in the trusted execution environment TEE through the interconnection interface between environments. As described in the above embodiment, the driver virtual host is a special virtual machine responsible for the shared driver implementation inside the TEE. This virtual machine reuses the shared device driver developed by the general driver framework (such as the Linux driver framework). The shared devices supported by the driver virtual host include the target device. Therefore, the operation control of the target device can be achieved by calling the driver virtual host.

[0083] In one possible implementation, the target driver semi-virtualization module also includes: a device driver implementation layer and a device driver service layer for the target device, and the method also includes: the device driver service layer obtains the target device operation instruction in response to the call operation of the second application, and sends the target device operation instruction to the device driver implementation layer; the device driver implementation layer converts the target device operation instruction into a corresponding target device virtual control instruction, and sends it to the driver virtual host through the environment interaction interface; wherein the environment interaction interface is used to realize information interaction between the rich execution environment REE and the trusted execution environment TEE.

[0084] Environmental interaction interfaces can include Figure 3 The TEE interface and TEE interaction interface shown in .

[0085] In a possible implementation, the driver virtual host also includes: a shared device driver service layer, a shared device driver implementation layer and a driver framework layer for at least the target device, and the method also includes: the shared device driver service layer receives the target device virtual control instructions, and sends the target device virtual control instructions to the device driver implementation layer corresponding to the target device; the shared device driver implementation layer converts the target device virtual control instructions into target device physical control instructions, and sends them to the driver framework layer; the driver framework layer converts the target device physical control instructions into target device hardware control instructions, thereby realizing control operations on the target device.

[0086] In some possible implementations, the universal driver framework is a Linux driver framework or other operating system driver frameworks.

[0087] It should be noted that the device calling method in the embodiment of the present application can implement the various processes of the embodiment of the aforementioned virtualization system and achieve the same effects and functions, which will not be repeated here.

[0088] In one example, the second application is a face application and the target device is a camera device. The face application can be any application that needs to process a face image. It is understandable that the face application may need to call a camera device to obtain a face image to perform image processing during use. At this time, if the second application in the REE needs to call the camera device, it can call the camera device interface (API) provided by the camera device driver service layer in the target driver semi-virtualization module (that is, the driver semi-virtualization module for the camera device) in the REE. The camera device driver service layer sends the camera device operation instructions corresponding to the camera interface to the camera device driver implementation layer of the target driver semi-virtualization module. The camera device driver implementation layer of the target driver semi-virtualization module converts the camera device operation instructions into corresponding camera device virtual control instructions, and sends them to the shared device driver service layer in the driver virtual host in the TEE through the environment interaction interface. The shared device driver service layer sends the camera virtual control instructions to the shared device driver implementation layer. The shared device driver implementation layer converts the camera device virtual control instructions into camera device physical control instructions, and sends them to the Linux-like driver framework layer. The Linux-like driver framework layer converts the camera device physical control instructions into camera device hardware control instructions, thereby realizing control of the camera device and data transmission.

[0089] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, segment or portion of code that includes one or more executable instructions for implementing the steps of a specific logical function or process, and the scope of the preferred embodiments of the present invention includes alternative implementations in which functions may not be performed in the order shown or discussed, including performing functions in a substantially simultaneous manner or in the reverse order depending on the functions involved, which should be understood by those skilled in the art to which the embodiments of the present invention belong.

[0090] About the method flow chart of the embodiment of the present application, some operations are described as different steps performed in a certain order.Such flow chart belongs to illustrative and non-restrictive.Some steps described in this article can be grouped together and performed in a single operation, some steps can be divided into multiple sub-steps, and some steps can be performed in an order different from that shown in this article.The various steps shown in the flow chart can be realized in any way by any circuit structure and / or tangible mechanism (for example, by software, hardware (for example, the logical function realized by processor or chip) etc. running on computer equipment and / or any combination thereof).

[0091] Figure 5 A virtualization device for a trusted execution environment according to an embodiment of the present application, for executing Figure 4 The virtualization method shown, the device includes: at least one processor; and a memory connected to the at least one processor in communication; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the method described in the above embodiment.

[0092] According to some embodiments of the present application, a non-volatile computer storage medium for a virtualization method for a trusted execution environment is provided, on which computer executable instructions are stored, and the computer executable instructions are configured to execute the method described in the above embodiments when executed by a processor.

[0093] Each embodiment in this application is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device, equipment, and computer-readable storage medium embodiments, since they are basically similar to the method embodiments, their descriptions are simplified, and the relevant parts can be referred to the partial description of the method embodiments.

[0094] The apparatus, device and computer-readable storage medium provided in the embodiments of the present application correspond one-to-one to the method. Therefore, the apparatus, device and computer-readable storage medium also have similar beneficial technical effects as the corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the apparatus, device and computer-readable storage medium will not be repeated here.

[0095] It will be appreciated by those skilled in the art that embodiments of the present invention may be provided as methods, systems or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0096] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0097] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0098] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0099] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0100] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0101] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be used to store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, read-only compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. In addition, although the operations of the method of the present invention are described in a particular order in the accompanying drawings, this does not require or imply that these operations must be performed in this particular order, or that all the operations shown must be performed to achieve the desired results. Additionally or alternatively, some steps can be omitted, multiple steps can be combined into one step, and / or one step can be decomposed into multiple steps.

[0102] Although the spirit and principle of the present invention have been described with reference to several specific embodiments, it should be understood that the present invention is not limited to the disclosed specific embodiments, and the division of various aspects does not mean that the features in these aspects cannot be combined to benefit, and such division is only for the convenience of expression. The present invention is intended to cover various modifications and equivalent arrangements included in the spirit and scope of the attached claims.

Claims

1. A virtualization system for a trusted execution environment, characterized in that: The system comprises: A driver virtual host, running in a trusted execution environment TEE, is used to reuse a shared device driver developed by a general driver framework within the trusted execution environment TEE to provide a shared driver service in the trusted execution environment TEE; At least one driver paravirtualization module, running in the rich execution environment REE and / or the TEE virtual machine in the trusted execution environment TEE, is used to call the shared driver service provided by the driver virtual host, and provide corresponding device driver services in the rich execution environment REE and / or the TEE virtual machine based on the shared driver service, The driver virtual host includes: The driver framework layer is used to provide basic device driver services compatible with the universal driver framework to support the basic operating environment of shared device drivers developed based on the universal driver framework; A shared device driver implementation layer, used to implement driver implementation of shared devices developed based on the general driver framework; The shared device driver service layer is used to provide the shared driver service for the driver paravirtualization module based on the function for the shared device provided by the shared device driver implementation layer.

2. The system according to claim 1, characterized in that The virtualization system further includes: A virtual machine secure communication module runs in the operating system of the trusted execution environment TEE and is used to provide secure communication services for the driver virtual host and the driver paravirtualization module running in the TEE virtual machine.

3. The system according to claim 2, characterized in that The driver semi-virtualization module also includes: The device driver implementation layer is used to call the shared driver service provided by the shared device driver service layer, and provide basic functional support for the corresponding device in the rich execution environment REE and / or the TEE virtual machine based on the shared driver service to complete the driver implementation of the corresponding device; The device driver service layer is used to provide the corresponding device driver service to the rich execution environment REE and / or the TEE virtual machine based on the functional service of the corresponding device provided by the device driver implementation layer.

4. The system according to claim 1, characterized in that The shared drive service includes at least one of the following: GPU, camera, LCD.

5. The system according to claim 1, characterized in that The universal driver framework is a Linux driver framework or other operating system driver framework.

6. A virtualization method for a trusted execution environment, characterized in that: Applied to the virtualization system according to any one of claims 1 to 5, the method comprises: The driver virtual host running in the trusted execution environment TEE reuses the shared device driver developed by the general driver framework inside the trusted execution environment TEE to provide a shared driver service in the trusted execution environment TEE; At least one driver paravirtualization module running in a TEE virtual machine in a rich execution environment REE and / or in the trusted execution environment TEE calls the shared driver service provided by the driver virtual host, and provides corresponding device driver services in the rich execution environment REE and / or in the TEE virtual machine based on the shared driver service, The driver virtual host includes a driver framework layer, a shared device driver implementation layer and a shared device driver service layer, and the method further includes: The driver framework layer provides basic device driver services compatible with the universal driver framework to support a basic operating environment for shared device drivers developed based on the universal driver framework; The shared device driver implementation layer performs driver implementation of shared devices developed based on the universal driver framework; The shared device driver service layer provides the shared driver service for the driver paravirtualization module based on the function for the shared device provided by the shared device driver implementation layer.

7. The method according to claim 6, characterized in that The method further comprises: A secure communication service is provided between the driver virtual host and the driver paravirtualization module running in the TEE virtual machine by utilizing the virtual machine secure communication module in the operating system running in the trusted execution environment TEE.

8. The method according to claim 6, characterized in that The driver semi-virtualization module includes a device driver implementation layer and a device driver service layer, and the method further includes: The device driver implementation layer calls the shared driver service provided by the shared device driver service layer, and provides basic functional support for the corresponding device in the rich execution environment REE and / or the TEE virtual machine based on the shared driver service to complete the driver implementation of the corresponding device; The device driver service layer provides the corresponding device driver service to the rich execution environment REE and / or the TEE virtual machine based on the functional service of the corresponding device provided by the device driver implementation layer.

9. The method according to claim 6, characterized in that The shared drive service includes at least one of the following: GPU, camera, LCD.

10. The method according to claim 6, characterized in that The universal driver framework is a Linux driver framework or other operating system driver framework.

11. A device calling method, characterized in that: A virtualization system applied to any one of claims 1 to 5, comprising: The first application running in any one TEE virtual machine in the trusted execution environment TEE responds to the target device operation instruction and calls the target device interface provided by the target driver paravirtualization module running in any one TEE virtual machine; The target driver semi-virtualization module converts the target device operation instruction into a target device virtual control instruction, and sends the instruction to the driver virtual host running in the trusted execution environment; The driver virtual host converts the target device virtual control instructions into target device physical control instructions, and converts the target device physical control instructions into target device hardware control instructions by reusing the shared device driver developed by the general driver framework, thereby realizing operational control of the target device.

12. The method according to claim 11, characterized in that The method further comprises: The target driver paravirtualization module sends the target device virtual control instruction to the virtual machine secure communication module running in the operating system of the trusted execution environment TEE; The virtual machine secure communication module forwards the target device virtual control instruction to the driver virtual host.

13. The method according to claim 12, characterized in that The target driver semi-virtualization module further includes: a device driver implementation layer and a device driver service layer for the target device, and the method further includes: The device driver service layer obtains the target device operation instruction in response to the calling operation of the first application, and sends the target device operation instruction to the device driver implementation layer; The device driver implementation layer converts the target device operation instruction into a corresponding target device virtual control instruction and sends it to a virtual machine secure communication module in the operating system running in the trusted execution environment TEE.

14. The method according to any one of claims 11 to 13, characterized in that: The driver virtual host also includes: a shared device driver service layer, a shared device driver implementation layer and a driver framework layer corresponding to the target device, and the method also includes: The shared device driver service layer receives the target device virtual control instruction, and sends the target device virtual control instruction to the shared device driver implementation layer; The shared device driver implementation layer converts the target device virtual control instruction into the target device physical control instruction and sends it to the driver framework layer; The driver framework layer converts the physical control instructions of the target device into hardware control instructions of the target device, thereby realizing the control operation on the target device.

15. A device calling method, characterized in that: Applied to the virtualization system according to any one of claims 1 to 5, the method comprises: The second application running in the rich execution environment REE calls the target device interface provided by the target driver paravirtualization module running in the rich execution environment REE in response to the target device operation instruction; The target driver paravirtualization module converts the target device operation instruction into a target device virtual control instruction and sends it to the driver virtual host running in the trusted execution environment TEE; The driver virtual host converts the target device virtual control instructions into target device physical control instructions, and converts the target device physical control instructions into target device hardware control instructions by reusing the shared device driver developed by the general driver framework, thereby realizing operational control of the target device.

16. The method according to claim 15, characterized in that The target driver semi-virtualization module further includes: a device driver implementation layer and a device driver service layer for the target device, and the method further includes: The device driver service layer obtains the target device operation instruction in response to the calling operation of the second application, and sends the target device operation instruction to the device driver implementation layer; The device driver implementation layer converts the target device operation instruction into a corresponding target device virtual control instruction, and sends it to the driver virtual host through the environment interaction interface; Among them, the environment interaction interface is used to realize information interaction between the rich execution environment REE and the trusted execution environment TEE.

17. The method according to claim 15 or 16, characterized in that The driver virtual host further includes: a shared device driver service layer, a shared device driver implementation layer and a driver framework layer at least for the target device, and the method further includes: The shared device driver service layer receives the target device virtual control instruction, and sends the target device virtual control instruction to the device driver implementation layer corresponding to the target device; The shared device driver implementation layer converts the target device virtual control instruction into the target device physical control instruction and sends it to the driver framework layer; The driver framework layer converts the physical control instructions of the target device into hardware control instructions of the target device, thereby realizing the control operation on the target device.

Images