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

Abstract

This application provides a communication method and device between trusted applications in a multi-trusted execution environment, applied in the field of terminal technology. The method includes: in response to an operation to start a first service, an electronic device creates a first link through a second trusted application and calls the first trusted application based on the first link to execute the first service; if the second trusted application exits abnormally after the first link is created, in response to an operation to restart the first service, the electronic device creates at least one new link through the second trusted application; after creating at least one new link, the electronic device releases the first link to prevent the first trusted application from being occupied; after releasing the first link, the electronic device calls the first trusted application based on at least one new link to execute the first service, avoiding interruption of the first service due to the abnormal exit of the second trusted application, thereby improving the stability of communication between trusted applications in a multi-trusted execution environment.

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 numerous. 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 a Certificate Authority (CA). These security services can run on the TEE OS as trusted applications (TAs). Currently, multiple TEEs can be created within electronic devices, but the relevant technologies do not disclose communication schemes between trusted applications under multiple TEEs when a trusted application abnormally exits. 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. It can avoid service interruption caused by abnormal exit of trusted applications and improve the stability of communication 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 the second trusted execution environment includes a second trusted application. The communication method includes:

[0005] In response to the operation of activating the first service, the electronic device creates a first link through the second trusted application and calls the first trusted application based on the first link to execute the first service.

[0006] If the second trusted application exits abnormally after the first connection is created, in response to the operation of restarting the first service, the electronic device creates at least one new connection through the second trusted application.

[0007] After creating at least one new link, the electronic device releases the first link and invokes the first trusted application based on the at least one new link to perform the first service.

[0008] The first link and at least one new link are links between the first trusted execution environment and the second trusted execution environment.

[0009] Wherein, the first trusted execution environment may correspond to QTVM in the embodiment, the second trusted execution environment may correspond to HTVM in the embodiment, the first service may be the face verification service provided by the client application in the rich execution environment, the second trusted application may correspond to Face TA in the embodiment, the first link may correspond to link 1 in the embodiment, the first trusted application may correspond to DSP_Service in the embodiment, and at least one new link includes link 2 and link 3 as in the embodiment.

[0010] It should be noted that the number of new links depends on the link threshold that can be maintained between the first trusted execution environment and the second trusted execution environment. For example, if the link threshold is 2, the number of new links created is 3; if the link threshold is 1, the number of new links created is 1.

[0011] In the communication method illustrated in this embodiment, a second trusted application in a second trusted execution environment can establish a first link with a first trusted execution environment and call the first trusted application in the first trusted execution environment based on the first link to execute a user-triggered first service. If the second trusted application exits abnormally after creating the first link, the electronic device can restart the second trusted application. If the user triggers the first service again, the electronic device can create at least one new link through the second trusted application. Since the first trusted application is still occupied by the first link, the electronic device needs to release the first link after creating at least one new link to prevent the first trusted application from being occupied, and then call the first trusted application based on the created at least one new link to execute the first service. This avoids interruption of the first service due to abnormal exit of the second trusted application and improves the stability of communication between trusted applications in the trusted execution environment.

[0012] In an optional embodiment, the first trusted execution environment further includes a first message queue driver, and the second trusted execution environment further includes a second message queue driver; the electronic device creates a first link through a second trusted application, including: the second trusted application of the electronic device sends a first request to the first message queue driver through the second message queue driver to create the first link.

[0013] The first message queue driver can correspond to message queue driver 1 in the embodiment, and the second message queue driver can correspond to message queue driver 2 in the embodiment.

[0014] In this embodiment, the second trusted application of the second trusted execution environment establishes a first link with the first message queue driver of the first trusted execution environment by calling the second message queue driver of the driver layer. The first link is a link between the second message queue driver and the first message queue driver, thereby realizing communication between the two trusted execution environments.

[0015] In an optional embodiment, the second trusted application of the electronic device sends a first request to the first message queue driver through the second message queue driver to create a first connection, including: the second trusted application sending a first request to the virtual machine manager through the second message queue driver; and the virtual machine manager sending a first request to the first message queue driver to create a first connection.

[0016] In this embodiment, the first message queue driver and the second message queue driver can communicate through the virtual machine manager.

[0017] In an optional embodiment, the first trusted execution environment further includes a proxy module; the communication method further includes: after receiving a first request, the first message queue driver sends a first request to the first trusted application through the proxy module, so that the first trusted application initializes an algorithm for executing the first service; invoking the first trusted application based on the first link to execute the first service includes: after the algorithm initialization is successful, the second trusted application of the electronic device sends a first instruction to the first message queue driver through the second message queue driver; the first message queue driver sends the first instruction to the first trusted application through the proxy module, so that the first trusted application executes the first service based on the algorithm.

[0018] In some examples, the proxy module resides at the protocol layer.

[0019] In this embodiment, the first message queue driver communicates with the first trusted application through a proxy module. The proxy module is responsible for forwarding requests (or instructions) from the second trusted application to the first trusted application so that the first trusted application can perform corresponding operations (such as algorithm initialization or execution of the first service based on the algorithm). The proxy module is also responsible for forwarding data from the first trusted application to the first message queue driver so that the first message queue driver can return a response (or data) to the second trusted application in the second trusted execution environment.

