CN112817697A - Virtualization system and method for trusted execution environment and device calling method - Google Patents

Virtualization system and method for trusted execution environment and device calling method Download PDF

Info

Publication number
CN112817697A
CN112817697A CN202110178416.2A CN202110178416A CN112817697A CN 112817697 A CN112817697 A CN 112817697A CN 202110178416 A CN202110178416 A CN 202110178416A CN 112817697 A CN112817697 A CN 112817697A
Authority
CN
China
Prior art keywords
driver
driving
shared
target
tee
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202110178416.2A
Other languages
Chinese (zh)
Inventor
曾望年
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Unionpay Co Ltd
Original Assignee
China Unionpay Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Unionpay Co Ltd filed Critical China Unionpay Co Ltd
Priority to CN202110178416.2A priority Critical patent/CN112817697A/en
Publication of CN112817697A publication Critical patent/CN112817697A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/45562Creating, deleting, cloning virtual machine instances

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

The invention provides a virtualization system, a virtualization method and a device calling method facing to a trusted execution environment, wherein the virtualization system comprises: the driving virtual host runs in the trusted execution environment TEE and is used for multiplexing a shared device driver developed by a general driving framework inside the trusted execution environment TEE so as to provide shared driving service in the trusted execution environment TEE; and the at least one driving paravirtualization module runs in the rich execution environment REE and/or a TEE virtual machine in the execution environment TEE, and is used for calling the shared driving service provided by the driving virtual host and providing the corresponding device driving service in the rich execution environment REE and/or the TEE virtual machine based on the shared driving service. By utilizing the system and the method, the repeated development of the related equipment driver can be avoided, the complexity of driver development is reduced, and the cost of driver development is reduced.

Description

