CN106547633B

CN106547633B - Multi-channel communication system and electronic device

Info

Publication number: CN106547633B
Application number: CN201610913379.4A
Authority: CN
Inventors: 孟庆洋; 高峰; 王锡廷; 张强
Original assignee: Shenyang Micro Trust Technology Co Ltd
Current assignee: Shenyang Micro Trust Technology Co Ltd
Priority date: 2016-10-19
Filing date: 2016-10-19
Publication date: 2019-12-31
Anticipated expiration: 2036-10-19
Also published as: CN106547633A; WO2018072714A1

Abstract

The invention relates to a multi-channel communication system and an electronic device. In particular a multi-channel communication system for communication between a normal execution environment and a trusted execution environment, the multi-channel communication system comprising: a normal execution environment and a trusted execution environment, wherein the trusted execution environment is isolated from the normal execution environment; an operating system and applications can run in both the trusted execution environment and the common execution environment, and the multi-channel communication system further comprises: the application channel, the driving channel and the scheduling and controlling channel are arranged between the ordinary execution environment and the trusted execution environment, wherein the application channel is used for communication between application programs of the ordinary execution environment and the trusted execution environment; the drive channel is used for running communication between the drives of the common execution environment and the trusted execution environment; and, the scheduling and control channel is to schedule and control communication of commands between the normal execution environment and the trusted execution environment.

Description

Multi-channel communication system and electronic device

Technical Field

The present invention relates to a multi-channel communication system for communication between a normal execution environment and a trusted execution environment and an electronic device applying the communication system.

Background

The basic idea of a trusted Execution environment tee (trusted Execution environment) or secure runtime environment (safe runtime environment) is that: besides the ordinary operating system, a safety operating system is provided and is isolated from the ordinary operating system, and the safety operating system runs on an isolated hardware basis, and the safety operating system is called TEE. It is known that a protected area can be generated in a microprocessor unit as a TEE by ARM trusted zone (trust zone) technology. The TEE is used to run an application called a trusted applet (trustlet). The ARM already supports the TEE comprehensively in the chip IP design, and the high-pass, the joint department, the Samsung, the Haesi, the spread message and the like all support the TEE on hardware at present. Similar solutions have been proposed in the Intel X86 architecture and the Imagination MIPS architecture. The common problem of these solutions is that the channel between the common execution environment REE and the trusted execution environment TEE is implemented in a single channel, so that the channel design is complex, the maintenance difficulty is high, and the communication efficiency is low.

Disclosure of Invention

The technical problem to be solved by the invention is to realize simplified and efficiency-improved communication between the common execution environment and the trusted execution environment.

To solve the technical problem, the present invention proposes a multi-channel communication system for communication between a general execution environment and a trusted execution environment, the multi-channel communication system comprising: a normal execution environment and a trusted execution environment, wherein the trusted execution environment is isolated from the normal execution environment; an operating system and applications can run in both the trusted execution environment and the common execution environment, and the multi-channel communication system further comprises: the application channel, the driving channel and the scheduling and controlling channel are arranged between the ordinary execution environment and the trusted execution environment, wherein the application channel is used for communication between application programs of the ordinary execution environment and the trusted execution environment; the drive channel is used for running communication between the drives of the common execution environment and the trusted execution environment; and, the scheduling and control channel is to schedule and control communication of commands between the normal execution environment and the trusted execution environment.

In an embodiment of the present invention, the application channel, the driver 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 are used for mutual independence between shared memories of different channels.

In one embodiment of the invention, the application channel, the driving channel and the scheduling and control channel respectively comprise a forward channel and a backward channel, wherein the forward channel is used for transmitting the messages in the sending queue of the common execution environment to the receiving queue of the trusted execution environment, and the backward channel is used for transmitting the messages in the sending queue of the trusted execution environment to the receiving queue of the common execution environment.

In one embodiment of the invention, the message type and the message content of the message to be sent or received are stored in the sending queue and the receiving queue of the common execution environment and the trusted execution environment respectively, so that each message is sent or received through a channel conforming to the message type.

In one embodiment of the invention, the application channel carries a standard application protocol.

In one embodiment of the invention, a client application, a main driver, a virtual driver and/or a processor core can run in a common execution environment, and a trusted application, a main driver, a virtual driver and/or a processor core can run in a trusted execution environment.

In one embodiment of the invention, the driver channel is constructed for communicating between the virtual driver and the host driver between the normal execution environment and the trusted execution environment to enable driver sharing between the normal execution environment and the trusted execution environment.

In one embodiment of the invention, in the case that the normal execution environment calls a specific driver, if a host driver of the driver exists in the trusted execution environment and a virtual driver of the driver exists in the normal execution environment, the normal execution environment calls the virtual driver of the driver, which is set in the normal execution environment, so as to trigger information related to the driver to be sent to a corresponding host driver of the trusted execution environment via a forward channel of a driving channel, and then the host driver is called and returns processed information to the virtual driver of the normal execution environment via a backward channel of the driving channel, and in the case that the trusted execution environment calls the 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 execution environment calls the virtual driver of the driver, which is set in the trusted execution environment, and triggering information related to the drive to be sent to a corresponding main drive of the common execution environment through a backward channel of the drive channel, and then calling the main drive and returning the processed information to the virtual drive of the trusted execution environment through a forward channel of the drive channel.

In one embodiment of the invention, a multi-channel communication system includes: the dividing unit is driven to divide the image into a plurality of image portions,

the drive dividing unit performs the steps of:

evaluating the security of drivers to be run on the multi-channel communication system,

if the safety of the driver is higher than a first safety threshold value, dividing the main driver of the driver into a trusted execution environment, and setting a virtual driver of the driver in a common execution environment;

if the safety of the driver is below a second safety threshold, dividing the main driver of the driver into a common execution environment, and setting a virtual driver of the driver in a trusted execution environment;

checking the availability and realizability of the drive if the safety of the drive lies between the first safety threshold and the second safety threshold;

if the availability is below the availability threshold and the realizability is above the realizability threshold, then the host driver of the driver is partitioned to the trusted execution environment and the virtual driver of the driver is set at the normal execution environment, otherwise the driver is partitioned to the normal execution environment and the virtual driver of the driver is set at the trusted execution environment.

In one embodiment of the present invention, the driving dividing unit:

dividing main drivers of a DRM driver, a camera driver, a network driver, a GPS driver and a storage driver into common execution environments; and/or

