Communication method and device between trusted applications in multiple trusted execution environments

Abstract

The invention provides a communication method and equipment among trusted applications in multiple trusted execution environments, which are applied to electronic equipment comprising a first trusted execution environment and a second trusted execution environment, and the first trusted execution environment comprises a first trusted application and a second trusted application. The second trusted execution environment comprises a third trusted application, a fourth trusted application and a second agent module. In response to the operation of starting the first service, a third trusted application of the electronic equipment calls the second agent module, and the first trusted application is called through a first link created by the second agent module to execute the first service; and in response to the operation of starting the second service, a fourth trusted application of the electronic equipment calls the second agent module, and calls the second trusted application through the first link to execute the second service. The first link can be reused by each trusted application of the first trusted execution environment, so that the system load can be reduced, and the communication quality among the trusted applications in the multiple trusted execution environments is improved.

Description

Technical Field

[0001] This application relates to the technical field of terminals, and in particular, to a communication method and device between trusted applications in a multi-trusted execution environment. Background Art

[0002] With the continuous development of communication technologies, there are more and more applications in electronic devices. To protect user privacy and information security, a trusted execution environment (TEE) can be created in an electronic device to provide a high-level and more reliable security guarantee for the electronic device. The TEE is also called a secure execution environment and can run a trusted execution environment operating system (TEE OS) to provide reliable security services (such as fingerprint verification services, password verification services, face verification services, etc.) for CAs. These security services can run on the TEE OS in the form of trusted applications (TAs). Currently, multiple TEEs can be created in an electronic device, and how to improve the communication quality between trusted applications under multiple TEEs is an urgent problem to be solved. Summary of the Invention

[0003] Embodiments of this application provide a communication method and device between trusted applications in a multi-trusted execution environment, which are applied to the technical field of terminals and can improve the communication quality between trusted applications in a multi-trusted execution environment.

[0004] In a first aspect, embodiments of this application provide a communication method between trusted applications in a multi-trusted execution environment, which is applied to an electronic device. The electronic device includes a first trusted execution environment and a second trusted execution environment. The first trusted execution environment includes a first trusted application and a second trusted application. The second trusted execution environment includes a third trusted application, a fourth trusted application, and a second proxy module. The method includes:

[0005] In response to an operation to start a first service, the third trusted application of the electronic device calls the second proxy module and calls the first trusted application through a first link created by the second proxy module to execute the first service;

[0006] In response to an operation to start a second service, the fourth trusted application of the electronic device calls the second proxy module and calls the second trusted application through the first link to execute the second service;

[0007] The first link is a link between the second trusted execution environment and the first trusted execution environment.

[0008] In this embodiment, the first trusted execution environment and the second trusted execution environment are two independent trusted execution environments in the electronic device. The first trusted execution environment can correspond to the QTVM in the foregoing embodiment, and the second trusted execution environment can correspond to the HTVM in the foregoing embodiment. The first trusted application and the second trusted application are trusted applications running in the first trusted execution environment. For example, the first trusted application is Figure 6 the DSP_Service, and the second trusted application is Figure 6 the TUICoreService. The third trusted application and the fourth trusted application are trusted applications running in the second trusted execution environment. For example, the third trusted application is Figure 6 the Face TA, and the fourth trusted application is Figure 6 the TUI TA. The first service and the second service are two different services provided for client applications in the rich execution environment of the electronic device. For example, the first service is a face verification service, and the second service is a secure display service. The first link can correspond to Link 1 in the foregoing embodiment.

[0009] In addition, the second proxy module is a functional module of the second trusted execution environment and can correspond to the proxy module 2 in the foregoing embodiment (i.e., Figure 6 the Minkhub module).

[0010] In some examples, the second proxy module creates the first link through the driver layer. The first link can be regarded as a link between two trusted execution environments (such as HTVM and QTVM).

[0011] Exemplarily, referring to Figure 6 , in response to the user's operation of using the face verification service provided by the client application CA (for example, the user opens the face verification service provided by the wallet application), the Face TA of the HTVM calls the proxy module 2 and calls the DSP_Service of the QTVM through the first link created by the proxy module 2 to perform the face verification service. Similarly, in response to the user's operation of using the secure display service provided by the client application (for example, the user calls up the keyboard), the TUI TA of the HTVM calls the proxy module 2 and calls the TUICoreService of the QTVM through the first link created by the proxy module 2 to perform the secure display service (such as securely displaying the virtual keyboard for the user to enter the password).

[0012] In the communication method shown in this embodiment, a second proxy module is included in the second trusted execution environment of the electronic device. Each trusted application in the second trusted execution environment can call the second proxy module and, based on the first link created by the second proxy module with the first trusted execution environment, call the corresponding trusted application in the first trusted execution environment to execute the corresponding service. That is to say, after the second proxy module creates the first link, each trusted application in the first trusted execution environment can use this first link to communicate with the first trusted execution environment. In this way, the system only needs to maintain one link, which can reduce the system load and improve the communication quality between trusted applications in a multi-trusted execution environment.

[0013] In an optional embodiment of the first aspect, the second trusted execution environment further includes a second message queue driver, and the first trusted execution environment further includes a first message queue driver; the second proxy module creating the first link includes: in response to an operation to start the first service, a third trusted application calls the second proxy module; the second proxy module sends a first request to the first message queue driver through the second message queue driver to create the first link.

[0014] In this embodiment, the second message queue driver can correspond to the message queue driver 2 in the foregoing embodiment, and the first message queue driver can correspond to the message queue driver 1 in the foregoing embodiment.

[0015] Exemplarily, taking the first service as a face verification service, in response to the operation of the user using the face verification service provided by the client application, the Face TA of the electronic device calls the proxy module 2, and the proxy module 2 sends a first request to the message queue driver 1 through the message queue driver 2 to create the link 1. For the specific process, refer to Figure 7 Steps S105 to S109 of the embodiment.

[0016] In the communication method shown in this embodiment, the second proxy module can create a first link with the first trusted execution environment based on the call of a certain trusted application in the second trusted execution environment. That is to say, when a trusted application in the second trusted execution environment needs to interact with the first trusted execution environment, the second proxy module creates this first link. At the same time, the second proxy module can instruct the second message queue driver to apply to the system for resources related to the first link (i.e., apply for resources when in use). In this way, the system resource utilization rate can be improved.

[0017] In an optional embodiment of the first aspect, the second proxy module creating the first link includes: after the electronic device is started, the second proxy module is initialized; after the second proxy module is initialized, the second proxy module sends a second request to the first message queue driver through the second message queue driver to create the first link. For details, refer to Figure 8 The embodiment.

[0018] In some examples, the startup of the electronic device refers to after the operating system of the second trusted execution environment of the electronic device is started.

[0019] For the communication method shown in this embodiment, after the second proxy module of the electronic device is successfully initialized, a first link with the first trusted execution environment is directly created. It can be understood that it takes a certain amount of time to create the first link. If the first link is created in advance, then after the third trusted application or the fourth trusted application in the second trusted execution environment is started, the second proxy module can interact with the corresponding trusted application in the first trusted execution environment based on the already created first link, thereby improving the response ability of the system application layer.

[0020] In an optional embodiment of the first aspect, the method further includes: after the third trusted application exits abnormally, the second proxy module receives a first system notification; the second proxy module determines whether to release the first link based on the first system notification.

[0021] For the communication method shown in this embodiment, after the second proxy module learns that the third trusted application has exited abnormally, it does not directly release the first link.

[0022] In an optional embodiment of the first aspect, the second proxy module determines whether to release the first link based on the first system notification, including: the second proxy module determines whether there are other trusted applications in the second trusted execution environment that are in a running state based on the first system notification; if so, the second proxy module determines not to release the first link; if not, the second proxy module determines to release the first link. Reference can be made to Figure 9 the embodiment.

[0023] In some examples, whether there are other trusted applications in the second trusted execution environment that are in a running state can also be described as: whether there are other trusted applications in the second trusted execution environment that are invoking the trusted application of the first trusted execution environment through the second proxy module.

[0024] For the communication method shown in this embodiment, after the second proxy module learns that the third trusted application has exited abnormally, it first determines whether there are other trusted applications in the current operating system of the second trusted execution environment that reuse the first link. If there are other applications that reuse this first link, the second proxy module does not release the first link, thus improving the response ability of the application layer of the second trusted execution environment.

[0025] In an optional embodiment of the first aspect, the first trusted execution environment further includes a first proxy module, and the method further includes: if the second proxy module determines to release the first link, the second proxy module sends first indication information to the second message queue, where the first indication information is used to indicate the release of the first link and the resources related to the first link; based on the first indication information, the second message queue releases the first link and the resources related to the first link in the second trusted execution environment, and sends the first indication information to the first message queue driver; the first message queue sends the first indication information to the first proxy module; based on the first indication information, the first proxy module releases the resources related to the first link in the first trusted execution environment. For details, please refer to Figure 9 the embodiment.

