Communication methods and devices between trusted applications in a multi-trusted execution environment

Abstract

This application provides a communication method and device for trusted applications in a multi-trusted execution environment, applied to an electronic device including 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, and the second trusted execution environment includes a third trusted application, a fourth trusted application, and a second proxy module. In response to an operation to enable a first service, the third trusted application of the electronic device calls the second proxy module, and through a first link created by the second proxy module, calls the first trusted application to execute the first service. In response to an operation to enable a second service, the fourth trusted application of the electronic device calls the second proxy module, and through the first link, calls the second trusted application to execute the second service. Since the first link can be reused by each trusted application in the first trusted execution environment, the system load can be reduced, and the communication quality between trusted applications in a multi-trusted execution environment can be improved.

Description

Technical Field

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

[0002] With the continuous development of communication technology, applications in electronic devices are becoming increasingly diverse. To protect user privacy and information security, a Trusted Execution Environment (TEE) can be created within electronic devices to deploy higher-level and more reliable security measures. A TEE, also known as a Secure Execution Environment, can run a Trusted Execution Environment Operating System (TEE OS), providing trusted security services (such as fingerprint verification, password verification, and facial recognition) to Certificate Authorities (CAs). These security services can run as Trust Applications (TAs) on the TEE OS. Currently, multiple TEEs can be created within electronic devices; improving the communication quality between trusted applications under multiple TEEs is a pressing issue that needs to be addressed. Summary of the Invention

[0003] This application provides a communication method and device for trusted applications in a multi-trusted execution environment, which is applied in the field of terminal technology 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, 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 the 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;

[0006] In response to the operation of enabling 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;

[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 previous embodiment, and the second trusted execution environment can correspond to the HTVM in the previous 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 second trusted application is DSP_Service. Figure 6 The TUICoreService. The third and fourth trusted applications are trusted applications running within the second trusted execution environment. For example, the third trusted application is... Figure 6 Face TA, the fourth trusted application Figure 6 The first service and the second service are two different services provided by client applications in the rich execution environment of an 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 aforementioned embodiment.

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

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

[0011] For example, refer to Figure 6 In response to a user's operation using the facial verification service provided by the client application CA (e.g., the user opening the facial verification service provided by the wallet application), HTVM's Face TA calls proxy module 2, which in turn calls QTVM's DSP_Service through the first link created by proxy module 2 to execute the facial verification service. Similarly, in response to a user's operation using the secure display service provided by the client application (e.g., the user accessing the keyboard), HTVM's TUI TA calls proxy module 2, which in turn calls QTVM's TUICoreService through the first link created by proxy module 2 to execute the secure display service (e.g., securely displaying a virtual keyboard for the user to enter a password).

[0012] The communication method illustrated in this embodiment includes a second proxy module within the second trusted execution environment of the electronic device. Each trusted application in the second trusted execution environment can invoke the second proxy module and, based on the first link created by the second proxy module with the first trusted execution environment, invoke the corresponding trusted application in the first trusted execution environment to execute the corresponding service. In other words, 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, reducing system load and improving the communication quality between trusted applications in multiple trusted execution environments.

[0013] In one 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 creates a first connection, including: in response to the operation of starting 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 connection.

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

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

[0016] The communication method shown in this embodiment allows the second proxy module to create a first link with the first trusted execution environment based on a call from a trusted application in the second trusted execution environment. In other words, the second proxy module creates the first link only when a trusted application in the second trusted execution environment needs to interact with the first trusted execution environment. At the same time, the second proxy module can instruct the second message queue driver to request resources related to the first link from the system (i.e., resources are requested only when they are used), which can improve the system resource utilization rate.

[0017] In one optional embodiment of the first aspect, the second proxy module creates the first link by: initializing the second proxy module after the electronic device starts up; and after the second proxy module is initialized, sending a second request to the first message queue driver through the second message queue driver to create the first link. See details below. Figure 8 Example.

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

[0019] The communication method illustrated in this embodiment involves the electronic device's second agent module successfully initializing and then directly establishing a first link with the first trusted execution environment. It is understood that creating the first link takes some time. If the first link is created in advance, then after the third or fourth trusted application in the second trusted execution environment starts, the second agent module can interact with the corresponding trusted application in the first trusted execution environment based on the established first link, thereby improving the system's application layer responsiveness.

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

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

[0022] In one optional embodiment of the first aspect, the second proxy module determines whether to release the first link based on a first system notification, including: the second proxy module determining, based on the first system notification, whether there are other trusted applications running in the second trusted execution environment; 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. (See also...) Figure 9 Example.

[0023] In some examples, whether other trusted applications are running in the second trusted execution environment can also be described as: whether other trusted applications in the second trusted execution environment are calling trusted applications in the first trusted execution environment through the second proxy module.

[0024] In 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 reusing the first link in the current second trusted execution environment operating system. If there are other applications reusing the first link, the second proxy module does not release the first link, thus improving the response capability of the application layer of the second trusted execution environment.

[0025] In one optional embodiment of the first aspect, 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 a second message queue, the first indication information being used to indicate the release of the first link and resources related to the first link; the second message queue, based on the first indication information, releases the first link and 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 agent module; the first agent module, based on the first indication information, releases resources related to the first link in the first trusted execution environment. See details for further information. Figure 9 Example.

[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 aforementioned embodiment (i.e. Figure 6 TVMMink module).

[0027] The communication method shown in this embodiment, after the third trusted application in the second trusted execution environment exits abnormally and the second agent module determines to release the first link, can notify the second message queue driver, and through the second message queue driver notify the first trusted execution environment, so as to release the resources related to the first link in both trusted execution environments, avoid the resources related to the first link from occupying system memory, and improve the system resource utilization.

[0028] In one optional embodiment of the first aspect, the second trusted execution environment further includes a first driver manager. The method further 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 second instruction information to a second message queue driver, the second instruction information being used to instruct the release of the first link and resources related to the first link; based on the first instruction information, the second message queue driver releases the first link and resources related to the first link in the second trusted execution environment, and sends the second instruction information to the first message queue driver; the first message queue sends the second instruction 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 instruction information. See details for further information. Figure 10 Example.

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

[0030] The communication method shown in this embodiment, after the second agent module exits abnormally, considering that the first link previously created by the second agent 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, so as to release the resources related to the first link in the two trusted execution environments, avoid the resources related to the first link from occupying system memory, and improve the system resource utilization.

[0031] In one 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, embodiments of this application provide an electronic device, including: a processor and a memory; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory, causing the electronic device to perform the method as described in any of the first aspects.

[0034] Thirdly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method as described in any of the first aspects.

[0035] Fourthly, embodiments of this application provide a computer program product, which includes a computer program that, when run, causes a computer to perform the method as described in any of the first aspects.

[0036] Fifthly, embodiments of this application provide a chip, the chip including a processor, the processor being configured to invoke a computer program in memory to perform the method as described in any of the first aspects.

[0037] It should be understood that the second to fifth aspects of this application correspond to the technical solutions of the first aspect of this application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation are similar, and will not be repeated here. Attached Figure Description

[0038] Figure 1 A schematic diagram of the frame of an electronic device provided in an embodiment of this application;

[0039] Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0040] Figure 3 A software structure block diagram of an electronic device provided in an embodiment of this application;

[0041] Figure 4 A schematic diagram of the frame of an electronic device provided in an embodiment of this application;

[0042] Figure 5 A schematic diagram of the interaction process of an electronic device provided in an embodiment of this application;

[0043] Figure 6 A schematic diagram of the frame of an electronic device provided in an embodiment of this application;

[0044] Figure 7 A schematic diagram of the interaction process of an electronic device provided in an embodiment of this application;

[0045] Figure 8 A schematic diagram of the interaction process of an electronic device provided in an embodiment of this application;

[0046] Figure 9 A schematic diagram of the interaction process of an electronic device provided in an embodiment of this application;

[0047] Figure 10 A schematic diagram of the interaction process of an electronic device provided in an embodiment of this application;

[0048] Figure 11 An interactive schematic diagram of an electronic device provided in an embodiment of this application;

[0049] Figure 12 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0050] Figure 13 This is a schematic diagram of the structure of a chip provided in an embodiment of this application. Detailed Implementation

[0051] To facilitate a clear description of the technical solutions in the embodiments of this application, some terms and technologies involved in the embodiments of this application will be briefly introduced below:

[0052] 1. Trusted Execution Environment (TEE): Also known as a secure execution environment. A Trusted Execution Environment Operating System (TEE OS) can run in a TEE. The TEE can also provide trusted security services (such as fingerprint verification, password verification, facial recognition, etc.) for client applications (CAs). These security services can run in the TEE OS as trusted applications (TAs).

[0053] In some embodiments, a Trusted Execution Environment (TEE) can be an execution region built using the secure region of a processor in an electronic device, providing a secure operating environment for services.

[0054] In some embodiments, the electronic device may employ trust zone technology to establish the TEE within the trust zone, thereby protecting the confidentiality and integrity of the code and data loaded in the TEE.

[0055] In some embodiments, ARM has introduced Virtualization Extension (VLE) technology to support hardware virtualization on the ARM platform, thereby providing hardware isolation for different operating environments even in normal operation. Unlike the Trust Zone (TZ) technology mentioned above, VLE is a technology that allows multiple operating systems to run on an electronic device. The electronic device can establish a TEE (Trusted Equipment Environment) on a virtual machine, enabling the TEE to provide a secure operating environment for business operations.

[0056] Currently, ARMv8 supports four exception levels (EL), from EL0 to EL3, with higher numbers indicating higher security levels. Generally, applications (e.g., client applications CA and trusted applications TA) run at EL0, the system kernel (called the operating system in some embodiments, such as REE OS or TEE OS) runs at EL1, and the virtual machine manager runs at EL2.

[0057] In some embodiments, the REE can be connected to the QTEE (QTEE is...) via a security monitor. The application provides a trusted execution environment (QTEE) for communication, wherein the security monitor runs at the EL3 layer. This application does not involve QTEE in its embodiments.

[0058] It should be noted that the multiple trusted execution environments involved in the embodiments of this application (such as the first trusted execution environment QTVM and the second trusted execution environment HTVM mentioned below) are all built on virtual machines. For details, please refer to [link / reference]. Figure 1 The frame shown.

[0059] 2. Rich Execution Environment (REE): This can be referred to as a general execution environment. The rich execution environment operating system (REE OS) and CA on a general-purpose processor can run within the REE. For example, the REE OS could be the Android operating system.

[0060] 3. Other terms

[0061] In the embodiments of this application, terms such as "first" and "second" are used to distinguish identical or similar items with essentially the same function and purpose. For example, "first trusted execution environment" and "second trusted execution environment" are merely used to distinguish different trusted execution environments and do not limit their order. Those skilled in the art will understand that terms such as "first" and "second" do not limit the quantity or execution order, and that "first" and "second" do not necessarily imply that they are different.

[0062] It should be noted that, in the embodiments of this application, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0063] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, a--c, bc, or abc, where a, b, and c can be single or multiple.

[0064] 4. Electronic equipment

[0065] The electronic devices in this application embodiment can be handheld devices, vehicle-mounted devices, etc., that have multiple TEEs deployed. For example, some electronic devices include: mobile phones, tablets, PDAs, laptops, mobile internet devices (MIDs), wearable devices, virtual reality (VR) devices, augmented reality (AR) devices, wireless terminals in industrial control, wireless terminals in self-driving vehicles, wireless terminals in remote medical surgery, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, cellular phones, cordless phones, session initiation protocol (SIP) phones, wireless local loop (WLL) stations, personal digital assistants (PDAs), handheld devices with wireless communication capabilities, computing devices or other processing devices connected to wireless modems, in-vehicle devices, wearable devices, terminal devices in 5G networks, or future evolution of public land mobile communication networks. Terminal devices in a network (PLMN), etc., are not limited to this in the embodiments of this application.

[0066] By way of example and not limitation, in this embodiment, the electronic device can also be a wearable device. Wearable devices, also known as wearable smart devices, are a general term for devices that utilize wearable technology to intelligently design and develop everyday wearables, such as glasses, gloves, watches, clothing, and shoes. Wearable devices are portable devices that are worn directly on the body or integrated into the user's clothing or accessories. Wearable devices are not merely hardware devices, but also achieve powerful functions through software support, data interaction, and cloud interaction. Broadly speaking, wearable smart devices include those that are feature-rich, large in size, and can achieve complete or partial functions without relying on a smartphone, such as smartwatches or smart glasses, as well as those that focus on a specific type of application function and require the use of other devices such as smartphones, such as various smart bracelets and smart jewelry for vital sign monitoring.

[0067] Furthermore, in this embodiment of the application, the electronic device can also be a terminal device in the 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 object-to-object interconnection.

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

[0069] Figure 1 This is a schematic diagram of the framework of an electronic device provided in an embodiment of this application. Figure 1 As shown, the framework includes: an Android VM running in a rich execution environment (REE), a QTVM (Qualcomm trusted VM, where VM is short for virtual machine) running in a first trusted execution environment, and an HTEE VM (Honor trusted execution environment VM, also known as HTVM) running in a second trusted execution environment.

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

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

[0072] Figure 1The diagram uses arrows and labels S11 to S18 to illustrate the specific process of a client application calling the trusted application TA2 of the second trusted execution environment. Specifically, when a client application needs to access TA2, it sends a request to the Android operating system. After passing through the kernel driver in the Android operating system, the request is sent to the virtual machine manager via an HVC (hypervisor call). The virtual machine manager processes the request and then sends it to the second trusted execution environment operating system. After further processing by the second trusted execution environment operating system, the request is sent to TA2. TA2 processes the received request and returns the result to the second trusted execution environment operating system, which then sends the result to the virtual machine manager via an HVC instruction. The virtual machine manager processes the request and returns the result to the Android operating system. Finally, the Android operating system sends the result to the corresponding client application.

[0073] When a client application needs to access a trusted application TA1 in the first trusted execution environment, the client application can access a trusted application TA2 in the second trusted execution environment, which in turn calls TA1. The process of TA2 calling TA1 can be found in [reference needed]. Figure 1 Specifically, in steps S21 to S28, TA2 sends a request to the second trusted execution environment (TEE). After passing through the kernel driver in the TEE, the request is sent to the virtual machine manager via an HVC call. The virtual machine manager processes the request and then sends it to the first TEE. The first TEE then distributes the request to TA1. TA1 processes the received request and returns the result to the second TEE. The second TEE then uses the second TEE to call an HVC instruction to send the result to the virtual machine manager. The virtual machine manager processes the request and returns the result to the second TEE. The second TEE then sends the result to TA2. Finally, TA2 returns the result from TA1 to the corresponding client application.

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

[0075] In addition, the electronic device also includes a hardware platform to support its operation and store secure hardware resources. For example, secure hardware resources may include secure memory, hardware keys, secure keyboards, etc. In this embodiment, secure memory can be used to store backup TEE OS images, resources related to links between trusted execution environments (e.g., Link 1 below), and data related to trusted applications (e.g., facial data).

[0076] Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 2 As 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, antenna 1, 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 headphone jack 170D, a sensor 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 is understood that the structure illustrated in this embodiment does not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some 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 this application, the operating environment of the processor 110 may include: a rich execution environment (REE) and at least two trusted execution environments, such as a first trusted execution environment and a second trusted execution environment. For example, the first trusted execution environment runs a trusted application TA1 and a first trusted execution environment operating system (QTVM OS), the second trusted execution environment runs a trusted application TA2 and a second trusted execution environment operating system (HTVM OS), and the REE runs a client application CA and an Android operating system (Android OS). The REE is used to receive trusted application requests initiated by the user through the client application, and according to the trusted application request, call TA1 in the first trusted execution environment or call TA2 in the second trusted execution environment, with the corresponding TA returning the result.

[0078] The software system of electronic device 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application embodiment uses a layered Android system as an example to illustrate the software structure of electronic device 100.

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

[0080] The application layer can include a series of application packages. For example... Figure 3 As shown, the application package may include applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, and SMS. In some embodiments of this application, the applications in the application layer run on the ELO layer of the electronic device.

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

[0082] The Android runtime consists of the core libraries and the virtual machine. The Android runtime is responsible for scheduling and managing the Android system. The core libraries comprise two parts: one part contains the functionalities that Java calls, and the other part is the core Android library itself. The application layer and application framework layer run in the virtual machine. The virtual machine executes the Java files of the application layer and 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] System libraries can include multiple functional modules. For example: surface manager, media libraries, 3D graphics processing libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), etc.

[0084] In some embodiments of this application, the Android runtime and system libraries in the Android system can be 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 includes at least display drivers, camera drivers, audio drivers, and sensor drivers. In some embodiments of this application, the kernel layer corresponds to the EL1 layer of the electronic device.

[0086] Figure 4 This is a schematic diagram of the framework of an electronic device provided in an embodiment of this application. In this framework, the electronic device includes an application layer (also known as a service layer), a protocol layer, a driver layer (also known as a kernel layer), and a hardware layer.

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

[0088] CA includes third-party applications or system applications such as banking applications, and CA runs in a Rich Execution Environment (REE). Trusted Application TA2 includes, for example, TUI (Trusted User Interface) TA and Face TA, and TA2 runs in a second trusted execution environment (HTVM). Trusted Application TA1 includes two services such as TUICoreService (Secure Display Service) and DSP_Service (Secure DSP (Digital Signal Processor) Service), which provide remote invocation services for TUI TA and Face TA respectively, and TA1 runs in a first trusted execution environment (QTVM).

[0089] The protocol layer is located between the application layer and the driver layer. It is responsible for data encapsulation and decapsulation, ensuring that data is transmitted in accordance with a specific protocol format. This specific protocol can be the minkipc protocol, which 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. The application layer's TUI TA or Face TA 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 TVMMink module, described in some embodiments as the first proxy module). Proxy module 1 is responsible for forwarding data from HTVM to TA1 corresponding to TA2, or encapsulating the data returned by TA1 to ensure that the data is returned to HTVM according to the minkipc protocol.

[0091] The driver layer includes Driver Manager 2 (platdrv) and Message Queue Driver 2 (msgq_drv1), Driver Manager 3 (tzdriver) and Message Queue Driver 3 (msgq_drv3), Message Queue Driver 1 (qmsgq_drv), the secure DSP driver, and the display driver. Driver Manager 2 and Message Queue Driver 2 run in a second trusted execution environment, Driver Manager 3 and Message Queue Driver 3 run in a rich execution environment, and Message Queue Driver 1, the secure DSP driver, and the display driver run in a first trusted execution environment.

[0092] Driver Manager 2 manages multiple drivers, including Message Queue Driver 2, and Driver Manager 3 manages multiple drivers, including Message Queue Driver 3. Message Queue Driver 2 communicates with Message Queue Driver 1 and Message Queue Driver 3 to enable data exchange between different execution environments. In other words, different execution environments can exchange data through links established at the driver layer. The security DSP driver is used to drive the secure process domain (PD). The display driver is used to drive the display.

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

[0094] The hardware layer includes, but is not limited to, secure PD, display, camera, etc. The secure PD is a virtual secure DSP that provides secure general-purpose computing acceleration capabilities. In this embodiment, the secure PD is configured with algorithms such as face data verification, which can improve the processing speed of face data verification.

[0095] based on Figure 4 As shown in the framework, when the client application CA of the electronic device needs to call the trusted application TA1 of the first trusted execution environment through the trusted application TA2 of the second trusted execution environment, communication can be achieved by constructing message queue (msgq) links (such as link 1, link 2, link 3, etc. below) 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 message queue driver 2 and message queue driver 1.

[0096] Figure 5 This is a schematic diagram illustrating the interaction process of an electronic device provided in an embodiment of this application. Figure 4Based on the framework shown, the following section uses trusted application TA2 as Face TA and trusted application TA1 as DSP_Service as an example to describe in detail the process of a client application calling the face verification service. Figure 5 As shown, the process includes:

[0097] S101. After the client application CA of the Rich Execution Environment (REE) starts, CA sends a first message to message queue driver 3. The first message is used to instruct the startup of the trusted application Face TA of the second trusted execution environment (HTVM).

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

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

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

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

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

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

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

[0105] After receiving the first message, Face TA instructs Message Queue Driver 2 to initialize Instance 2 via Driver Manager 2. Instance 2 is another instance in Message Queue Driver 2, distinct from Instance 1. Instance 2 is responsible for transmitting and processing messages between HTVM and QTVM.

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

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

[0108] For example, taking CA as a wallet application, after a 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 HTVM's Face TA through message queue driver 3, so that Face TA calls QTVM's DSP_Service.

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

[0110] S106. Message queue driver 3 sends a second message to message queue driver 2.

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

[0112] S107. Message queue driver 2 sends a second message to Face TA.

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

[0114] S108.Face TA sends a first request to message queue driver 2 based on the second message. The first request is used to request the establishment of a link between HTVM and QTVM.

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

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

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

[0118] S110. Message queue driver 1 sends the first request to agent module 1 of QTVM.

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

[0120] S111. Agent module 1 sends the first request to DSP_Service.

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

[0122] In some examples, the DSP_Service invokes the secure DSP driver based on the first request, so that the secure DSP driver drives the secure PD to initialize the face verification algorithm.

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

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

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

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

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

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

[0129] After completing the initialization process of the face verification algorithm, Face TA can call DSP_Service through Link 1 to perform face data verification, as detailed in S117 to S123 below.

[0130] S117.Face TA, based on the first response, sends a first instruction to message queue driver 2. The first instruction is used to instruct DSP_Service to perform facial data verification.

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

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

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

[0134] S119. Message queue driver 1 sends the first instruction to agent module 1.

[0135] S120. Agent module 1 sends the first instruction to DSP_Service.

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

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

[0138] S122.DSP_Service sends the face verification results to Face TA.

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

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

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

[0142] The above embodiment illustrates the interaction process of HTVM's trusted application Face TA establishing a link with QTVM through the driver layer, and communicating with QTVM's trusted application DSP_Service based on this link, thereby realizing communication between trusted applications in 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 the DSP_Service of QTVM and the Face TA of HTVM in the previous embodiment. For details, please refer to the previous embodiment.

[0144] based on Figure 5 As illustrated in the embodiments, a trusted application in the second trusted execution environment can establish a link between the second and first trusted execution environments 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 and first trusted execution environments. Similarly, 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 and first trusted execution environments.

[0145] Considering that multiple TA2s may access the first trusted execution environment at the same time, a preset number of links (e.g., 2) can usually be maintained between the first trusted execution environment and the second trusted execution environment. In this way, at the same time, both Face TA and TUI TA can communicate with the first trusted execution environment based on the links they have created.

[0146] It is 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 consumed, which will affect the communication quality between the two trusted execution environments. In view of this, embodiments of this 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 below) to the protocol layer of the second trusted execution environment, each trusted application in the second trusted execution environment can interact with the first trusted execution environment through the added proxy module, thereby reducing system load and improving the communication quality between trusted applications in multiple trusted execution environments.

[0147] The following is in conjunction with the appendix Figure 6 A detailed description of the framework for improving electronic devices is provided.

[0148] Figure 6 This is a schematic diagram of the framework of an electronic device provided in an embodiment of this application. Figure 4 Based on the framework shown, as Figure 6As shown, in the second Trusted Execution Environment (HTVM), the protocol layer configures proxy module 2 (or Minkhub module, described in some embodiments as a second proxy module). Proxy module 2 is responsible for encapsulating and processing requests (or instructions) from trusted applications in the HTVM and forwarding them to driver manager 2. Driver manager 2 then drives message queue driver 2, which in turn sends the requests (or instructions) from trusted applications in the HTVM to the first Trusted Execution Environment (QTVM). Furthermore, proxy module 2 is also responsible for returning responses (or data) from the QTVM to the corresponding trusted application in the HTVM. Figure 6 For other modules or components, please refer to... Figure 4 Examples are not described here.

[0149] based on Figure 6 In the framework shown, 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 proxy module 2, enabling communication between the two trusted execution environments. When one of the TA2s (such as Face TA) in the second trusted execution environment abnormally exits, other TA2s (such as TUI TA) can still communicate normally with the first trusted execution environment through proxy module 2 based on the previously established link. That is, the abnormality of one TA2 in the second trusted execution environment does not affect other TA2s from calling the corresponding trusted application in the first trusted execution environment to execute corresponding business operations based on the previously established link. Therefore, by using the added proxy module 2 to communicate with the first trusted execution environment, the second trusted execution environment only needs to maintain one link, which can reduce system load and improve the stability of system communication.

[0150] Figure 7 This is a schematic diagram illustrating the interaction process of an electronic device provided in an embodiment of this application. Figure 6 Based on the framework shown, the following section uses trusted application TA2 as Face TA and trusted application TA1 as DSP_Service as an example to describe in detail the process of a client application calling the face verification service. Figure 7 As shown, the process includes:

[0151] S201. After the second trusted execution environment (HTVM) operating system starts, initialize agent module 2.

[0152] After the HTVM system starts, the agent module 2 can be initialized by calling the interface provided by agent module 2.

[0153] S202. Agent module 2 sends a third message to message queue driver 2.

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

[0155] S203. Message queue driver 2 initializes instance 2 of message queue driver 2 based on a third message.

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

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

[0158] S106. Message queue driver 3 sends a second message to message queue driver 2.

[0159] S107. Message queue driver 2 sends a second message to Face TA.

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

[0161] After Face TA receives the second message, execute:

[0162] S204.Face TA sends a first request to agent module 2 based on the second message. The first request is used to request the establishment of a link between HTVM and QTVM.

[0163] In some examples, Face TA sends the first request to Proxy Module 2 by calling the interface provided by Proxy Module 2.

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

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

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

[0167] After S205, execute:

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

[0169] In some examples, message queue driver 2 requests resources related to link 1 from the HTVM system based on the first request, and then sends the first request to message queue driver 1.

[0170] S110. Message queue driver 1 sends the first request to agent module 1 of QTVM.

[0171] S111. Agent 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. Agent 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 a first response to agent module 1. The first response is used to indicate that the face verification algorithm has been successfully initialized.

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

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

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

[0179] After S115, execute:

[0180] S206. Message-driven queue 2 sends the first response to agent module 2.

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

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

[0183] Based on the first response, S208.Face TA sends a first instruction to agent module 2, which instructs DSP_Service to perform facial data verification.

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

[0185] S209. Agent module 2 sends the first instruction to message queue driver 2.

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

[0187] After S209, execute:

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

[0189] S119. Message queue driver 1 sends the first instruction to agent module 1.

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

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

[0192] S122.DSP_Service sends the face verification results to Face TA.

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

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

[0195] S123.Face TA sends the facial verification results to CA.

[0196] S118 to S121 and S123 can be referred to the aforementioned embodiments, and will not be elaborated here.

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

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

[0199] S301. Message Queue Driver 2 requests resources related to HTVM-side Link 1.

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

[0201] S303. Message queue driver 1 sends a second request to agent module 1.

[0202] S304. Agent module 1 requests resources related to QTVM side link 1 based on the second request.

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

[0204] Based on the aforementioned embodiments, in one possible scenario, after Face TA starts, it may exit abnormally due to various reasons, such as execution errors caused by code exceptions or camera service abnormalities.

[0205] In some embodiments, based on Figure 4 As shown in the framework, after Face TA exits abnormally (or normally), the HTVM system can send a system notification to Driver Manager 2. Based on the system notification, Driver Manager 2 instructs Message Queue Driver 2 to release the link with QTVM and the resources associated with that 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 on Figure 6 As shown in the framework, after Face TA exits abnormally, the HTVM system can send a system notification to agent module 2. Based on the system notification, agent module 2 determines whether to instruct message queue driver 2 to release the connection with QTVM and the resources associated with that connection. It can be understood that since agent module 2 is responsible for handling requests from different trusted applications in HTVM, when Face TA exits abnormally, agent module 2 needs to determine whether to release existing connections and their associated resources based on the running status of other trusted applications (such as TUI TA) in the current HTVM system. The following section, in conjunction with the appendix... Figure 9 This document provides a detailed explanation of the interaction process of electronic devices after Face TA exits abnormally.

[0207] Figure 9 This is an interactive schematic diagram of an electronic device provided in an embodiment of this application. Based on Figure 6 The frame shown and Figure 7 As shown in the process, HTVM's Face TA has established a link 1 with QTVM by calling proxy module 2, as follows. Figure 9 As shown, if Face TA crashes after startup, the following procedure can be followed:

[0208] S401. Agent module 2 receives a first system notification, which indicates that Face TA has exited abnormally.

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

[0210] After receiving the first system notification, the agent module 2 determines whether there are other trusted applications running in the current HTVM. If so, it does not release link 1; otherwise, it executes S403.

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

[0212] S403. Agent module 2 sends a first indication message to message queue driver 2. The first indication message is used to indicate the release of link 1 and the resources associated with link 1.

[0213] In some examples, agent module 2 sends the first instruction information to message queue driver 2 through driver manager 2.

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

[0215] S404. Message queue driver 2 sends the first instruction information to message queue driver 1.

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

[0217] S405. Message queue driver 1 sends the first instruction information to agent module 1.

[0218] S406. Agent module 1 releases resources related to QTVM side link 1 based on the first instruction information.

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

[0220] S407. Message queue driver 2 releases resources related to link 1 and HTVM-side link 1 based on the first instruction information.

[0221] The communication method illustrated in this embodiment, where Face TA, a trusted application in the second Trusted Execution Environment (HTVM), establishes a link with the first Trusted Execution Environment (QTVM) through proxy module 2, can determine whether to release the existing link and related resources with QTVM based on the running status of other trusted applications in the current HTVM system if Face TA abnormally exits. Therefore, after Face TA's abnormal exit, proxy module 2 does not directly release the existing link and related resources based on the event. If other applications in the HTVM need to reuse the existing link, proxy module 2 can retain the existing link without responding to the event, thus improving the responsiveness of the HTVM application layer.

[0222] based on Figure 7 In the illustrated embodiment, under one possible scenario, after proxy module 2 starts, it may abnormally exit (or crash) due to reasons such as execution errors caused by code exceptions. It is understood that after proxy module 2 abnormally exits, the link established between the Face TA of the second trusted execution environment HTVM and QTVM through proxy module 2 becomes invalid, and the resources associated with this link consume system memory.

[0223] In view of this, this application embodiment shows a communication method by adding a message notification mechanism to the driver layer. This message notification is different from the aforementioned minkipc protocol. If the agent module 2 exits abnormally, the HTVM system is responsible for restarting the agent 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, thereby improving the system resource utilization.

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

[0225] S501. Driver Manager 2 receives a second system notification, which indicates that Agent Module 2 has exited abnormally.

[0226] S502.Driver Manager 2 sends a second instruction message to Message Queue Driver 2 based on the second system notification. The second instruction message is used to instruct the release of Link 1 and the resources associated with Link 1.

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

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

[0229] Example 3 is an example in Message Queue Driver 2 that differs from Examples 1 and 2. Example 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, message queue driver 2 sends a second instruction to message queue driver 1 via the virtual machine manager.

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

[0232] S505. Agent module 1 releases resources related to QTVM side link 1 based on the second instruction information.

[0233] Following S503, the following is also executed:

[0234] S506. Message queue driver 2 releases the resources associated with link 1 and HTVM-side link 1 based on the second instruction information.

[0235] 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 exits abnormally, the HTVM system notifies the message queue driver 2 in the driver layer, which releases the existing link and notifies QTVM to release the corresponding resources, thereby avoiding the failure link from occupying system memory and improving system resource utilization.

[0236] Based on the aforementioned embodiments, by adding a proxy module 2 to the second trusted execution environment (HTVM) of the electronic device, the function of each trusted application in the HTVM calling the libminkipc shared library for data encapsulation is integrated into the proxy module 2. This decouples the module functions in the HTVM environment, thereby improving the stability of system communication. For example, based on the aforementioned... Figure 9 In this example, an abnormal exit of Face TA will not affect proxy module 2, and proxy module 2 can still serve other trusted applications of HTVM. For another example, based on the aforementioned... Figure 10 In this example, the abnormal exit of proxy module 2 will not affect Face TA, and the system can restart the proxy module after the abnormal exit of proxy module 2. Face TA can then call proxy module 3 again to establish a new connection with QTVM.

[0237] Based on the foregoing embodiments, this application provides a communication method between trusted applications in a multi-trusted execution environment, applied to electronic devices, with reference 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 agent module. The method includes:

[0238] In response to the 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 the operation of enabling 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] 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 previous embodiment, and the second trusted execution environment can correspond to the HTVM in the previous 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 second trusted application is DSP_Service. Figure 6 The TUICoreService. The third and fourth trusted applications are trusted applications running within the second trusted execution environment. For example, the third trusted application is... Figure 6 Face TA, the fourth trusted application Figure 6 The first service and the second service are two different services provided by client applications in the rich execution environment of an 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 aforementioned embodiment.

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

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

[0244] For example, refer to Figure 6 In response to a user's operation using the facial verification service provided by the client application CA (e.g., the user opening the facial verification service provided by the wallet application), HTVM's Face TA calls proxy module 2, which in turn calls QTVM's DSP_Service through the first link created by proxy module 2 to execute the facial verification service. Similarly, in response to a user's operation using the secure display service provided by the client application (e.g., the user accessing the keyboard), HTVM's TUI TA calls proxy module 2, which in turn calls QTVM's TUICoreService through the first link created by proxy module 2 to execute the secure display service (e.g., securely displaying a virtual keyboard for the user to enter a password).

[0245] The communication method illustrated in this embodiment includes a second proxy module within the second trusted execution environment of the electronic device. Each trusted application in the second trusted execution environment can invoke the second proxy module and, based on the first link created by the second proxy module with the first trusted execution environment, invoke the corresponding trusted application in the first trusted execution environment to execute the corresponding service. In other words, 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, reducing system load and improving the communication quality between trusted applications in multiple trusted execution environments.

[0246] In one 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 creates a first connection, including: in response to the operation of starting 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 connection.

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

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

[0249] The communication method shown in this embodiment allows the second proxy module to create a first link with the first trusted execution environment based on a call from a trusted application in the second trusted execution environment. In other words, the second proxy module creates the first link only when a trusted application in the second trusted execution environment needs to interact with the first trusted execution environment. At the same time, the second proxy module can instruct the second message queue driver to request resources related to the first link from the system (i.e., resources are requested only when they are used), which can improve the system resource utilization rate.

[0250] In one optional embodiment, the second proxy module creates the first link by: after the electronic device starts up, initializing the second proxy module; 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.

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

[0252] The communication method illustrated in this embodiment involves the electronic device's second agent module successfully initializing and then directly establishing a first link with the first trusted execution environment. It is understood that creating the first link takes some time. If the first link is created in advance, then after the third or fourth trusted application in the second trusted execution environment starts, the second agent module can interact with the corresponding trusted application in the first trusted execution environment based on the established first link, thereby improving the system's application layer responsiveness.

[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] In the communication method shown in this embodiment, the second proxy module does not directly release the first connection after learning that the third trusted application has exited abnormally.

[0255] In one optional embodiment, the second proxy module determines whether to release the first link based on a first system notification, including: the second proxy module determining whether any other trusted applications are 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. (See also...) Figure 9 Example.

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

[0257] In 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 reusing the first link in the current second trusted execution environment operating system. If there are other applications reusing the first link, the second proxy module does not release the first link, thus improving the response capability of the application layer of the second trusted execution environment.

[0258] In an optional embodiment, the first trusted execution environment further includes a first agent module. The method further includes: if the second agent module determines to release the first link, the second agent module sends first indication information to a second message queue, the first indication information indicating the release of the first link and resources associated with the first link; based on the first indication information, the second message queue releases the first link and resources associated with 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 agent module; the first agent module releases resources associated with the first link in the first trusted execution environment based on the first indication information. See details for further information. Figure 9 Example.

[0259] 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 aforementioned embodiment (i.e. Figure 6 TVMMink module).

[0260] The communication method shown in this embodiment, after the third trusted application in the second trusted execution environment exits abnormally and the second agent module determines to release the first link, can notify the second message queue driver, and through the second message queue driver notify the first trusted execution environment, so as to release the resources related to the first link in both trusted execution environments, avoid the resources related to the first link from occupying system memory, and improve the system resource utilization.

[0261] In an optional embodiment, the second trusted execution environment further includes a first driver manager. The method further 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 second instruction information to a second message queue driver, the second instruction information being used to instruct the release of the first link and resources related to the first link; based on the first instruction information, the second message queue driver releases the first link and resources related to the first link in the second trusted execution environment, and sends the second instruction information to the first message queue driver; the first message queue sends the second instruction 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 instruction information. See details for further information. Figure 10 Example.

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

[0263] The communication method shown in this embodiment, after the second agent module exits abnormally, considering that the first link previously created by the second agent 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, so as to release the resources related to the first link in the two trusted execution environments, avoid the resources related to the first link from occupying system memory, and improve the system resource utilization.