Dividing main drives of drives related to data transmission and data analysis in the iris drives into a credible execution environment, and dividing main drives of other drives in the iris drives into a common execution environment; and/or

Dividing a main drive of the NFC drive into common execution environments; and/or

Dividing a main drive of a drive related to data transmission and data analysis in the fingerprint drive into a trusted execution environment, and dividing a main drive of a drive related to shared peripheral interrupt initiation in the fingerprint drive into a common execution environment; and/or

Partitioning the SE drivers into trusted execution environments; and/or

A main driver supporting a driver of a Trusted User Interface (TUI) is provided in a normal execution environment as well as in a trusted execution environment.

In one embodiment of the invention, the security of the normal execution environment is lower than that of the trusted execution environment, and the normal execution environment comprises a security level Hypervisor and a security level Container with the security lower than the Hypervisor, wherein the Hypervisor and the Container are isolated from each other.

In one embodiment of the invention, context initialization of both the Container and the Hypervisor in the normal execution environment is initiated and detected from the trusted execution environment, wherein the trusted execution environment boots and initializes the Hypervisor, which reboots and initializes the Container.

In one embodiment of the invention, the trusted execution environment cryptographically encrypts data to be transferred to the normal execution environment to ensure that data flowing to the normal execution environment is ciphertext.

In one embodiment of the invention, a multi-channel communication system includes: a scheduling unit of the processor core is provided,

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

if the task load of the processor core of the trusted execution environment is too high, transferring the task load of the too high part of the processor core of the trusted execution environment to other processor cores of the trusted execution environment which are not too high in task load, and if the overall task load of the processor cores of the trusted execution environment is still too high after transferring, the processor core scheduling unit transfers the processor core of the common execution environment to the trusted execution environment through the scheduling and control channel to be used as the processor core of the trusted execution environment to process the task 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 ordinary execution environment via the scheduling and control channel, so as to execute the tasks of the ordinary execution environment as the processor cores of the ordinary execution environment,

if the tasks of the trusted execution environment are reduced and an idle processor core appears, the processor core scheduling unit transfers the idle processor core to the ordinary execution environment through the scheduling and control channel so as to be used as the processor core of the ordinary execution environment to execute the tasks of the ordinary execution environment.

In one embodiment of the invention, the processor core scheduling unit checks the task load condition of each processor core of the trusted execution environment every set time (such as 100 ms).

In one embodiment of the invention, if the overall task load of the processor cores of the trusted execution environment is too high, a request is sent to the processor core scheduling unit by the processor cores of the trusted execution environment with too high task load, so that the processor core scheduling unit checks the state of the processor cores of the ordinary execution environment and randomly selects the processor core in the suspended state to be transferred to the trusted execution environment to serve as the processor core of the trusted execution environment to execute the tasks of the trusted execution environment, and the processor core scheduling unit distributes the tasks to be distributed of the processor cores which send the request to the processor cores of the newly transferred trusted execution environment according to a specific task rule for processing.

In one embodiment of the invention, a multi-channel communication system includes an interrupt control unit that, if an interrupt is received by a processor core of a trusted execution environment, divides the interrupt that can only be processed by the processor core of the trusted execution environment into a first group as a secure interrupt and divides other interrupts into a second group as non-secure interrupts.

In one embodiment of the invention, the interrupt control unit hands a first set of secure interrupts to be processed by a processor core of the trusted execution environment and transfers a second set of non-secure interrupts to be processed by a processor core of the normal execution environment via the dispatch and control channel.

In one embodiment of the invention, the interrupt control unit hands the secure interrupts of the first set to a processor core of the trusted execution environment, and the interrupt control unit determines whether the non-secure interrupts in the second set are shared peripheral interrupts, private interrupts, or soft interrupts:

if the interrupt is the shared peripheral interrupt, the interrupt control unit instructs the processor core of the trusted execution environment which receives the interrupt to discard the interrupt, and the interrupt control unit transfers the discarded shared peripheral interrupt to the processor core of the common execution environment for processing through the scheduling and control channel;

if the interrupt is a private interrupt or a soft interrupt, the interrupt control unit informs the processor core scheduling unit, and the processor core scheduling unit then transfers the processor core of the trusted execution environment which receives the interrupt to the normal execution environment via the scheduling and control channel to become the processor core of the normal execution environment, and queues the task of the interrupt in the work queue.

In one embodiment of the invention, the processor core scheduling unit is configured to schedule the processor cores inside the trusted execution environment and between the trusted execution environment and the 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 re-transfers the processor core of the normal execution environment receiving the interrupt back to the trusted execution environment via the scheduling and control channel, thereby making it become the processor core of the trusted execution environment again to wait for receiving other interrupts.

The invention also proposes an electronic device, characterized in that it comprises: according to the multi-channel communication system and the network interface and the peripheral device interface of the invention, a user can obtain an application through the network interface or the peripheral device interface and install the application in the multi-channel communication system, and the user can run different applications through the multi-channel communication system.

By the method and the device, different channels can be concurrent, and the client application arranged at the REE end and the trusted application arranged at the TEE end in the same channel are called without waiting for the returned result, so that concurrent operation is really realized.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings needed to be used in the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art that other drawings can be obtained according to the drawings without creative efforts. Wherein:

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

Fig. 2 schematically shows an embodiment of the drive channel according to the invention.

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

Fig. 4 schematically shows the security hierarchy of a multi-channel communication system according to the invention.

Fig. 5 schematically illustrates a virtual docking manner between the REE and the TEE.

Fig. 6 schematically shows a schematic diagram of the way a core scheduling unit according to the present invention works.

Fig. 7 schematically shows the workflow of the interrupt control unit according to the invention.

Fig. 8 schematically shows an electronic device according to the invention.

For the sake of overview, elements that are the same or equivalent are designated by the same reference numeral throughout the drawings. The figures are merely schematic, in which elements are not necessarily to scale.

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, not all, embodiments of the present invention.

According to an embodiment of the present invention, a multi-channel communication system for communication between a REE and a TEE is presented. The multi-channel communication system comprises an REE and a TEE isolated from the REE, wherein an operating system and an application run in both the TEE and the REE, for example, a client application, a main driver, a virtual driver and/or a processor core run on the REE side, and a trusted application, a main driver, a virtual driver and/or a processor core run on the TEE side; also included are application channels, driver channels, and scheduling and control channels disposed between the REE and the TEE. Wherein the application channel is structured for communication of the application between the REE and the TEE; the drive channel is constructed for communication between drives for operation between the REE and the TEE; and, the scheduling and control channel is structured for communication between the REE and the TEE for scheduling and control commands.