[0026] In this embodiment, the first proxy module is a functional module of the first trusted execution environment, and can correspond to the proxy module 1 in the foregoing embodiment (i.e., Figure 6 the TVMMink module).

[0027] For the communication method shown in this embodiment, after the third trusted application in the second trusted execution environment exits abnormally and the second proxy module determines to release the first link, the second proxy module can notify the second message queue driver and, through the second message queue driver, notify the first trusted execution environment to release the resources related to the first link in the two trusted execution environments, so as to avoid the occupation of system memory by the resources related to the first link and improve the utilization rate of system resources.

[0028] In an optional embodiment of the first aspect, the second trusted execution environment further includes a first driver manager, and the method further includes: after the second proxy module exits abnormally, the first driver manager receives a second system notification; based on the second system notification, the first driver manager sends second indication information to the second message queue driver, where the second indication information is used to indicate the release of the first link and the resources related to the first link; based on the first indication information, the second message queue driver releases the first link and the resources related to the first link in the second trusted execution environment, and sends the second indication information to the first message queue driver; the first message queue sends the second indication information to the first proxy module; based on the second indication information, the first proxy module releases the resources related to the first link in the first trusted execution environment. For details, please refer to Figure 10 the embodiment.

[0029] In this embodiment, the first driver manager can correspond to the driver manager 2 in the foregoing embodiment.

[0030] In the communication method shown in this embodiment, after the second proxy module abnormally exits, considering that the first link created by the second proxy module has become invalid, the second trusted execution environment operating system can notify the second message queue driver and, through the second message queue driver, notify the first trusted execution environment to release the resources related to the first link in the two trusted execution environments, avoiding the occupation of system memory by the resources related to the first link, and improving the utilization rate of system resources.

[0031] In an optional embodiment of the first aspect, the second message queue driver sends second indication information to the first message queue driver, including: the second message queue driver sends the second indication information to the first message queue driver based on a preset communication protocol.

[0032] In this embodiment, the preset communication protocol can be a protocol different from the minkipc protocol.

[0033] In a second aspect, an embodiment of the present application provides an electronic device, including: a processor and a memory; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory, causing the electronic device to execute the method according to any one of the first aspect.

[0034] In a third aspect, an embodiment of the present application provides a computer-readable storage medium, where the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, it implements the method according to any one of the first aspect.

[0035] In a fourth aspect, an embodiment of the present application provides a computer program product, where the computer program product includes a computer program, and when the computer program is run, it causes the computer to execute the method according to any one of the first aspect.

[0036] In a fifth aspect, an embodiment of the present application provides a chip, where the chip includes a processor, and the processor is used to call a computer program in a memory to execute the method according to any one of the first aspect.

[0037] It should be understood that the second to fifth aspects of the present application correspond to the technical solutions of the first aspect of the present application, and the beneficial effects obtained by each aspect and the corresponding feasible implementation manners are similar and will not be elaborated. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Figure 1 It is a framework schematic diagram of an electronic device provided by an embodiment of the present application;

[0039] Figure 2 It is a structural schematic diagram of an electronic device provided by an embodiment of the present application;

[0040] Figure 3 It is a software structure block diagram of an electronic device provided by an embodiment of the present application;

[0041] Figure 4 Schematic diagram of the framework of an electronic device provided by an embodiment of the present application;

[0042] Figure 5 Schematic diagram of the interaction process of an electronic device provided by an embodiment of the present application;

[0043] Figure 6 Schematic diagram of the framework of an electronic device provided by an embodiment of the present application;

[0044] Figure 7 Schematic diagram of the interaction process of an electronic device provided by an embodiment of the present application;

[0045] Figure 8 Schematic diagram of the interaction process of an electronic device provided by an embodiment of the present application;

[0046] Figure 9 Schematic diagram of the interaction process of an electronic device provided by an embodiment of the present application;

[0047] Figure 10 Schematic diagram of the interaction process of an electronic device provided by an embodiment of the present application;

[0048] Figure 11 Schematic diagram of the interaction of an electronic device provided by an embodiment of the present application;

[0049] Figure 12 Schematic diagram of the structure of an electronic device provided by an embodiment of the present application;

[0050] Figure 13 Schematic diagram of the structure of a chip provided by an embodiment of the present application. Detailed implementation manners

[0051] To facilitate a clear description of the technical solutions of the embodiments of the present application, the following briefly introduces some terms and technologies involved in the embodiments of the present application:

[0052] 1. Trusted Execution Environment (TEE): It can be called a secure execution environment. A trusted execution environment operating system (TEE OS) can run in the TEE. The TEE can also provide reliable security services (such as fingerprint verification service, password verification service, face verification service, etc.) for client applications (CAs). These security services can run in the TEE OS in the form of trusted applications (TAs).

[0053] In some embodiments, the TEE may be an execution area constructed using the secure area of the processor in an electronic device, and the trusted execution environment can provide a secure operating environment for services.

[0054] In some embodiments, an electronic device may adopt the trust zone technology to establish the TEE in the trust zone, which can protect the confidentiality and integrity of the code and data loaded in the TEE.

[0055] In some embodiments, ARM has introduced the virtualization extension technology to support the hardware virtualization of the ARM platform, so that hardware isolation can also be achieved for different operating environments in the normal operating environment. Different from the above trust zone technology, the virtualization extension technology is a technology for running multiple operating systems on an electronic device. The electronic device can establish the TEE on a virtual machine, so that the TEE can provide a secure operating environment for service execution.

[0056] Currently, ARMv8 supports four exception levels (EL), namely EL0 to EL3, and the larger the number after the exception level, the higher the security level. Generally speaking, application programs (such as client applications CA and trusted applications TA) run on the EL0 layer, the system kernel (referred to as the operating system in some embodiments, such as REE OS or TEE OS) runs on the EL1 layer, and the virtual machine monitor runs on the EL2 layer.

[0057] In some embodiments, the REE can communicate with the QTEE (QTEE is a trusted execution environment provided) through a security monitor, where the security monitor runs on the EL3 layer, and the embodiments of this application do not involve QTEE.

[0058] It should be noted that the multiple trusted execution environments (such as the first trusted execution environment QTVM and the second trusted execution environment HTVM in the following text) involved in the embodiments of this application are all established on virtual machines, specifically referring to Figure 1 the framework shown.

[0059] 2. Rich Execution Environment (REE): It can be called a general execution environment. Among them, the rich execution environment operating system (REE OS) and CA on a general-purpose processor can run in the REE. Exemplarily, the REE OS can be the Android operating system (Android OS).

[0060] 3. Other Terms

[0061] In the embodiments of the present application, terms such as "first" and "second" are used to distinguish identical or similar items with basically the same functions and roles. For example, the first trusted execution environment and the second trusted execution environment are only used to distinguish different trusted execution environments, and do not limit their sequence. Those skilled in the art can understand that terms such as "first" and "second" do not limit the quantity and execution order, and "first", "second", etc. do not necessarily mean different.

[0062] It should be noted that in the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design described as "exemplary" or "for example" in the present application should not be construed as more preferred or more advantageous than other embodiments or design. Rather, the use of words such as "exemplary" or "for example" aims to present relevant concepts in a specific manner.

[0063] In the embodiments of the present application, "at least one" means one or more, and "multiple" means two or more. "And / or" describes the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the associated objects before and after are in an "or" relationship. "At least one (item)" or its similar expression refers to any combination of these items, including any combination of single item (item) or plural items (items). For example, at least one (item) of a, b, or c can represent: a, b, c, a - b, a - c, b - c, or a - b - c, where a, b, c can be single or multiple.

[0064] 4. Electronic Device

[0065] The electronic device according to the embodiment of the present application can be a handheld device, a vehicle-mounted device, etc. deployed with multiple TEEs. For example, some electronic devices are: mobile phone, tablet computer, handheld computer, laptop computer, mobile internet device (MID), wearable device, virtual reality (VR) device, augmented reality (AR) device, wireless terminal in industrial control, wireless terminal in self-driving, wireless terminal in remote medical surgery, wireless terminal in smart grid, wireless terminal in transportation safety, wireless terminal in smart city, wireless terminal in smart home, cellular phone, cordless phone, session initiation protocol (SIP) phone, wireless local loop (WLL) station, personal digital assistant (PDA), handheld device with wireless communication function, computing device or other processing device connected to a wireless modem, vehicle-mounted device, wearable device, terminal device in a 5G network or terminal device in a future evolved public land mobile network (PLMN), etc. The embodiment of the present application does not limit this.

[0066] As an example and not a limitation, in the embodiment of the present application, the electronic device can also be a wearable device. A wearable device can also be called a wearable intelligent device, which is the general term for devices developed by applying wearable technology to the intelligent design of daily wear, such as glasses, gloves, watches, clothing, shoes, etc. A wearable device is a portable device that is directly worn on the body or integrated into the user's clothes or accessories. A wearable device is not only a hardware device, but also realizes powerful functions through software support, data interaction, and cloud interaction. Broadly speaking, wearable intelligent devices include those with complete functions and large sizes that can realize complete or partial functions without relying on a smartphone, such as smart watches or smart glasses, etc., and those that only focus on a certain type of application function and need to cooperate with other devices such as smartphones, such as various smart bracelets and smart jewelry for physical sign monitoring.