Virtualization system and method for trusted execution environment and device calling method
Technical Field
The invention belongs to the field of operating systems, and particularly relates to a virtualization system and a virtualization method for a trusted execution environment.
Background
This section is intended to provide a background or context to the embodiments of the invention that are recited in the claims. The description herein is not admitted to be prior art by inclusion in this section.
The trusted Execution environment tee (trusted Execution environment) technology can provide a trusted Execution environment/operating system protected by hardware isolation for a smart terminal such as a mobile phone.
Currently, the TEE technology has been popularized in smart phones and gradually expanded from the mobile phones to the fields of automotive electronics, industrial terminals, and the like. The ecological and equipment types of industries covered by the TEE become more and more diversified, how a plurality of service parties TEE safely coexist on one equipment becomes more and more important, and a multi-TEE virtual machine solution based on a virtualization technology can well solve the requirements.
In the prior art, a paravirtualization scheme is adopted, referring to fig. 1, for a requirement that multiple TEE operating systems (TEE OSs) coexist in the same device, a paravirtualization method is adopted to simultaneously run multiple TEE OSs and TEE virtual machine device drivers (such as a GPU, a camera, an LCD, and the like) in a hardware isolation environment, and a paravirtualization module calls the device drivers provided by the TEE OSs to complete related device operations. However, in the existing paravirtualization scheme, the device driver is located in the TEE OS, the TEE virtual machine calls the device driver provided by the TEE OS through the paravirtualization module to complete the related device operation, because the drive reference implementation provided by hardware and chip manufacturers mainly aims at the Linux-like system, and the TEE platform driver architecture is greatly different from the Linux-like system, for devices with higher complexity (such as a GPU, a camera, an LCD, and the like), the workload for developing the device driver on the TEE platform is very large, and the floor popularization of the scheme is greatly influenced.
Disclosure of Invention
In view of the problems in the prior art, a virtualization system and method for a trusted execution environment are provided, and the problems can be solved by using the virtualization system and method.
The present invention provides the following.
In a first aspect, a virtualization system oriented to a trusted execution environment is provided, where the virtualization system includes: the driving virtual host runs in the trusted execution environment TEE and is used for multiplexing a shared device driver developed by a general driving framework inside the trusted execution environment TEE so as to provide shared driving service in the trusted execution environment TEE; and the at least one driving paravirtualization module runs in the rich execution environment REE and/or a TEE virtual machine in the execution environment TEE, and is used for calling the shared driving service provided by the driving virtual host and providing the corresponding device driving service in the rich execution environment REE and/or the TEE virtual machine based on the shared driving service.
In some possible embodiments, the virtualization implementation system further includes: and the virtual machine security communication module runs in an operating system of the trusted execution environment TEE and is used for providing security communication service for the virtual drive host and the drive paravirtualization module running in the TEE virtual machine.
In some possible embodiments, the driving the virtual host further includes: the driving framework layer is used for providing device driving basic services compatible with the universal driving framework so as to support a basic operation environment of the shared device driver developed based on the universal driving framework; the shared device driving implementation layer is used for implementing the driving implementation of the shared device developed based on the universal driving framework; and the shared device driver service layer is used for providing shared driver service for the driver paravirtualization module based on the function aiming at the shared device provided by the shared device driver implementation layer.
The device driver implementation layer is used for calling a shared driver service provided by the shared device driver service layer and providing basic function support for corresponding devices in the REE and/or TEE virtual machine based on the shared driver service so as to complete the driver implementation of the corresponding devices; and the device driver service layer is used for providing corresponding device driver services for the REE and/or TEE virtual machines based on the function services of the corresponding devices provided by the device driver implementation layer.
Some possible embodiments of the shared drive service include at least one of: GPU, camera, LCD. In some possible embodiments, the generic driver framework is a Linux driver framework or other operating system driver framework.
In a second aspect, a virtualization method oriented to a trusted execution environment is provided, which is applied to the virtualization implementation system as in the first aspect, and the method includes: the driving virtual host running in the trusted execution environment TEE multiplexes a shared device driver developed by a general driving framework inside the trusted execution environment TEE so as to provide a shared driving service in the trusted execution environment TEE; at least one driver paravirtualization module in a TEE virtual machine running in the rich execution environment REE and/or in the executable environment TEE calls a shared driver service provided by a driver virtual host and provides a corresponding device driver service in the rich execution environment REE and/or in the TEE virtual machine based on the shared driver service.
In some possible embodiments, the method further comprises: the method comprises the steps of utilizing a virtual machine security communication module in an operating system running in a trusted execution environment TEE to provide security communication service between a virtual drive host and a drive paravirtualization module in the TEE virtual machine.
In some possible embodiments, the driving virtual host includes a driving framework layer, a shared device driver implementation layer, and a shared device driver service layer, and the method further includes: the driving framework layer provides device driving basic services compatible with the universal driving framework so as to support a basic operation environment of the shared device driver developed based on the universal driving framework; the shared device drive implementation layer executes the drive implementation of the shared device developed based on the universal drive framework; the shared device driver service layer provides shared driver service for the driver paravirtualization module based on the function for the shared device provided by the shared device driver implementation layer.
In some possible embodiments, the driver paravirtualization module includes a device driver implementation layer and a device driver service layer, and the method further includes: the device driver implementation layer calls a shared driver service provided by the shared device driver service layer, and provides basic function support for corresponding devices in the REE and/or TEE virtual machine based on the shared driver service so as to complete the driver implementation of the corresponding devices; the device driver service layer provides corresponding device driver services for the REE and/or TEE virtual machines based on the function services of the corresponding devices provided by the device driver implementation layer.
In some possible embodiments, the shared drive service includes at least one of: GPU, camera, LCD.
In some possible embodiments, the generic driver framework is a Linux driver framework or other operating system driver framework.
In a third aspect, a device call method is provided, which is applied to the virtualization system as in the first aspect, and includes: responding to a target device operation instruction by a first application running in any TEE virtual machine in a trusted execution environment TEE, and calling a target device interface provided by a target driving paravirtualization module running in any TEE virtual machine; the target driving paravirtualization module converts the target equipment operation instruction into a target equipment virtual control instruction and sends the target equipment virtual control instruction to a driving virtual host running in a trusted execution environment; the driving virtual host converts the target equipment virtual control instruction into a target equipment physical control instruction, and converts the target equipment physical control instruction into a target equipment hardware control instruction by multiplexing a shared equipment driver developed by a general driving framework, thereby realizing the operation control of the target equipment.
In one possible embodiment, the method further comprises: the target driving paravirtualization module sends a target device virtual control instruction to a virtual machine security communication module running in an operating system of a Trusted Execution Environment (TEE); and the virtual machine safety communication module forwards the target equipment virtual control instruction to the driving virtual host.
In one possible embodiment, the target-driven para-virtualization module further comprises a device driver implementation layer and a device driver service layer for the target device, and the method further comprises: the device driver service layer responds to the calling operation of the first application, obtains a target device operation instruction and sends the target device operation instruction to the device driver implementation layer; and the device driver implementation layer converts the target device operation instruction into a corresponding target device virtual control instruction and sends the target device virtual control instruction to a virtual machine security communication module running in an operating system of the trusted execution environment TEE.
In one possible embodiment, the driving virtual host further includes: a shared device driver service layer, a shared device driver implementation layer, and a driver framework layer corresponding to the target device, the method further comprising: the shared device driving service layer receives the target device virtual control instruction and sends the target device virtual control instruction to the shared device driving implementation layer; the shared device driver implementation layer converts the target device virtual control instruction into a target device physical control instruction and sends the target device physical control instruction to the driver framework layer; and the driving frame layer converts the physical control instruction of the target equipment into a hardware control instruction of the target equipment, so that the control operation of the target equipment is realized.
In a fourth aspect, a device call method is provided, which is applied to the virtualization system as in the first aspect, and the method includes: responding to the target device operation instruction by a second application running in the rich execution environment REE, and calling a target device interface provided by a target driving para-virtualization module running in the rich execution environment REE; the target driving paravirtualization module converts the target equipment operation instruction into a target equipment virtual control instruction and sends the target equipment virtual control instruction to a driving virtual host running in a Trusted Execution Environment (TEE); the driving virtual host converts the target equipment virtual control instruction into a target equipment physical control instruction, and converts the target equipment physical control instruction into a target equipment hardware control instruction by multiplexing a shared equipment driver developed by a general driving framework, thereby realizing the operation control of the target equipment.
In one possible embodiment, the target-driven para-virtualization module further comprises a device driver implementation layer and a device driver service layer for the target device, and the method further comprises: the device driver service layer responds to the calling operation of the second application, obtains a target device operation instruction 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 the target device virtual control instruction to the driving virtual host through the environment interaction interface; the environment interaction interface is used for realizing information interaction between the rich execution environment REE and the trusted execution environment TEE.
In one possible embodiment, the driving virtual host further includes: at least for a shared device driver service layer, a shared device driver implementation layer, and a driver framework layer of the target device, the method further comprises: the shared equipment driving service layer receives the target equipment virtual control instruction and sends the target equipment virtual control instruction to an equipment driving implementation layer corresponding to the target equipment; the shared device driver implementation layer converts the target device virtual control instruction into a target device physical control instruction and sends the target device physical control instruction to the driver framework layer; and the driving frame layer converts the physical control instruction of the target equipment into a hardware control instruction of the target equipment, so that the control operation of the target equipment is realized.
The embodiment of the application adopts at least one technical scheme which can achieve the following beneficial effects: in the embodiment, a virtualization method based on a driving virtual host is innovatively adopted in the TEE, and a universal device driver such as a Linux driving frame or other operating system driving frames is multiplexed in the driving virtual host to be used by the TEE virtual machine and the REE, so that the repeated development of related device drivers is avoided, the driving development complexity is reduced, and the driving development cost is reduced.
It should be understood that the above description is only an overview of the technical solutions of the present invention, so as to clearly understand the technical means of the present invention, and thus can be implemented according to the content of the description. In order to make the aforementioned and other objects, features and advantages of the present invention comprehensible, embodiments accompanied with figures are described in detail below.
Drawings
The advantages and benefits described herein, as well as other advantages and benefits, will be apparent to those of ordinary skill in the art upon reading the following detailed description of the exemplary embodiments. The drawings are only for purposes of illustrating exemplary embodiments and are not to be construed as limiting the invention. Also, like reference numerals are used to refer to like elements throughout. In the drawings:
FIG. 1 is a schematic diagram of a paravirtualization scheme according to the prior art;
FIG. 2 is a block diagram of a trusted execution environment oriented virtualization system according to an embodiment of the present invention;
FIG. 3 is a block diagram of a virtualized system oriented to a trusted execution environment according to another embodiment of the invention;
FIG. 4 is a flowchart illustrating a trusted execution environment oriented virtualization method according to an embodiment of the present invention;
fig. 5 is a schematic structural diagram of a virtualization apparatus facing a trusted execution environment according to another embodiment of the present invention.
In the drawings, the same or corresponding reference numerals indicate the same or corresponding parts.
Detailed Description
Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.
In the description of the embodiments of the present application, it is to be understood that terms such as "including" or "having" are intended to indicate the presence of the features, numbers, steps, actions, components, parts, or combinations thereof disclosed in the specification, and are not intended to preclude the presence or addition of one or more other features, numbers, steps, actions, components, parts, or combinations thereof.
Unless otherwise stated, "/" indicates an OR meaning, e.g., A/B may indicate A or B; "and/or" herein is merely an association describing an associated object, and means that there may be three relationships, e.g., a and/or B, which may mean: a exists alone, A and B exist simultaneously, and B exists alone.
The terms "first", "second", etc. are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first," "second," etc. may explicitly or implicitly include one or more of that feature. In the description of the embodiments of the present application, "a plurality" means two or more unless otherwise specified.
All code in this application is exemplary and variations will occur to those skilled in the art based upon the programming language used, the specific needs and personal habits without departing from the spirit of the application.
It should be noted that the embodiments and features of the embodiments may be combined with each other without conflict. The present invention will be described in detail below with reference to the embodiments with reference to the attached drawings.
Fig. 2 is a schematic structural diagram of a virtualization system oriented to a trusted execution environment according to an embodiment of the present application.
As shown in fig. 2, the virtualization system is deployed on a terminal including a trusted execution environment TEE and a rich execution environment REE, and may include:
the driving virtual host 21 runs in the trusted execution environment TEE and is used for multiplexing a shared device driver developed by a general driving framework inside the trusted execution environment TEE so as to provide a shared driving service in the trusted execution environment TEE;
and the at least one driving paravirtualization module 22 runs in the rich execution environment REE and/or a TEE virtual machine in the execution environment TEE, and is used for calling the shared driving service provided by the driving virtual host and providing the corresponding device driving service in the rich execution environment REE and/or the TEE virtual machine by using the shared driving service.
It will be appreciated that the driver vm 21 is a special virtual machine within the TEE that is responsible for the implementation of shared drivers, and that this virtual machine only provides shared driver services. The driver paravirtualization module 22 may be a module in the TEE virtual machine responsible for specific device driver services, or may be a module in the rich execution environment REE responsible for specific device driver services.
The rich execution environment REE may be a rich operating system such as Android, IOS, and the like, which is not particularly limited in this application.
The shared driver service may be a driver service of a shared device, and it is understood that drivers such as a GPU, a camera, NFC, an LCD, and the like having a huge code amount and a complex protocol stack may be set as the shared device, and the drivers are compatible with complex drivers such as a GPU, a camera, NFC, an LCD, and the like developed by a general driver framework (such as Linux) through a hardware-assisted full virtualization method in the driver virtualization host 21.
In this embodiment, a virtualization method based on a driving virtual host is innovatively adopted in the TEE, and a general device driver such as a Linux driver framework or other operating system driver frameworks is multiplexed in the driving virtual host to be used by the TEE virtual machine and the REE, so that the repeated development of related device drivers is avoided, the driving development complexity is reduced, and the driving development cost is reduced.
It is to be understood that in fig. 2, a situation is shown in which one driving para-virtualization module is respectively run in the rich execution environment REE, and two driving para-virtualization modules are respectively run in the two TEE virtual machines in the executable environment TEE. However, one or more driving paravirtualization modules may be only run in the rich execution environment REE, or only run in one or more TEE virtual machines in the executable environment TEE, and so on, and the number of driving paravirtualization modules is not particularly limited in the present application.
Fig. 3 is a schematic structural diagram of a virtualization system oriented to a trusted execution environment according to an embodiment of the present application. This embodiment describes the configuration of the virtualization system in further detail based on the embodiment shown in fig. 2.
As shown in fig. 3, in some possible embodiments, to implement secure communication, the virtualization implementation system may further include: a virtual machine security communication module 23, the virtual machine security communication module 23 running in an operating system (TEE OS) of the trusted execution environment TEE and being responsible for providing security communication services for the virtual driver host 21 and the driver paravirtualization module 22 running in the TEE virtual machine.
In yet other possible implementations, the virtual machine secure communication module may also provide secure communication services for communication between a number of TEE virtual machines in the trusted execution environment TEE.
In one example, a plurality of security policies are deployed in the virtual machine security communication module 23, and based on the security policies, it can be determined whether secure communication between any two or more virtual machines is possible. The security policy may be preset by a developer, or may be set based on a state of the virtual machine.
As shown in fig. 3, in some possible embodiments, 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, where the driver framework layer 211 is configured to provide a device driver basic service compatible with the generic driver framework, so as to support a basic operating environment of the shared device driver developed based on the generic driver framework. The shared device driver implementation layer 212 is used for implementing driver implementation of the shared device developed based on the common driver framework. The shared device driver service layer 213 is configured to provide a shared driver service for the driver paravirtualization module based on the function for the shared device provided by the shared device driver implementation layer.
As shown in fig. 3, in some possible embodiments, the running driver paravirtualization module 22 in the TEE virtual machine may further include a device driver implementation layer 221 and a device driver service layer 222, where the device driver implementation layer 221 is configured to call, through the virtual machine security communication module 23 implemented in the TEE OS, a shared driver service provided by the shared device driver service layer 213, and provide basic function support for a corresponding device in the TEE virtual machine based on the shared driver service, so as to complete driver implementation of the corresponding device. The device driver service layer 222 is configured to provide a corresponding device driver service to the TEE virtual machine based on the function service of the corresponding device provided by the device driver implementation layer 221. Therefore, the related function operation of the shared driver can be utilized in the TEE virtual machine without repeatedly developing the related device driver in the TEE.
As shown in fig. 3, in other possible embodiments, the running driver paravirtualization module 22 in the REE may further include a device driver implementation layer 221 and a device driver service layer 222, where the device driver implementation layer is configured to call, through the TEE interface deployed in the REE and the TEE interaction interface deployed in the TEE, a shared driver service provided by the shared device driver service layer 213, and provide basic function support for the corresponding device in the REE by using the shared driver service, so as to complete driver implementation of the corresponding device. The device driver service layer 222 is configured to provide a corresponding device driver service to the REE based on the function service of the corresponding device provided by the device driver implementation layer 221. Thus, the related function operations of the shared driver can be utilized in the REE without repeatedly developing the related device driver within the TEE or the REE.
In some possible embodiments, the shared driver service is a driver service for a shared device, which may include at least one of: GPU, camera, LCD, etc. In some possible embodiments, the generic driver framework is a Linux driver framework or other operating system driver framework.
In the description of the present specification, reference to the description of the terms "some possible implementations," "some embodiments," "examples," "specific examples," or "some examples," or the like, means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the schematic representations of the terms used above are not necessarily intended to refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, various embodiments or examples and features of different embodiments or examples described in this specification can be combined and combined by one skilled in the art without contradiction.
Further, in the description of the present invention, "a plurality" means at least two, e.g., two, three, etc., unless specifically limited otherwise.
Based on the same technical concept, the embodiment of the present invention further provides a virtualization method oriented to a trusted execution environment, which is applied to the virtualization implementation system provided by any of the above embodiments. Fig. 4 is a flowchart of a virtualization method for a trusted execution environment according to an embodiment of the present invention.
As shown in fig. 4, the method 400 includes:
s401: a driving virtual host running in a Trusted Execution Environment (TEE) multiplexes a shared device driver developed by a general driving framework inside the Trusted Execution Environment (TEE) to provide a shared driving service in the Trusted Execution Environment (TEE);
s402: at least one driver paravirtualization module in a TEE virtual machine running in a rich execution environment REE and/or in the executable environment TEE invokes the shared driver service provided by the driver virtual host and provides a corresponding device driver service in the rich execution environment REE and/or in the TEE virtual machine based on the shared driver service.
In the embodiment, a virtualization method based on a driving virtual host is innovatively adopted in the TEE, and a universal device driver such as a Linux driving frame or other operating system driving frames is multiplexed in the driving virtual host to be used by the TEE virtual machine and the REE, so that the repeated development of related device drivers is avoided, the driving development complexity is reduced, and the driving development cost is reduced.
In some possible embodiments, the method further comprises: providing a secure communication service between the virtual driver host and the driver paravirtualization module running in the TEE virtual machine using a virtual machine secure communication module running in an operating system of the trusted execution environment TEE.
In some possible embodiments, 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 driving framework layer provides device driving basic services compatible with the universal driving framework so as to support a basic operation environment of a shared device driver developed based on the universal driving framework; the shared device driver implementation layer executes the driver implementation of the shared device developed based on the universal driving 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.
In some possible embodiments, the driver paravirtualization module includes a device driver implementation layer and a device driver service layer, and the method further includes the device driver implementation layer calling the shared driver service provided by the shared device driver service layer, and providing basic function support for a corresponding device in the rich execution environment REE and/or the TEE virtual machine based on the shared driver service to complete 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 function service of the corresponding device provided by the device driver implementation layer.
In some possible embodiments, the shared drive service comprises at least one of: GPU, camera, LCD.
In some possible embodiments, the generic driver framework is a Linux driver framework or other operating system driver framework.
It should be noted that the virtualization method in the embodiment of the present application can implement each process of the foregoing embodiments of the virtualization system, and achieve the same effect and function, which is not described herein again.
In an embodiment of the present application, there is further provided a device call method, which is applied to the virtualization system described in the foregoing embodiment, and the method specifically includes: responding to a target device operation instruction by a first application running in any TEE virtual machine in a trusted execution environment TEE, and calling a target device interface provided by a target driving paravirtualization module running in any TEE virtual machine; the target driving paravirtualization module converts the target equipment operation instruction into a target equipment virtual control instruction and sends the target equipment virtual control instruction to a driving virtual host running in a trusted execution environment; the driving virtual host converts the target equipment virtual control instruction into a target equipment physical control instruction, and converts the target equipment physical control instruction into a target equipment hardware control instruction by multiplexing a shared equipment driver developed by a general driving framework, thereby realizing the operation control of the target equipment.
The shared device driver may be a driver for devices with huge code amounts and complex protocol stacks, such as GPUs, cameras, NFC, LCDs, etc. The target device may be any one or more of the shared devices. The target driven paravirtualization module is a driven paravirtualization module corresponding to the target device, such as a driven paravirtualization module corresponding to a camera device and a driven paravirtualization module corresponding to an NFC device.
Referring to fig. 2, the first application may be deployed in any one of the TEE virtual machines in the trusted execution environment TEE, which may be any kind of application program that needs to invoke the target device, such as a face payment application, an NFC payment application, and the like. For example, if a certain TEE virtual machine is a TEE virtual machine corresponding to a certain payment system (such as a unionpay payment system), a face payment application, an NFC payment application, and the like of the payment system may be deployed in the TEE virtual machine. Furthermore, when the face payment application needs to call the camera device, a driving paravirtualization module corresponding to the camera device, namely a target driving paravirtualization module, can be called in the TEE virtual machine. The driver paravirtualization module of the camera device invokes a driver virtual host running in a trusted execution environment. As described in the above embodiments, the driving vm is a special vm within the TEE that is responsible for implementing the shared driver, and the virtual machine multiplexes the shared device driver developed by the general driver framework (such as the Linux driver framework), and the shared device supported by the driving vm includes the target device, so that the operation control on the target device can be implemented by calling the driving vm.
In one possible embodiment, the method further comprises: the target driving paravirtualization module sends a target device virtual control instruction to a virtual machine security communication module running in an operating system of a Trusted Execution Environment (TEE); and the virtual machine safety communication module forwards the target equipment virtual control instruction to the driving virtual host.
In one possible embodiment, the target-driven para-virtualization module further comprises a device driver implementation layer and a device driver service layer for the target device, and the method further comprises: the device driver service layer responds to the calling operation of the first application, obtains a target device operation instruction and sends the target device operation instruction to the device driver implementation layer; and the device driver implementation layer converts the target device operation instruction into a corresponding target device virtual control instruction and sends the target device virtual control instruction to a virtual machine security communication module running in an operating system of the trusted execution environment TEE.
In one possible embodiment, the driving virtual host further includes: a shared device driver service layer, a shared device driver implementation layer, and a driver framework layer corresponding to the target device, the method further comprising: the shared device driving service layer receives the target device virtual control instruction and sends the target device virtual control instruction to the shared device driving implementation layer; the shared device driver implementation layer converts the target device virtual control instruction into a target device physical control instruction and sends the target device physical control instruction to the driver framework layer; and the driving frame layer converts the physical control instruction of the target equipment into a hardware control instruction of the target equipment, so that the control operation of the target equipment is realized.
In some possible embodiments, the generic driver framework is a Linux driver framework or other operating system driver framework.
It should be noted that the device call method in the embodiment of the present application may implement each process of the foregoing embodiment of the virtualization system, and achieve the same effect and function, which is not described herein again.
In one example, the first application is a payment application provided by the payment system a, and the target device is a camera device, it is understood that the payment application may need to call the camera device to obtain a real-time face image of the user during use to perform face payment. A plurality of systems of TEE virtual machines may be deployed in the trusted execution environment TEE, such as a TEE virtual machine 1 for deploying a payment system a and a TEE virtual machine 2 for deploying a payment system B, at this time, if a payment application of the payment system a in the TEE virtual machine 1 needs to call a camera device, a camera device interface (API) provided by a camera device driving service layer in a target driving paravirtualization module (i.e. a driving paravirtualization module for the camera device) in the TEE virtual machine 1 may be called, the camera device driving service layer sends a camera device operation instruction corresponding to the camera interface to a camera device driving implementation layer in the TEE virtual machine, the camera device driving implementation layer in the TEE virtual machine converts the camera device operation instruction into a corresponding camera device virtual control instruction, and sends the camera device virtual control instruction to a virtual machine security communication module in the TEE OS, the camera equipment virtual control instruction is forwarded to a shared equipment drive service layer in the drive virtual host by a virtual machine safety communication module in the TEE OS, the camera virtual control instruction is sent to a shared equipment drive implementation layer by the shared equipment drive service layer, the camera equipment virtual control instruction is converted into a camera equipment physical control instruction by the shared equipment drive implementation layer and is sent to a similar Linux drive framework layer, and the camera equipment physical control instruction is converted into a camera equipment hardware control instruction by the similar Linux drive framework layer, so that the control and data transmission of the camera equipment are realized.
In this embodiment, another device calling method is further provided, which is applied to the virtualization system described in the foregoing embodiment, and the method specifically includes: responding to the target device operation instruction by a second application running in the rich execution environment REE, and calling a target device interface provided by a target driving para-virtualization module running in the rich execution environment REE; the target driving paravirtualization module converts the target equipment operation instruction into a target equipment virtual control instruction and sends the target equipment virtual control instruction to a driving virtual host running in a Trusted Execution Environment (TEE); the driving virtual host converts the target equipment virtual control instruction into a target equipment physical control instruction, and converts the target equipment physical control instruction into a target equipment hardware control instruction by multiplexing a shared equipment driver developed by a general driving framework, thereby realizing the operation control of the target equipment.
The shared device driver may be a driver for devices with huge code amounts and complex protocol stacks, such as GPUs, cameras, NFC, LCDs, etc. The target device may be any one or more of the shared devices. The target driven paravirtualization module is a driven paravirtualization module corresponding to the target device, such as a driven paravirtualization module corresponding to a camera device and a driven paravirtualization module corresponding to an NFC device.
Referring to fig. 2, the second application runs in a rich execution environment REE, which may be any application program that needs to call a target device, such as a human face application. For example, when the face application needs to call a camera device, a driver paravirtualization module corresponding to the camera device, that is, a target driver paravirtualization module, may be called in the REE. The driving paravirtualization module of the camera device can call a driving virtual host running in the trusted execution environment TEE through an interconnection interface between environments. As described in the above embodiments, the driving vm is a special vm within the TEE that is responsible for implementing the shared driver, and the virtual machine multiplexes the shared device driver developed by the general driver framework (such as the Linux driver framework), and the shared device supported by the driving vm includes the target device, so that the operation control on the target device can be implemented by calling the driving vm.
In one possible embodiment, the target-driven para-virtualization module further comprises a device driver implementation layer and a device driver service layer for the target device, and the method further comprises: the device driver service layer responds to the calling operation of the second application, obtains a target device operation instruction 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 the target device virtual control instruction to the driving virtual host through the environment interaction interface; the environment interaction interface is used for realizing information interaction between the rich execution environment REE and the trusted execution environment TEE.
The environment interaction interface may include a TEE interface and a TEE interaction interface as shown in fig. 3.
In one possible embodiment, the driving virtual host further includes: at least for a shared device driver service layer, a shared device driver implementation layer, and a driver framework layer of the target device, the method further comprises: the shared equipment driving service layer receives the target equipment virtual control instruction and sends the target equipment virtual control instruction to an equipment driving implementation layer corresponding to the target equipment; the shared device driver implementation layer converts the target device virtual control instruction into a target device physical control instruction and sends the target device physical control instruction to the driver framework layer; and the driving frame layer converts the physical control instruction of the target equipment into a hardware control instruction of the target equipment, so that the control operation of the target equipment is realized.
In some possible embodiments, the generic driver framework is a Linux driver framework or other operating system driver framework.
It should be noted that the device call method in the embodiment of the present application may implement each process of the foregoing embodiment of the virtualization system, and achieve the same effect and function, which is not described herein again.
In one example, the second application is a face application and the target device is a camera device, and the face application may be any application program that needs to process a face image. It can be understood that the face application may need to call a camera device to acquire a face image to perform image processing during use. At this time, if a second application in the REE needs to call the camera device, a camera device interface (API) provided by a camera device driving service layer in a target driving paravirtualization module (i.e. a driving paravirtualization module for the camera device) in the REE can be called, the camera device driving service layer sends a camera device operation instruction corresponding to the camera interface to a camera device driving implementation layer of the target driving paravirtualization module, the camera device driving implementation layer of the target driving paravirtualization module converts the camera device operation instruction into a corresponding camera device virtual control instruction, sends the camera device virtual control instruction to a shared device driving service layer in a driving virtual host in the TEE through an environment interaction interface, the shared device driving service layer sends the camera virtual control instruction to the shared device driving implementation layer, and the shared device driving implementation layer converts the camera device virtual control instruction into a camera device physical control instruction, and sending the control command to a similar Linux driving framework layer, wherein the similar Linux driving framework layer converts the physical control command of the camera equipment into a hardware control command of the camera equipment, thereby realizing the control and data transmission of the camera equipment.
Any process or method descriptions in flow charts or otherwise described herein may be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps of the process, and alternate implementations are included within the scope of the preferred embodiment of the present invention in which functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those reasonably skilled in the art of the present invention.
With regard to the method flow diagrams of embodiments of the present application, certain operations are described as different steps performed in a certain order. Such flow diagrams are illustrative and not restrictive. Certain steps described herein may be grouped together and performed in a single operation, may be divided into multiple sub-steps, and may be performed in an order different than that shown herein. The various steps shown in the flowcharts may be implemented in any way by any circuit structure and/or tangible mechanism (e.g., by software running on a computer device, hardware (e.g., logical functions implemented by a processor or chip), etc., and/or any combination thereof).
Fig. 5 is a trusted execution environment-oriented virtualization apparatus according to an embodiment of the present application, configured to execute the virtualization method shown in fig. 4, where the apparatus includes: at least one processor; and a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of the above embodiments.
According to some embodiments of the present application, there is provided a non-transitory computer storage medium of a trusted execution environment oriented virtualization method having stored thereon computer-executable instructions configured to, when executed by a processor, perform: the method as described in the above example.
The embodiments in the present application are described in a progressive manner, and the same and similar parts among the embodiments can be referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the apparatus, device, and computer-readable storage medium embodiments, the description is simplified because they are substantially similar to the method embodiments, and reference may be made to some descriptions of the method embodiments for their relevance.
The apparatus, the device, and the computer-readable storage medium provided in the embodiment of the present application correspond to the method one to one, and therefore, the apparatus, the device, and the computer-readable storage medium also have advantageous technical effects similar to those of the corresponding method.
As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, 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, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. Moreover, while the operations of the method of the invention are depicted in the drawings in a particular order, this does not require or imply that the operations must be performed in this particular order, or that all of the illustrated operations must be performed, to achieve desirable results. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step execution, and/or one step broken down into multiple step executions.
While the spirit and principles of the invention have been described with reference to several particular embodiments, it is to be understood that the invention is not limited to the disclosed embodiments, nor is the division of aspects, which is for convenience only as the features in such aspects may not be combined to benefit. The invention is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