According to an embodiment of the present invention, the application channel, the driver channel, and the scheduling and control channel are isolated from each other and are capable of parallel communication. Therefore, various safety problems of biological identification, mobile payment, digital copyright protection, safe positioning, Internet of things safety and the like can be simultaneously and efficiently solved on one mobile terminal.

In contrast, the single channel structure has the disadvantages that:

(1) the structural design of the channel is complex. Because a single channel is used, the TEE side needs to analyze the information of the REE side, and the loader communicates with the access object corresponding to the TEE side. On the contrary, if the TEE side has an application to call the programs, drivers, etc. of the REE side, communication can be performed only through the channel. The channel is used for data structures of driving, applying, scheduling and other operations, and the inclusion of multiple data types in one communication brings great difficulty to design and implementation.

(2) The method does not conform to the low-coupling software design idea, and has great difficulty in maintenance and upgrading. Upgrading of the channel may cause mutual influence of corresponding modules, and errors are easily generated.

(3) The efficiency is low. The single channel cannot realize concurrent processing of different types such as data processing and driving.

According to the embodiment of the invention, as for the application channel, the driving channel and the scheduling and control channel, the shared memories respectively arranged between the REE side and the TEE side are mutually independent. By sharing the memory, the REE and the TEE realize the transfer of different data types in different channels.

In other words, the shared memory for implementing different channels is a memory portion that is disposed on the REE side and can be shared with the TEE, belongs to an untrusted memory (the memory disposed on the TEE side is a trusted memory that is not accessible by the REE side), and mutual independence between the memories of different channels can be implemented by means of logical partitioning. For example, fixed and mutually independent memory regions may be divided for different channels, or the memory regions allocated to the channels may be adjusted as needed in each operation, and after each adjustment, the independence between the channels is still ensured by the logical division.

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

firstly, loading data into shared memories of different channels; then, reading data at the REE or TEE side; next, on the REE or TEE side, data is identified and encapsulated into different data structures according to the data type, and then the data is placed in a corresponding work queue to be processed.

Since the memories for the different channels are independent of each other, the virtual "channels" are naturally also isolated from each other. In this way, different types of data are transferred via dedicated channels, full concurrency is achieved, and a "multi-TEE" architecture is enabled, i.e. simultaneous communication of multiple virtual machines virtualized on the TEE side.

According to the embodiment of the invention, the application channel, the driving channel and the scheduling and control channel can adopt a simplex mode respectively and respectively comprise a forward channel and a backward channel, wherein the forward channel is used for transmitting the message in the sending queue of the REE side to the receiving queue of the TEE side, and the backward channel is used for transmitting the message in the sending queue of the TEE side to the receiving queue of the REE side. This further improves the "concurrency" and reduces the probability of errors in the data transmission. The application channel, the driving channel and the scheduling and control channel can also adopt a half-duplex or duplex communication mode, and correspondingly, the forward channel and the reverse channel can also be virtual channels and can be realized by switching or competition.

According to the embodiment of the present invention, the message type and the message content of the message to be transmitted or received are stored in the respective transmission queue and reception queue of the REE side and the TEE side, so that each message is transmitted or received via a channel conforming to the message type. In this way, the division of the messages to be transmitted into the correct channels can be achieved in a simple manner.

According to an embodiment of the present invention, the application channel carries a standard application protocol, such as a Client API conforming to the GPTEE note 1 standard.

According to an embodiment of the present invention, the drive channels are constructed for communication between the virtual drive and the master drive between the REE and the TEE to enable drive sharing between the REE and the TEE.

The scheme of the embodiment of the invention takes the TEE technology as the core, faces to but is not limited to a processor chip supporting ARMTrutzone expansion, and can simultaneously and efficiently solve various safety problems of biological identification, mobile payment, digital copyright protection, safe positioning, Internet of things safety and the like on one mobile terminal through the multi-level operation method provided by the invention.

The architecture of a TEE can be roughly divided into three layers, including a hardware layer, a TEE OS (operating system) layer, and a TA (Trusted Application) layer. The multi-channel communication system according to the embodiment of the invention is realized at a 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 an REE 101 and a TEE 102 isolated from the REE 101, wherein an operating system and applications run in both the TEE 102 and the REE 101, for example, a client application, a master driver, a virtual driver and/or a processor core run on the REE 101 side, and a trusted application, a master driver, a virtual driver and/or a processor core run on the TEE 102 side.

The tee (managed execution environment) is a secure execution environment, which is isolated from the common execution environment (REE), and the operating system and the application can be respectively run in the two execution environments. Requiring a channel to be provided between the TEE and the REE for data transfer.

Thus, the multi-channel communication system 100 further includes an application channel 103, a driver channel 104, and a dispatch and control channel 105 disposed between the REE 101 and the TEE 102, wherein the application channel 103 is structured for communication between applications in the REE 101 and the TEE 102; drive channel 104 is configured for communication between drives running in REE 101 and TEE 102; and, the scheduling and control channel 105 is structured for scheduling and controlling communication of commands between the REE 101 and the TEE 102.

The application channel 103 may provide a specified interface for APP of an application vendor, and as long as the interface is followed, the vendor may apply registered APP to the present platform, wherein APP with high security may be placed on the TEE side according to the present invention. Admission authority for APP installed on the TEE side is generally negotiated between the trusted application developer and the equipment vendor, TEE provider, at the factory stage of the device, and is verified by signature.

Due to the difference of the types and the sizes of the occupied resources of the drivers, the communication between the host driver and the virtual driver can be realized through the driver channel 104. Different drives can be flexibly set to be saved on the TEE side or the REE side. The drives which occupy more resources and have more migration difficulty can be retained on the REE side. While on the TEE side, drivers that occupy less resources and require higher security levels can be saved.

With respect to the dispatch channel, current trusted execution environments do not have a dispatch of resources. For example, in the current TEE, a designated processor core is generally allocated to be responsible for running TEE-related services and tasks (tasks), and because the current TEE has less protection contents to be run, the processing capacity of a single core can also be handled. However, as the demand for TEE expands, the use of iris, DRM, and other related applications causes a significant increase in the load on the TEE side. Therefore, a reasonable scheduling of resources is essential. None of the currently known TEE vendors implement processor scheduling between REEs and TEEs.