[0067] In addition, in the embodiments of the present application, the electronic device may also be a terminal device in an Internet of Things (IoT) system. IoT is an important part of the future development of information technology. Its main technical feature is to connect objects to the network through communication technology, thereby realizing an intelligent network of human-machine interconnection and thing-thing interconnection.

[0068] The electronic device in the embodiments of the present application may also be referred to as: terminal device, user equipment (UE), mobile station (MS), mobile terminal (MT), access terminal, user unit, user station, mobile station, mobile terminal, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication device, user agent or user device, etc.

[0069] Figure 1 It is a framework schematic diagram of an electronic device provided for the embodiments of the present application. As Figure 1 shown, the framework includes: an Android VM running in a Rich Execution Environment (REE), a QTVM (Qualcomm Trusted VM, where VM is the abbreviation of virtual machine) running in a first trusted execution environment, and an HTEE VM (Honor Trusted Execution Environment VM, also referred to as HTVM) running in a second trusted execution environment.

[0070] The first trusted execution environment and the second trusted execution environment are two independent trusted execution environments. QTVM and HTVM can be regarded as two virtual machines running in different trusted execution environments. In some embodiments, QTVM and HTVM can also be regarded as two different trusted execution environments.

[0071] Figure 1 Among them, the client application CA and the Android OS run on the Android VM, the trusted application TA1 and the first trusted execution environment operating system (i.e., the HTVM OS in the figure) run on the HTVM, and the trusted application TA2 and the second trusted execution environment operating system (i.e., the QTVM OS in the figure) run on the QTVM.

[0072] Figure 1The specific process of the client application invoking the trusted application TA2 in the second trusted execution environment is represented by arrows and labels S11 to S18. Specifically, when the client application needs to access TA2, the client application sends a request to the Android operating system. After passing through the kernel driver in the Android operating system, the client application request is sent to the virtual machine manager by calling HVC (hypervisor call). After being processed by the virtual machine manager, it is sent to the second trusted execution environment operating system. After being processed by the distribution of the second trusted execution environment operating system, it is sent to TA2. After TA2 processes the received request, the processing result is returned to the second trusted execution environment operating system, and the HVC instruction is called through the second trusted execution environment operating system and sent to the virtual machine manager; after being processed by the virtual machine manager, the processing result of TA2 is returned to the Android operating system; then the Android operating system sends the processing result to the corresponding client application.

[0073] When the client application needs to access the trusted application TA1 in the first trusted execution environment, the client application can access the trusted application TA2 in the second trusted execution environment, and TA2 calls TA1. Among them, the process of TA2 calling TA1 can refer to Figure 1 S21 to S28 in. Specifically, TA2 sends a request to the second trusted execution environment operating system. After passing through the kernel driver in the second trusted execution environment operating system, the request is sent to the virtual machine manager by calling HVC. After being processed by the virtual machine manager, it is sent to the first trusted execution environment operating system. After being processed by the distribution of the first trusted execution environment operating system, it is sent to TA1. After TA1 processes the received request, the processing result is returned to the second trusted execution environment operating system, and the HVC instruction is called through the second trusted execution environment operating system and sent to the virtual machine manager. After being processed by the virtual machine manager, the processing result of TA1 is returned to the second trusted execution environment operating system; then the second trusted execution environment operating system sends the processing result to TA2. Subsequently, TA2 returns the processing result from TA1 to the corresponding client application.

[0074] In some embodiments, when the client application needs to access TA1, it can communicate with the first trusted execution environment directly through the virtual machine manager without passing through the second trusted execution environment. The interaction process is similar to the interaction process (S11 to S18) between the client application and TA2, and will not be elaborated here.

[0075] In addition, the electronic device further includes a hardware platform for supporting the operation of the electronic device and storing security hardware resources. For example, the security hardware resources may include secure memory, hardware keys, secure keyboards, etc. In the embodiments of the present application, the secure memory can be used to store the backed-up TEE OS image, resources related to the links between trusted execution environments (such as Link 1 described later), and data related to trusted applications (such as facial data).

[0076] Figure 2 It is a schematic structural diagram of an electronic device provided by an embodiment of the present application. As Figure 2 shown, the electronic device 100 may include: a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headset interface 170D, sensors 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. It can be understood that the structure illustrated in this embodiment does not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may include more or fewer components than those illustrated, or combine certain components, or split certain components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0077] In some embodiments of the present application, the operating environment of the processor 110 may include: a rich execution environment REE, at least two trusted execution environments, such as a first trusted execution environment and a second trusted execution environment. Exemplarily, a trusted application TA1 and a first trusted execution environment operating system (QTVM OS) are running in the first trusted execution environment, a trusted application TA2 and a second trusted execution environment operating system (HTVM OS) are running in the second trusted execution environment, and a client application CA and an Android operating system (Android OS) are running in the REE. The REE is used to receive a trusted application request initiated by a user through the client application, and call TA1 in the first trusted execution environment or call TA2 in the second trusted execution environment according to the trusted application request, and the corresponding TA returns the result.

[0078] The software system of the electronic device 100 may adopt a layered architecture, an event-driven architecture, a microkernel architecture, a microservices architecture, or a cloud architecture. In the embodiments of this application, taking the Android system with a layered architecture as an example, the software structure of the electronic device 100 is exemplarily described.

[0079] Figure 3 This is a software structure block diagram of an electronic device provided in the embodiments of this application. The layered architecture divides the software into several layers, and each layer has a clear role and division of labor. The layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom, which are the application layer, the application framework layer, the Android runtime and system libraries, and the kernel layer.

[0080] The application layer may include a series of application packages. As Figure 3 shown, the application packages may include applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, short message, etc. In some embodiments of this application, the applications in this application layer run on the EL0 layer of the electronic device.

[0081] The application framework layer provides application programming interfaces (APIs) and programming frameworks for the applications in the application layer. The application framework layer includes some predefined functions. As Figure 3 shown, the application framework layer may include a window manager, a content provider, a view system, a telephone manager, a resource manager, a notification manager, etc. In some embodiments of this application, the application framework layer in the Android system correspondingly distributes in the EL0 and EL1 layers of the electronic device.

[0082] The Android runtime includes a core library and a virtual machine. The Android runtime is responsible for the scheduling and management of the Android system. The core library contains two parts: one part is the functional functions that the Java language needs to call, and the other part is the core library of Android. The application layer and the application framework layer run in the virtual machine. The virtual machine executes the Java files of the application layer and the application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0083] The system libraries may include multiple functional modules. For example: surface manager, Media Libraries, 3D graphics processing library (e.g., OpenGL ES), 2D graphics engine (e.g., SGL), etc.

[0084] In some embodiments of the present application, the Android runtime and system libraries in the Android system can be correspondingly distributed in the EL0 and EL1 layers of the electronic device.

[0085] The kernel layer is the layer between hardware and software. The kernel layer at least includes a display driver, a camera driver, an audio driver, and a sensor driver. In some embodiments of the present application, the kernel layer is correspondingly distributed in the EL1 layer of the electronic device.

[0086] Figure 4 It is a schematic diagram of the framework of an electronic device provided by an embodiment of the present application. In this framework, the electronic device includes an application layer (which can also be called a service layer), a protocol layer, a driver layer (which can also be called a kernel layer), and a hardware layer.

[0087] The application layer includes a client application CA, a trusted application TA2, and a trusted application TA1 that provides services for the trusted application.

[0088] CA includes third-party applications or system applications such as banking applications, etc. CA runs in the rich execution environment REE. The trusted application TA2 includes, for example, TUI (trusted user interface) TA and Face (face) TA. TA2 runs in the second trusted execution environment HTVM. The trusted application TA1 includes two services, namely TUICoreService (secure display service) and DSP_Service (secure DSP (digital signal processing) service), which provide remote call services for TUI TA and Face TA respectively. TA1 runs in the first trusted execution environment QTVM.

[0089] The protocol layer is located between the application layer and the driver layer, and is responsible for data encapsulation and unpacking processing to ensure that data is transmitted in accordance with a specific protocol format. This specific protocol can be the minkipc protocol, and minkipc is the communication protocol for remote calls between the first trusted execution environment and the second trusted execution environment.

[0090] In HTVM, the protocol layer provides the libminkipc shared library, and the TUI TA or Face TA in the application layer communicates with the driver layer by calling the interface of the libminkipc shared library. In QTVM, the protocol layer is configured with a proxy module 1 (or called the TVMMink module, which is described as the first proxy module in some embodiments). The proxy module 1 is responsible for forwarding the data from HTVM to the TA1 corresponding to TA2, or encapsulating the data returned by TA1 to ensure that the data is returned to HTVM in accordance with the minkipc protocol.