[0020] In an optional embodiment, if the second trusted application abnormally exits after the first link is created, in response to the operation of restarting the first service, the electronic device creates a new link through the second trusted application. After creating the new link, the electronic device releases the first link and invokes the first trusted application based on the new link to execute the first service.

[0021] It should be noted that this embodiment is based on the premise that only one link can be maintained between the first trusted execution environment and the second trusted execution environment. In this embodiment, the electronic device creates an over-limit link (i.e., creates a second link after creating a first link). Since only one link can be maintained between the first and second trusted execution environments, after creating the second link, the first trusted application can be invoked again by disconnecting the first link, thus avoiding the inability to execute the first service due to the first trusted application being occupied by the first link.

[0022] In an optional embodiment, in response to the operation of reactivating the first service, the electronic device creates at least one new link through the second trusted application, including: in response to the operation of reactivating the first service, the second trusted application of the electronic device sequentially creates a second link and a third link; after creating at least one new link, the electronic device releases the first link and calls the first trusted application based on the at least one new link to perform the first service, including: after creating the second link and the third link sequentially, the electronic device releases the first link and calls the first trusted application based on the third link.

[0023] The second link corresponds to link 2 in the embodiment, and the third link corresponds to link 3 in the embodiment. See details for further information. Figure 7 Example.

[0024] In the communication method illustrated in this embodiment, a second trusted application in a second trusted execution environment can establish a first link with a first trusted execution environment and call the first trusted application in the first trusted execution environment based on the first link to execute a user-triggered first service. If the second trusted application exits abnormally after creating the first link, the electronic device can restart the second trusted application. If the user triggers the first service again, the electronic device can sequentially create a second link (the electronic device does not use this link to call the first trusted application) and a third link through the second trusted application. Since two links can be maintained simultaneously between the first and second trusted execution environments, and the first trusted application is still occupied by the first link, the electronic device needs to release the first link after creating the third link to maintain two links between the first and second trusted execution environments and prevent the first trusted application from being occupied. Based on this, the electronic device can call the first trusted application based on the subsequently created third link to execute the first service, avoiding interruption of the first service due to the abnormal exit of the second trusted application and improving the stability of communication between trusted applications in the trusted execution environment.

[0025] It should be noted that after the second link is created, because the first trusted application is occupied by the first link, the electronic device cannot call the first trusted application based on the second link, resulting in the interruption of the first service. For details, please refer to [link to relevant documentation]. Figure 6 The illustrated embodiment.

[0026] In an optional embodiment, in response to the operation of reactivating the first service, the second trusted application of the electronic device sequentially creates a second link and a third link, including: in response to the operation of reactivating the first service, the second trusted application sends a second request to the first message queue driver through the second message queue driver to create the second link; after creating the second link, the second trusted application sends a third request to the first message queue driver through the second message queue driver to create the third link.

[0027] In this embodiment, after the second trusted application in the second trusted execution environment exits abnormally and restarts, if the user triggers the first service again, the second trusted application can establish a second and a third link with the first trusted execution environment through the second message queue driver. By creating an over-limit link, the first link established between them is released, thereby preventing the first trusted application from being occupied.

[0028] In an optional embodiment, the electronic device releases the first link by: after receiving a third request, a first message queue driver sends a third request to a proxy module; the proxy module releases the first link and resources associated with the first link based on the third request. Wherein, the proxy module releasing resources associated with the first link based on the third request means that the proxy module releases resources associated with the first link on the first trusted execution environment side based on the third request.

[0029] In some examples, after releasing the first connection, the second message queue driver releases the resources associated with the first connection on the second trusted execution environment side. In other examples, after the second trusted application exits abnormally, the second message queue driver releases the resources associated with the first connection on the second trusted execution environment side, as detailed below. Figure 7 S302 of the embodiment.

[0030] In this embodiment, the proxy module releases the first link so that the first trusted application can be invoked again. Furthermore, it releases the resources associated with the first link to improve the resource utilization of the electronic device.

[0031] In an optional embodiment, after the agent module of the electronic device releases the first connection based on the third request, it sends a third request to the first trusted application; the first trusted application initializes the algorithm for executing the first service based on the third request.

[0032] In this embodiment, after the electronic device creates a third link, it forwards a third request through a proxy module so that the first trusted application initializes the algorithm for executing the first service. After the algorithm is successfully initialized, the second trusted application can call the first trusted application based on the third link to execute the first service.

[0033] In an optional embodiment, before the electronic device invokes the first trusted application based on the third link, the communication method further includes: the electronic device releasing the second link and the resources associated with the second link.

[0034] In some examples, after the agent module of the electronic device releases the first connection based on a third request, it sends a third request to the first trusted application. Based on the third request, the first trusted application initializes the algorithm for executing the first service. After successful algorithm initialization, the first trusted application sends a third response to the agent module, indicating successful algorithm initialization. Based on the third response, the agent module releases the second connection and the resources associated with the second connection on the first trusted execution environment side.