In one embodiment of the invention, the application channel 103, the driver channel 104, and the scheduling and control channel 105 may be the same channel. In this embodiment, the TEE employs a macro-kernel or sandbox architecture, which, based on its own features, is that the kernel object is associated with only one process, resulting in communication between the TEE and the REE being able to communicate only through a single channel. In particular, sandbox is a secure mechanism to separate running programs, often for executing untested code or third party untrusted programs. The sandbox can generally provide a set of tightly controlled resource sets for a user to ensure the running of the program, can provide a virtual system environment for the user APP, and even if errors occur in the program running in the sandbox environment, the local temporary resources are only modified and damaged, and the system can not be crashed. The sandbox works originally by only comprising one sandbox to operate at the same time, and only one trusted application TA can be simultaneously operated in the TEE under the condition that the virtualization technology is not supported and the mechanism of the sandbox.

However, this single, shared channel implementation has the following features: (1) the structural design of the channel is complex. Because a single channel is used, the TEE side needs to analyze the information of the REE side, and the loader communicates with the access object corresponding to the TEE side. On the contrary, if the TEE side has an application to call the programs, drivers, etc. of the REE side, communication can be performed only through the channel. The channel is used for data structures of driving, applying, scheduling and other operations, and the inclusion of multiple data types in one communication brings great difficulty to design and implementation. (2) The method does not conform to the low-coupling software design idea, and has great difficulty in maintenance and upgrading. Upgrading of the channel may cause mutual influence of corresponding modules, and errors are easily generated. (3) The efficiency is low. The single channel cannot realize concurrent processing of different types such as data processing and driving.

According to yet another embodiment of the invention, the application channel 103, the drive channel 104 and the scheduling and control channel 105 are isolated from each other and can be concurrent. The application channel 103 is responsible for communication between a Client APP (a Client application on the REE side) and a Trusted APP (a Trusted application on the TEE side), and the application channel 103 mainly carries a standard application protocol (such as a Client API conforming to the GPTEE note 1 standard); the drive channel 104 is responsible for communication between the main and virtual drives of the REEs and TEEs; the driving channel 104 bears communication interfaces of various types of drives, and the method adopts a driving virtual docking method to complete the driving sharing between the REE and the TEE; the scheduling and control channel 105 carries scheduling class and control class commands between REEs and TEEs.

The channels isolated from each other are realized by virtualization technology. Specifically, this is achieved by providing shared memories between the REE side and the TEE side for the application channel 103, the driver channel 104, and the scheduling and control channel 105, respectively, the shared memories for the different channels being independent of each other. The application channel 103, the driving channel 104, and the scheduling and control channel 105 each include a forward channel for transmitting a message in a transmission queue of the REE side to a reception queue of the TEE side, and a backward channel for transmitting a message in a transmission queue of the TEE side to a reception queue of the REE side. The message type and the message content of the message to be sent or received are stored in the sending queue and the receiving queue of the REE side and the TEE side respectively, so that each message is sent or received through a channel conforming to the message type. Thus, when the message is transmitted through multiple channels, the message can be correctly transmitted to the REE or the TEE through different channels according to types. There are separate threads for message queues of CA (Client Application) and TA (Trusted Application) to handle the content in the queues. Through the scheme of the embodiment, different channels can be concurrent, and the calling of the CA and the TA in the same channel does not need to wait for the returned result, so that the concurrent operation is really realized.

The mutually isolated multiple channels of the present invention support concurrent calls. By using the virtualization techniques described above, multiple virtual machines may be virtualized on one TEE, creating execution spaces for different TAs. For example, a plurality of CAs disposed on the REE side may call a plurality of TAs disposed on the TEE side at the same time, a plurality of drivers may share one another at the same time, and so on. The characteristics of the virtual machine are isolation and safety, and meanwhile, safety isolation can be achieved. The scheme of the embodiment really realizes the multi-channel concurrency technology and is in the leading position on the performance and the expandability of the system. Through the multi-level operation method provided by the embodiment, various safety problems such as biological identification, mobile payment, digital copyright protection, safe positioning, Internet of things safety and the like can be simultaneously and efficiently solved on one mobile terminal.

Compared with the technical scheme which does not support virtualization, the mutually isolated multiple channels of the invention also realize greater safety. The protection level and level on the TEE side have obvious advantages compared with the existing TEE software products.

Data exchange between a TEE and a REE can be done in a number of ways, 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 allow for efficient control of driving and scheduling. The support of multiple TEEs based on virtualization is the greatest advantage of the isolated multiple channels of the present invention over other TEE vendors. Currently, other manufacturers do not support multiple TEEs.

FIG. 2 illustrates a drive channel according to one embodiment of the present invention. As shown in FIG. 2, the drive channel 104 is structured for communication between the virtual drive and the master drive between the REE and the TEE to enable drive sharing between the REE and the TEE.

The calling of the driver is realized by means of virtual docking. The main driver and the virtual driver can be distributed in different execution environments according to the characteristics of the drivers. That is, a main driver of a driver is set in one execution environment, and a virtual driver of the driver is set in another execution environment. For example, the file system driver is placed in the REE and the FP driver is placed in the TEE. The driving division is further described below.

In the case where a specific drive is called on the REE side, if there is only a virtual drive of the drive on the REE side and a master drive of the drive on the TEE side, the REE calls the virtual drive of the drive provided on the REE side, thereby triggering information related to the drive to be transmitted to the corresponding master drive on the TEE side via a forward channel of a drive channel, and further the master drive is called and returns the processed information to the virtual drive on the REE side via a reverse channel of the drive channel.

In the case that a specific drive is called by the TEE side, if only a virtual drive of the drive exists on the TEE side and a main drive of the drive exists on the REE side, the TEE calls the virtual drive of the drive arranged on the TEE side, so that information related to the drive is triggered to be sent to the corresponding main drive on the REE side through a reverse channel of a drive channel, and the main drive is called and returns the processed information to the virtual drive on the TEE side through a forward channel of the drive channel.

In this way, the application can invoke any drive on either the REE side or the TEE side without feeling the transition between the REE and TEE. Taking the fingerprinting application as an example, the fingerprint driver is invoked on the REE side, while the main, or true, driver of the driver is located on the TEE side. In other words, the fingerprint driver is called on the REE side to acquire fingerprint information, while the REE side does not have a real fingerprint driver, but defines an interface for operating fingerprints on the REE side in a virtualization manner.

According to the multi-channel communication system, the virtualized fingerprint interface at the REE side is called, the information of the fingerprint interface is actually transmitted to the TEE through the forward channel of the driving channel 104, the TEE side obtains the relevant fingerprint information through calling the real fingerprint interface, then the information is sent to the REE side through the reverse driving channel, and the REE obtains the relevant fingerprint result. The CA on the REE side does not perceive that the call driven is actually a switch between the two execution environments. The information communication is realized by combining a driving channel in a virtualization mode.

Various hardware loaded on the terminal and security services provided by the hardware, such as fingerprint identification, iris identification, DRM (Digital Rights Management), NFC, etc., have their own drivers, and the driver division is on the REE side or the TEE side. The invention provides a method for dividing a drive based on the requirement degree of safety and usability and an implementation method adopting a virtual docking mode.

According to one embodiment of the present invention, a multi-channel communication system includes a driving dividing unit. Fig. 3 schematically shows the workflow of the drive dividing unit. The drive dividing unit performs the steps of:

in step 301, evaluating the security of a driver to be run on a multi-channel communication system; under the condition that the safety of the drive is above a first safety threshold, dividing the main drive of the drive to a TEE side in step 302, and setting a virtual drive of the drive on a REE side; under the condition that the safety of the drive is below a second safety threshold, dividing the main drive of the drive to the REE side in step 303, and setting the virtual drive of the drive on the TEE side; on the condition that the safety of the drive lies between the first safety threshold and the second safety threshold, the availability and the realizability of the drive are checked in step 304, if the availability is below the availability threshold and the realizability is above the realizability threshold, the primary drive of the drive is divided into the TEE side and the virtual drive of the drive is set in the REE side in step 305, otherwise the primary drive of the drive is divided into the REE side and the virtual drive of the drive is set in the TEE side in step 306.

The division mode takes safety, usability and realizability into consideration. Specifically, the method comprises the following steps:

security & availability considerations: the partitioning is done from the security aspect of the driving resources. For drivers with strong safety requirements, the TEE side division is approached, wherein safety is the first standard and is the main purpose of establishing a separate TEE, so the drivers with safety higher than a threshold value are divided into the TEE side; compared with the situation that the demand for availability is more for safety, the REE side division is tended, and safety is ensured by utilizing a virtual interface mode of REE and TEE. For example, a fingerprint Driver commonly used in a terminal device at present has a strong security requirement, so a main Driver (Host Driver) of a fingerprint is divided into a TEE, and a virtual (Virtualized) Driver interface is reserved in the REE for the REE to use; for example, the drive system of the storage and network is larger, and the demand for availability is more relative to the safety, so that the main drive is divided into an REE side, and a virtual drive interface is reserved on a TEE side.

-realisability: the protection for some special drives and operations cannot be considered only in terms of safety, and technical realizability needs to be considered comprehensively. Such as DRM (digital rights management) driver, NFC (near field communication) driver and iris camera driver, it is characterized in that the driving system is larger and difficult to be completely migrated into TEE and has a certain degree of security requirement. For the drivers, considering the technical realizability, the drivers can be divided into REE sides, and for the safety of the drivers, the invention utilizes the virtualization technology and the container technology in the REE to protect the driving resources.

According to an embodiment of the present invention, the drive dividing unit divides main drives of the DRM drive, the camera drive, the network drive, the GPS drive, and the storage drive to the REE side; dividing main drives of partial drives related to data transmission and data analysis in the iris drives into a TEE side, and dividing main drives of other partial drives in the iris drives into a REE side; dividing a main drive of the NFC drive to an REE side; dividing a main drive of a partial drive related to data transmission and data analysis in the fingerprint drive into a TEE side, and dividing a main drive of a partial drive initiated by a related SPI interrupt (shared peripheral interrupt) in the fingerprint drive into a REE side; dividing SE (secure element) drive to TEE side; and setting main drivers supporting driving of the TUI (trusted user interface) on the REE side and the TEE side. This division takes into account the security level requirements as well as the protection level of the overall architecture. The drive supporting the TUI includes an LCD drive, a touch screen drive, and an I2C drive.

Fig. 4 schematically shows the security hierarchy of a multi-channel communication system according to the invention. REE is less secure than TEE, and comprises a security level Hypervisor and a security level Container which is less secure than Hypervisor, wherein Hypervisor and Container are isolated from each other, and REE and TEE are isolated from each other.

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

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

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

If the drivers are divided for these security levels according to the security level of the driver and the requirement of the security of the whole architecture, there are:

REE: network drive and GPS drive. Storage drives, etc., for which the security requirements are not so high, but the demand is very high. Requiring frequent use. If it is placed in the TEE, it will seriously affect the performance of the system. So placement in the REE is unprotected.

REE Container: the protection for some special drives and operations cannot be considered only in terms of safety, and technical realizability needs to be considered comprehensively. Such as DRM driving, NFC driving, and iris camera driving, which are characterized in that the driving system is relatively difficult to be completely migrated into TEE and has a certain degree of security requirement. According to the invention, for example, the drivers of the iris driver related to the data transmission and data analysis are placed in the safe end, and the drivers of the other parts are placed in the REE Container. Since these two parts of the drive are related to safety protection. But the other part has a lower security protection level, so it is placed in the REE Container.

REE Hypervisor: in REE, arm virtualization supports hardware virtualization of EL2 in REE. Virtualization may increase the security level, but after all in REE, the security level is lower than TEE. The NFC is gradually applied at present, but is mainly applied to a non-secure end, and the market demand of NFC payment is small; secondly, NFC device manufacturers rarely provide the migration code in the TEE, and the migration difficulty is considerable, which has a considerable impact on system stability. Therefore, the NFC driver is kept on the REE side, but is placed in the Hypervisor, increasing the security level.

TEE: the use of fingerprints is related to payment, which is absolutely secure, so placing the fingerprint driver in the TEE, the use of fingerprint devices can only be used in the secure world. The initiation of the SPI interrupt in the fingerprint driver is initiated in the REE, which is not protected by the TEE, and other fingerprint data transmission, analysis, etc. are placed in the TEE. The SE is the highest level of security and the SE drive must be placed in the TEE.

TUI: refers to a trusted user interface. The driving of the screen is placed in both the REE and TEE. The use of screens is the most frequent and requires the inclusion of screen drives on the REE side. But to ensure that the screen driver needs to be called directly at the security end when the security interface is needed, such as when a bank account number and a password are input and executed in the TEE.