[0091] The driver layer includes a driver manager 2 (platdrv) and a message queue driver 2 (msgq_drv1), a driver manager 3 (tzdriver) and a message queue driver 3 (msgq_drv3), a message queue driver 1 (qmsgq_drv), a secure DSP driver, a display driver, etc. Among them, the driver manager 2 and the message queue driver 2 run in the second trusted execution environment, the driver manager 3 and the message queue driver 3 run in the rich execution environment, and the message queue driver 1, the secure DSP driver, and the display driver run in the first trusted execution environment.

[0092] The driver manager 2 is responsible for managing multiple drivers including the message queue driver 2, the driver manager 3 is responsible for managing multiple drivers including the message queue driver 3, and the message queue driver 2 communicates with the message queue driver 1 and the message queue driver 3 respectively to achieve data interaction between different execution environments. That is to say, different execution environments can perform data interaction through the links established by the driver layer. The secure DSP driver is used to drive the secure PD (secure process domain) to work. The display driver is used to drive the display to work.

[0093] In some examples, the message queue driver 2 communicates with the message queue driver 1 through the virtual machine manager, and the message queue driver 2 communicates with the message queue driver 3 through the virtual machine manager.

[0094] The hardware layer includes but is not limited to a secure PD, a display, a camera, etc. Among them, the secure PD is a virtual secure DSP that provides secure general computing acceleration capabilities. In the embodiments of the present application, a face data verification algorithm is configured in the secure PD to improve the processing speed of face data verification.

[0095] Based on Figure 4 In the shown framework, when the client application CA of the electronic device needs to call the trusted application TA1 in the first trusted execution environment through the trusted application TA2 in the second trusted execution environment, it can communicate by constructing a message queue (abbreviated as msgq) link (such as link 1, link 2, link 3, etc.) through the driver layer. The message queue link can be regarded as a link between two trusted execution environments (i.e., between HTVM and QTVM), specifically, it can be a link between the message queue driver 2 and the message queue driver 1.

[0096] Figure 5 It is a schematic diagram of the interaction process of an electronic device provided by the embodiments of the present application. In Figure 4Based on the framework shown above, taking the trusted application TA2 as the Face TA and the trusted application TA1 as the DSP_Service as an example, the process of the client application invoking the facial verification service will be described in detail. As Figure 5 shown, this process includes:

[0097] S101. After the client application CA in the Rich Execution Environment REE is started, CA sends a first message to the message queue driver 3. The first message is used to indicate starting the trusted application Face TA in the second trusted execution environment HTVM.

[0098] In some examples, after CA is started, CA sends a first message to the message queue driver 3 through the driver manager 3.

[0099] Among them, CA can be, for example, a wallet application of the Android system. In response to the user's operation of starting the wallet application, the wallet application communicates with the Face TA in the HTVM through the message queue driver 3 in the driver layer to start the Face TA.

[0100] S102. The message queue driver 3 sends the first message to the message queue driver 2.

[0101] In some examples, the message queue driver 3 sends the first message to the message queue driver 2 through the virtual machine manager.

[0102] S103. The message queue driver 2 sends the first message to the Face TA.

[0103] In some examples, the message queue driver 2 sends the first message to the Face TA through the driver manager 2. Specifically, instance 1 of the message queue driver 2 sends the first message to the Face TA through the driver manager 2. Instance 1 is an instance in the message queue driver 2 and is responsible for transmitting and processing messages between the HTVM and the REE.

[0104] S104. Based on the first message, the Face TA initializes instance 2 in the message queue driver 2.

[0105] After receiving the first message, the Face TA instructs the message queue driver 2 to initialize instance 2 through the driver manager 2. Instance 2 is another instance in the message queue driver 2, different from instance 1. Instance 2 is responsible for transmitting and processing messages between the HTVM and the QTVM.

[0106] After the Face TA is started, it initializes instance 2 in the message queue driver 2 to prepare for subsequent communication between the Face TA in the HTVM and the DSP_Service in the QTVM.

[0107] S105. In response to the user's operation of using the face verification service of CA, CA sends a second message to the message queue driver 3, and the second message is used to request to call the DSP_Service (including the face verification service) of the first trusted execution environment QTVM.

[0108] Exemplarily, taking CA as the wallet application, after the user opens the wallet application, in response to the operation of using the face verification service provided by the wallet application, the wallet application sends a second message to the Face TA of HTVM through the message queue driver 3, so that the Face TA calls the DSP_Service of QTVM.

[0109] In some examples, CA sends a second message to the message queue driver 3 through the driver manager 3.

[0110] S106.The message queue driver 3 sends the second message to the message queue driver 2.

[0111] In some examples, the message queue driver 3 sends the second message to the message queue driver 2 through the virtual machine manager.

[0112] S107.The message queue driver 2 sends the second message to the Face TA.

[0113] In some examples, instance 1 of the message queue driver 2 sends the second message to the Face TA through the driver manager 2.

[0114] S108.Based on the second message, the Face TA sends a first request to the message queue driver 2, and the first request is used to request to establish a link between HTVM and QTVM.

[0115] In some examples, the Face TA calls the protocol layer libminkipc shared library based on the second message and sends a first request to the message queue 2 through the driver manager 2.

[0116] S109.The message queue driver 2 sends the first request to the message queue driver 1 to establish link 1 between HTVM and QTVM.

[0117] In some examples, based on the first request, the message queue driver 2 applies for resources related to link 1 (i.e., resources related to link 1 on the HTVM side) from the HTVM system, and then sends the first request to the message queue driver 1.

[0118] S110.The message queue driver 1 sends the first request to the proxy module 1 of QTVM.

[0119] In some examples, after receiving the first request, the proxy module 1 applies for resources related to link 1 (i.e., resources related to link 1 on the QTVM side) from the QTVM system.

[0120] S111. The proxy module 1 sends a first request to the DSP_Service.

[0121] S112. Based on the first request, the DSP_Service initializes the face verification algorithm.

[0122] In some examples, based on the first request, the DSP_Service calls the secure DSP driver to make the secure DSP driver drive the secure PD to initialize the face verification algorithm.

[0123] S113. After the face verification algorithm is successfully initialized, the DSP_Service sends a first response to the proxy module 1, and the first response is used to indicate that the face verification algorithm is successfully initialized.

[0124] S114. The proxy module 1 sends the first response to the message queue driver 1.

[0125] S115. The message queue driver 1 sends the first response to the message queue driver 2.

[0126] In some examples, the message queue driver 1 sends the first response to the message queue driver 2 through the virtual manager.

[0127] S116. The message queue driver 2 sends the first response to the Face TA.

[0128] In some examples, the message queue driver 2 sends the first response to the Face TA through the driver manager 2.

[0129] After completing the initialization process of the face verification algorithm, the Face TA can call the DSP_Service through Link 1 for face data verification, specifically referring to S117 to S123 below.

[0130] S117. Based on the first response, the Face TA sends a first instruction to the message queue driver 2, and the first instruction is used to indicate that the DSP_Service performs face data verification.

[0131] In some examples, based on the first response, the Face TA sends a first instruction to the message queue driver 2 through the driver manager 2.

[0132] S118. The message queue driver 2 sends the first instruction to the message queue driver 1.

[0133] In some examples, the message queue driver 2 sends the first instruction to the message queue driver 1 through the virtual machine manager.

[0134] S119. The message queue driver 1 sends the first instruction to the proxy module 1.

[0135] S120. The proxy module 1 sends a first instruction to DSP_Service.

[0136] S121. Based on the first instruction, DSP_Service verifies the facial data and obtains a facial verification result.

[0137] In some examples, based on the first instruction, DPS_Service calls the secure DSP driver to enable the secure DSP driver to drive secure PD to perform facial data verification. Specifically, secure PD obtains the facial data collected by the camera from the shared memory and performs facial data verification based on a preset facial verification algorithm to obtain a facial verification result.

[0138] S122. DSP_Service sends the facial verification result to Face TA.

[0139] After obtaining the facial verification result from secure PD, DSP_Service sends the facial verification result to Face TA. In some examples, DSP_Service sends the facial verification result to message queue driver 1 through proxy module 1, and then message queue driver 1 sends the facial verification result to message queue driver 2. Instance 2 of message queue driver 2 sends the facial verification result to Face TA through driver manager 2.

[0140] S123. Face TA sends the facial verification result to CA.

[0141] In some examples, Face TA sends the facial verification result to message queue driver 2 through driver manager 2, and then instance 1 of message queue driver 2 sends the facial verification result to message queue driver 3. Message queue driver 3 sends the facial verification result to CA through driver manager 3 to complete this facial verification.

[0142] The above embodiments illustrate the interaction process in which the trusted application Face TA of HTVM establishes a link with QTVM through the driver layer and communicates with the trusted application DSP_Service of QTVM based on this link, realizing the communication of trusted applications between two trusted execution environments.