[0035] In some examples, after receiving the third response, the proxy module sends the third response to the first message queue driver; the first message queue driver then sends the third response to the second trusted application via the second message queue driver. Based on the third response, the second trusted application instructs the second message queue driver to release resources associated with the second link on the second trusted execution environment side.

[0036] In this embodiment, before the second trusted application of the electronic device can call the first trusted application based on the third link, the electronic device can release the second link and the resources associated with the second link to improve the resource utilization of the device.

[0037] 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.

[0038] 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.

[0039] 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.

[0040] 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.

[0041] 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

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

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

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

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

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

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

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

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

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

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

[0052] 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:

[0053] 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).

[0054] 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.

[0055] 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.

[0056] 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.

[0057] 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.

[0058] 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.

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

[0060] 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.

[0061] 3. Other terms

[0062] In the embodiments of this application, terms such as "first" and "second" are used to distinguish identical or similar items with substantially the same function and purpose. For example, "first chip" and "second chip" are used only to distinguish different chips and do not limit their order of execution. 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.

[0063] 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.

[0064] 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.

[0065] 4. Electronic equipment

[0066] 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.

[0067] 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.

[0068] 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.

[0069] 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.

[0070] 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.

[0071] 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.

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

[0073] Figure 1The diagram uses arrows and labels S11 to S18 to illustrate the specific process of a client application calling a second trusted application within a second trusted execution environment (TEX). Specifically, when a client application needs to access a second trusted application, it sends a request to the Android operating system. This request is then processed by the kernel driver within the Android operating system, which calls HVC (hypervisor call) to send the client application's request to the virtual machine manager. After processing by the virtual machine manager, the request is sent to the second trusted execution environment (TEX) operating system. Following further processing by the TEX, the request is then sent to the second trusted application. The second trusted application processes the received request and returns the result to the TEX, which in turn calls the HVC instruction to send it to the virtual machine manager. After processing by the virtual machine manager, the result is returned to the Android operating system. Finally, the Android operating system sends the result to the corresponding client application.

[0074] When a client application needs to access the first trusted application in the first trusted execution environment, the client application can access the second trusted application in the second trusted execution environment, which in turn calls the first trusted application. The process of the second trusted application calling the first trusted application can be found in [reference needed]. Figure 1 In steps S21 to S28, specifically, the second trusted application sends a request to the second trusted execution environment (TIA) operating system. After being processed by the kernel driver in the TIA, 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 trusted execution environment (TIA). The first TIA then distributes the request to the first trusted application. The first trusted application processes the received request and returns the result to the second TIA. The second TIA then uses the second TIA 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 TIA. The second TIA then sends the result back to the second trusted application. Finally, the second trusted application returns the result from the first trusted application to the corresponding client application.

[0075] In some embodiments, when a client application needs to access a first trusted application, 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 the second trusted application (S11 to S18), and will not be elaborated here.

[0076] 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).

[0077] 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.

[0078] 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 first trusted application TA1 and a first trusted execution environment operating system (QTVM OS), the second trusted execution environment runs a second 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.

[0079] 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.

[0080] 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.

[0081] 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.

[0082] 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.

[0083] 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.

[0084] 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.

[0085] 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.

[0086] 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.

[0087] 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.

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

[0089] 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).

[0090] 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.

[0091] In HTVM, the protocol layer provides the libminkipc shared library, which includes the minkipc protocol corresponding to different TAs (Task Agents). For example, the minkipc protocol for the TUI TA and the minkipc protocol for the Face TA. In QTVM, the protocol layer is configured with a proxy module (TVMMink module). The proxy module can forward data from HTVM to TA1 corresponding to TA2, or encapsulate the data returned by TA1 to ensure that the data is returned to HTVM according to the minkipc protocol.

[0092] 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.

[0093] 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.

[0094] 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.

[0095] 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.

[0096] based on Figure 4 In the framework shown, when the client application CA of an electronic device needs to call the trusted application TA1 of the first trusted execution environment QTVM through the trusted application TA2 of the second trusted execution environment HTVM, the HTVM and QTVM can communicate by establishing message queue (msgq) links (such as link 1, link 2, link 3, etc. below) at the driver layer. The message queue link can be viewed as a link between the two trusted execution environments (HTVM and QTVM), specifically referring to the link between message queue driver 2 and message queue driver 1 at the driver layer.

[0097] 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 TA2 as Face TA and 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:

[0098] 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).

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

[0100] 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.

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

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

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

[0104] 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.

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

[0106] 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.

[0107] 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.

[0108] 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.

[0109] 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.

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

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

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

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

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

[0115] 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.

[0116] In some examples, Face TA uses the minkipc protocol corresponding to Face TA in the libminkipc shared library of the protocol layer to send the first request to message queue 2 through driver manager 2 based on the second message.

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

[0118] In some examples, after message queue driver 2 sends a first request to message queue driver 1 to establish link 1, message queue driver 2 can request resources related to link 1 from the HTVM system (i.e., resources related to link 1 on the HTVM side).

[0119] In some examples, message queue driver 2 can also request resources related to link 1 from the HTVM system based on instructions from driver manager 2.

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

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

[0122] S111. The agent module sends the first request to the DSP_Service.

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

[0124] 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.

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

[0126] S114. The agent module sends the first response to message queue driver 1.

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

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

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

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

[0131] 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.

[0132] 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.

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

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

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

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

[0137] S120. The agent module sends the first instruction to the DSP_Service.

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

[0139] 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.

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

[0141] 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 a proxy module, and then message queue driver 1 sends the face verification result to message queue driver 2. Message queue driver 2 then sends the face verification result to Face TA through driver manager 2.

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

[0143] 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 sends the face verification result to message queue driver 3. Message queue driver 3 then sends the face verification result to CA through driver manager 3, thus completing the face verification.

[0144] The above embodiment illustrates the interaction process of HTVM's trusted application Face TA establishing a link 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.

[0145] based on Figure 5In the illustrated embodiment, under certain circumstances, after Face TA starts, it may abnormally exit due to various reasons, such as execution errors caused by code exceptions or camera service malfunctions. After Face TA abnormally exits, the HTVM system can restart Face TA. After Face TA restarts, if the user uses the CA's face verification service again, face verification will fail because the DSP_Service is occupied by a previously created link (such as link 1 mentioned above). The following is a related example... Figure 6 This section describes the interaction process of an electronic device after Face TA crashes and restarts.

[0146] Figure 6 This is a schematic diagram of the interaction process of an electronic device provided in an embodiment of this application. Based on Figure 5 In the illustrated embodiment, Face TA calls DSP_Service based on link 1. Based on this, as follows... Figure 6 As shown, if Face TA exits abnormally and restarts, and the user uses CA's facial verification service again (e.g., the user uses the wallet application's facial verification again), the following process can be executed:

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

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

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

[0150] The above S105 to S107 can be referred to in the foregoing. Figure 5 Examples are not elaborated here.

[0151] After S107, execute:

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

[0153] In some examples, Face TA, based on a second message, uses the minkipc protocol corresponding to FaceTA in the libminkipc shared library of the protocol layer to send a second request to message queue driver 2 through driver manager 2.

[0154] S202. Message queue driver 2 sends a second request to message queue driver 1 to establish link 2 between HTVM and QTVM.

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

[0156] In some examples, after message queue driver 2 sends a second request to message queue driver 1 to establish link 2, message queue driver 2 can request resources related to link 2 from the HTVM system (i.e., resources related to link 2 on the HTVM side).

[0157] S203. Message queue driver 1 sends a second request to the agent module.

[0158] In some examples, after receiving the second request, the proxy module requests resources related to Link 2 from the QTVM system (i.e., resources related to Link 2 on the QTVM side).

[0159] S204. The agent module sends a second response to Face TA, indicating that DSP_Service is occupied.

[0160] Upon initial startup, Face TA creates Link 1 via Message Queue Driver 1 and invokes DSP_Service through the proxy module based on Link 1. Upon receiving the second request, the proxy module determines that DSP_Service is already in use (or held by Link 1). At this point, Face TA cannot invoke DSP_Service through the proxy module to reinitialize the face verification algorithm based on the newly established Link 2. Therefore, the proxy module returns a second response to HTVM's Message Queue Driver 2 via Message Queue Driver 1, and Message Queue Driver 2 returns a second response to Face TA, indicating that DSP_Service is currently in use.

[0161] S205.Face TA, based on the second response, sends a third message to CA, indicating that face verification failed.

[0162] In some examples, Face TA, based on the second response, sends a third message to message queue driver 2 via driver manager 2. Message queue driver 2 then sends the third message to message queue driver 3 on the REE side based on instance 1. Message queue driver 3 sends the third message to CA to indicate that face verification failed.

[0163] The above embodiment illustrates the interaction flow when HTVM's Face TA exits abnormally and restarts, attempting to call QTVM's DSP_Service again. Since QTVM can maintain two connections with HTVM simultaneously, Face TA can establish a new connection (connection 2) through the driver layer to communicate with QTVM's trusted application DSP_Service. However, because QTVM's DSP_Service can only maintain one connection, Face TA cannot call DSP_Service based on the new connection, resulting in face verification failure.

[0164] Based on the foregoing Figure 6 As can be seen from the examples, the QTVM side has the following two limitations: two connections can be maintained between HTVM and QTVM simultaneously, and QTVM's DSP_Service can only maintain one connection. Based on these two limitations, when Face TA exits abnormally, the system restarts Face TA and can use the method of creating an over-limit connection (i.e., creating a third connection, such as connection 3, if two connections are already established between HTVM and QTVM) to disconnect the earliest connection (such as connection 1) on the QTVM and HTVM side and reclaim the resources associated with the earliest connection on the QTVM and HTVM side, so that DSP_Service can be invoked again, avoiding the inability to perform face verification due to DSP_Service being occupied.

[0165] The following is in conjunction with the appendix Figure 7 This paper introduces improvements to the interaction process of electronic devices after Face TA crashes and restarts.

[0166] Figure 8 This is a schematic diagram of the interaction process of an electronic device provided in an embodiment of this application. Based on Figure 5 In the illustrated embodiment, Face TA calls DSP_Service based on link 1. Based on this, as follows... Figure 7 As shown, if Face TA crashes and restarts, and the user uses CA's face verification service again, the following process can be executed:

[0167] After the S201.HTVM system detects that Face TA has exited abnormally, it sends a system notification to message queue driver 2.

[0168] In some examples, the HTVM system sends system notifications to message queue driver 2 via driver manager 2.

[0169] S202. Message Queue Driver 2 releases resources related to HTVM-side Link 1 based on system notifications.

[0170] In some examples, after the HTVM system detects an abnormal exit of Face TA, it notifies Driver Manager 2. Based on the system notification, Driver Manager 2 issues an instruction to Message Queue Driver 2, which then releases the resources related to HTVM-side Link 1.

[0171] In addition, after Face TA exits abnormally, the following steps are performed:

[0172] S105. When the user uses the CA's face verification service again, the CA sends a second message to the message queue driver 3. The second message is used to request the invocation of the DSP_Service of the first trusted execution environment QTVM.

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

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

[0175] The above S105 to S107 can be referred to in the foregoing. Figure 5 Examples are not elaborated here.

[0176] After S107, execute:

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

[0178] S202. Message queue driver 2 sends a second request to message queue driver 1 to establish link 2 between HTVM and QTVM.

[0179] S203. Message queue driver 1 sends a second request to the agent module.

[0180] S204. The agent module sends a second response to Face TA, indicating that DSP_Service is occupied.

[0181] The above S201 to S204 can be referred to in the foregoing. Figure 6 Examples are not elaborated here.

[0182] After S204, execute:

[0183] S303.Face TA, based on the second response, sends a third request to message queue driver 2, which is used to request the establishment of a link between HTVM and QTVM.

[0184] In some examples, Face TA, based on the second response, uses the minkipc protocol corresponding to FaceTA in the libminkipc shared library of the protocol layer to send a third request to message queue driver 2 through driver manager 2.

[0185] In some examples, message queue driver 2 requests resources related to link 3 from the HTVM system after receiving a third request (i.e., resources related to link 3 on the HTVM side).

[0186] S304. Message queue driver 2 sends a third request to message queue driver 1 to establish a link 3 between HTVM and QTVM.

[0187] In some examples, message queue driver 2 sends a third request to message queue driver 1 via the virtual machine manager.

[0188] S305. Message queue driver 1 sends a third request to the agent module.

[0189] S306. Based on the third request, the proxy module releases the resources related to Link 1 and QTVM side Link 1.

[0190] After receiving the third request, the proxy module determines that DSP_Service is occupied by link 1 and the number of links between HTVM and QTVM has reached the preset number, such as 2. Based on the order in which the links were created, the proxy module first releases link 1 to ensure that the number of links maintained between HTVM and QTVM is still the preset number. Then, it releases the resources related to link 1 on the QTVM side to reclaim the resources of the abandoned links and improve the system resource utilization.

[0191] In some examples, the proxy module can request resources related to link 3 (i.e., resources related to link 3 on the QTVM side) from the QTVM system after releasing the resources related to link 1 on the QTVM side.

[0192] S307. The agent module sends a third request to the DSP_Service.

[0193] In some examples, DSP_Service invokes the secure DSP driver based on a third-party request, so that the secure DSP driver initializes the face verification algorithm using secure PD.

[0194] S308.DSP_Service initializes the face verification algorithm based on a third-party request.

[0195] S309. After the face verification algorithm is successfully initialized, DSP_Service sends a third response to the proxy module. The third response is used to indicate that the face verification algorithm has been successfully initialized.

[0196] S310. The proxy module releases the resources related to Link 2 and QTVM-side Link 2 based on the third request.

[0197] S311. The agent module sends a third response to message queue driver 1.

[0198] S312. Message queue driver 1 sends a third response to message queue driver 2.

[0199] In some examples, message queue driver 1 sends a third response to message queue driver 2 via the virtual machine manager.

[0200] S313. Message queue driver 2 sends a third response to Face TA.

[0201] In some examples, message queue driver 2 sends a third response to Face TA via driver manager 2.

[0202] S314.Face TA, based on a third response, instructs message queue driver 2 to release resources associated with link 2 and HTVM-side link 2.

[0203] In some examples, Face TA notifies Driver Manager 2 based on a third response. Driver Manager 2 then issues an instruction to Message Queue Driver 2 based on the notification, which releases the resources associated with HTVM-side Link 2.

[0204] After S312, Face TA calls DSP_Service based on link 3 to perform facial data verification. The specific process can be found in S117 to S123, which will not be elaborated here.

[0205] The above embodiment illustrates that after HTVM's Face TA exits abnormally, the system restarts Face TA. Face TA establishes a new connection (connection 2) with QTVM through message queue driver 2. Since DSP_Service is occupied by connection 1, Face TA can attempt to establish a new connection (connection 3) with QTVM again through message queue driver 2. Due to the limitation on the number of connections on the QTVM side, QTVM actively releases the first connection (connection 1) and the resources associated with it, allowing QTVM to call DSP_Service again based on connection 3. This avoids the problem of face verification failure due to abnormal exit of Face TA, thus improving the user experience.

[0206] 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 QTVM's DSP_Service and HTVM's FaceTA in the aforementioned embodiments. For details, please refer to the aforementioned embodiments.

[0207] Based on the foregoing embodiments, this application provides 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 the second trusted execution environment includes a second trusted application. (Refer to...) Figure 8 The communication method includes:

[0208] S801. In response to the operation of starting the first service, the electronic device creates a first link through the second trusted application and calls the first trusted application based on the first link to execute the first service.

[0209] S802. If the second trusted application exits abnormally after the first connection is created, in response to the operation of restarting the first service, the electronic device creates at least one new connection through the second trusted application.

[0210] S803. After creating at least one new link, the electronic device releases the first link and invokes the first trusted application based on the at least one new link to perform the first service.

[0211] The first link and at least one new link are links between the first trusted execution environment and the second trusted execution environment.

[0212] Wherein, the first trusted execution environment can correspond to QTVM in the aforementioned embodiment, the second trusted execution environment can correspond to HTVM in the aforementioned embodiment, the first service can be the face verification service provided by the client application of the aforementioned rich execution environment, the second trusted application can correspond to Face TA in the aforementioned embodiment, the first link can correspond to link 1 in the aforementioned embodiment, the first trusted application can correspond to DSP_Service in the aforementioned embodiment, and at least one new link includes link 2 and link 3 as in the aforementioned embodiment.

[0213] It should be noted that the number of new links depends on the link threshold that can be maintained between the first trusted execution environment and the second trusted execution environment. For example, if the link threshold is 2, the number of new links created is 3; if the link threshold is 1, the number of new links created is 1.

[0214] In the communication method illustrated in this embodiment, a second trusted application in a second trusted execution environment can establish a first link with a first trusted execution environment and call the first trusted application in the first trusted execution environment based on the first link to execute a user-triggered first service. If the second trusted application exits abnormally after creating the first link, the electronic device can restart the second trusted application. If the user triggers the first service again, the electronic device can create at least one new link through the second trusted application. Since the first trusted application is still occupied by the first link, the electronic device needs to release the first link after creating at least one new link to prevent the first trusted application from being occupied, and then call the first trusted application based on the created at least one new link to execute the first service. This avoids interruption of the first service due to abnormal exit of the second trusted application and improves the stability of communication between trusted applications in the trusted execution environment.

[0215] In an optional embodiment, the first trusted execution environment further includes a first message queue driver, and the second trusted execution environment further includes a second message queue driver; the electronic device creates a first link through a second trusted application, including: the second trusted application of the electronic device sends a first request to the first message queue driver through the second message queue driver to create the first link.

[0216] The first message queue driver can correspond to message queue driver 1 in the aforementioned embodiment, and the second message queue driver can correspond to message queue driver 2 in the aforementioned embodiment.

[0217] In this embodiment, the second trusted application of the second trusted execution environment establishes a first link with the first message queue driver of the first trusted execution environment by calling the second message queue driver of the driver layer. The first link is a link between the second message queue driver and the first message queue driver, thereby realizing communication between the two trusted execution environments.

[0218] In an optional embodiment, the second trusted application of the electronic device sends a first request to the first message queue driver through the second message queue driver to create a first connection, including: the second trusted application sending a first request to the virtual machine manager through the second message queue driver; and the virtual machine manager sending a first request to the first message queue driver to create a first connection.

[0219] In this embodiment, the first message queue driver and the second message queue driver can communicate through the virtual machine manager.

[0220] In an optional embodiment, the first trusted execution environment further includes a proxy module; the communication method further includes: after receiving a first request, the first message queue driver sends a first request to the first trusted application through the proxy module, so that the first trusted application initializes an algorithm for executing the first service; invoking the first trusted application based on the first link to execute the first service includes: after the algorithm initialization is successful, the second trusted application of the electronic device sends a first instruction to the first message queue driver through the second message queue driver; the first message queue driver sends the first instruction to the first trusted application through the proxy module, so that the first trusted application executes the first service based on the algorithm.

[0221] In some examples, the proxy module resides at the protocol layer.

[0222] In this embodiment, the first message queue driver communicates with the first trusted application through a proxy module. The proxy module is responsible for forwarding requests (or instructions) from the second trusted application to the first trusted application so that the first trusted application can perform corresponding operations (such as algorithm initialization or execution of the first service based on the algorithm). The proxy module is also responsible for forwarding data from the first trusted application to the first message queue driver so that the first message queue driver can return a response (or data) to the second trusted application in the second trusted execution environment.

[0223] In an optional embodiment, if the second trusted application abnormally exits after the first link is created, in response to the operation of restarting the first service, the electronic device creates a new link through the second trusted application. After creating the new link, the electronic device releases the first link and invokes the first trusted application based on the new link to execute the first service.

[0224] It should be noted that this embodiment is based on the premise that only one link can be maintained between the first trusted execution environment and the second trusted execution environment. In this embodiment, the electronic device creates an over-limit link (i.e., creates a second link after creating a first link). Since only one link can be maintained between the first and second trusted execution environments, after creating the second link, the first trusted application can be invoked again by disconnecting the first link, thus avoiding the inability to execute the first service due to the first trusted application being occupied by the first link.

[0225] In an optional embodiment, in response to the operation of reactivating the first service, the electronic device creates at least one new link through the second trusted application, including: in response to the operation of reactivating the first service, the second trusted application of the electronic device sequentially creates a second link and a third link; after creating at least one new link, the electronic device releases the first link and calls the first trusted application based on the at least one new link to perform the first service, including: after creating the second link and the third link sequentially, the electronic device releases the first link and calls the first trusted application based on the third link.

[0226] The second link can correspond to link 2 in the aforementioned embodiment, and the third link can correspond to link 3 in the aforementioned embodiment.

[0227] In the communication method illustrated in this embodiment, a second trusted application in a second trusted execution environment can establish a first link with a first trusted execution environment and call the first trusted application in the first trusted execution environment based on the first link to execute a user-triggered first service. If the second trusted application exits abnormally after creating the first link, the electronic device can restart the second trusted application. If the user triggers the first service again, the electronic device can sequentially create a second link (the electronic device does not use this link to call the first trusted application) and a third link through the second trusted application. Since two links can be maintained simultaneously between the first and second trusted execution environments, and the first trusted application is still occupied by the first link, the electronic device needs to release the first link after creating the third link to maintain two links between the first and second trusted execution environments and prevent the first trusted application from being occupied. Based on this, the electronic device can call the first trusted application based on the subsequently created third link to execute the first service, avoiding interruption of the first service due to the abnormal exit of the second trusted application and improving the stability of communication between trusted applications in the trusted execution environment.

[0228] It should be noted that after the second link is created, the electronic device cannot call the first trusted application based on the second link because the first trusted application is already occupied by the first link. For details, please refer to [link / reference needed]. Figure 6 The illustrated embodiment.

[0229] In an optional embodiment, in response to the operation of reactivating the first service, the second trusted application of the electronic device sequentially creates a second link and a third link, including: in response to the operation of reactivating the first service, the second trusted application sends a second request to the first message queue driver through the second message queue driver to create the second link; after creating the second link, the second trusted application sends a third request to the first message queue driver through the second message queue driver to create the third link.

[0230] In this embodiment, after the second trusted application in the second trusted execution environment exits abnormally and restarts, if the user triggers the first service again, the second trusted application can establish a second and a third link with the first trusted execution environment through the second message queue driver. By creating an over-limit link, the first link established between them is released, thereby preventing the first trusted application from being occupied.

[0231] In an optional embodiment, the electronic device releases the first link by: after receiving a third request, a first message queue driver sends a third request to a proxy module; the proxy module releases the first link and resources associated with the first link based on the third request. Wherein, the proxy module releasing resources associated with the first link based on the third request means that the proxy module releases resources associated with the first link on the first trusted execution environment side based on the third request.

[0232] In some examples, after releasing the first connection, the second message queue driver releases the resources associated with the first connection on the second trusted execution environment side. In other examples, after the second trusted application exits abnormally, the second message queue driver releases the resources associated with the first connection on the second trusted execution environment side, as detailed below. Figure 7 S302 of the embodiment.

[0233] In this embodiment, the proxy module releases the first link so that the first trusted application can be invoked again. Furthermore, it releases the resources associated with the first link to improve the resource utilization of the electronic device.

[0234] In an optional embodiment, after the agent module of the electronic device releases the first connection based on the third request, it sends a third request to the first trusted application; the first trusted application initializes the algorithm for executing the first service based on the third request.

[0235] In this embodiment, after the electronic device creates a third link, it forwards a third request through a proxy module so that the first trusted application initializes the algorithm for executing the first service. After the algorithm is successfully initialized, the second trusted application can call the first trusted application based on the third link to execute the first service.

[0236] In an optional embodiment, before the electronic device invokes the first trusted application based on the third link, the communication method further includes: the electronic device releasing the second link and the resources associated with the second link.

[0237] In some examples, after the agent module of the electronic device releases the first connection based on a third request, it sends a third request to the first trusted application. Based on the third request, the first trusted application initializes the algorithm for executing the first service. After successful algorithm initialization, the first trusted application sends a third response to the agent module, indicating successful algorithm initialization. Based on the third response, the agent module releases the second connection and the resources associated with the second connection on the first trusted execution environment side.

[0238] In some examples, after receiving the third response, the proxy module sends the third response to the first message queue driver; the first message queue driver then sends the third response to the second trusted application via the second message queue driver. Based on the third response, the second trusted application instructs the second message queue driver to release resources associated with the second link on the second trusted execution environment side.

[0239] In this embodiment, before the second trusted application of the electronic device can call the first trusted application based on the third link, the electronic device can release the second link and the resources associated with the second link to improve the resource utilization of the device.

[0240] 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.

[0241] 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.