Claims (19)

1. A trusted execution environment oriented virtualization system, the system comprising:
the driving virtual host runs in a trusted execution environment TEE and is used for multiplexing a shared device driver developed by a general driving framework inside the trusted execution environment TEE so as to provide a shared driving service in the trusted execution environment TEE;
at least one driving paravirtualization module, running in a rich execution environment REE and/or a TEE virtual machine in the executable environment TEE, for calling the shared driving service provided by the driving virtual host, and providing a corresponding device driving service in the rich execution environment REE and/or the TEE virtual machine based on the shared driving service.
2. The system of claim 1, wherein the virtualization implementation system further comprises:
and the virtual machine security communication module runs in an operating system of the TEE and is used for providing security communication service for the virtual driving host and the driving paravirtualization module running in the TEE virtual machine.
3. The system of claim 1, wherein the driver hypervisor, further comprising:
the driving framework layer is used for providing device driving basic services compatible with the universal driving framework so as to support a basic operation environment of a shared device driver developed based on the universal driving framework;
the shared device drive realization layer is used for finishing the drive realization of the shared device developed based on the universal drive framework;
and the shared device driver service layer is used for providing the shared driver service for the driver paravirtualization module based on the function aiming at the shared device provided by the shared device driver implementation layer.
4. The system of claim 3, wherein the driver paravirtualization module further comprises:
the device driver implementation layer is used for calling the shared driver service provided by the shared device driver service layer and providing basic function support for corresponding devices in the REE and/or the TEE virtual machine based on the shared driver service so as to complete the driver implementation of the corresponding devices;
and the device driver service layer is used for providing the corresponding device driver service for 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.
5. The system of claim 1, wherein the shared drive service comprises at least one of: GPU, camera, LCD.
6. The system of claim 1, wherein the generic driver framework is a Linux driver framework or other operating system driver framework.
7. A virtualization method oriented to a trusted execution environment, applied to the virtualization implementation system according to any one of claims 1 to 6, the method comprising:
a driving virtual host running in a Trusted Execution Environment (TEE) multiplexes a shared device driver developed by a general driving framework inside the Trusted Execution Environment (TEE) to provide a shared driving service in the Trusted Execution Environment (TEE);
at least one driver paravirtualization module in a TEE virtual machine running in a rich execution environment REE and/or in the executable environment TEE invokes the shared driver service provided by the driver virtual host and provides a corresponding device driver service in the rich execution environment REE and/or in the TEE virtual machine based on the shared driver service.
8. The method of claim 7, further comprising:
providing a secure communication service between the virtual driver host and the driver paravirtualization module running in the TEE virtual machine using a virtual machine secure communication module running in an operating system of the trusted execution environment TEE.
9. The method of claim 7, wherein the driver virtual host comprises a driver framework layer, a shared device driver implementation layer, and a shared device driver service layer, the method further comprising:
the driving framework layer provides device driving basic services compatible with the universal driving framework so as to support a basic operation environment of a shared device driver developed based on the universal driving framework;
the shared device driver implementation layer executes the driver implementation of the shared device developed based on the universal driving 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.
10. The method of claim 9, wherein the driver paravirtualization module comprises a device driver implementation layer and a device driver service layer, the method further comprising:
the device driver implementation layer calls the shared driver service provided by the shared device driver service layer, and provides basic function support for corresponding devices in the REE and/or the TEE virtual machine based on the shared driver service so as to complete the driver implementation of the corresponding devices;
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 function service of the corresponding device provided by the device driver implementation layer.
11. The method of claim 7, wherein the shared driver service comprises at least one of: GPU, camera, LCD.
12. The method according to claim 7, wherein the generic driver framework is a Linux driver framework or other operating system driver framework.
13. A device calling method applied to the virtualization system according to any one of claims 1 to 6, comprising:
responding to a target device operation instruction by a first application running in any TEE virtual machine in a trusted execution environment TEE, and calling a target device interface provided by a target driving paravirtualization module running in the any TEE virtual machine;
the target driving paravirtualization module converts the target equipment operation instruction into a target equipment virtual control instruction and sends the target equipment virtual control instruction to a driving virtual host running in the trusted execution environment;
and the driving virtual host converts the target equipment virtual control instruction into a target equipment physical control instruction, and converts the target equipment physical control instruction into a target equipment hardware control instruction by multiplexing a shared equipment driver developed by a general driving framework, so that the operation control of the target equipment is realized.
14. The method of claim 13, further comprising:
the target driving paravirtualization module sends the target device virtual control instruction to a virtual machine security communication module running in an operating system of the trusted execution environment TEE;
and the virtual machine safety communication module forwards the target equipment virtual control instruction to the driving virtual host.
15. The method of claim 14, wherein the target driven paravirtualization module further comprises a device driver implementation layer and a device driver service layer for the target device, the method further comprising:
the device driver service layer responds to the calling operation of the first application, acquires the target device operation instruction and sends the target device operation instruction to the device driver implementation layer;
and the device driver implementation layer converts the target device operation instruction into a corresponding target device virtual control instruction and sends the target device virtual control instruction to a virtual machine security communication module running in an operating system of the trusted execution environment TEE.
16. The method of any of claims 13-15, wherein driving the virtual host further comprises: a shared device driver service layer, a shared device driver implementation layer, and a driver framework layer corresponding to the target device, the method further comprising:
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 the target device physical control instruction to the driver framework layer;
and the driving frame layer converts the physical control instruction of the target equipment into a hardware control instruction of the target equipment, so that the control operation of the target equipment is realized.
17. A device call method, applied to a virtualization system according to any one of claims 1-6, the method comprising:
responding to a target device operation instruction by a second application running in the rich execution environment REE, and calling a target device interface provided by a target driving para-virtualization module running in the rich execution environment REE;
the target driving paravirtualization module converts the target equipment operation instruction into a target equipment virtual control instruction and sends the target equipment virtual control instruction to a driving virtual host running in the trusted execution environment TEE;
and the driving virtual host converts the target equipment virtual control instruction into a target equipment physical control instruction, and converts the target equipment physical control instruction into a target equipment hardware control instruction by multiplexing a shared equipment driver developed by a general driving framework, so that the operation control of the target equipment is realized.
18. The method of claim 17, wherein the target driven paravirtualization module further comprises a device driver implementation layer and a device driver service layer for the target device, the method further comprising:
the device driver service layer responds to the calling operation of the second application, obtains the target device operation instruction 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 the target device virtual control instruction to the driving virtual host through an environment interaction interface;
wherein the environment interaction interface is used for realizing information interaction between the rich execution environment REE and the trusted execution environment TEE.
19. The method of claim 17 or 18, wherein the driving the virtual host further comprises: for at least a shared device driver service layer, a shared device driver implementation layer, and a driver framework layer of the target device, the method further comprises:
the shared device driver service layer receives the target device virtual control instruction and sends the target device virtual control instruction to a 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 the target device physical control instruction to the driver framework layer;
and the driving frame layer converts the physical control instruction of the target equipment into a hardware control instruction of the target equipment, so that the control operation of the target equipment is realized.
CN202110178416.2A 2021-02-09 2021-02-09 Virtualization system and method for trusted execution environment and device calling method Pending CN112817697A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110178416.2A CN112817697A (en) 2021-02-09 2021-02-09 Virtualization system and method for trusted execution environment and device calling method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110178416.2A CN112817697A (en) 2021-02-09 2021-02-09 Virtualization system and method for trusted execution environment and device calling method