[0143] It should be noted that the communication between the trusted application TUICoreService of the first trusted execution environment QTVM and the TUI TA of the second trusted execution environment HTVM is similar to the communication between DSP_Service of QTVM and Face TA of HTVM in the foregoing embodiments, and can be specifically referred to the foregoing embodiments.

[0144] Based onFigure 5 As can be learned from the illustrated embodiments, the trusted applications in the second trusted execution environment can establish a link between the second trusted execution environment and the first trusted execution environment by calling the Libminkipc interface corresponding to the trusted application in the Libminkipc shared library of the protocol layer and sending a request to the message queue driver 2 through the driver manager 2. For example, FaceTA calls the Libminkipc shared library and sends a request to the message queue driver 2 through the driver manager 2 to establish a link between the second trusted execution environment and the first trusted execution environment. Another example is that TUI TA calls the Libminkipc shared library and sends a request to the message queue driver 2 through the driver manager 2 to establish a link between the second trusted execution environment and the first trusted execution environment.

[0145] Considering that multiple TAs 2 may access the first trusted execution environment during the same period, generally, a preset number (e.g., the preset number is 2) of links can be maintained between the first trusted execution environment and the second trusted execution environment. In this way, during the same period, the above-mentioned Face TA and TUI TA can communicate with the first trusted execution environment based on the links created by them respectively.

[0146] It can be understood that the more links that can be maintained between the first trusted execution environment and the second trusted execution environment, the more system resources are occupied, which will affect the communication quality between the two trusted execution environments. In view of this, the embodiments of the present application provide an improved framework for an electronic device. By adding a proxy module (such as the second proxy module or proxy module 2 described later) to the protocol layer of the second trusted execution environment, each trusted application in the second trusted execution environment interacts with the first trusted execution environment through the added proxy module, which can reduce the system load and improve the communication quality between trusted applications in a multi-trusted execution environment.

[0147] The following will Figure 6 describe the improved framework of the electronic device in detail.

[0148] Figure 6 is a schematic diagram of the framework of an electronic device provided by an embodiment of the present application. Based on the Figure 4 illustrated framework, as Figure 6As shown in the figure, in the second trusted execution environment HTVM, the protocol layer configures the proxy module 2 (or called the Minkhub module, described as the second proxy module in some embodiments). The proxy module 2 is responsible for encapsulating the requests (or instructions) from the trusted applications in the HTVM and forwarding them to the driver manager 2, so that the driver manager 2 drives the message queue driver 2, and the message queue driver 2 sends the requests (or instructions) from the trusted applications in the HTVM to the first trusted execution environment QTVM. In addition, the proxy module 2 is also responsible for returning the responses (or data) from the QTVM to the corresponding trusted applications in the HTVM. Figure 6 For other modules or devices in Figure 4 the embodiments, they will not be elaborated here.

[0149] Based on Figure 6 the framework shown in the figure, one or more trusted applications TA2 in the second trusted execution environment, such as Face TA and / or TUI TA, can establish a link with the first trusted execution environment through the proxy module 2 to achieve communication between the two trusted execution environments. When a certain TA2 (such as Face TA) in the second trusted execution environment exits abnormally, other TA2s (such as TUI TA) can still communicate with the first trusted execution environment normally through the proxy module 2 based on the previously established link, that is, the abnormal exit of a certain TA2 in the second trusted execution environment does not affect other TA2s from calling the corresponding trusted applications in the first trusted execution environment to execute corresponding services based on the previously established link. It can be seen that the second trusted execution environment communicates with the first trusted execution environment through the added proxy module 2, only needs to maintain one link, can reduce the system load, and improve the stability of system communication.

[0150] Figure 7 This is a schematic diagram of the interaction process of an electronic device provided by an embodiment of the present application. Based on Figure 6 the framework shown in the figure, taking the trusted application TA2 as Face TA and the trusted application TA1 as DSP_Service as an example, the process of the client application calling the face verification service will be described in detail below. As Figure 7 shown in the figure, this process includes:

[0151] S201. After the operating system of the second trusted execution environment HTVM is started, the proxy module 2 is initialized.

[0152] After the HTVM system is started, the proxy module 2 can be initialized by calling the interface provided by the proxy module 2.

[0153] S202. The proxy module 2 sends the third message to the message queue driver 2.

[0154] In some examples, after initializing the proxy module 2, the proxy module 2 sends a third message to the message queue driver 2 through the driver manager 2. The third message is used to indicate initializing an instance 2 of the message queue driver 2. Based on the foregoing embodiments, the instance 2 of the message queue driver 2 is responsible for transmitting and processing messages between the HTVM and the QTVM.

[0155] S203. Based on the third message, the message queue driver 2 initializes an instance 2 of the message queue driver 2.

[0156] In some embodiments, after S203, the following is executed:

[0157] S105. In response to the user's operation of using the face verification service of the CA, the CA sends a second message to the message queue driver 3. The second message is used to request to invoke the DSP_Service of the QTVM (including the face verification service).

[0158] S106. The message queue driver 3 sends the second message to the message queue driver 2.

[0159] S107. The message queue driver 2 sends the second message to the Face TA.

[0160] S105 to S107 can be referred to the foregoing embodiments and will not be elaborated here.

[0161] After the Face TA receives the second message, the following is executed:

[0162] S204. Based on the second message, the Face TA sends a first request to the proxy module 2. The first request is used to request to establish a link between the HTVM and the QTVM.

[0163] In some examples, the Face TA sends the first request to the proxy module 2 by invoking an interface provided by the proxy module 2.

[0164] S205. The proxy module 2 sends the first request to the message queue driver 2.

[0165] In some examples, after receiving the first request, the proxy module 2 encapsulates and processes the first request by invoking the protocol layer libminkipc shared library, and then sends the processed first request to the message queue driver 2.

[0166] In some examples, the proxy module 2 sends the first request to the message queue driver 2 through the driver manager 2.

[0167] After S205, the following is executed:

[0168] S109. The message queue driver 2 sends the first request to the message queue driver 1 to establish a link 1 between the HTVM and the QTVM.

[0169] In some examples, after the message queue driver 2 applies for resources related to link 1 from the HTVM system based on the first request, it sends the first request to the message queue driver 1.

[0170] S110. The message queue driver 1 sends the first request to the proxy module 1 of QTVM.

[0171] S111. The proxy module 1 sends the first request to DSP_Service.

[0172] S112. DSP_Service initializes the face verification algorithm based on the first request.

[0173] S111. The proxy module 1 sends the first request to DSP_Service.

[0174] S112. DSP_Service initializes the face verification algorithm based on the first request.

[0175] S113. After the face verification algorithm is successfully initialized, DSP_Service sends the first response to the proxy module 1, and the first response is used to indicate that the face verification algorithm is successfully initialized.

[0176] S114. The proxy module 1 sends the first response to the message queue driver 1.

[0177] S115. The message queue driver 1 sends the first response to the message queue driver 2.

[0178] S109 to S115 can be referred to the foregoing embodiments and will not be elaborated here.

[0179] After S115, execute:

[0180] S206. The message queue driver 2 sends the first response to the proxy module 2.

[0181] In some examples, the message queue driver 2 sends the first response to the proxy module 2 through the driver manager 2.

[0182] S207. The proxy module 2 sends the first response to Face TA.

[0183] S208. Face TA sends the first instruction to the proxy module 2 based on the first response, and the first instruction is used to instruct DSP_Service to perform face data verification.

[0184] In some examples, Face TA sends the first instruction to the proxy module 2 based on the first response by calling the interface provided by the proxy module 2.

[0185] S209. The proxy module 2 sends a first instruction to the message queue driver 2.

[0186] In some examples, the proxy module 2 encapsulates the first instruction by calling the protocol layer libminkipc shared library, and then sends the processed first instruction to the message queue driver 2.

[0187] After S209, execute:

[0188] S118. The message queue driver 2 sends the first instruction to the message queue driver 1.

[0189] S119. The message queue driver 1 sends the first instruction to the proxy module 1.

[0190] S120. The proxy module 1 sends the first instruction to DSP_Service.

[0191] S121. DSP_Service verifies the facial data based on the first instruction and obtains a facial verification result.

[0192] S122. DSP_Service sends the facial verification result to Face TA.

[0193] After obtaining the facial verification result from secure PD, DSP_Service sends the facial verification result to Face TA.

[0194] In some examples, DSP_Service sends the facial verification result to the message queue driver 1 through the proxy module 1, and then the message queue driver 1 sends the facial verification result to the message queue driver 2. The message queue driver 2 sends the facial verification result to the driver manager 2, and the driver manager 2 sends the facial verification result to Face TA through the proxy module 2.

[0195] S123. Face TA sends the facial verification result to CA. [[ID=3,2]]

[0196] S118 to S121 and S123 can refer to the foregoing embodiments and will not be elaborated here.

[0197] The communication method shown in this embodiment, compared with Face TA itself establishing a link with QTVM through the driver layer (see the embodiment shown in Figure 5 ), by adding a proxy module 2 independent of Face TA, Face TA calls the proxy module 2, and the proxy module 2 establishes a link with QTVM. When other trusted applications of HTVM (such as Figure 6 's TUI TA) call the corresponding trusted application in QTVM (such as Figure 6When communicating with QTVM through the TUICoreService in the system, the existing link established by the proxy module 2 based on the Face TA call can be directly reused, thereby achieving communication with QTVM. In this way, the system only needs to maintain one link, which can reduce the system load and improve the communication quality between trusted applications in a multi-trusted execution environment.

[0198] In some embodiments, after S203, as Figure 8 shown, the following steps can be executed:

[0199] S301. The message queue driver 2 applies for resources related to the HTVM side link 1.

[0200] S302. The message queue driver 2 sends a second request to the message queue driver 1. The second request is used to request to establish a link between the HTVM and the QTVM. In some examples, the instance 2 of the message queue driver 2 sends the second request to the message queue driver 1 through the virtual machine manager.

[0201] S303. The message queue driver 1 sends the second request to the proxy module 1.

[0202] S304. The proxy module 1 applies for resources related to the QTVM side link 1 based on the second request.

[0203] Different from Figure 7 the embodiments, in this embodiment, after the proxy module 2 is initialized, it can directly drive the message queue driver 2 to initiate a link request (i.e., the second request) to the first trusted execution environment QTVM to establish a link between the HTVM and the QTVM. When a trusted application in the second trusted execution environment HTVM needs to call a trusted application of the QTVM, this link can be directly used for communication. This embodiment is applicable to services (businesses) with high performance requirements. In this way, by reusing the pre-created link, the response ability of the HTVM application layer (business layer) can be improved.

[0204] Based on the foregoing several embodiments, in a possible situation, after the Face TA is started, due to some reasons, such as execution errors caused by code exceptions, camera service exceptions, etc., the Face TA may exit abnormally.

[0205] In some embodiments, based on Figure 4 the framework shown, after the Face TA exits abnormally (or exits normally), the HTVM system can send a system notification to the driver manager 2. The driver manager 2, based on the system notification, instructs the message queue driver 2 to release the link between the HTVM and the QTVM and the resources related to this link. By releasing the abandoned link and related resources, the system load can be reduced and the communication quality between trusted applications in a multi-trusted execution environment can be improved.

[0206] In some embodiments, based onFigure 6 For the framework shown, after Face TA abnormally exits, the HTVM system can send a system notification to proxy module 2. Based on the system notification, proxy module 2 determines whether to instruct message queue driver 2 to release the link between it and QTVM and the resources related to this link. It can be understood that since proxy module 2 is responsible for processing requests from different trusted applications in HTVM, after Face TA abnormally exits, proxy module 2 needs to determine whether to release the existing link and the resources related to the existing link based on the running status of other trusted applications (such as TUI TA, etc.) in the current HTVM system. The following combines the attached Figure 9 A detailed description of the interaction process of the electronic device after Face TA abnormally exits is provided.

[0207] Figure 9 FIG. is an interaction schematic diagram of an electronic device provided by an embodiment of the present application. Based on Figure 6 the framework shown and Figure 7 the process shown, Face TA of HTVM has established a link 1 with QTVM by calling proxy module 2. As Figure 9 shown, if Face TA abnormally exits after startup, the following process can be executed:

[0208] S401. Proxy module 2 receives a first system notification, which is used to indicate that Face TA abnormally exits.

[0209] S402. Proxy module 2 determines whether to release link 1 based on the first system notification.

[0210] After receiving the first system notification, proxy module 2 determines whether there are other trusted applications running in the current HTVM. If so, link 1 is not released; if not, S403 is executed.

[0211] In some embodiments, whether there are other trusted applications running in HTVM can also be described as: whether there are other trusted applications in HTVM that are calling the trusted applications of the first trusted execution environment through proxy module 2.

[0212] S403. Proxy module 2 sends a first indication message to message queue driver 2, and the first indication message is used to indicate the release of link 1 and the resources related to link 1.

[0213] In some examples, proxy module 2 sends the first indication message to message queue driver 2 through driver manager 2.

[0214] Exemplarily, after the Face TA abnormally exits, the HTVM system sends a first system notification to the proxy module 2. If the proxy module 2 determines that the TUI TA is in a running state (e.g., the TUI TA calls the TUICoreService of QTVM through the proxy module 2), then after receiving the first system notification, the proxy module 2 does not release the link 1 between the HTVM and the QTVM.

[0215] S404. The message queue driver 2 sends a first indication message to the message queue driver 1.

[0216] In some examples, the message queue driver 2 sends a first indication message to the message queue driver 1 through the virtual machine manager.

[0217] S405. The message queue driver 1 sends a first indication message to the proxy module 1.

[0218] S406. The proxy module 1 releases the resources related to the link 1 on the QTVM side based on the first indication message.

[0219] After S404, the following is also executed:

[0220] S407. The message queue driver 2 releases the resources related to the link 1 and the link 1 on the HTVM side based on the first indication message.

[0221] In the communication method shown in this embodiment, when the trusted application Face TA in the second trusted execution environment HTVM establishes a link with the first trusted execution environment QTVM through the proxy module 2, if the Face TA abnormally exits, the proxy module 2 independent of the Face TA can determine whether to release the existing link with the QTVM and the resources related to the link based on the running states of other trusted applications in the current HTVM system. It can be seen that after the Face TA abnormally exits, the proxy module 2 does not directly release the existing link and the resources related to the link based on this event. If there are other applications in the HTVM that need to reuse the existing link, the proxy module 2 can not respond to this event and retain the existing link. In this way, the recovery ability of the application layer of the HTVM can be improved.

[0222] Based on Figure 7 the embodiments shown, in a possible situation, after the proxy module 2 is started, due to some reasons, such as execution errors caused by code exceptions, etc., the proxy module 2 abnormally exits (it can also be described as the proxy module 2 crashing). It can be understood that after the proxy module 2 abnormally exits, the link established by the Face TA in the second trusted execution environment HTVM with the QTVM through the proxy module 2 becomes invalid, and the resources related to this link occupy the system memory.

[0223] In view of this, an embodiment of the present application shows a communication method by adding a message notification mechanism in the driver layer. This message notification is different from the aforementioned minkipc protocol. If the proxy module 2 exits abnormally, the HTVM system is responsible for restarting the proxy module 2. At the same time, the message notification mechanism is used to notify QTVM through the message queue driver 2 of the driver layer to release the corresponding resources on the QTVM side to improve system resource utilization.

[0224] Figure 10 This is a schematic diagram of an electronic device interaction provided by an embodiment of the present application. Figure 6 The framework shown and Figure 7 As shown in the process, the Face TA of HTVM has established a link 1 with QTVM by calling the proxy module 2, as shown in Figure 10 As shown, if the proxy module 2 exits abnormally, the following process can be executed:

[0225] S501. The driver manager 2 receives a second system notification, where the second system notification is used to indicate that the agent module 2 exits abnormally.

[0226] S502. The driver manager 2 sends a second instruction message to the message queue driver 2 based on the second system notification. The second instruction message is used to instruct the release of the link 1 and resources related to the link 1.

[0227] S503. Message queue driver 2 sends second instruction information to message queue driver 1.

[0228] The message queue driver 2 initializes the instance 3 based on the second indication information, and sends the second indication information to the message queue driver 1 based on the instance 3.

[0229] Instance 3 is an instance in message queue driver 2 that is different from Instance 1 and Instance 2. Instance 3 is based on a new message notification mechanism (using a protocol different from minkipc) to transmit and process messages between HTVM and QTVM.

[0230] In some examples, the message queue driver 2 sends the second indication information to the message queue driver 1 through the virtual machine manager.

[0231] S504 . The message queue driver 1 sends a second instruction message to the agent module 1 .

[0232] S505. The proxy module 1 releases resources related to the QTVM side link 1 based on the second indication information.

[0233] After S503, the following steps are also executed:

[0234] S506. The message queue driver 2 releases the link 1 and the resources related to the link 1 on the HTVM side based on the second instruction information.

[0235] In the communication method shown in this embodiment, when the trusted application Face TA in the second trusted execution environment HTVM establishes a link with the first trusted execution environment QTVM through the proxy module 2, if the proxy module 2 abnormally exits, the HTVM system notifies the message queue driver 2 of the driver layer. The message queue driver 2 releases the existing link and notifies QTVM to release the corresponding resources, avoiding the occupied system memory by the invalid link and improving the utilization rate of system resources.

[0236] Based on the foregoing several embodiments, by adding the proxy module 2 to the second trusted execution environment HTVM of the electronic device, the function of encapsulating data by each trusted application in HTVM by calling the libminkipc shared library is integrated into the proxy module 2, so as to decouple the module functions in the HTVM environment and achieve the purpose of improving the communication stability of the system. For example, based on the foregoing Figure 9 embodiment, the abnormal exit of Face TA will not affect the proxy module 2, and the proxy module 2 can still serve other trusted applications of HTVM. For another example, based on the foregoing Figure 10 embodiment, the abnormal exit of the proxy module 2 will not affect Face TA, and after the proxy module 2 abnormally exits, the system can restart the proxy module, and Face TA can re - call the proxy module 3 to establish a new link with QTVM.

[0237] Based on the foregoing several embodiments, the embodiment of the present application provides a communication method between trusted applications in a multi - trusted execution environment, which is applied to an electronic device. Referring to Figure 11 , the electronic device includes a first trusted execution environment and a second trusted execution environment. The first trusted execution environment includes a first trusted application and a second trusted application. The second trusted execution environment includes a third trusted application, a fourth trusted application, and a second proxy module. The method includes: [[ID=??]]

[0238] In response to an operation of starting the first service, the third trusted application of the electronic device calls the second proxy module and calls the first trusted application through the first link created by the second proxy module to execute the first service;

[0239] In response to an operation of starting the second service, the fourth trusted application of the electronic device calls the second proxy module and calls the second trusted application through the first link to execute the second service;

[0240] The first link is a link between the second trusted execution environment and the first trusted execution environment.

[0241] It should be noted that there seems to be a missing reference in . You may want to check and correct it for a more accurate translation. Also, the "??" in [[ID=??]] is likely a mistake in the original text.In this embodiment, the first trusted execution environment and the second trusted execution environment are two independent trusted execution environments in an electronic device. The first trusted execution environment can correspond to the QTVM in the foregoing embodiment, and the second trusted execution environment can correspond to the HTVM in the foregoing embodiment. The first trusted application and the second trusted application are trusted applications running in the first trusted execution environment. For example, the first trusted application is Figure 6 DSP_Service, and the second trusted application is Figure 6 TUICoreService. The third trusted application and the fourth trusted application are trusted applications running in the second trusted execution environment. For example, the third trusted application is Figure 6 Face TA, and the fourth trusted application is Figure 6 TUI TA. The first service and the second service are two different services provided for client applications in the rich execution environment of the electronic device. For example, the first service is a face verification service, and the second service is a secure display service. The first link can correspond to Link 1 in the foregoing embodiment.

[0242] In addition, the second proxy module is a functional module of the second trusted execution environment and can correspond to the proxy module 2 in the foregoing embodiment (i.e., Figure 6 Minkhub module).

[0243] In some examples, the second proxy module creates the first link through the driver layer. The first link can be regarded as a link between two trusted execution environments (such as HTVM and QTVM).

[0244] Exemplarily, referring to Figure 6 , in response to the user's operation of using the face verification service provided by the client application CA (for example, the user opens the face verification service provided by the wallet application), the Face TA of the HTVM calls the proxy module 2 and calls the DSP_Service of the QTVM through the first link created by the proxy module 2 to perform the face verification service. Similarly, in response to the user's operation of using the secure display service provided by the client application (for example, the user calls up the keyboard), the TUI TA of the HTVM calls the proxy module 2 and calls the TUICoreService of the QTVM through the first link created by the proxy module 2 to perform the secure display service (such as securely displaying the virtual keyboard for the user to enter the password).

[0245] The communication method shown in this embodiment is such that the second trusted execution environment of the electronic device includes a second proxy module. Each trusted application in the second trusted execution environment can call the second proxy module and, based on the first link created by the second proxy module with the first trusted execution environment, call the corresponding trusted application in the first trusted execution environment to execute the corresponding service. That is to say, after the second proxy module creates the first link, each trusted application in the first trusted execution environment can use this first link to communicate with the first trusted execution environment. In this way, the system only needs to maintain one link, which can reduce the system load and improve the communication quality between trusted applications in a multi-trusted execution environment.

[0246] In an optional embodiment, the second trusted execution environment further includes a second message queue driver, and the first trusted execution environment further includes a first message queue driver; the second proxy module creating the first link includes: in response to an operation to start the first service, the third trusted application calls the second proxy module; the second proxy module sends a first request to the first message queue driver through the second message queue driver to create the first link.

[0247] In this embodiment, the second message queue driver can correspond to the message queue driver 2 in the foregoing embodiment, and the first message queue driver can correspond to the message queue driver 1 in the foregoing embodiment.

[0248] Exemplarily, taking the first service as the face verification service, in response to the operation of the user using the face verification service provided by the client application, the Face TA of the electronic device calls the proxy module 2, and the proxy module 2 sends a first request to the message queue driver 1 through the message queue driver 2 to create the link 1. For the specific process, refer to Figure 7 S105 to S109 of the embodiment.

[0249] The communication method shown in this embodiment is such that the second proxy module can create a first link with the first trusted execution environment based on the call of a certain trusted application in the second trusted execution environment. That is to say, when a trusted application in the second trusted execution environment needs to interact with the first trusted execution environment, the second proxy module creates this first link. At the same time, the second proxy module can instruct the second message queue driver to apply to the system for resources related to the first link (i.e., apply for resources when in use). In this way, the system resource utilization rate can be improved.

[0250] In an optional embodiment, the second proxy module creating the first link includes: after the electronic device is started, the second proxy module is initialized; after the initialization of the second proxy module is completed, the second proxy module sends a second request to the first message queue driver through the second message queue driver to create the first link.

[0251] In some examples, the startup of the electronic device refers to after the operating system of the second trusted execution environment of the electronic device is started.

[0252] For the communication method shown in this embodiment, after the second proxy module of the electronic device is successfully initialized, a first link with the first trusted execution environment is directly created. It can be understood that it takes a certain amount of time to create the first link. If the first link is created in advance, then after the third trusted application or the fourth trusted application in the second trusted execution environment is started, the second proxy module can interact with the corresponding trusted application in the first trusted execution environment based on the already created first link, thereby improving the response ability of the system application layer.

[0253] In an optional embodiment, the method further includes: after the third trusted application exits abnormally, the second proxy module receives a first system notification; the second proxy module determines whether to release the first link based on the first system notification.

[0254] For the communication method shown in this embodiment, after the second proxy module learns that the third trusted application has exited abnormally, it does not directly release the first link.

[0255] In an optional embodiment, the second proxy module determines whether to release the first link based on the first system notification, including: the second proxy module determines whether there are other trusted applications running in the second trusted execution environment based on the first system notification; if so, the second proxy module determines not to release the first link; if not, the second proxy module determines to release the first link. Refer to Figure 9 the embodiment.

[0256] In some examples, whether there are other trusted applications running in the second trusted execution environment can also be described as: whether there are other trusted applications in the second trusted execution environment that are invoking the trusted application of the first trusted execution environment through the second proxy module.

[0257] For the communication method shown in this embodiment, after the second proxy module learns that the third trusted application has exited abnormally, it first determines whether there are other trusted applications in the current operating system of the second trusted execution environment that reuse the first link. If there are other applications that reuse the first link, the second proxy module does not release the first link, thus improving the response ability of the application layer of the second trusted execution environment.

[0258] In an optional embodiment, the first trusted execution environment also includes a first agent module, and the method further includes: if the second agent module determines to release the first link, the second agent module sends a first indication message to the second message queue, and the first indication message is used to indicate the release of the first link and the resources related to the first link; the second message queue releases the first link and the resources related to the first link in the second trusted execution environment based on the first indication message, and drives the sending of the first indication message to the first message queue; the first message queue sends the first indication message to the first agent module; the first agent module releases the resources related to the first link in the first trusted execution environment based on the first indication message. For details, please refer to Figure 9 Example.

[0259] In this embodiment, the first agent module is a functional module of the first trusted execution environment, which may correspond to the agent module 1 (ie Figure 6 TVMMink module).

[0260] In the communication method shown in this embodiment, when the third trusted application in the second trusted execution environment exits abnormally and the second agent module determines to release the first link, the second agent module can notify the second message queue driver and notify the first trusted execution environment through the second message queue driver to release the resources related to the first link in the two trusted execution environments, thereby avoiding the resources related to the first link from occupying system memory, and improving system resource utilization.

[0261] In an optional embodiment, the second trusted execution environment also includes a first driver manager, and the method also includes: after the second agent module exits abnormally, the first driver manager receives a second system notification; based on the second system notification, the first driver manager sends a second indication information to the second message queue driver, and the second indication information is used to indicate the release of the first link and the resources related to the first link; based on the first indication information, the second message queue driver releases the first link and the resources related to the first link in the second trusted execution environment, and sends the second indication information to the first message queue driver; the first message queue sends the second indication information to the first agent module; the first agent module releases the resources related to the first link in the first trusted execution environment based on the second indication information. For details, please refer to Figure 10 Example.

[0262] In this embodiment, the first driver manager may correspond to the driver manager 2 in the aforementioned embodiment.

[0263] The communication method shown in this embodiment, after the second proxy module abnormally exits, considering that the first link created by the second proxy module has become invalid, the second trusted execution environment operating system can notify the second message queue driver and, through the second message queue driver, notify the first trusted execution environment to release the resources related to the first link in the two trusted execution environments, avoiding the occupation of system memory by the resources related to the first link, and improving the utilization rate of system resources.

[0264] In an optional embodiment, the second message queue driver sends second indication information to the first message queue driver, including: the second message queue driver sends the second indication information to the first message queue driver based on a preset communication protocol.

[0265] In this embodiment, the preset communication protocol can be a protocol different from the minkipc protocol.

[0266] The communication method between trusted applications in a multi-trusted execution environment provided by the embodiments of the present application can be applied to an electronic device deployed with multiple trusted execution environments. The embodiments of the present application do not limit the specific form of the electronic device.

[0267] The embodiments of the present application provide an electronic device, which includes: a processor and a memory; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory, so that the electronic device executes the above method.

[0268] Figure 12 It is a schematic structural diagram of an electronic device provided by the embodiments of the present application. As Figure 12 shown, the electronic device includes a processor 1201, a communication line 1204, and at least one communication interface ( Figure 12 exemplarily illustrated by the communication interface 1203).

[0269] The processor 1201 can be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of the program of the present application solution.

[0270] The communication line 1204 can include a circuit for transmitting information between the above components.

[0271] The communication interface 1203 uses any transceiver-like device for communicating with other devices or communication networks, such as Ethernet, wireless local area networks (WLAN), etc.

[0272] In some embodiments, the electronic device may further include a memory 1202.

[0273] The memory 1202 may be a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM) or other type of dynamic storage device that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM), or other optical disc storage, optical disc storage (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), magnetic disk storage media, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory may exist independently and be connected to the processor through a communication line 1204. The memory may also be integrated with the processor.