[0242] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 9 As shown, the electronic device includes a processor 901, a communication line 904, and at least one communication interface. Figure 9 (The example provided uses communication interface 903 as an example.)

[0243] The processor 901 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.

[0244] Communication line 904 may include circuitry for transmitting information between the aforementioned components.

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

[0246] In some embodiments, the electronic device may further include a memory 902.

[0247] The memory 902 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 optical discs, laser discs, optical discs, digital versatile optical 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 904. The memory may also be integrated with the processor.

[0248] The memory 902 stores computer execution instructions for implementing the scheme of this application, and its execution is controlled by the processor 901. The processor 901 executes the computer execution instructions stored in the memory 902 to implement the method provided in the embodiments of this application.

[0249] 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.

[0250] As an example, processor 901 may include one or more CPUs.

[0251] 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).

[0252] 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.

[0253] Figure 10 This is a schematic diagram of a chip structure provided in an embodiment of this application. Figure 10 As shown, chip 1000 includes one or more processors 1020 and communication interface 1030.

[0254] In some embodiments, the memory 1040 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.

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

[0256] In this embodiment, the memory 1040, the communication interface 1030, and the memory 1040 are coupled together via a bus system 1010. The bus system 1010 includes a data bus, and may also include a power bus, a control bus, and a status signal bus, etc. For ease of description, in... Figure 10 The general labeled all buses as Bus System 1010.

[0257] The methods described in the embodiments of this application can be applied to, or implemented by, the processor 1020. The processor 1020 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 the processor 1020 or by instructions in software form. The processor 1020 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. The processor 1020 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application.

[0258] 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.

[0259] 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.

[0260] 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.

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

[0262] 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.

[0263] 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 method for communication between trusted applications in a multi-trusted execution environment, characterized in that, The application is applied to an electronic device including a first trusted execution environment and a second trusted execution environment, the first trusted execution environment including a first trusted application, and the second trusted execution environment including a second trusted application, and the method includes: In response to an operation of starting a first service, the electronic device creates a first link through the second trusted application and calls the first trusted application based on the first link to execute the first service; If the second trusted application abnormally exits after the first link is created, in response to an operation of starting the first service again, the electronic device creates at least one new link through the second trusted application; After the at least one new link is created, if the number of the new links is equal to a threshold value of links that can be maintained between the first trusted execution environment and the second trusted execution environment, the electronic device releases the first link and calls the first trusted application based on the at least one new link to execute the first service; The first link and the at least one new link are both links between the first trusted execution environment and the second trusted execution environment.

2. The method of claim 1, wherein, The first trusted execution environment further includes a first message queue driver, and the second trusted execution environment further includes a second message queue driver; The electronic device creates a first link through the second trusted application, including: The second trusted application of the electronic device sends a first request to the first message queue driver through the second message queue driver to create the first link.

3. The method of claim 2, wherein, The second trusted application of the electronic device sends a first request to the first message queue driver through the second message queue driver to create the first link, including: The second trusted application sends the first request to a virtual machine manager through the second message queue driver; The virtual machine manager sends the first request to the first message queue driver to create the first link.

4. The method of claim 2, wherein, The first trusted execution environment further includes an agent module; and the method further includes: After receiving the first request, the first message queue driver sends the first request to the first trusted application through the agent module to make the first trusted application initialize an algorithm for executing the first service; The calling of the first trusted application based on the first link to execute the first service includes: After the algorithm is initialized successfully, the second trusted application of the electronic device sends a first instruction to the first message queue driver through the second message queue driver; The first message queue driver sends the first instruction to the first trusted application through the agent module to make the first trusted application execute the first service based on the algorithm.

5. The method according to any one of claims 1 to 4, characterized in that, The electronic device creates at least one new link through the second trusted application in response to an operation of starting the first service again, including: In response to an operation of starting the first service again, the second trusted application of the electronic device creates a second link and a third link in sequence; The electronic device releases the first link and invokes the first trusted application based on the at least one new link to execute the first service after the at least one new link is created, including: After the second link and the third link are created in sequence, if the link threshold is 2, the electronic device releases the first link and invokes the first trusted application based on the third link.

6. The method of claim 5, wherein, The second trusted application of the electronic device creates a second link and a third link in sequence in response to the operation of restarting the first service, including: In response to the operation of restarting the first service, the second trusted application sends a second request to a first message queue driver through a second message queue driver to create the second link; After the second link is created, the second trusted application sends a third request to the first message queue driver through the second message queue driver to create the third link.

7. The method of claim 6, wherein, The electronic device releases the first link, including: After receiving the third request, the first message queue driver sends a third request to a proxy module; The proxy module releases the first link and resources related to the first link based on the third request.

8. The method of claim 5, wherein, Before the electronic device invokes the first trusted application based on the third link, the method further includes: The electronic device releases the second link and resources related to the second link.

9. An electronic device, comprising: Including: A processor and a memory; The memory stores computer execution instructions; The processor executes the computer execution instructions stored in the memory, so that the electronic device executes the method as claimed in any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program, the computer program comprising instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 9. The computer program is executed by the processor to implement the method as claimed in any one of claims 1 to 8.

Images