According to the embodiment of the invention, the virtual docking method between different security levels is realized. Specifically, initialization of the environment on the REE side, whether Container or Hypervisor, is initiated and detected from the TEE side, where the TEE boots and initializes the Hypervisor, which in turn boots and initializes the Container. Therefore, the TEE is used as a safe and credible basis to ensure that the whole safe guide is established on the basis of authenticity and integrity check.

Fig. 5 schematically illustrates a virtual docking manner between the REE and the TEE. Initialization of the environment on the REE side, whether Container or Hypervisor, is initiated and detected from the TEE side, where the TEE boots and initializes the Hypervisor, which reboots and initializes the Container. The TEE is used as a safe and credible basis to ensure that the whole safe guide is established on the basis of authenticity and integrity check.

For DRM and iris, when DRM or iris TA performs safe operation, the driver module in the Container in REE is used, and after one call is completed, Hypervisor immediately disables the IO control driven by DRM and iris cameras, and the mechanism similar to IOMMU or SMMU in a processor chip is used for completing the operation, so that the REE OS driven by the controller can not be tampered during safe operation.

For NFC drivers, such as offline payment, which are isolated and protected in one virtual machine on the Hypervisor, the key eSE drivers for the expected coordination are completely protected in the TEE, which interacts directly with the SE of the highest security level that may exist.

Other protection such as safety positioning and internet of things safety key positioning modules and driving modules can be realized through similar schemes.

By the drive division method and the butt joint method, the problems of various drive protection modes and methods of the TEE are solved practically. At present, the drive system processing mode of other TEE manufacturers generally adopts the mode of completely migrating to a safe end or completely placing in a REE. Although such a design is simple and relatively high in safety, the type and characteristics of the drive are not analyzed correspondingly, which causes a serious defect in implementation, and known well-known TEEs have a practice of migrating all the drives into the TEEs, but the drive is not implemented at present because the drive is closely related to the system, and although the drive can be completely protected, the drive cannot be implemented or cannot be implemented.

According to an embodiment of the present 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 such as the non-tampering and non-interception of the TEE side is transmitted to the receiver of the REE side, and the higher security of the TEE operation environment and the whole multi-channel communication system is ensured.

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

in the event of too high task load of the processor core on the TEE side, transferring the task load thereof to other processor cores on the TEE side without too high task load, and in the event of overall still too high task load of the processor cores on the TEE side after transfer, the processor core scheduling unit migrating the processor core on the REE side to the TEE side via the scheduling and control channel, as the processor core on the TEE side to process the task on the TEE side;

in case 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 channel to execute the tasks on the REE side as the processor cores on the REE side;

in the event of a reduction in tasks on the TEE side and the occurrence of an idle processor core, the processor core scheduling unit migrates the idle processor core to the REE side via the scheduling and control channel to execute the task on the REE side as the processor core on the REE side.

This approach can take maximum advantage of the processor resources of current systems to ensure benign execution of the processing programs in the TEE and REE.

According to an embodiment of the present invention, in a case that an overall task load of the TEE-side processor core is too high, a request may be issued to the processor core scheduling unit by the TEE-side processor core having the too high task load, so that the processor core scheduling unit checks a state of the REE-side processor core and randomly selects a processor core in a suspended state to be transferred to the TEE side as the TEE-side processor core to execute the TEE-side task, and the processor core scheduling unit distributes a task to be distributed of the requesting processor core to the newly transferred TEE-side processor core according to a specific task rule, for example, in a priority order or in a transition time order, to process.

Fig. 6 schematically shows a schematic diagram of the way a core scheduling unit according to the present invention works. As shown in fig. 6, the processor Core 2 is used as a Core dedicated for the TEE side to process a security Task (Secure Task), and during the period, the processor Core 2 is periodically returned to the REE through global scheduling, mainly responding to inter-Core scheduling and routine Task and interrupt scheduling of the REE OS, and the processor Core 3 is dynamically added to the TEE operating environment according to the load condition of the TEE to process the Secure Task, which is the basic global scheduling method provided by the present invention.

In yet another embodiment of the present invention, the processor core scheduling unit employs a time slice based single core scheduling algorithm to schedule the core on the TEE side. Wherein each task is assigned a priority. Multiple processes are executed alternately on the same TEE core, and N processes may be executing simultaneously during any one time, but only one process is executing at any one time. If a process runs out of its time slice but has not yet been executed, the core currently in use needs to be switched to another process, and the mentioned process running out of time slice is switched back to the core to run upon arrival of its time slice in the next round of time slice cycle between processes by means of a timed interrupt. In the case where the TEE and REE have multiple cores in total, the processor core scheduling unit may continue execution of the time-sliced-out process by starting the new core, i.e., balancing the load of the cores by enabling the new core. The new core is preferably an idle core in the TEE, or a core randomly selected from idle cores in the REE and migrated from the REE side. To implement this embodiment, for example, a HEFT (Heterogeneous-early-Finish-Time) or CPOP (Critical-path-on-a-Processor) algorithm may be used.

According to one embodiment of the invention, the multi-channel communication system comprises an interrupt control unit which, in case of an interrupt received by a processor core on the TEE side:

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

Next, the following processing may be performed:

-the interrupt control unit handing over the secure interrupts in the first group to be processed by the processor core on the TEE side, and

-the interrupt control unit transfers the non-secure interrupts in the second set to the processor core on the REE side for processing via the dispatch and control channel.

Or the following treatment is carried out:

-the Interrupt control unit determining whether the non-secure Interrupt in the second group is SPI (shared Peripheral Interrupt), PPI (private Interrupt) or SGI (soft Interrupt), if SPI, the Interrupt control unit instructing the processor core on the TEE side that received the Interrupt to discard it, and the Interrupt control unit transferring the discarded SPI to the processor core on the REE side via the scheduling and control channel for processing; if PPI or SGI, the interrupt control unit informs the processor core scheduling unit, the processor core scheduling unit then transfers the processor core on the TEE side receiving the interrupt to the REE side through the scheduling and control channel to become the processor core on the REE side, and queues the task of the interrupt in a corresponding work Queue (work Queue), and then the processor core scheduling unit transfers the processor core on the REE side receiving the interrupt back to the TEE side through the scheduling and control channel to become the processor core on the TEE side again to wait for receiving other interrupts. Optionally, after the interrupt is put into the work queue, the processor core scheduling unit transfers the processor core on the REE side receiving the interrupt back to the TEE side via the scheduling and control channel. According to the scheme of the embodiment, a large amount of SPI can be discarded and sent to other REE processor cores for processing, the times of switching the TEE processor core back to the REE processor core for processing are greatly reduced, and therefore the processing efficiency of the TEE is greatly improved.

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