[0264] In one 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 in this application embodiment can be applied to electronic devices deployed with a multi-trusted execution environment. This application embodiment does not limit the specific form of the electronic device.

[0267] This application provides an electronic device, which includes a processor and a memory; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory, causing the electronic device to perform the above-described method.

[0268] Figure 12 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 12 As shown, the electronic device includes a processor 1201, a communication line 1204, and at least one communication interface. Figure 12 (The example is illustrated using communication interface 1203).

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

[0270] Communication line 1204 may include circuitry for transmitting information between the aforementioned components.

[0271] 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 capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed discs, laser discs, optical discs, digital universal discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. The memory may exist independently and be connected to the processor via communication line 1204. The memory may also be integrated with the processor.

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

[0275] The computer execution instructions in the embodiments of this application may also be referred to as application code, and the embodiments of this application do not specifically limit this.

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

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

[0278] This application provides a chip. The chip includes a processor, which is used to call a computer program in memory to execute the technical solutions in the above embodiments. Its implementation principle and technical effects are similar to those in the related embodiments described above, and will not be repeated here.

[0279] Figure 13 This is a schematic diagram of a chip structure provided in an embodiment of this application. Figure 13 As shown, chip 1300 includes one or more processors 1320 and communication interface 1330.

[0280] In some embodiments, memory 1340 stores the following elements: executable modules or data structures, or a subset of executable modules or data structures, or an extended set of executable modules or data structures.

[0281] In this embodiment, memory 1340 may include read-only memory and random access memory, and provides instructions and data to processor 1320. A portion of memory 1340 may also include non-volatile random access memory (NVRAM).

[0282] In this embodiment, the memory 1340, the communication interface 1330, and the memory 1340 are coupled together via a bus system 1310. The bus system 1310 may include a data bus, a power bus, a control bus, and a status signal bus, in addition to the data bus. For ease of description, in... Figure 13 The general designated all buses as Bus System 1310.

[0283] The methods described in the embodiments of this application can be applied to, or implemented by, processor 1320. Processor 1320 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above methods can be completed by integrated logic circuits in the hardware of processor 1320 or by instructions in software form. Processor 1320 may be a general-purpose processor (e.g., a microprocessor or 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 gates, transistor logic devices, or discrete hardware components. Processor 1320 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this 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 into the memory, or it can be downloaded and installed into the memory as software.

[0285] This application also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the methods described above. The methods described in the above embodiments can be implemented wholly or partially by software, hardware, firmware, or any combination thereof. If implemented in software, the functionality can be stored as one or more instructions or code on or transmitted over the computer-readable medium. The computer-readable medium can include computer storage media and communication media, and can 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 one possible implementation, a computer-readable medium may include RAM, ROM, read-only optical disc or other optical disc storage, disk storage or other magnetic storage device, or any other medium targeted to carry or to store the required program code in the form of instructions or data structures, and accessible by a computer. Furthermore, any connection is appropriately referred to as 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, DSL, or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. As used herein, disks and optical discs include optical discs, laser discs, optical discs, Digital Versatile Discs (DVDs), floppy disks, and Blu-ray discs, where disks typically reproduce data magnetically, while optical discs optically reproduce data using lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0287] This application provides a computer program product, which includes a computer program that, when run, causes a computer to perform the above-described method.

[0288] This application describes embodiments of methods, apparatus (systems), and computer program products according to embodiments of this application with reference to flowchart illustrations and / or block diagrams. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processing unit of a general-purpose computer, special-purpose computer, embedded processor, or other programmable device to produce a machine, such that the instructions, which execute via the processing unit of the computer or other programmable data processing device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0289] The above specific embodiments further illustrate the purpose, technical solution and beneficial effects of this application. It should be understood that the above are only specific embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of this application should be included within the scope of protection of this 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 including a first trusted application and a second trusted application, the second trusted execution environment including a third trusted application, a fourth trusted application, and a second proxy 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 proxy module, and calls the first trusted application through the first link created by the second proxy module to execute the first service; In response to the operation of enabling the second service, the fourth trusted application of the electronic device calls the second proxy module to call 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; The method further includes: After the third trusted application exits abnormally, the second agent module receives a notification from the first system. Based on the notification from the first system, the second agent module determines whether there are other trusted applications running in the second trusted execution environment; 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.

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 proxy module creates the first link, including: In response to the operation of starting the first service, the third trusted application invokes 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 connection.

3. The method according to claim 1, characterized in that, The first trusted execution environment further includes a first agent module, and the method further includes: If the second proxy module determines to release the first link, the second proxy module sends a first indication message to the second message queue. The first indication message is used to indicate the release of the first link and the resources associated with 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 agent module; Based on the first instruction information, the first proxy module releases the resources associated with the first link in the first trusted execution environment.

4. The method according to claim 2, characterized in that, The second proxy module creates the first link, including: After the electronic device is started, the second agent 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 connection.

5. The method according to any one of claims 1 to 4, 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 notification from the second system. Based on the second system notification, the first driver manager sends a second instruction message to the second message queue driver. The second instruction message is used to instruct the release of the first link and the resources associated with the first link. Based on the second 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; Based on the second instruction information, the first proxy module releases the resources associated with the first link in the first trusted execution environment.

6. The method according to claim 5, characterized in that, The second message queue driver sends the 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.

7. An electronic device, characterized in that, include: Processor and memory; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the electronic device to perform the method as described in any one of claims 1 to 6.

8. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 6.

Images