[0274] The memory 1202 is used to store computer-executable instructions for implementing the solution of this application, and is controlled by the processor 1201 for execution. The processor 1201 is used to execute the computer-executable instructions stored in the memory 1202, so as to implement the method provided by the embodiments of this application.

[0275] The computer-executable instructions in the embodiments of this application may also be referred to as application code, and the embodiments of this application do not make specific limitations thereto.

[0276] As an example, the processor 1201 may include one or more CPUs.

[0277] As an example, the electronic device may include multiple processors. Each processor may be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. Here, the processor may refer to one or more devices, circuits, and / or processing cores for processing data (such as computer program instructions).

[0278] The embodiments of this application provide a chip. The chip includes a processor, and the processor is used to call a computer program in the memory to execute the technical solutions in the above embodiments. The implementation principle and technical effects are similar to those of the above related embodiments, and will not be elaborated here.

[0279] Figure 13 It is a schematic structural diagram of a chip provided by the embodiments of this application. AsFigure 13 As shown, chip 1300 includes one or more (including two) processors 1320 and a communication interface 1330.

[0280] In some embodiments, memory 1340 stores the following elements: executable modules or data structures, or subsets of executable modules or data structures, or extended sets of executable modules or data structures.

[0281] In the embodiments of the present application, memory 1340 may include a read-only memory and a random access memory, and provide instructions and data to processor 1320. A part of memory 1340 may also include a non-volatile random access memory (NVRAM).

[0282] In the embodiments of the present application, memory 1340, communication interface 1330, and memory 1340 are coupled together through a bus system 1310. Among them, bus system 1310 may include a power bus, a control bus, a status signal bus, etc. in addition to a data bus. For the sake of description, in Figure 13 all kinds of buses are labeled as bus system 1310.

[0283] The methods described in the above embodiments of the present application can be applied to processor 1320 or implemented by processor 1320. Processor 1320 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit in hardware or instructions in software form in processor 1320. The above-mentioned processor 1320 may be a general-purpose processor (for example, a microprocessor or a conventional processor), a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate, transistor logic devices, or discrete hardware components. Processor 1320 can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of the present application.

[0284] In the above embodiments, the instructions stored in the memory for the processor to execute can be implemented in the form of a computer program product. The computer program product can be pre-written in the memory or downloaded and installed in the memory in the form of software.

[0285] The embodiments of the present application also provide a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, the above-mentioned method is implemented. The methods described in the above embodiments can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. If implemented in software, the functions can be stored as one or more instructions or codes on a computer-readable medium or transmitted on a computer-readable medium. The computer-readable medium may include a computer storage medium and a communication medium, and may also include any medium that can transfer a computer program from one place to another. The storage medium can be any target medium accessible by a computer.

[0286] In a possible implementation, the computer-readable medium may include RAM, ROM, a read-only optical disc or other optical disc storage, a magnetic disk storage or other magnetic storage device, or any other medium targeted to carry or store the required program code in the form of instructions or data structures and accessible by a computer. Moreover, any connection is properly termed a computer-readable medium. For example, if software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, Digital Subscriber Line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of the medium. As used herein, disk and disc include optical disc, laser disc, optical disc, Digital Versatile Disc (DVD), floppy disk, and Blu-ray disc, where disks usually reproduce data magnetically, while discs reproduce data optically using lasers. The above combinations should also be included within the scope of the computer-readable medium.

[0287] The embodiments of the present application provide a computer program product including a computer program, which when run, causes a computer to execute the above-mentioned method.

[0288] The embodiments of the present application are described with reference to the flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or block in the flowchart and / or block diagram, and 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 the processing unit of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable devices to generate a machine, such that the instructions executed by the processing unit of the computer or other programmable data processing devices generate means for implementing the functions specified in one process Figure 1 one process or multiple processes and / or blocks Figure 1 one block or multiple blocks.

[0289] The above specific implementation manners have further elaborated on the purpose, technical solution and beneficial effects of the present application. It should be understood that the above are only specific implementation manners of the present application and are not used to limit the protection scope of the present application. Any modifications, equivalent replacements, improvements, etc. made on the basis of the technical solution of the present application shall be included within the protection scope of the present application.

Claims

1. A communication method between trusted applications in a multi-trusted execution environment, characterized in that: Applied to an electronic device, the electronic device includes a first trusted execution environment and a second trusted execution environment, the first trusted execution environment includes a first trusted application and a second trusted application, the second trusted execution environment includes a third trusted application, a fourth trusted application and a second agent module, the method includes: In response to the operation of starting the first service, the third trusted application of the electronic device calls the second agent module, and calls the first trusted application through the first link created by the second agent module to execute the first service; In response to the operation of starting the second service, the fourth trusted application of the electronic device calls the second agent module and calls the second trusted application through the first link to execute the second service; The first link is a link between the second trusted execution environment and the first trusted execution environment.

2. The method according to claim 1, characterized in that The second trusted execution environment further includes a second message queue driver, and the first trusted execution environment further includes a first message queue driver; The second agent module creates the first link, including: In response to the operation of starting the first service, the third trusted application calls the second agent module; The second agent module sends a first request to the first message queue driver through the second message queue driver to create the first link.

3. The method according to claim 1 or 2, characterized in that The method further comprises: After the third trusted application exits abnormally, the second agent module receives a first system notification; The second agent module determines whether to release the first link based on the first system notification.

4. The method according to claim 3, characterized in that The second agent module determines whether to release the first link based on the first system notification, including: The second agent module determines, based on the first system notification, whether other trusted applications are running in the second trusted execution environment; If so, the second agent module determines not to release the first link; If not, the second agent module determines to release the first link.

5. The method according to claim 3 or 4, characterized in that The first trusted execution environment further includes a first agent module, and the method further includes: If the second agent module determines to release the first link, the second agent module sends first indication information to the second message queue, where the first indication information is used to instruct to release the first link and resources related to the first link; The second message queue releases the first link and resources related to the first link in the second trusted execution environment based on the first indication information, and sends the first indication information to the first message queue driver; The first message queue sends the first indication information to the first agent module; The first agent module releases resources related to the first link in the first trusted execution environment based on the first indication information.

6. The method according to claim 1, wherein The second agent module creates the first link, including: After the electronic device is started, initializing the second agent module; After the second agent module is initialized, the second agent module sends a second request to the first message queue driver through the second message queue driver to create the first link.

7. The method according to any one of claims 1 to 6, characterized in that The second trusted execution environment further includes a first driver manager, and the method further includes: After the second agent module exits abnormally, the first driver manager receives a second system notification; The first driver manager sends second indication information to the second message queue driver based on the second system notification, where the second indication information is used to instruct the release of the first link and resources related to the first link; The second message queue driver releases the first link and resources related to the first link in the second trusted execution environment based on the first indication information, and sends the second indication information to the first message queue driver; The first message queue sends the second indication information to the first agent module; The first agent module releases resources related to the first link in the first trusted execution environment based on the second indication information.

8. The method according to claim 7, characterized in that The second message queue driver sending the second indication information to the first message queue driver includes: The second message queue driver sends the second indication information to the first message queue driver based on a preset communication protocol.

9. An electronic device, characterized in that: include: processor and memory; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory, so that the electronic device performs the method according to any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 8 is implemented.

Images