Because of the limited hardware resources on the TEE side, to increase the processing power of the TEE processor core, interrupts that do not have to be processed in the TEE side are typically distributed to the REE processor core for processing to relieve TEE resource load. Thus, partitioning interrupts received by the TEE core as described above enables targeting of processor cores on the TEE side. And scheduling the generated non-safety interruption IRQ or safety interruption FIQ, and avoiding the overlarge load of the processor core at the TEE side as much as possible. The next step may be to leave the secure interrupt FIQ for TEE processor core processing and migrate the non-secure interrupt IRQ to the REE side via the dispatch and control channel 105 for joining the work queue by the REE processor core. Thereafter, the processor core is switched back to the TEE side by the interrupt control unit, continuing to wait for other interrupts from the core to be received.

In an optional next step, it is further distinguished whether the non-safety interrupt IRQ is a shared peripheral interrupt SPI, a private interrupt PPI or a soft interrupt SGI. Where the unsecured SPI may be discarded by the TEE core, handed over and processed by the REE core through the dispatch and control channel 105. The SPI may be taken over by any processor core, while the interrupt PPI and soft interrupt SGI can only be handled by the TEE processor core that currently receives the interrupt, so the optimized way to handle this part of the interrupt is to migrate this TEE processor core to the REE side to handle the interrupt PPI and soft interrupt SGI as the REE processor core. Thereby separating interrupts that do not need to be processed in the TEE processor core as much as possible to the REE processor core for processing. Because the TEE processor core discards a large amount of SPI and hands over the SPI to other REE processor cores for processing, the times of switching the TEE processor core back to the REE processor core for processing are greatly reduced, and the processing efficiency of the TEE is greatly improved.

Fig. 8 schematically shows an electronic device according to the invention. The electronic device has a multi-channel communication system according to the invention and a network interface and a peripheral interface, wherein a user can obtain applications via the network interface or the peripheral interface and install them on the multi-channel communication system, and the user can also run different applications. The electronic device may be, for example, any electronic device deemed appropriate by those skilled in the art, such as a mobile phone, a handheld computer, a laptop computer, a desktop computer, a wearable intelligent communication device, and the like.

The invention also relates to a multichannel communication method which is designed for operating a multichannel communication system according to the above-described embodiments of the invention.

The invention also relates to a computer program product with a program code for causing a multi-channel communication method according to an embodiment of the invention to be performed when the computer program is executed on a computer.

The invention also relates to a data carrier with a program code of a computer program for causing a multi-channel communication method according to an embodiment of the invention to be performed when the computer program is executed on a computer.

The invention further relates to an electronic device with a drive dividing unit according to an embodiment of the invention and a network interface and a peripheral interface, wherein a user can obtain a drive via the network interface or the peripheral interface and the drive dividing unit divides a master drive of the drive into a trusted execution environment or a normal execution environment.

The invention further relates to an electronic device with a processor core scheduling unit according to an embodiment of the invention and a network interface and a peripheral interface, wherein a user can obtain an application via the network interface or the peripheral interface, during running of the application on the electronic device the processor core scheduling unit schedules the processor core within the trusted execution environment and between the trusted execution environment and the normal execution environment in dependence of a load state on the processor core of the trusted execution environment.

The invention also relates to a processor core scheduling method, which is designed for running a processor core scheduling unit according to an embodiment of the invention.

The invention also relates to a computer program product having a program code for causing a method of scheduling processor cores according to the invention to be performed when the computer program is executed on a computer.

The invention also relates to a data carrier having a program code of a computer program for causing a method of scheduling processor cores according to an embodiment of the invention to be performed when the computer program is executed on a computer.

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

The invention also relates to an interrupt control method which is designed for operating an interrupt control unit according to an embodiment of the invention.

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

The invention also relates to a data carrier having a program code of a computer program for causing an 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 a 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 conceive of changes or substitutions within the technical scope of the present disclosure, and shall be covered by the scope of the present disclosure. Therefore, the protection scope of the present disclosure shall be subject to the protection scope of the claims.

List of reference numerals

REE common 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 channel

DRM digital rights protection

NFC near field communication

IRQ non-secure interrupts

FIQ safe interrupts

SPI shared peripheral interrupt

PPI private interrupts

SGI soft interrupt

eSE embedded security unit

Claims

1. A multi-channel communication system for communication between a normal execution environment and a trusted execution environment,

it is characterized in that the preparation method is characterized in that,

the multi-channel communication system includes: a normal execution environment and a trusted execution environment,

wherein the content of the first and second substances,

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

an operating system and an application can run in both the trusted execution environment and the generic execution environment,

the multi-channel communication system further comprises: an application channel, a driver channel and a scheduling and control channel arranged between the normal execution environment and the trusted execution environment,

wherein the content of the first and second substances,

the application channel is used for communication between the common execution environment and an application program of the trusted execution environment;

the driver channel is used for running communication between the drivers of the common execution environment and the trusted execution environment;

and the number of the first and second groups,

the scheduling and control channel is used to schedule and control communication of commands between the normal execution environment and the trusted execution environment.

2. The multi-channel communication system of claim 1, wherein the application channel, the driver 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 are used for mutual independence between the shared memories of different channels.

3. The multi-channel communication system of claim 1 or 2, wherein the application channel, the driver channel, and the scheduling and control channel each comprise a forward channel and a backward channel, wherein the forward channel is configured to transmit messages in a transmit queue of the normal execution environment to a receive queue of the trusted execution environment, and wherein the backward channel is configured to transmit messages in a transmit queue of the trusted execution environment to a receive queue of the normal execution environment.

4. A multi-channel communication system according to claim 3, wherein the message type and message content of messages to be sent or received are maintained in the send queue and receive queue of the normal execution environment and trusted execution environment, respectively, such that each message is sent or received via a channel that conforms to the message type.

5. The multi-channel communication system of claim 1, wherein the application channel carries a standard application protocol.

6. A multi-channel communication system according to claim 1, wherein a client application, a host driver, a virtual driver and/or a processor core can run in the normal execution environment, and a trusted application, a host driver, a virtual driver and/or a processor core can run in the trusted execution environment.

7. A multi-channel communication system as claimed in claim 6, wherein a driver channel is constructed for communicating between the virtual driver and the host driver between the normal execution environment and the trusted execution environment to enable driver sharing between the normal execution environment and the trusted execution environment.

8. The multi-channel communication system of claim 7,

in the case that the normal execution environment calls a specific driver, if there is a main driver of the driver in the trusted execution environment and there is a virtual driver of the driver in the normal execution environment, the normal execution environment calls the virtual driver set in the normal execution environment of the driver, thereby triggering information related to the driver to be sent to the corresponding main driver of the trusted execution environment via a forward channel of the driving channel, and further the main driver is called and returns processed information to the virtual driver of the normal execution environment via a backward channel of the driving channel, and,

under the condition that the trusted execution environment calls a specific driver, if the virtual driver of the driver exists in the trusted execution environment and the main driver of the driver exists in the ordinary execution environment, the trusted execution environment calls the virtual driver of the driver, which is arranged in the trusted execution environment, so that the information related to the driver is triggered to be sent to the corresponding main driver of the ordinary execution environment through a backward channel of the driving channel, and the main driver is called and returns the processed information to the virtual driver of the trusted execution environment through a forward channel of the driving channel.

9. Multi-channel communication system according to claim 1, characterized in that the multi-channel communication system comprises: the dividing unit is driven to divide the image into a plurality of image portions,

the drive dividing unit performs the steps of:

evaluating the security of a driver to be run on the multi-channel communication system,

if the safety of the driver is above a first safety threshold value, dividing the main driver of the driver into the trusted execution environment, and setting the virtual driver of the driver in the common execution environment;

if the safety of the driver is below a second safety threshold, dividing the main driver of the driver into the ordinary execution environment, and setting the virtual driver of the driver in the trusted execution environment;

if the availability is below an availability threshold and the realizability is above a realizability threshold, partitioning the host driver of the driver to the trusted execution environment and setting a virtual driver of the driver at the normal execution environment, otherwise partitioning the host driver of the driver to the normal execution environment and setting the virtual driver of the driver at the trusted execution environment.

10. Multi-channel communication system according to claim 9, characterized in that the driving dividing unit

Dividing main drivers of a DRM driver, a camera driver, a network driver, a GPS driver and a storage driver into the common execution environment; and/or

Dividing main drivers of drivers related to data transmission and data analysis in the iris drivers into the trusted execution environment, and dividing main drivers of other drivers in the iris drivers into the common execution environment; and/or

Dividing a main drive of an NFC drive into the common execution environment; and/or

Dividing a main drive of a drive related to data transmission and data analysis in the fingerprint drive into the trusted execution environment, and dividing a main drive of a drive related to shared peripheral interrupt initiation in the fingerprint drive into the common execution environment; and/or

Partitioning an SE drive to the trusted execution environment; and/or

And setting a main driver supporting a driver of a trusted user interface in the common execution environment and the trusted execution environment.

11. A multi-channel communication system according to claim 1 or 10, wherein the normal execution environment is less secure than the trusted execution environment, and the normal execution environment further comprises a security level Hypervisor and a security level Container less secure than Hypervisor, wherein Hypervisor and Container are isolated from each other.

12. A multi-channel communication system as recited in claim 11, wherein at the normal execution environment, context initialization of both the Container and the Hypervisor is initiated and detected from the trusted execution environment, wherein the trusted execution environment boots and initializes the Hypervisor, which reboots and initializes the Container.

13. The multi-channel communication system of claim 1, wherein the trusted execution environment cryptographically encrypts data to be transmitted to the generic execution environment to ensure that data flowing to the generic execution environment is ciphertext.

14. A multi-channel communication system according to claim 1, characterized in that the multi-channel communication system comprises: a scheduling unit of the processor core is provided,

if the task load of the processor core of the trusted execution environment is too high, transferring the task load of the too high part of the processor core of the trusted execution environment to other processor cores of the trusted execution environment which are not too high in task load, and if the overall task load of the processor cores of the trusted execution environment is still too high after the transfer, the processor core scheduling unit transfers the processor core of the common execution environment to the trusted execution environment through the scheduling and control channel and processes the task of 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 ordinary execution environment via the scheduling and control channel to execute the tasks of the ordinary execution environment as the processor cores of the ordinary execution environment,

15. The multi-channel communication system of claim 14, wherein the processor core scheduling unit checks task load conditions of each processor core of the trusted execution environment at set intervals.

16. The multi-channel communication system of claim 15, wherein the set time is 100 ms.

17. The multi-channel communication system according to claim 14 or 15, wherein if the overall task load of the processor cores of the trusted execution environment is too high, a request is issued to the processor core scheduling unit by the processor core of the trusted execution environment whose task load is too high, so that the processor core scheduling unit checks the state of the processor core of the normal execution environment and randomly selects the processor core in the suspended state to transfer to the trusted execution environment to execute the task of the trusted execution environment as the processor core of the trusted execution environment, and the processor core scheduling unit distributes the task to be distributed of the processor core issuing the request to the processor core of the newly transferred trusted execution environment for processing according to a specific task rule.

18. Multi-channel communication system according to claim 1, characterized in that the multi-channel communication system comprises an interrupt control unit,

the interrupt control unit is to partition interrupts that can only be processed by the processor cores of the trusted execution environment into a first group as secure interrupts and to partition other interrupts into a second group as non-secure interrupts if the processor cores of the trusted execution environment receive the interrupts.

19. The multi-channel communication system of claim 18,

the interrupt control unit handing over the secure interrupts of the first group to be processed by a processor core of the trusted execution environment, an

Transferring the non-secure interrupts of the second set to processor cores of the normal execution environment for processing via the dispatch and control channel.

20. The multi-channel communication system of claim 18, wherein:

The interrupt control unit determines whether an insecure interrupt in the second group is a shared peripheral interrupt, a private interrupt, or a soft interrupt,

21. The multi-channel communication system of claim 20, wherein the processor core scheduling unit is configured to schedule processor cores 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 put into the work queue, the processor core scheduling unit transfers the processor core of the ordinary execution environment receiving the interrupt back to the trusted execution environment through the scheduling and control channel, so that the processor core becomes the processor core of the trusted execution environment again to wait for receiving other interrupts.

22. An electronic device, comprising: a multi-channel communication system and network interface and peripheral interface as claimed in any of claims 1 to 21 wherein a user obtains an application via the network interface or peripheral interface and installs the application to the multi-channel communication system, the user also running a different application with the multi-channel communication system.