Publications (1)

Publication Number Publication Date
CN112817697A true CN112817697A (en) 2021-05-18

Family

ID=75864657

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110178416.2A Pending CN112817697A (en) 2021-02-09 2021-02-09 Virtualization system and method for trusted execution environment and device calling method

Country Status (1)

Country Link
CN (1) CN112817697A (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114625484A (en) * 2022-03-31 2022-06-14 苏州浪潮智能科技有限公司 Virtualization implementation method, device, electronic equipment, medium and ARM platform
CN115017497A (en) * 2021-11-24 2022-09-06 荣耀终端有限公司 Information processing method, device and storage medium
CN116049813A (en) * 2022-07-29 2023-05-02 荣耀终端有限公司 Touch screen data processing method, device and storage medium based on trusted execution environment
WO2024075929A1 (en) * 2022-10-04 2024-04-11 삼성전자 주식회사 Electronic device for providing trusted execution environment

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100031325A1 (en) * 2006-12-22 2010-02-04 Virtuallogix Sa System for enabling multiple execution environments to share a device
WO2016168487A1 (en) * 2015-04-14 2016-10-20 Gigavation, Inc. Paravirtualized security threat protection of a computer-driven system with networked devices
CN106548077A (en) * 2016-10-19 2017-03-29 沈阳微可信科技有限公司 Communication system and electronic equipment
US20180113730A1 (en) * 2016-10-25 2018-04-26 Microsoft Technology Licensing Llc Secure service hosted in a virtual security environment

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100031325A1 (en) * 2006-12-22 2010-02-04 Virtuallogix Sa System for enabling multiple execution environments to share a device
WO2016168487A1 (en) * 2015-04-14 2016-10-20 Gigavation, Inc. Paravirtualized security threat protection of a computer-driven system with networked devices
CN106548077A (en) * 2016-10-19 2017-03-29 沈阳微可信科技有限公司 Communication system and electronic equipment
US20180113730A1 (en) * 2016-10-25 2018-04-26 Microsoft Technology Licensing Llc Secure service hosted in a virtual security environment

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
黄勇军等: "智能终端虚拟化及安全隔离技术", 电信科学, no. 02, 20 February 2018 (2018-02-20) *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115017497A (en) * 2021-11-24 2022-09-06 荣耀终端有限公司 Information processing method, device and storage medium
CN114625484A (en) * 2022-03-31 2022-06-14 苏州浪潮智能科技有限公司 Virtualization implementation method, device, electronic equipment, medium and ARM platform
CN116049813A (en) * 2022-07-29 2023-05-02 荣耀终端有限公司 Touch screen data processing method, device and storage medium based on trusted execution environment
CN116049813B (en) * 2022-07-29 2023-10-20 荣耀终端有限公司 Touch screen data processing method, device and storage medium based on trusted execution environment
WO2024075929A1 (en) * 2022-10-04 2024-04-11 삼성전자 주식회사 Electronic device for providing trusted execution environment

Similar Documents

Publication Publication Date Title
CN112817697A (en) Virtualization system and method for trusted execution environment and device calling method
EP2248014B1 (en) Selective exposure to usb device functionality for a virtual machine
EP3571586B1 (en) Dynamic and application-specific virtualized graphics processing
WO2018119951A1 (en) Gpu virtualization method, device, system, and electronic apparatus, and computer program product
EP2479666B1 (en) Methods and systems to display platform graphics during operating system initialization
CN106797388B (en) Cross-system multimedia data encoding and decoding method and device, electronic equipment and computer program product
US20140359613A1 (en) Physical/virtual device failover with a shared backend
US8978051B2 (en) Method and apparatus for displaying application image
US9529617B2 (en) Instant virtual machines
CN109725977B (en) Multi-application display method based on Android system and terminal equipment
EP4033724A1 (en) Account number binding method, device and system
CN114499945B (en) Intrusion detection method and device for virtual machine
EP4303725A1 (en) Method and device for identifying android system drawing thread, and mobile terminal and storage medium
US10318343B2 (en) Migration methods and apparatuses for migrating virtual machine including locally stored and shared data
CN111736943A (en) Virtual machine migration method and system
CN110545415A (en) Data transmission method and device and server
CN109522111B (en) Calling method and device of heterogeneous ecosystem, electronic equipment and storage medium
EP3198406B1 (en) Facilitation of guest application display from host operating system
CN115629809A (en) Data processing method and device, electronic equipment and computer readable storage medium
CN115640116B (en) Service processing method and related device
CN109710352A (en) A kind of display methods and device of boot animation
CN111258715B (en) Multi-operating system rendering processing method and device
TWI556167B (en) System and method for multiple native software applications user interface composition
CN116361033B (en) Communication method, electronic device, and storage medium
Xie et al. A study and implementation of vga multi-resolution on android platform

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination