WO2018072715A1

WO2018072715A1 - Communication system and electronic device

Info

Publication number: WO2018072715A1
Application number: PCT/CN2017/106734
Authority: WO
Inventors: 孟庆洋; 高峰; 孟令智; 张强
Original assignee: 北京豆荚科技有限公司
Priority date: 2016-10-19
Filing date: 2017-10-18
Publication date: 2018-04-26
Also published as: CN106547618B; CN106547618A

Abstract

The present invention relates to a communication system and an electronic device, and in particular, to a communication system used for communication between an ordinary execution environment and a trusted execution environment. The communication system comprises the ordinary execution environment and the trusted execution environment. The trusted execution environment is isolated from the ordinary execution environment, and an operation system and an application both can run in the trusted execution environment and the ordinary execution environment. The communication system also comprises a processor core scheduling unit. The processor core scheduling unit is used for checking the task load condition of each processor core of the trusted execution environment every once in a while, and scheduling, according to the task load condition, the processor core between the trusted execution environment and the ordinary execution environment through by a scheduling and control channel.

Description

Communication systems and electronic devices

Technical field

The present invention relates to a communication system for communication between a general execution environment and a trusted execution environment and an electronic device to which the communication system is applied.

Background technique

The basic idea of the Trusted Execution Environment (TEE) or the safe runtime environment is to provide a secure operating system that is isolated from the normal operating system and run in a set of isolated On top of the hardware, this secure operating system is called TEE. It is known that a protected area can be generated in a microprocessor unit as a TEE by the ARM trust zone technique. This TEE is used to run an application called a trustlet. ARM has fully supported TEE in chip IP design. At present, Qualcomm, MediaTek, Samsung, HiSilicon, and Spreadtrum have already supported TEE on hardware. Intel's X86 architecture and Imagination's MIPS architecture have also introduced similar solutions. The common problem of these solutions is that the channel between the common execution environment REE and the trusted execution environment TEE is realized in a single channel, which makes the channel design complicated, the maintenance difficulty and the communication efficiency low.

Summary of the invention

The technical problem to be solved by the present invention is to implement processor core scheduling between a common execution environment and a trusted execution environment to optimally allocate resources.

In order to solve the technical problem, the present invention proposes a communication system for communication between a general execution environment and a trusted execution environment, wherein the communication system includes: a normal execution environment and a trusted execution environment, wherein the trusted execution The environment is isolated from the general execution environment; both the trusted execution environment and the normal execution environment are capable of running an operating system and an application, and the communication system further includes a processor core scheduling unit, and the processor core scheduling unit checks the trusted execution environment at intervals Task load conditions for each processor core:

If the processor core task of the Trusted Execution Environment is overloaded, transfer its task load to other Trusted Execution Environment processor cores that are not under-loaded, if the Trusted Execution Environment Processor Core is still tasked after the transfer If the load is too high, the processor core scheduling unit migrates the processor core of the normal execution environment to the trusted execution environment via the scheduling and control channel, and processes the trusted execution environment as the processor core of the trusted execution environment.

If all tasks of the trusted execution environment are in a blocked or suspended state, the processor core scheduling unit migrates all processor cores of the trusted execution environment to the normal execution environment via the scheduling and control channels as a processor of the normal execution environment. The core performs the tasks of the normal execution environment,

If the task of the trusted execution environment is reduced and an idle processor core is present, the processor core scheduling unit migrates the idle processor core to the normal execution environment via the scheduling and control channels to perform normal execution as the processor core of the normal execution environment. The task of the environment.

In an embodiment in accordance with the invention, the processor core scheduling unit checks the task load conditions of the processor cores of the trusted execution environment every set time (eg, 100 ms).

In an embodiment in accordance with the present invention, if the trusted execution environment processor core overall task load is too high, the processor core of the trusted execution environment with too high task load issues a request to the processor core scheduling unit to cause the processor The core scheduling unit checks the state of the processor core of the normal execution environment and randomly selects the CPU core of the suspended state to transfer to the trusted execution environment to perform the task of the trusted execution environment as the processor core of the trusted execution environment, and processes The core scheduling unit distributes the tasks to be distributed of the requesting processor core to the newly transferred processor core of the trusted execution environment for processing according to specific task rules.

In an embodiment in accordance with the invention, the communication system further includes an interrupt control unit that interrupts the interrupt control unit to be processed only by the processor core of the trusted execution environment if the processor core of the trusted execution environment receives the interrupt The safety interruption is divided into the first group, and the other interruptions are divided into the second group as non-safety interruptions.

In an embodiment in accordance with the invention, the interrupt control unit hands the first set of security interrupts to the processor core of the trusted execution environment and transfers the second set of non-secure interrupts to the normal execution via the scheduling and control channels. The processor core processing of the environment.

In an embodiment in accordance with the invention, the interrupt control unit hands the first set of security interrupts to the processor core of the trusted execution environment, and the interrupt control unit determines that the non-secure interrupts in the second group are shared peripheral interrupts, Private interrupt or soft interrupt:

If it is a shared peripheral interrupt, the interrupt control unit indicates that the processor core of the trusted execution environment that received the interrupt discards it, and the interrupt control unit transfers the discarded shared peripheral interrupt to the normal execution environment via the scheduling and control channel. Processor core for processing;

If it is a private interrupt or a soft interrupt, the interrupt control unit notifies the processor core scheduling unit, which then transfers the processor core of the trusted execution environment receiving the interrupt to the normal execution environment via the scheduling and control channel. Become the processor core of the normal execution environment and queue the interrupted tasks in the work queue.

In an embodiment in accordance with the invention, a processor core scheduling unit is configured to schedule a processor core within a trusted execution environment and between a trusted execution environment and a normal execution environment,

Wherein, after the task of the private interrupt or the soft interrupt is put into the work queue, the processor core scheduling unit retransmits the processor core of the normal execution environment that receives the interrupt to the trusted execution environment via the scheduling and control channel, thereby Re-establish the processor core of the trusted execution environment to wait for other interrupts to be received.

In an embodiment in accordance with the present invention, the communication system further includes: an application channel and a drive channel disposed between the normal execution environment and the trusted execution environment, wherein the application channel is used in the normal execution environment and the trusted execution environment Communication between applications; drive channels are used to communicate between drives in a normal execution environment and a trusted execution environment.

In an embodiment in accordance with the present invention, the application channel, the drive channel, and the scheduling and control channel are respectively disposed in a shared memory between the normal execution environment and the trusted execution environment, and the shared memory for the different channels are independent of each other.

In an embodiment in accordance with the invention, the application channel, the drive channel, and the scheduling and control channels each include a forward channel and a reverse channel, wherein the forward channel is used to transmit messages in the transmit queue of the normal execution environment to In the receive queue of the message execution environment, the reverse channel is used to transfer messages in the send queue of the trusted execution environment to the receive queue of the normal execution environment.

In an embodiment in accordance with the invention, the message type and message content of the message to be transmitted or received are stored in the respective transmit queues and receive queues of the normal execution environment and the trusted execution environment, thereby being sent via the channel conforming to the message type. Or receive individual messages.

In an embodiment in accordance with the invention, a client application, a host driver, a virtual driver, and/or a processor core can be run in a general execution environment, and a trusted application, a host driver, a virtual driver can be run in a trusted execution environment. And / or processor core.

In an embodiment in accordance with the invention, the drive channel is configured to communicate between the virtual drive and the host drive between the normal execution environment and the trusted execution environment to implement the common execution environment and the trusted execution environment. Drive sharing between.

In an embodiment in accordance with the present invention, in the case where a normal execution environment invokes a specific driver, if the host driver of the driver exists in the trusted execution environment and the virtual driver of the driver exists in the normal execution environment, the normal execution environment calls The drive is arranged in a virtual drive of the normal execution environment, thereby triggering information related to the drive to be sent to the corresponding master drive of the trusted execution environment via the forward channel of the drive channel, and the master drive is invoked and will process The resulting information is returned to the virtual drive of the normal execution environment via the reverse channel of the drive channel, and

In the case where the trusted execution environment invokes a specific driver, if the virtual driver of the driver exists in the trusted execution environment and the host driver of the driver exists in the normal execution environment, the trusted execution environment invokes the setting of the driver at the trusted Executing a virtual drive of the environment, thereby triggering information related to the drive to be sent to a corresponding main drive of the normal execution environment via a reverse channel of the drive channel, and the main drive is invoked and the information obtained after processing is via the drive channel The forward channel is returned to the virtual drive of the trusted execution environment.

The present invention also proposes an electronic device comprising: a communication system according to the present invention; and a network interface and a peripheral device interface, wherein the user can obtain an application via a network interface or a peripheral device interface and install the application in the communication system, Users can also run different applications with the aid of a communication system.

Through the invention, the processor core is scheduled between the trusted execution environment and the common execution environment via the scheduling and control channel, and the problem of limited processing capability in the TEE is solved.

DRAWINGS

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the embodiments or the prior art description will be briefly described below. Obviously, the drawings in the following description are only some of the present invention. For the embodiments, those skilled in the art can obtain other drawings according to the drawings without any creative work. among them:

Figure 1 schematically illustrates a multi-channel communication system for communication between REE and TEE.

FIG. 2 schematically illustrates an embodiment of a drive channel in accordance with an embodiment of the present invention.

Fig. 3 schematically shows the workflow of the drive division unit.

FIG. 4 schematically illustrates a security hierarchy of a multi-channel communication system in accordance with an embodiment of the present invention.

Fig. 5 schematically shows a virtual docking mode between REE and TEE.

Fig. 6 schematically shows a schematic diagram of the operation of a core scheduling unit in accordance with an embodiment of the present invention.

Fig. 7 schematically shows the workflow of an interrupt control unit in accordance with an embodiment of the present invention.

FIG. 8 schematically illustrates an electronic device in accordance with an embodiment of the present invention.

For the sake of overview, the same or corresponding elements are designated by the same reference numerals throughout the drawings. The drawings are merely schematic and the elements are not necessarily to scale.

detailed description

The technical solutions in the embodiments of the present invention are clearly and completely described in the following with reference to the accompanying drawings in the embodiments of the present invention. It is obvious that the described embodiments are a part of the embodiments of the present invention, but not all embodiments.

According to an embodiment of the present invention, a multi-channel communication system for communication between REE and TEE is proposed System. The multi-channel communication system includes a REE and a TEE isolated from the REE, and an operating system and an application are run in both the TEE and the REE, for example, a client application, a host driver, a virtual driver, and/or a processor core running on the REE side. A trusted application, a main drive, a virtual drive, and/or a processor core are run on the TEE side; and an application channel, a drive channel, and a scheduling and control channel disposed between the REE and the TEE are also included. Wherein, the application channel is constructed as communication between the application between the REE and the TEE; the drive channel is constructed to communicate between the driver for running between the REE and the TEE; and the scheduling and control channel is constructed to be in the REE Communication between scheduling and control commands between TEEs.

According to an embodiment of the invention, the application channel, the drive channel and the scheduling and control channel are isolated from each other and are capable of communicating in parallel. Therefore, multiple types of security problems such as biometrics, mobile payment, digital copyright protection, secure positioning, and Internet of Things security can be efficiently solved on one mobile terminal at the same time.

In contrast, the disadvantages of a single-channel structure are:

(1) The structural design of the channel is complicated. Because a single channel is used, the TEE side needs to parse the information on the REE side, and the loader communicates with the access object corresponding to the TEE side. On the other hand, if there is an application on the TEE side to call the program, driver, etc. on the REE side, communication can only be performed through this channel. This channel is used for data structures for operations such as driving, application, scheduling, etc. The inclusion of multiple data types in a communication poses great difficulties in design and implementation.

(2) Software design ideas that do not conform to low coupling are very difficult for maintenance and upgrade. The upgrade of the channel may cause the mutual influence of the corresponding modules, which is prone to errors.

(3) Inefficiency. Single channel cannot handle concurrent processing of different types of concurrent data such as data and drivers.

According to the embodiment of the present invention, for the application channel, the driving channel, and the scheduling and control channel, the shared memory between the REE side and the TEE side is respectively set, and the shared memory for different channels is independent of each other. Through shared memory, different data types are passed between different channels in REE and TEE.

In other words, the shared memory used to implement different channels is a memory portion that is set on the REE side and can be shared with the TEE, and belongs to non-trusted memory (the memory set on the TEE side is a trusted memory that is inaccessible on the REE side), and The memory of different channels can be independent of each other by means of logical division. For example, fixed and independent memory areas can be divided for different channels, or the memory area allocated to each channel can be adjusted as needed in each operation. After each adjustment, the independence between the channels is still ensured by logical division. .

For example, the data transfer process for each channel is as follows:

First, load the data into the shared memory of different channels; then, read the data on the REE or TEE side; next, identify the data on the REE or TEE side according to the data type and package it into different data structures, then Put the data in the appropriate work queue and wait for it to be processed.

Since the memory used for different channels is independent of each other, the virtual "channels" are naturally isolated from each other. In this way, different types of data are transmitted via dedicated channels, achieving full concurrency and enabling support for "multi-TEE" architecture, ie simultaneous communication of multiple virtual machines virtualized on the TEE side.

According to an embodiment of the present invention, the application channel, the driving channel, and the scheduling and control channel may be respectively in a simplex manner, and each includes a forward channel and a reverse channel, wherein the forward channel is used to send the REE side in the transmission queue. The message is transmitted to the receiving queue on the TEE side, and the reverse channel is used to transmit the message in the sending queue on the TEE side to the receiving queue on the REE side. This further increases "concurrency" and reduces the probability of errors in data transmission. The application channel, the drive channel, and the scheduling and control channel can also adopt a half-duplex or duplex communication mode. Accordingly, the forward channel and the reverse channel can also be virtual channels, which can be implemented by switching or competing.

According to an embodiment of the present invention, message types and message contents of messages to be transmitted or received are stored in respective transmission queues and reception queues on the REE side and the TEE side, thereby transmitting or receiving respective messages via channels conforming to the message type. In this way, it is possible to simply divide the message to be transmitted into the correct channel.

According to an embodiment of the invention, the application channel carries a standard application protocol, such as a Client API compliant with the GPTEE Note 1 standard.

In accordance with an embodiment of the present invention, the drive channel is configured to communicate between the virtual drive and the main drive between the REE and the TEE to enable drive sharing between the REE and the TEE.

The solution of the embodiment of the present invention is based on the TEE technology, and is not limited to a processor chip supporting the ARM Trustzone extension. The multi-level operation method proposed by the present invention can simultaneously and efficiently solve a biological problem on a mobile terminal. Identification, mobile payment, digital copyright protection, secure positioning, Internet of Things security and many other security issues.

The TEE architecture can be roughly divided into three layers, including the hardware layer, the TEE OS (operating system) layer, and the TA (Trusted Application Trusted Application) layer. A multi-channel communication system according to an embodiment of the present invention is implemented at the TEEOS layer.

FIG. 1 illustrates a multi-channel communication system 100 for communication between a REE and a TEE, in accordance with an embodiment of the present invention. As shown in FIG. 1, the multi-channel communication system 100 includes a REE 101 and a TEE 102 isolated from the REE 101, wherein an operating system and an application are run in both the TEE 102 and the REE 101, for example, a customer running on the REE 101 side. End applications, host drivers, virtual drives, and/or processor cores run on the TEE 102 side with trusted applications, host drivers, virtual drives, and/or processor cores.

The TEE (trusted execution environment) is a secure execution environment that is isolated from the Common Execution Environment (REE), which can be run in two execution environments. Thus need Provides a channel between TEE and REE for data transfer.

Accordingly, the multi-channel communication system 100 also includes an application channel 103, a drive channel 104, and a dispatch and control channel 105 disposed between the REE 101 and the TEE 102, wherein the application channel 103 is configured as an application in the REE 101 and TEE 102 Communication between the drives; the drive channel 104 is configured for communication between the drives running in the REE 101 and the TEE 102; and the scheduling and control channel 105 is configured for scheduling and controlling commands between the REE 101 and the TEE 102 Communication.

The application channel 103 can provide a specified interface for the application vendor's APP. As long as the interface is followed, the vendor can apply the registered APP to the platform. According to the present invention, the highly secure APP can be placed on the TEE side. For the access permission of the APP placed on the TEE side, it is generally at the factory stage of the device, and the trusted application developer and the equipment vendor and the TEE provider negotiate to verify the access by signature.

The communication between the host driver and the virtual driver can be achieved by driving the channel 104 due to the type of the driver and the size of the occupied resources. Different drivers can be flexibly set to save on the TEE side or the REE side. For a driver that occupies more resources and is more difficult to migrate, it can remain on the REE side. On the TEE side, you can save drivers that take up less resources and require a higher level of security.

Regarding the scheduling channel, the current trusted execution environment has no scheduling of resources. For example, in the current TEE, the designated processor core is generally responsible for the operation of the TEE-related services and tasks. Since the protection content to be run in the current TEE is small, the processing capability of the single core can also be handled. However, with the expansion of the demand for TEE, the use of related applications such as iris and DRM will greatly increase the load on the TEE side. Therefore, reasonable scheduling of resources is necessary. None of the currently known TEE vendors implement processor scheduling between REE and TEE.

In one embodiment of the invention, application channel 103, drive channel 104, and scheduling and control channel 105 may be the same channel. In this embodiment, the TEE adopts a macro kernel or a sandbox architecture. Based on its own characteristics, the kernel object is associated with only one process, and the communication between the TEE and the REE can only be communicated through a single channel. Specifically, sandbox (sandbox technology) is a security mechanism that separates running programs and is often used to execute untested code or third-party non-trusted programs. The sandbox can usually provide users with a tightly controlled set of resources to ensure the running of the program. It can provide a virtual system environment for the user APP. Even if there is an error in the program running in the sandbox environment, it only modifies the local temporary resources. Will not cause a system crash. The work of the sandbox originally can only contain one sandbox operation at the same time. Under the condition that the virtualization technology is not supported, and the mechanism of the sandbox, only one trusted application TA can be run simultaneously in the TEE.

However, the implementation of this single, shared channel has the following characteristics: (1) The structural design of the channel is complicated. Since the single channel is used, the TEE side needs to parse the information on the REE side through the loader and TEE. The corresponding access object on the side communicates. On the other hand, if there is an application on the TEE side to call the program, driver, etc. on the REE side, communication can only be performed through this channel. This channel is used for data structures for operations such as driving, application, scheduling, etc. The inclusion of multiple data types in a communication poses great difficulties in design and implementation. (2) Software design ideas that do not conform to low coupling are very difficult for maintenance and upgrade. The upgrade of the channel may cause the mutual influence of the corresponding modules, which is prone to errors. (3) Inefficiency. Single channel cannot handle concurrent processing of different types of concurrent data such as data and drivers.

In accordance with yet another embodiment of the present invention, application channel 103, drive channel 104, and scheduling and control channel 105 are isolated from each other and are concurrent. The application channel 103 is responsible for communication between the client APP (the client application on the REE side) and the Trusted APP (the trusted application on the TEE side), and the application channel 103 mainly carries the standard application protocol (such as the Client API conforming to the GPTEE Note 1 standard). The drive channel 104 is responsible for communication between the device main drive and the virtual drive between the REE and the TEE; the drive channel 104 carries the communication interface of various types of drives, and the present invention adopts a method of driving virtual docking to complete the drive between the REE and the TEE. Sharing; scheduling and control channel 105 carries scheduling and control commands between REE and TEE.

The isolated channels are implemented through virtualization technology. Specifically, the shared memory between the REE side and the TEE side is respectively set for the application channel 103, the driving channel 104, and the scheduling and control channel 105, and the shared memories for the different channels are independent of each other. The application channel 103, the drive channel 104, and the scheduling and control channel 105 each include a forward channel and a reverse channel, wherein the forward channel is used to transmit a message in the transmit queue on the REE side to the receive queue on the TEE side, in the reverse direction. The channel is used to transmit the message in the send queue on the TEE side to the receive queue on the REE side. Message types and message contents of messages to be transmitted or received are stored in respective transmission queues and reception queues on the REE side and the TEE side, thereby transmitting or receiving respective messages via channels conforming to the message type. In this way, when the message is transmitted through multiple channels, the message can be correctly transmitted to the REE or TEE through different channels according to the type. Message queues for CA (Client Application, Client Application) and TA (Trusted Application) must have separate threads to handle the contents of the queue. With the solution of this embodiment, different channels can be concurrently executed, and the calls of CA and TA in the same channel do not have to wait for the returned result, and the concurrent operation is truly performed.

The mutually isolated multi-channel of the present invention supports concurrent calls. By using the above virtualization technology, multiple virtual machines can be virtualized on one TEE to create execution space for different TAs. For example, a plurality of CAs disposed on the REE side can simultaneously call a plurality of TAs disposed on the TEE side, and multiple drivers can be shared with each other at the same time. The characteristics of the virtual machine are isolation and security, and security isolation can also be achieved. The solution of this embodiment truly achieves multi-channel concurrency technology and is in a leading position in system performance and scalability. Through the multi-level operation method proposed in this embodiment, biometrics can be efficiently solved simultaneously on one mobile terminal. Mobile payment, digital copyright protection, secure location, Internet of Things security and many other security issues.

This mutually isolated multi-channel by the present invention also achieves greater security than a technical solution that does not support virtualization. The level of protection and level of the TEE side has obvious advantages over the existing TEE software products.

Data exchange between TEE and REE can take many forms. For example, in a mobile terminal, application data (AD) and control data (MCP, NQ) are transmitted via different buffers, but such buffer-based data Transmission does not achieve effective control for the drive and scheduling. The support of multiple TEEs based on virtualization is currently the biggest advantage of the isolated multi-channels of the present invention compared to other TEE vendors. Currently, other vendors do not support multiple TEEs.

Figure 2 illustrates a drive channel in accordance with one embodiment of the present invention. As shown in FIG. 2, the drive channel 104 is configured to communicate between the virtual drive and the main drive between the REE and the TEE to enable drive sharing between the REE and the TEE.

The driver's call is implemented by means of virtual docking. The main drive and virtual drive can be assigned to different execution environments depending on the characteristics of the drive itself. That is, the main driver of the drive is set in one execution environment, and the virtual drive of the drive is set in another execution environment. For example, put the file system driver in the REE and the FP driver in the TEE. The division of the driver will be further explained below.

In the case where a specific driver is called on the REE side, if there is only the virtual drive of the drive on the REE side and the main drive of the drive exists on the TEE side, the REE calls the virtual drive of the drive set on the REE side, thereby triggering the The drive related information is sent to the corresponding main drive on the TEE side via the forward channel of the drive channel, and the main drive is called and the processed information is returned to the virtual drive on the REE side via the reverse channel of the drive channel.

In the case where a specific driver is called on the TEE side, if there is only the virtual drive of the drive on the TEE side and the main drive of the drive exists on the REE side, the TEE calls the virtual drive of the drive set on the TEE side, thereby triggering The drive related information is sent to the corresponding main drive on the REE side via the reverse channel of the drive channel, and the main drive is called and the processed information is returned to the virtual drive on the TEE side via the forward channel of the drive channel.

In this way, the application can call any driver on the REE side or the TEE side without feeling the transition between REE and TEE. Taking the fingerprint recognition application as an example, the fingerprint drive is called on the REE side, and the main drive of the drive, or the real drive, is located on the TEE side. In other words, the fingerprint driver is called on the REE side to obtain the fingerprint information, but the REE side does not have the real fingerprint driver, but the interface for operating the fingerprint is defined on the REE side by means of virtualization.

The multi-channel communication system according to the embodiment of the present invention invokes the virtualized fingerprint interface on the REE side, and actually transmits the information of the fingerprint interface to the TEE through the forward channel of the drive channel 104, and the TEE side obtains the real fingerprint interface. After the fingerprint related information, the information is sent to the REE side through the reverse driving channel, and the REE obtains the fingerprint related result. The CA that does not feel the driver on the REE side actually has a switchover between the two execution environments. This is achieved by the way of virtualization combined with the drive channel to achieve message communication.

All kinds of hardware and security services such as fingerprint recognition, iris recognition, DRM (Digital Rights Management), NFC, etc. are installed on the terminal, and their drivers are divided on the REE side or in the REE side. On the TEE side, the current TEE software products do not give a clear division method and implementation method. The present invention proposes a method of driving division based on the degree of security and availability, and an implementation method using a virtual docking method.

According to an embodiment of the invention, the multi-channel communication system comprises a drive division unit. Fig. 3 schematically shows the workflow of the drive division unit. The drive dividing unit performs the following steps:

In step 301, the security of the driver to be operated on the multi-channel communication system is evaluated; under the condition that the security of the driver is above the first security threshold, the main drive of the drive is divided into the TEE side in step 302, The virtual drive of the drive is set on the REE side; under the condition that the security of the drive is below the second security threshold, the main drive of the drive is divided into the REE side in step 303, and the virtual drive of the drive is set on the TEE side. Under the condition that the security of the driver is between the first security threshold and the second security threshold, the availability and achievability of the driver is checked in step 304 if the availability is below the availability threshold and the achievability is Above the fulfillment threshold, the main drive of the drive is divided to the TEE side in step 305 and the driven virtual drive is placed on the REE side, otherwise the main drive of the drive is divided to the REE side and the drive is set on the TEE side in step 306 Virtual drive.

This division takes into account security, availability and achievability. in particular:

- Security & Usability Considerations: Divide from the security aspects of the driver resources. For the driver with strong security demand, it tends to be divided into TEE side. Among them, security is the first standard and the main purpose of setting up a separate TEE. Therefore, the driver with higher security than the threshold should be divided into the TEE side; In the case of more demand for usability, the REE side is divided, and the REE and TEE virtual docking methods are used to ensure security. For example, the fingerprint driver commonly used in terminal devices has strong security requirements. Therefore, the host driver of the fingerprint is divided into TEE, and a virtualized virtual interface is reserved for REE in the REE; for example, storage and network. The drive system is large, and its demand for availability is more than security. Therefore, the main drive is divided on the REE side, and the virtual drive interface is left on the TEE side.

- achievability: for some special drive and operation protection is not only able to consider its security, but also It is necessary to consider the technical achievability. Such as DRM (Digital Rights Management) driver, NFC (Near Field Communication) driver and iris camera driver, it is characterized that the drive system is relatively difficult to fully migrate to the TEE and there is a certain degree of security requirements. For such drivers, considering the technical achievability, it will be divided into the REE side. For the security of this type of driver, the present invention utilizes the virtualization technology and container technology in REE to protect such driving resources.

According to an embodiment of the present invention, the driving division unit divides the main drive of the DRM drive, the camera drive, the network drive, the GPS drive, and the storage drive to the REE side; and the partially driven main drive for data transmission and data analysis in the iris drive Divided to the TEE side, and the main drive driven by the other part of the iris drive is divided into the REE side; the main drive of the NFC drive is divided into the REE side; the main drive division of the partial drive for data transmission and data analysis in the fingerprint drive is divided Go to the TEE side and divide the main driver of the partial drive initiated by the SPI interrupt (shared peripheral interrupt) in the fingerprint driver to the REE side; divide the SE (secure element) driver to the TEE side; and, support the TUI (trusted user) The main drive of the drive of the interface is set on the REE side as well as on the TEE side. This division takes into account the level of security requirements and the level of protection of the overall architecture. Drivers that support TUI include LCD drivers, touch screen drivers, and I2C drivers.

FIG. 4 schematically illustrates a security hierarchy of a multi-channel communication system in accordance with an embodiment of the present invention. REE is less secure than TEE. REE includes a security level hypervisor and a security level lower than that of the hypervisor. The hypervisor and the container are isolated from each other, and the REE and TEE are isolated from each other.

The Container layer refers to the related technology similar to the container technology under the Linux operating system. The Hypervisor refers to the virtual software layer established by the hardware-supported virtualization extension technology. The TEE refers to the TEE technology provided by the processor chip not limited to the ARM Trustzone extension. .

According to an embodiment of the present invention, the drive dividing unit sets the main drive of the drive divided to the REE side to the Container or the Hypervisor, respectively.

In an embodiment of the present invention, the multi-channel communication system according to the embodiment of the present invention further includes an SE operating environment that is isolated from the REE and the TEE, and the SE operating environment may cover an eSE (embedded secure element) in the mobile terminal. Unit), SIM (Subscriber Identification Module), SSD (secure storage device), etc., have the highest security level, but the processing power is weak.

If these drivers are partitioned according to the driver's security level and overall architecture security requirements, then:

REE: network driver, GPS driver. Storage drivers, etc., are not so demanding for their security, but the demand is very high. Need to use frequently. If you put it in the TEE, it will seriously affect the performance of the system. So placed in REE without protection.

REE Container: For the protection of some special drivers and operations, it is not possible to consider only its security, but also to consider the technical achievability. Such as DRM drive, NFC drive and iris camera drive, it is characterized that the drive system is relatively difficult to fully migrate to the TEE and there is a certain degree of security requirements. According to the present invention, for example, the driver for the data transmission and data analysis sections in the iris drive is placed on the secure end, and the other parts are driven in the REE Container. Because the two parts of the drive involve security protection. But other parts of the security level are lower, so put it in the REE Container.

REE Hypervisoer: In REE, arm virtualization supports EL2 hardware virtualization in REE. Virtualization can increase the level of security, but after all, it is in REE, and the security level is lower than TEE. NFC has been gradually applied, but it is mainly used in non-secure terminals. The market demand for NFC payment is relatively small. Secondly, NFC equipment vendors rarely provide porting code in TEE. The porting difficulties are quite large, which will have a considerable impact on system stability. . So, keep the NFC driver on the REE side, but put it in the hypervisor to increase the security level.

TEE: The use of fingerprints is related to payment, and payment is absolutely safe, so the fingerprint driver is placed in the TEE, and the use of the fingerprint device can only be used in the security world. The SPI interrupt initiation in the fingerprint driver is initiated in the REE. This part is not protected by the TEE. Other fingerprint data transmission and analysis are placed in the TEE. The SE has the highest level of security and the SE driver must be placed in the TEE.

TUI: Refers to the trusted user interface. The driver for the screen is placed in both REE and TEE. The use of the screen is the most frequent, and the screen driver needs to be included on the REE side. However, in order to ensure that when a secure interface is required, such as when entering a bank account number and password, it is necessary to directly invoke the screen driver on the secure side when executing in the TEE.

According to an embodiment of the invention, a virtual docking method between different security levels is implemented. Specifically, the initialization of the environment on the REE side, whether it is a Container or a Hypervisor, is initiated and detected from the TEE side, wherein the TEE boots and initializes the Hypervisor, and the Hypervisor redirects and initializes the Container. Therefore, TEE is the basis of security and credibility, ensuring that the entire security guidance is based on authenticity and integrity verification.

Fig. 5 schematically shows a virtual docking mode between REE and TEE. On the REE side, both the Container and the Hypervisor environment are initialized and detected from the TEE side. The TEE boots and initializes the Hypervisor, and the Hypervisor redirects and initializes the Container. As a basis for security and credibility, TEE ensures that the entire security guidance is based on authenticity and integrity verification.

For DRM and iris, when DRM or iris TA performs safe operation, it borrows the driver module in Container of REE. When a call is completed, Hypervisor immediately controls the IO of DRM and iris camera. The prohibition is done by means of a mechanism similar to IOMMU or SMMU in the processor chip, ensuring that the control register REE OS of the driver cannot be tampered with during safe operation.

For the NFC driver, taking the offline payment as an example, the NFC driver is isolated and protected in a virtual machine on the hypervisor. It is expected that the key eSE driver is fully protected in the TEE, and it may exist with the highest security. The hierarchical SE performs direct interaction.

Other security-critical and IoT security critical positioning modules and driver module protection can be achieved through a similar solution.

Through the driving division method and the docking method of the invention, the protection methods and methods of the TEE for various types of driving are effectively solved. At present, other TEE vendors generally handle the migration of the drive system to the secure end or all of them in the REE. Although the design is simple and the security is relatively high, there is no corresponding analysis of the types and characteristics of the driver, resulting in serious defects in the implementation. Among the well-known TEE vendors, all of them are present. The driver migrated to the TEE, but it has not been implemented until now, because the driver and the system are closely related. Although it can completely protect the driver, it is an indisputable fact that it cannot be realized.

According to an embodiment of the invention, the TEE cryptographically encrypts the data to be transmitted to the REE side to ensure that the data flowing to the REE side is ciphertext. Therefore, the security of the TEE side is not tamperable and undetectable, and the security is transmitted to the receiver on the REE side, which ensures the higher security of the TEE operating environment and the entire multi-channel communication system.

The multi-channel communication system can also include a processor core scheduling unit. The processor core scheduling unit can schedule the processor cores within the TEE and between the TEE and the REE. The processor core scheduling unit checks the task load status of each processor core on the TEE side at intervals (for example, 100 ms), and processes according to the result of the check:

- In the case that the processor core task load on the TEE side is too high, the task load is transferred to other TEE side processor cores that are not task-loaded too much. After the transfer, the TEE side processor core is still too task-intensive. In this case, the processor core scheduling unit migrates the processor core on the REE side to the TEE side via the scheduling and control channel, and processes the TEE side task as the processor core on the TEE side;

- In the case where all tasks on the TEE side are in a blocked or suspended state, the processor core scheduling unit migrates all processor cores on the TEE side to the REE side via the scheduling and control channels to perform REE as the processor core on the REE side Side task

- In the case where the task on the TEE side is reduced and an idle processor core is present, the processor core scheduling unit migrates the idle processor core to the REE side via the scheduling and control channel to execute the REE side as the processor core on the REE side Task.

This approach maximizes the use of processor resources in the current system to ensure the benign operation of handlers in TEE and REE.

According to an embodiment of the present invention, in a case where the total task load of the TEE side processor core is too high, a processor core of the TEE side with a task overload may be requested to issue a request to the processor core scheduling unit, so that the processor core scheduling The unit checks the state of the processor core on the REE side and randomly selects the processor core in the suspended state to transfer to the TEE side to perform the task on the TEE side as the processor core on the TEE side, and the processor core scheduling unit will issue the request processing The tasks to be distributed of the core of the device are distributed to the newly transferred processor core on the TEE side for processing according to specific task rules, for example, in order of priority or in order of migration time.

As shown in FIG. 6, the processor core 2 acts as a dedicated task processing security task (Secure Task) on the TEE side, and periodically returns the processor core 2 to the REE through global scheduling, mainly in response to the inter-core scheduling and routine of the REE OS. Task and interrupt scheduling, the processor core 3 dynamically joins the TEE runtime environment according to the load of the TEE, and processes the Secure Task, which is the basic global scheduling method proposed by the present invention.

In still another embodiment of the present invention, the processor core scheduling unit uses a time slice based single core scheduling algorithm to schedule the core on the TEE side. Among them, each task is assigned a priority. Multiple processes alternately execute on the same TEE core, and N processes can execute simultaneously at any one time, but only one process is executing at any one time. If a process runs out of its own time slice, but has not yet completed it, then you need to switch the currently used core to other processes. The process that uses the time slice mentioned is interrupted by the time between the next round of processes. In the slice loop, when it belongs to its own time slice, it is switched back to the core to run. In the case where there are multiple cores in total for TEE and REE, the processor core scheduling unit can continue to execute the execution of the process running out of time slices by starting a new core, that is, by balancing the core load by enabling the new core. The new core is preferably a core that is idle in the TEE, or a core that is randomly selected from the idle cores in the REE and migrated from the REE side. To implement this embodiment, for example, HEFT (Heterogeneous-Earliest-Finish-Time) or CPOP (Critical-path-on-a-Processor) algorithm can be used.

In accordance with an embodiment of the present invention, a multi-channel communication system includes an interrupt control unit in the event that an interrupt is received by a processor core on the TEE side:

The interrupt control unit divides the interrupts that can only be handled by the processor core on the TEE side into the first group as interrupts, and divides the other interrupts in the interrupt into the second group as non-safe interrupts.

Next, you can do the following:

- the interrupt control unit hands over the safety interrupts in the first group to the processor core on the TEE side, and

The interrupt control unit transfers the non-secure interrupts in the second group to the processor core on the REE side via the scheduling and control channels.

Or proceed as follows:

The interrupt control unit determines whether the non-secure interrupt in the second group is an SPI (Share Peripheral Interrupt), a PPI (Private Interrupt), or a SGI (Soft Interrupt). If it is an SPI, the interrupt control unit indicates that the interrupt is received. The processor core of the TEE side discards it, and the interrupt control unit transfers the discarded SPI to the processor core on the REE side via the scheduling and control channel for processing; if it is PPI or SGI, the interrupt control unit notifies the processor The core scheduling unit, the processor core scheduling unit then transfers the processor core of the TEE side receiving the interrupt to the REE side via the scheduling and control channel to become the processor core of the REE side, and places the interrupted task in the corresponding The working queue is queued. After that, the processor core scheduling unit re-transfers the processor core of the REE side that receives the interrupt to the TEE side via the scheduling and control channel, thereby re-establishing it as the processor core on the TEE side. Waiting to receive other interrupts. For example, after the interrupt is placed in the work queue, the processor core scheduling unit immediately transfers the processor core on the REE side that received the interrupt back to the TEE side via the scheduling and control channel. The solution of this embodiment can discard a large number of SPIs and process them to other REE processor cores, which greatly reduces the number of times the TEE processor core switches back to the REE processor core for processing, thereby greatly improving the processing efficiency of the TEE.

Fig. 7 schematically shows the workflow of an interrupt control unit in accordance with an embodiment of the present invention. As shown in FIG. 7, in response to the TEE processor core receiving the interrupt, the interrupt control unit determines whether the interrupt is a secure interrupt FIQ or a non-secure interrupt IRQ, and puts the safety interrupt FIQ into one group and the other interrupt to another In the group. Based on the division of secure interrupts and non-secure interrupts, the interrupt needs to be handled in the TEE for secure interrupts, and other interrupts must be handled in other REE processor cores or in the REE processor core.

Due to the limited hardware resources on the TEE side, in order to improve the processing power of the TEE processor core, the interrupts that are not necessarily processed in the TEE side are generally allocated to the REE processor core for processing to reduce the TEE resource load. Therefore, dividing the interrupt received by the TEE core as above enables the processor core on the TEE side. The generated non-secure interrupt IRQ or the safety interrupt FIQ is scheduled to avoid excessive load on the TEE side processor core. In the next step, the safety interrupt FIQ can be left to the TEE processor core processing, and the non-secure interrupt IRQ is migrated to the REE side via the scheduling and control channel 105 to be added to the work queue by the REE processor core. Thereafter, the processor core is switched back to the TEE side by the interrupt control unit and continues to wait for other interrupts of the core.

In the optional next step, further distinguish between non-secure interrupt IRQ is shared peripheral interrupt SPI, private Interrupt PPI or soft interrupt SGI. The non-secure SPI can be discarded by the TEE core and taken over by the REE core through the scheduling and control channel 105. The SPI can be taken over by any processor core, and the interrupt PPI and soft interrupt SGI can only be processed by the TEE processor core that currently receives the interrupt, so the optimization of the processing of this part of the interrupt is to migrate the TEE processor core. Go to the REE side to handle the interrupt PPI and soft interrupt SGI as the REE processor core. Therefore, the interrupts that are not processed in the TEE processor core are distributed to the REE processor core as much as possible. Because the TEE processor core discards a large number of SPIs and processes them by other REE processor cores, the number of times that the TEE processor core switches back to the REE processor core is greatly reduced, thereby greatly improving the processing efficiency of the TEE.

FIG. 8 schematically illustrates an electronic device in accordance with an embodiment of the present invention. The electronic device has a multi-channel communication system and a network interface and a peripheral device interface according to an embodiment of the present invention, wherein a user can obtain an application via a network interface or a peripheral device interface and install on a multi-channel communication system, and the user can also run different application. The electronic device can be, for example, a mobile phone, a palmtop computer, a notebook computer, a desktop computer, a wearable smart communication device, or the like, any electronic device that is considered reasonable by those skilled in the art.

The present invention also relates to a multi-channel communication method designed to operate a multi-channel communication system in accordance with an embodiment of the present invention as described above.

The invention further relates to a computer program product having program code for causing execution of a multi-channel communication method in accordance with an embodiment of the present invention when the computer program is executed on a computer.

The invention further relates to a data carrier having program code of a computer program for causing execution of a multi-channel communication method in accordance with an embodiment of the present invention when the computer program is executed on a computer.

The present invention also relates to an electronic device having a drive dividing unit and a network interface and a peripheral device interface according to an embodiment of the present invention, wherein a user can obtain a drive via a network interface or a peripheral device interface, and drive the dividing unit to drive the The main drive is divided into a trusted execution environment or a normal execution environment.

The present invention also relates to an electronic device having a processor core scheduling unit and a network interface and a peripheral device interface according to an embodiment of the present invention, wherein a user can obtain an application via a network interface or a peripheral device interface, and run on the electronic device During application, the processor core scheduling unit schedules the processor cores within the trusted execution environment and between the trusted execution environment and the normal execution environment in accordance with the load state on the processor core of the trusted execution environment.

The invention further relates to a processor core scheduling method designed to run a processor core scheduling unit in accordance with an embodiment of the present invention.

The invention further relates to a computer program product having program code for causing execution of a processor core scheduling method in accordance with the present invention when the computer program is executed on a computer.

The invention further relates to a data carrier having program code of a computer program for causing execution of a processor core scheduling method in accordance with an embodiment of the present invention when the computer program is executed on a computer.

The present invention also relates to an electronic device having an interrupt control unit and a network interface and a peripheral device interface according to an embodiment of the present invention, wherein a user can obtain an application via a network interface or a peripheral device interface while the application is running on the electronic device The interrupt control unit schedules the interrupt between the processor core of the trusted execution environment and the processor core of the normal execution environment in accordance with the type of interrupt received by the processor core of the trusted execution environment.

The invention further relates to an interrupt control method designed to operate an interrupt control unit in accordance with an embodiment of the present invention.

The invention further relates to a computer program product having program code for causing execution of an interrupt control method according to an embodiment of the invention when executing a computer program on a computer.

The invention further relates to a data carrier having program code of a computer program for causing execution of an interrupt control method according to an embodiment of the invention when the computer program is executed on a computer.

The above is only the specific embodiment of the present disclosure, but the scope of the present disclosure is not limited thereto, and any person skilled in the art can easily think of changes or substitutions within the technical scope of the disclosure, and should cover It is within the scope of protection of the present disclosure. Therefore, the scope of protection of the disclosure should be determined by the scope of the claims.

List of reference signs

REE normal execution environment

TEE Trusted Execution Environment

SE safety element

100 multi-channel communication system

101 REE

102 TEE

103 application channel

104 drive channel

105 scheduling and control channels

DRM Digital Copyright Protection

NFC short-range wireless communication

IRQ non-secure interrupt

FIQ security interrupt

SPI shared peripheral interrupt

PPI private interrupt

SGI soft interrupt

eSE Embedded Security Unit

Claims

A communication system for communication between a general execution environment and a trusted execution environment,

among them,

The communication system includes: a general execution environment and a trusted execution environment,

among them,

The trusted execution environment is isolated from the normal execution environment;

An operating system and an application can be run in both the trusted execution environment and the normal execution environment.

The communication system also includes a processor core scheduling unit,

The processor core scheduling unit checks the task load of each processor core of the trusted execution environment at intervals:

If the processor core task of the trusted execution environment is overloaded, transfer its task load to other untrusted trusted execution processor cores, if the trusted execution environment processor core is global after the transfer If the task load is too high, the processor core scheduling unit migrates the processor core of the normal execution environment to the trusted execution environment via the scheduling and control channel as the processor core of the trusted execution environment. To handle the tasks of the trusted execution environment,

If all tasks of the trusted execution environment are in a blocked or suspended state, the processor core scheduling unit migrates all processor cores of the trusted execution environment to the normal execution environment via the scheduling and control channel, Perform the tasks of a normal execution environment with a processor core that acts as a normal execution environment.

If the task of the trusted execution environment is reduced and an idle processor core is present, the processor core scheduling unit migrates the idle processor core to the normal execution environment via the scheduling and control channel as a normal execution environment The processor core performs the tasks of a normal execution environment.
The communication system according to claim 1, wherein said processor core scheduling unit checks a task load condition of each processor core of said trusted execution environment every set time.
The communication system according to claim 2, wherein said set time is 100 ms.
A communication system according to at least one of claims 1 to 3, wherein if the trusted execution environment processor core overall task load is too high, the processor core of the trusted execution environment having a high task load is directed to the processing The core scheduling unit issues a request to cause the processor core scheduling unit to check the processing of the normal execution environment The state of the core and randomly select the pending processor core to transfer to the trusted execution environment to perform the task of the trusted execution environment as the processor core of the trusted execution environment, and the processor core scheduling unit will issue the request for processing The tasks to be distributed by the core of the kernel are distributed to the processor core of the new trusted execution environment for processing according to specific task rules.
The communication system according to at least one of claims 1 to 4, wherein the communication system further comprises an interrupt control unit, if the processor core of the trusted execution environment receives an interrupt, the interrupt control unit Interrupts that can only be handled by the processor core of the trusted execution environment are divided into the first group as security interrupts, and other interrupts are divided into the second group as non-secure interrupts.
The communication system according to claim 5, wherein

The interrupt control unit hands the first set of security interrupts to the processor core of the trusted execution environment, and

The second set of non-secure interrupts are transferred to the processor core processing of the normal execution environment via the scheduling and control channel.
The communication system according to claim 5, wherein

The interrupt control unit hands the first set of security interrupts to the processor core of the trusted execution environment, and

The interrupt control unit determines whether the non-secure interrupt in the second group is a shared peripheral interrupt, a private interrupt, or a soft interrupt.

If it is a shared peripheral interrupt, the interrupt control unit instructs the processor core of the trusted execution environment that received the interrupt to discard it, and the interrupt control unit transfers the discarded shared peripheral interrupt via the dispatch and control channel Processing to a processor core of the general execution environment;

If it is a private interrupt or a soft interrupt, the interrupt control unit notifies the processor core scheduling unit, which then transfers the processor core of the trusted execution environment receiving the interrupt to the normal execution via the dispatch and control channel. The environment thus becomes the processor core of the normal execution environment, and the interrupted tasks are queued in the work queue.
The communication system of claim 7 wherein said processor core scheduling unit is operative to schedule a processor core within a trusted execution environment and between a trusted execution environment and a normal execution environment,

After the task of the private interrupt or the soft interrupt is placed in the work queue, the processor core scheduling unit re-processes the processor core of the normal execution environment that receives the interrupt via the scheduling and control channel. Transfer back to the trusted execution environment, causing it to re-enter the processor core of the trusted execution environment to wait for other interrupts to be received.
A communication system according to any one of claims 1-8, wherein

The communication system further includes: an application channel and a drive channel disposed between the normal execution environment and the trusted execution environment,

among them,

The application channel is for communication between the normal execution environment and an application of the trusted execution environment;

The drive channel is for operating communication between the normal execution environment and the drive of the trusted execution environment.
The communication system according to claim 9, wherein said application channel, said drive channel, and said scheduling and control channel are respectively disposed in a shared memory between said normal execution environment and said trusted execution environment, Independent of the shared memory of different channels.
The communication system according to claim 9, wherein said application channel, said drive channel, and said scheduling and control channel each comprise a forward channel and a reverse channel, wherein said forward channel is for said A message in a send queue of a normal execution environment is transmitted to a receive queue of the trusted execution environment, the reverse channel being configured to transmit a message in a send queue of the trusted execution environment to the normal execution environment In the receive queue.
The communication system according to claim 11, wherein a message type and a message content of a message to be transmitted or received are stored in respective transmission queues and reception queues of said normal execution environment and said trusted execution environment, thereby Channels that match the message type send or receive individual messages.
The communication system of claim 9 wherein said general execution environment is capable of running a client application, a host driver, a virtual driver and/or a processor core, wherein said trusted execution environment is capable of running a trusted application , main drive, virtual drive and / or processor core.
The communication system of claim 13 wherein the drive channel is configured to communicate between the virtual drive and the host drive between the normal execution environment and the trusted execution environment to enable Drive sharing between the normal execution environment and the trusted execution environment.
The communication system according to claim 14, wherein

In the case that the normal execution environment invokes a specific driver, if there is a main driver of the driver in the trusted execution environment and the virtual driver of the driver exists in the normal execution environment, the normal execution environment calls the driver. a virtual drive disposed in the normal execution environment, thereby triggering information related to the drive to be sent to a corresponding primary drive of the trusted execution environment via a forward channel of the drive channel, and the primary drive is invoked and Returning the processed information to the virtual drive of the normal execution environment via the reverse channel of the drive channel, and

In the case that the trusted execution environment invokes a specific driver, if there is a virtual driver of the driver in the trusted execution environment and a host driver of the driver exists in the normal execution environment, the trusted execution environment invokes a virtual drive of the drive disposed in the trusted execution environment, thereby triggering information related to the drive to be sent to a corresponding main drive of the normal execution environment via a reverse channel of the drive channel, and the host drive is further The information obtained and processed is returned to the virtual drive of the trusted execution environment via the forward channel of the drive channel.
An electronic device, comprising: the communication system according to any one of claims 1 to 15, and a network interface and a peripheral device interface, wherein a user can obtain an application via the network interface or a peripheral device interface and The application is installed in the communication system, and the user can also run different applications by means of the communication system.