CN117827475A

CN117827475A - Method, apparatus, electronic device and medium for inter-process communication

Info

Publication number: CN117827475A
Application number: CN202211198995.8A
Authority: CN
Inventors: 杜冬冬; 江学强; 夏虞斌; 孙康
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2022-09-29
Filing date: 2022-09-29
Publication date: 2024-04-05

Abstract

Embodiments of the present disclosure provide methods, apparatus, electronic devices, and media for inter-process communication in a trusted execution environment. The method comprises the steps of distributing at least one token to a service enclave process of a trusted execution environment, mapping a virtual address range of the service enclave process to safe memory areas of the trusted execution environment based on the token, and binding each safe memory area with one token; assigning a token of the at least one token to a client enclave process of the trusted execution environment; mapping the virtual address range of the client enclave process to a secure memory area bound to the allocated token; inter-process communication of the service enclave process and the client enclave is performed based on a mapping of virtual address ranges of the service enclave process and the client enclave process to the secure memory area. The scheme of the present disclosure realizes efficient asynchronous communication between enclave processes on the basis of not significantly increasing a trusted computing base, and has higher communication performance.

Description

Method, apparatus, electronic device and medium for inter-process communication

Technical Field

Embodiments of the present disclosure relate generally to the field of computer technology, and more particularly, to operating system technology. More particularly, embodiments of the present disclosure relate to methods, apparatuses, electronic devices, computer readable storage media, and computer program products for interprocess communication.

Background

A trusted execution environment (Trusted Execution Environment, abbreviated as "TEE") is a secure area in a computer system constructed by software and hardware, and protects code execution and data assets by ensuring the integrity and privacy of code and data loaded into the area. An enclave process (enclave) is a trusted application running in a trusted execution environment, whose running environment is provided by trusted hardware and trusted software.

The trusted execution environment has a stronger isolation mechanism, thus introducing greater restrictions on communications between enclave processes running in the trusted execution environment. For cloud scenarios, communication between enclave processes running on the cloud is a critical performance factor.

Disclosure of Invention

Embodiments of the present disclosure provide an inter-process communication scheme between enclave processes for a trusted execution environment.

According to a first aspect of the present disclosure, a method for interprocess communication is provided. The method comprises the following steps: assigning at least one token to a service enclave process of a trusted execution environment; mapping a virtual address range of the service enclave process to at least one secure memory area of the trusted execution environment based on the at least one token, each secure memory area being bound to one of the at least one token; assigning a token of the at least one token to a client enclave process of the trusted execution environment; mapping the virtual address range of the client enclave process to a secure memory area bound with the token; and performing inter-process communication of the service enclave process and the client enclave process based on the mapping of the virtual address range of the service enclave process and the virtual address range of the client enclave process to the secure memory area.

In this way, the mapping of the virtual address ranges of the service enclave process and the client enclave process to the same or shared secure memory area can be established based on the binding relationship between the token and the secure memory area in the trusted execution environment, respectively, thereby establishing a secure connection between the service enclave process and the client enclave process. Since the token assignment and address mapping process is trusted and under a trusted execution environment other processes without tokens cannot access the shared secure memory area bound to the token, the serving enclave process and the client enclave process need not thereafter perform calls and authentications in the privileged state each time a communication is made. Therefore, asynchronous through communication between the service enclave process and the client enclave process is realized, and communication performance between enclave processes of a trusted execution environment is improved.

In some embodiments of the first aspect, assigning at least one token to a service enclave process of the executable environment may include: starting a communication manager enclave process for inter-process communication; in response to receiving a request to register a service for a service enclave process, a communication manager enclave process obtains at least one token for the service; and the communication manager enclave process assigning at least one token for the service to the service enclave process. In this way, the service enclave process may obtain tokens bound to the secure memory area based on the service, whereby the client enclave process may also obtain one of these tokens based on the service. Thus, service-based inter-process communication between the service enclave process and the client enclave process is achieved.

In some embodiments of the first aspect, assigning the token to the client enclave process of the trusted execution environment may include: in response to receiving a request for service by a client enclave process, the communication manager enclave process assigns a token of the at least one token to the client enclave process. In this way, the client enclave process may obtain a token associated with the desired service that the service enclave process has obtained and bound to a particular shared secure memory region. Thus, the client enclave process and the serving enclave process may utilize the same token to establish a mapping to a particular shared secure memory region for subsequent asynchronous pass-through communications.

In some embodiments of the first aspect, the communication manager enclave process may be an enclave process running in a user state, wherein the communication manager enclave process allocates at least one token serving the enclave process and a token of the client enclave process based on control of a security monitor of the trusted execution environment. Compared with the prior communication scheme which relies on the invocation and authentication of the privilege state, the communication manager is set to run in the user state, so that the trusted computing base of the system can be effectively reduced, and the higher system security is ensured. In addition, no participation of the communication manager and privilege management is required after the secure connection between enclave processes is established, thereby achieving higher communication performance.

In some embodiments of the first aspect, mapping the virtual address range of the serving enclave process to the at least one secure memory region of the trusted execution environment may include: for each token in at least one token, creating a secure memory area bound with each token in a privilege state of a trusted execution environment to obtain at least one secure memory area; and mapping the virtual address range of the serving enclave process to at least one secure memory region. In this way, software and hardware of the trusted execution environment can be utilized to ensure the security of access to the secure memory area by the service enclave process.

In some embodiments of the first aspect, the method may further comprise: determining an address space for inter-process communication of the trusted execution environment based on the values of the registers of the trusted execution environment; and determining a virtual address range of the serving enclave process and a virtual address range of the client enclave process in the address space. In this way, a virtual address space dedicated to interprocess communication of a trusted execution environment is defined using hardware. When the enclave process accesses a virtual address in a virtual address space defined by a register, the security of a memory corresponding to such a virtual address can be protected on hardware, and such hardware ensures that it is imperceptible to the enclave process and does not affect the execution efficiency of the enclave process.

In some embodiments of the first aspect, the method may further comprise: generating a global shared key of the trusted execution environment; and in response to the service enclave process or the client enclave process accessing the secure memory region, encrypting and decrypting using the global shared key. In this way, the enclave process can use a unified key, so that encryption and decryption overhead of the memory data is simplified while the privacy of the memory data is protected.

In some embodiments of the first aspect, the global shared key may be generated based on or derived from hardware of the trusted execution environment, and encrypting and decrypting using the global shared key may include: encryption and decryption is performed using a global shared key via hardware of the trusted execution environment. In this way, privacy protection of memory data is achieved using hardware, and such hardware guarantees that it is imperceptible to the enclave process, without affecting the execution efficiency of the enclave process. If the enclave process is to access the shared secure memory area for inter-process communication, as determined by the value of the hardware register, memory encryption and decryption are performed using the global hardware key of the enclave process, and if other memory areas are being accessed, memory encryption and decryption are performed using the private hardware key.

In some embodiments of the first aspect, performing inter-process communication of the serving enclave process and the client enclave process may include: writing a service request of the client enclave process into the secure memory area based on the mapping of the virtual address range of the client enclave process to the secure memory area; updating the state of the secure memory area to indicate the presence of a service request; in response to the status indicating the presence of a service request, reading the service request by the service enclave process for processing based on a mapping of the virtual address range of the service enclave process to the secure memory area; writing a processing result of the service enclave process aiming at the service request into a safe memory area; and updating the state of the secure memory area to indicate that the processing is completed, so that the client enclave process obtains the processing result. In this way, highly reliable communication between the serving enclave process and the client enclave process is achieved.

In some embodiments of the first aspect, the client enclave process is a first client enclave process, the token assigned to the first client enclave process is a first token, the secure memory region bound to the first token is a first secure memory region, the method may further comprise: assigning a second token of the at least one token to a second client enclave process of the trusted execution environment; mapping the virtual address range of the second client enclave process to a second secure memory region bound to the second token; and performing communication between the service enclave process and the second client enclave process based on the virtual address range of the service enclave process and the mapping of the virtual address range of the second client enclave process to the second secure memory area. The privilege level call and authentication are not needed after the connection between the service enclave process and the client enclave process is established, so that the service enclave process can simultaneously connect and communicate with a plurality of client enclave processes, and the communication performance is improved.

In some embodiments of the first aspect, the method may further comprise: polling the first secure memory area and the second secure memory area; and responsive to the status of either the first secure memory area or the second secure memory area indicating the presence of a service request, the service enclave process reads the corresponding service request for processing. In this way, the service enclave process is able to directly use an interface like a synchronous function call without regard to the details of the asynchronous communication.

According to a second aspect of the present disclosure, there is provided an apparatus for interprocess communication, comprising: a first allocation unit configured to allocate at least one token to a service enclave process of a trusted execution environment; a first mapping unit configured to map a virtual address range of a service enclave process to at least one secure memory area of a trusted execution environment based on at least one token, each secure memory area being bound to one of the at least one token; a second allocation unit configured to allocate a token of the at least one token to a client enclave process of the trusted execution environment; a second mapping unit configured to map a virtual address range of the client enclave process to a secure memory area bound to the token; and an inter-process communication element configured to perform inter-process communication of the service enclave process and the client enclave process based on the mapping of the virtual address range of the service enclave process and the virtual address range of the client enclave process to the secure memory area.

According to a third aspect of the present disclosure, there is provided an electronic device comprising a processor comprising a plurality of processing cores; a memory; at least one of the plurality of processing cores is configured to execute instructions in memory, causing the electronic device to perform a method according to the first aspect of the present disclosure.

According to a fourth aspect of the present disclosure there is provided a computer readable storage medium having stored thereon one or more computer instructions, wherein execution of the one or more computer instructions by a processor causes the processor to perform a method according to the first aspect of the present disclosure.

According to a fifth aspect of the present disclosure, there is provided a computer program product comprising machine executable instructions which, when executed by a device, cause the device to perform a method according to the first aspect of the present disclosure.

Drawings

The above and other features, advantages, and aspects of embodiments of the present disclosure will become more apparent by reference to the following detailed description when taken in conjunction with the accompanying drawings. In the drawings, wherein like or similar reference numerals designate like or similar elements, and wherein:

FIG. 1 illustrates a schematic diagram of an example environment in which various embodiments of the present disclosure may be implemented;

FIG. 2 illustrates a schematic flow diagram of a process for interprocess communication in accordance with some embodiments of the disclosure;

3A-3D illustrate schematic diagrams of a process of establishing a connection between enclave processes according to embodiments of the present disclosure;

FIG. 4 illustrates a process schematic flow diagram for performing inter-process communication between enclave processes in accordance with an embodiment of the present disclosure;

5A-5C illustrate a schematic diagram of a process by which an enclave process accesses a secure memory region according to an embodiment of the present disclosure;

FIG. 6 shows a schematic block diagram of an apparatus for interprocess communication in accordance with an embodiment of the disclosure; and

FIG. 7 shows a schematic block diagram of an example device that may be used to implement embodiments of the present disclosure.

Detailed Description

Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While certain embodiments of the present disclosure have been shown in the accompanying drawings, it is to be understood that the present disclosure may be embodied in various forms and should not be construed as limited to the embodiments set forth herein, but are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are for illustration purposes only and are not intended to limit the scope of the present disclosure.

In describing embodiments of the present disclosure, the term "comprising" and its like should be taken to be open-ended, i.e., including, but not limited to. The term "based on" should be understood as "based at least in part on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The terms "first," "second," and the like, may refer to different or the same object. Other explicit and implicit definitions are also possible below.

A Trusted Execution Environment (TEE) is a secure execution area that relies on the strongly isolated nature of the processor, which ensures confidentiality and integrity of internally loaded code and data. Code and data of trusted applications running in a trusted execution environment cannot be read and written and tampered with by an untrusted operating system or application. Corresponding trusted execution environment schemes have been proposed in some mainstream Central Processing Unit (CPU) architectures, such as software daemon extensions (Software Guard eXtensions, SGX) under the x86 architecture, trusted domain extensions (Trust Domain eXtension, TDX), trust zone under the ARM architecture, confidential computing architecture (Confidential Compute Architecture, CCA), penglai (Penglai) under the RISC-V architecture, keystone, etc.

In a trusted computing environment, enclave process (Enclave) refers to a trusted application running in a trusted execution environment, typically in a user state, whose trusted execution environment is provided by trusted hardware as well as trusted software. Herein, inter-enclave process communication refers to communication between two or more enclave processes.

A trusted computing base (Trusted Computing Base) refers to a collection of all security mechanisms that implement security protection for a computer system, which may exist in hardware, firmware, or software. On hardware, the trusted computing base includes physical memory protection (Physical Memory Protection, PMP) for implementing secure memory access rights control. On firmware or software, the trusted computing base includes a security Monitor (Secure Monitor). The security monitor is operated at the highest privilege level and is responsible for the life cycle management and part of security assurance of the enclave process.

In some conventional schemes, enclave inter-process communication uses a synchronous communication scheme. The security monitor or other trusted mechanism is utilized, each round of communication needs to be sunk to the security monitor through a privilege level call, and the security monitor performs communication authority check, context switching and mapping of data communication data. The problem with this approach is that each round of communication needs to pass through the security monitor, performance is limited, and the serving enclave process does not support simultaneous invocation by multiple client enclave processes, with limited concurrent communication capabilities.

In other conventional schemes, an unsecure memory is established as a shared memory between enclave processes, which utilize the unsecure shared memory for inter-process communication of enclave processes. The client enclave process needs to encrypt communication data and then write the communication data into the unsafe shared memory, the service enclave process decrypts the unsafe shared memory and then writes the communication data into the private safe memory, then processes the communication data, encrypts and writes a processing result into the unsafe shared memory after the processing is completed, and the client enclave process decrypts the processing result and then writes the processing result into the private safe memory. The problem with this approach is that direct sharing of secure memory between enclave processes cannot be supported. The reason is that different enclave processes use different private keys to encrypt and decrypt the secure memory and a static secure memory isolation mechanism, so that the communication in a mode of sharing the non-secure memory with the host process needs to perform additional data copying and encryption and decryption operations during each round of communication, which results in limited performance.

In view of this, embodiments of the present disclosure provide a secure shared memory mechanism for enabling efficient asynchronous pass-through communications between enclave processes in a trusted execution environment. In the method of the present disclosure, tokens are assigned to the service enclave processes and the client enclave processes that are engaged in communication. The service enclave process and the client enclave process use the same token to establish a mapping of respective virtual addresses to the same block of shared secure memory area. In a trusted execution environment of an embodiment of the present disclosure, a token is a credential to access a shared secure memory area. The enclave process without the token cannot establish the mapping from the virtual address to the memory physical address, thereby realizing data isolation. Based on the mapping of the virtual address to the shared secure memory area, a connection between the service enclave process and the client enclave process is established. Therefore, the service enclave process and the client enclave process can directly use the shared secure memory area to carry out asynchronous inter-process communication, each round of communication is not required to carry out authentication through privilege level calling, and additional software layer encryption and decryption operations are not required to be carried out, so that the communication performance between enclave processes in a trusted execution environment is improved. Example embodiments of the present disclosure are described in detail below with reference to fig. 1 to 7.

FIG. 1 illustrates a schematic diagram of an example environment 100 in which various embodiments of the present disclosure may be implemented. Environment 100 represents a trusted execution environment of a computer system (hereinafter referred to as trusted execution environment 100). The trusted execution environment 100 may be implemented in a variety of computing devices having computing capabilities, and exemplary computing devices may include servers provided by various service providers, mainframe computing devices, cloud servers, and the like. The user terminal is, for example, any type of mobile terminal, fixed terminal or portable terminal, including a mobile handset, a site, a unit, a device, a multimedia computer, a multimedia tablet, an internet node, a communicator, a desktop computer, a laptop computer, a notebook computer, a netbook computer, a tablet computer, a Personal Communication System (PCS) device, a personal navigation device, a Personal Digital Assistants (PDA), an audio/video player, a digital camera/camcorder, a positioning device, a television receiver, a radio broadcast receiver, an electronic book device, a game device, or any combination thereof, including accessories and peripherals for these devices, or any combination thereof.

As shown, trusted execution environment 100 includes a plurality of enclave processes running in a user state, including enclave process 110, enclave process 120, and enclave process 130. It should be appreciated that the number of enclave processes in trusted execution environment 100 is not limited to that shown in fig. 1, and may include more or fewer enclave processes. Enclave processes 110, 120, and 130 may initiate inter-process communications based on a service-client approach. As an example, enclave process 120 may request services from enclave process 110, and in particular, may transmit request data to enclave process 110 through an asynchronous interprocess communication method according to an embodiment of the disclosure. Enclave process 110 processes the request data and then transmits the processing results to enclave process 120 through an asynchronous interprocess communication method according to an embodiment of the present disclosure. Optionally, synchronous inter-process communication may also be performed between enclave processes 110, 120, and 130, e.g., privilege level scheduling and authentication based on the trusted computing base of trusted execution environment 100.

Herein, an enclave process requesting a service may be referred to as a client enclave process, and an enclave process providing a service may be referred to as a service enclave process. The role of the enclave process may change. In other words, an enclave process may take the role of a serving enclave process in one interprocess communication session and a client enclave process in another process communication session.

As shown, the viable execution environment 100 further includes a security monitor 140 running in a privileged state, and a secure memory 150, a physical memory protection module 160, and an encryption and decryption module 170 at the hardware level. This piece of components works in concert to provide its secure operating environment as a trusted computing base for user-state enclave processes 110, 120, and 130. Enclave processes 110, 120, and 130 have sensitive data that needs to be restricted from other processes' access to their data. When the data of enclave processes 110, 120, and 130 are loaded from external memory (e.g., a hard disk), they are decrypted, validated, and then stored to an address range in secure memory 150 that is specific to the corresponding enclave process. Physical memory protection module 160 may provide access control for enclave process data. For example, a portion of secure memory 150 may be allocated to a particular enclave process and associated with a unique identifier of the enclave process such that access to data of the enclave process is limited to only the enclave process itself or an authorized process.

The encryption and decryption module 170 may provide hardware-level encryption and decryption processing. For example, when enclave processes 110, 120, and 130 are created, the encryption and decryption module generates a key for each enclave process. When the enclave processes 110, 120, and 130 write to the secure memory 150, the encryption and decryption module 170 encrypts the write data using the key such that the data in the secure memory 150 is encrypted data. Upon a read operation from secure memory 150, enclave processes 110, 120, and 130 perform decryption processing using the keys, resulting in decrypted data, which is provided to a processor (not shown) for processing.

Security monitor 140 is software or firmware that runs in a privileged state. In some cases, security monitor 140 may operate in the highest privilege state, controlling lifecycle management and security assurance of enclave processes 110, 120, and 130. Security monitor 140 may provide for synchronized communications between user-state executing enclave processes 110, 120, and 130, including, but not limited to, communication authority checking, context switching, and mapping of data communication data. Specifically, during an initialization phase of communication, a service enclave process may register a communication call interface with security monitor 140 through a privilege level call, upon which security monitor 140 may perform creation of access rights, e.g., using a capability (capability) mechanism, and a client enclave process obtains the communication capability of a corresponding service enclave process 120 from security monitor 140 through the privilege level call. During communication, the client enclave process initiates a communication call to the security monitor 140 through a privilege call, the security monitor 140 checks whether the client enclave process has corresponding communication rights, after the rights check pass, the communication data is demapped from a page table of the client enclave process, the communication data page is mapped to the service enclave process, then context switching is performed, a control flow is directly cut into an entry point of the service enclave process, and the service enclave process 110 returns to the client enclave process by adopting a similar control flow switching path after the communication request is processed.

According to embodiments of the present disclosure, security monitor 140 also provides asynchronous communications between enclave processes 110, 120, and 130 that control access to secure memory 150 by enclave processes 110, 120, and 130 through tokens, helping the communicating enclave processes to establish a secure connection. The details will be described below in connection with fig. 2 to 7, which will not be described in detail here.

Trusted execution environment 100 is described above with reference to fig. 1. It is to be understood that the environment shown in fig. 1 is merely exemplary, and that embodiments of the present disclosure may also be implemented in different environments. For example, the environment may also include more or less software, firmware, or hardware for trusted computing. By way of example, the environment may also include a processor for trusted computing and its instruction sets, registers, an operating system with trusted computing components, and the like.

Fig. 2 illustrates a schematic flow diagram of a process 200 for interprocess communication in accordance with some embodiments of the disclosure. It should be appreciated that process 200 may also include additional acts not shown and/or may omit acts shown, and may be performed in a different order, as the scope of the present disclosure is not limited in this respect. For ease of understanding, process 200 is described in connection with FIG. 1.

At block 210, at least one token is assigned to a service enclave process of a trusted execution environment. As mentioned above, a serving enclave process refers to an enclave process that provides a service in a trusted execution environment, obtains requests of other enclave processes as client enclave processes, processes the requests, and provides the processing results to the client enclave processes. A token is a globally unique credential for the service enclave process and the client enclave process to access a shared secure memory located in secure memory 150, load managed and allocated by security monitor 140. Under the control of security monitor 140, the serving enclave process and the client enclave process may establish a mapping of their virtual addresses to the physical addresses of the secure memory based on the token.

Specifically, security monitor 140 binds each piece of secure shared memory with a globally unique token, and security monitor 140 only allows secure shared memory to be mapped into the virtual address range of the enclave process that owns the corresponding token. In some embodiments, security monitor 140 may provide a secure shared memory-related privilege level call interface including, but not limited to: interface enclaspe_ shmget (shared memory get) for secure memory acquisition, interface enclaspe_ shmat (shared memory attach) for secure memory attachment, interface enclaspe_ shmdt (shared memory dettach) for secure memory disconnection, interface enclaspe_ shmrevoke (shared memory revoke) for secure memory withdrawal, and interface enclaspe_ shmdestroty (shared memory destroy) for secure memory destruction. The interfaces described above are exemplary only and the nomenclature is not limited thereto.

Fig. 3A illustrates a schematic diagram of a process for a service enclave process to obtain a token and establish a mapping of its virtual address to a physical address of secure memory, according to an embodiment of the present disclosure. For ease of illustration, serving enclave process 310 in fig. 3A may be enclave process 110 of fig. 1 and client enclave process 320 may be enclave process 120 of fig. 1. In fig. 3, communication manager 330 is an enclave process running in a user state, responsible for establishing communication between enclave processes and implementing corresponding access control policies. Communication manager 330 may be, for example, enclave process 130 of fig. 1. To establish asynchronous pass-through communications between enclave processes, serving enclave process 310 and client enclave process 320 may register with communications manager 330 in the manner of synchronous inter-process communications. The synchronization inter-process communication relies on authentication by the security monitor 140 including, for example, communication rights checking, context switching, and mapping of data communication data.

After communications manager 330 has been booted, service enclave process 310 registers a service with communications manager 330 in act 301, as shown in fig. 3A. Upon registration, the service enclave process 310 may provide the service name and the number of most accepted client enclave processes. In response to receiving the registration service request for service enclave process 310, communication manager 330 generates a corresponding number of tokens for the service and, at act 302, assigns the tokens to service enclave process 310 in accordance with the synchronized interprocess communication manner. Thus, successfully registered service enclave process 310 obtains at least one token from communications manager 330 that is the same as the maximum number of connections. The service enclave process 310 may use these tokens to establish a mapping of its virtual address range to secure memory.

With continued reference to FIG. 2, at block 220, a virtual address range of the serving enclave process is mapped to at least one secure memory area of the trusted execution environment based on the at least one token, each secure memory area being bound to one of the at least one token. Referring to FIG. 3A, at 303, a serving enclave process 310 requests allocation of a secure memory area for inter-process communication from a security monitor 140. For example, the serving enclave process 310 may create a secure memory area bound to several tokens obtained from the communication manager 330 by initiating a secure privilege level call enclave to the security monitor 140. In some embodiments, the token obtained from communication manager 330 may be carried in a privilege level invocation enclave_sheet. Alternatively, information indicating the service name may also be carried in enclave_sheet, with all tokens associated with the service being acquired by security monitor 140 from communication manager 330.

The security monitor 140 creates a secure memory area 151, 152 … …,15N (collectively secure memory area 15, where N is the number of tokens serving the enclave process 310) bound to each token for each token serving the enclave process in response to a request to allocate the secure memory area. The secure memory region is also referred to herein as a shared memory region, which are used interchangeably. The secure memory regions 151, 152 … …,15N may be contiguous or non-contiguous. Security monitor 140 then maps the virtual address range of serving enclave process 310 to created secure memory region 15. The virtual address range may be within a specified one of the complete address spaces of the serving enclave process 310. Thus, security monitor 140 may control access to secure memory region 15 in secure memory 150 based on the token. The serving enclave process 310 has these tokens and its virtual address range is mapped to the secure memory area 15, so the serving enclave process 310 has access. It should be noted that, the creation of the secure memory area 151, 152 … …,15N may be performed when the registration of the service enclave process 310 is completed, or may be performed at other times, for example, when a connection request of the client enclave process 320 is received, and a mapping for the secure memory area 151, 152 … …,15N is created and established when inter-process communication is to be performed.

FIG. 3B illustrates a schematic diagram of a mapping of virtual address ranges to secure memory regions for an exemplary serving enclave process. As shown in FIG. 3B, an address space 314 for inter-process communication of the trusted execution environment is partitioned in a complete address space 312 of the serving enclave process 310. The address space 314 for inter-process communication may be defined by registers 180 in hardware. In some embodiments, registers 180 may include two registers: the value of the base address register 182 defines the starting address of the address space 314 and the value of the size register 184 defines the size of the address space 314. The values of the base address register 182 and the size register 184 may be set by software. Thus, the service enclave process 310 accessing a virtual address in the address space 314 means that the service enclave process 310 is to perform inter-process communication between enclave processes. In fig. 3B, virtual address range 316 located in address space 314 is mapped to secure memory area 15 in secure memory 150. That is, virtual address range 316 belongs to an address range of a service registered by service enclave process 310 with communication manager 330 for which data access occurs within virtual address range 316.

After successful creation of secure memory area 15 and mapping of the virtual address range of serving enclave process 310 to secure memory area 15, secure memory area 15 is initialized. Thereafter, the serving enclave process 310 may check the state of the secure memory area 15, confirm whether a client enclave process initiated a connection and requested service.

As mentioned above, with trusted computing-based hardware, enclave processes in a trusted execution environment may use private keys for hardware-level encryption and decryption when accessing secure memory. Such hardware-level encryption and decryption is transparent to the enclave process. In some embodiments, in addition to the private key of each enclave process, embodiments of the present disclosure provide a global shared key for encryption and decryption of secure memory region 15. The global shared key may be provided by hardware in the trusted execution environment or derived from a hardware key, and hardware-level encryption and decryption using the global shared key is also transparent to the enclave process.

For example, when the serving enclave process 310 requests allocation of the secure memory area 15 for inter-process communication from the security monitor 140, it may be specified whether the secure memory area 15 requires encryption. Thereafter, when the serving enclave process 310 initiates a memory access, if the virtual address of the access is located within the address space 316 specified by registers 182 and 184, and encryption is enabled for the secure memory area 15 to which the virtual address is mapped, then the secure memory area 15 is encrypted using the global shared key via hardware of the trusted execution environment, otherwise the secure memory area 15 is not encrypted. Thus, the data stored in the secure memory area 15 is encrypted data, and has higher security.

With continued reference to FIG. 2, at block 230, a client enclave process of the trusted execution environment is assigned a token of the at least one token. Client enclave process 320 may obtain a token, which is a credential for asynchronous inter-process communication by client enclave process 320 and serving enclave process 310, by requesting a token from communication manager 330.

Fig. 3C illustrates a schematic diagram of a process of a client enclave process acquiring a token and establishing a mapping of its virtual address to a physical address in secure memory, according to an embodiment of the present disclosure. To obtain the token, client enclave process 320 may initiate a communication connection to serving enclave service process 310 via security monitor 140 to communication manager 330 by way of synchronous inter-process communication at 304. The corresponding service name needs to be provided when initiating the connection. At 305, in response to receiving a request for service from client enclave process 320, communications manager 330 may assign one of the tokens already assigned to serving enclave process 310 to client enclave process 330. On the other hand, if the requested service does not exist or the maximum number of connections has been reached (e.g., all tokens have been assigned to other client enclave processes without tokens being available), an error value is returned to client enclave process 320 via the synchronous inter-process communication return interface of security monitor 140.

At block 240 of FIG. 2, the virtual address range of the client enclave process is mapped to a secure memory area bound to the token. Referring to fig. 3C, at 306, client enclave process 320, having successfully acquired the token, establishes a mapping of one of secure memory regions 15 bound to the corresponding token using the token by initiating a secure privilege level call to security monitor 140. If the call fails, perhaps because the service is not initialized, then client enclave process 320 may wait briefly before proceeding with the call. Upon successful invocation, client enclave process 320 may update the secure memory region to which it maps, thereby establishing a communication connection with serving enclave process 310.

FIG. 3D illustrates a schematic diagram of a mapping of virtual address ranges to secure memory regions for an exemplary client enclave process. As shown in FIG. 3D, similar to serving enclave process 310, an address space 324 for inter-process communication of a trusted execution environment is partitioned in a complete address space 322 of client enclave process 320. The address space 324 for inter-process communication may be defined by registers 180 of the hardware. Address space 312 of serving enclave process 310 and address space 322 of client enclave process 320 may be defined by common registers 182 and 184, or may be defined by more registers. Thus, client enclave process 320 accessing a virtual address in address space 324 means that client enclave process 320 is to perform inter-process communication between enclave processes. In FIG. 3D, virtual address range 326 located in address space 324 is mapped to one of regions 151 in secure memory region 15, i.e., the region in secure memory region 15 created in act 220 that is bound to the token assigned to client enclave process 320. It will be appreciated that the mapping of virtual address range 326 to region 151 is merely illustrative, and that virtual address range 326 may be mapped to any one of secure memory regions 15. That is, virtual address range 326 belongs to an address range where client enclave process 320 performs inter-process communication to service enclave process 310, and client enclave process 320 exchanges data with service enclave process 310 in corresponding region 151 by accessing virtual address range 326. Thereby establishing a connection between serving enclave process 310 and client enclave process 320.

In addition, the service enclave process 310 has multiple tokens, each bound to one secure memory area 151, 152 …,15N. Thus, the serving enclave process 310 may concurrently establish connections with multiple client enclave processes, each using one of the secure memory regions 15. For example, a different token may be assigned to another client enclave process than that assigned to client enclave process 320, and the virtual address of that client enclave process may be mapped to a different one of secure memory regions 151, 152 …,15N to which the token is bound, thereby establishing a connection of serving enclave process 310 with the other client enclave process. In this manner, the service enclave process 310 may have connections of multiple client enclave processes simultaneously for concurrent communications.

As mentioned above, the secure memory area 150 may be designated as requiring encryption when created. In this case, when guest enclave process 320 accesses virtual address range 326, hardware level encryption and decryption is performed using the global shared key. Specifically, via hardware in the trusted execution environment, write data of client enclave process 320 for corresponding region 151 is encrypted, and data read from region 151 by client enclave process 320 is decrypted using the global shared key.

Returning to FIG. 2, at block 250, inter-process communication of the service enclave process and the client enclave process is performed based on the mapping of the virtual address range of the service enclave process and the virtual address range of the client enclave process to the secure memory area. In general, serving enclave process 310 and client enclave process 320 may perform inter-process communications directly using shared secure memory areas. For example, the client enclave process 320 writes request data in the secure memory area 15, the service enclave process reads a request from the secure memory area 15, processes it, and writes the processing result to the secure memory area, and then the client enclave process 320 acquires the processing result from the secure memory area 15. Such interprocess communications are asynchronous, and do not require each round of communications to rely on the security monitor 140 or other trusted computing base for authentication, with higher communications performance.

An exemplary communication procedure between the serving enclave process 310 and the client enclave process 320 is described below in connection with fig. 4, 5A-5C. Fig. 4 shows a schematic flow diagram of a process 400 of performing inter-process communication between enclave processes according to an embodiment of the present disclosure. Process 400 may be an exemplary implementation of act 250 shown in fig. 2. It should be appreciated that process 400 may also include additional acts not shown and/or may omit acts shown, and may be performed in a different order, as the scope of the present disclosure is not limited in this respect. In addition, embodiments of the present disclosure support multiple rounds of communication for the same connection, with the steps of one round of communication being shown in fig. 4. These steps may be repeated in multiple rounds of communication.

At block 410, a service request for a client enclave process is written to a secure memory area based on a mapping of a virtual address range of the client enclave process to the secure memory area. By way of example, client enclave process 320 accesses virtual address range 326 associated with the desired service, virtual address range 326 being mapped to secure memory area 151. The request data of client enclave process 320 is written to secure memory area 151. In the case where the area 151 is specified to be encrypted and decrypted, the request data may be encrypted by the global shared key.

Fig. 5A-5C are schematic diagrams illustrating a process of an enclave process accessing a secure memory region according to an embodiment of the present disclosure. In fig. 5A, the secure memory area 151 may include a status area 51, a parameter area 52, and a data area 53. The status field 51 indicates the current status of the secure memory area 151 including, but not limited to, "initialize", "commit", "complete", and the like. The parameter area holds the request parameters of client enclave process 320, such as the requested service name, service function name. Data field 53 holds the requested data, e.g., function parameters, etc., of client enclave process 320. Data area 53 is used to store the results of the processing by service enclave process 320. The status area 51, parameter area 52, data area 53 of the secure shared memory area 151 may be continuous or discontinuous.

The client enclave process 320 may write 502 communication parameters required for one round of communication into the parameter area 52 of the secure memory area 151 and write 503 communication data required for one round of communication into the data area 53, and atomically update 501 the status area 51 to "commit" in the status area 51 of the secure shared memory, indicating that a service request exists. A memory barrier needs to be inserted between acts 502, 503 and act 501. All write operations before the memory barrier ensure that they are written to memory, and read operations after the memory barrier can obtain the result of write operations before the synchronization barrier. Client enclave process 320 may poll state 51 of the secure memory area after commit for "complete".

In response to the status indicating the presence of the service request, the service enclave process is caused to read the service request for processing based on a mapping of the virtual address range of the service enclave process to the secure memory region at block 420. As an example, the service enclave process 310 that establishes a communication connection polls the secure shared memory areas 151 through 15N for which the tokens correspond.

As shown in fig. 5B, if the status field 51 of a certain secure shared memory (e.g., field 151) is updated to "commit", the service enclave process 110 goes to the "commit" state by polling detection 504, the communication parameters of the client enclave process 320 are read 505 from the parameter field 52 and the communication data of the client enclave process 320 are read 506 from the data field 53.

At block 430, the results of the processing of the service request by the service enclave process are written to the secure memory area. As an example, the service enclave process 310 performs processing according to the communication parameters and communication data read from the parameter area 52 and the data area 53, and after the processing is completed, writes the returned result to the result area of the secure shared memory, writes the result parameter write 508 to the parameter area 52, and writes the result data to the data area 53.

At block 440, the state of the secure memory area is updated to indicate that the process is complete, such that the client enclave process obtains the processing results. As an example, the serving enclave process atomically updates 507 the state of the state region 51 of secure shared memory to "complete". A memory barrier is also inserted between acts 508, 509 and act 507. The serving enclave process 310 then continues to poll the secure shared memory 151 through 15N for the token. Process 400 may be repeated multiple times until inter-process communication between enclave processes is completed.

As mentioned above, the service enclave process 310 may have connections for multiple client enclave processes at the same time. Each connection has a corresponding secure memory area. In some embodiments, the service enclave process 310 may poll the areas and, in response to the status region of any of the areas indicating the presence of a service request ("commit" status), the service enclave process 310 reads the corresponding service request for processing.

In addition, upon ending the inter-process communication between client enclave process 320 and serving enclave process 310, the mapping of client enclave process 320 to secure memory area 15 may be unmapped, for example, by a privilege level call (e.g., enclave_shmdt) of security monitor 140. In addition, the token assigned to the client enclave process 320 may also be revoked by a privilege level call (e.g., enclave_shrvoke) of the security monitor 140, i.e., the same token cannot be reused to establish an address mapping of the secure memory area and the client enclave process to ensure security. In addition, the service enclave process 310 may also destroy the corresponding secure shared memory by invoking a privilege level call (e.g., enclave_shmdest) of the security monitor 140.

The mechanisms for directly sharing secure memory between enclave processes in a trusted execution environment, and bypassing a security monitor and runtime efficient communication when communicating between enclave processes implemented accordingly, are described above with reference to fig. 1-5C, according to embodiments of the present disclosure. Compared with the prior art, the method and the device have the advantages that at least the control surface and the data surface of the inter-process communication of the enclave are separated while the size of the trusted computing base is not increased significantly, so that asynchronous direct communication among the processes of the enclave is achieved without privilege level software in the communication process.

In order not to significantly increase the trusted computing base, a communication manager enclave process running in user mode is introduced, which is responsible for the establishment of the communication connection between the enclave processes. Specifically, an enclave service process for performing asynchronous inter-process communication registers service to a communication manager enclave process in a synchronous inter-process communication mode, service names and the number of the most accepted client enclave processes are required to be provided during registration, and the successfully registered enclave processes acquire tokens with the same maximum connection number from the communication manager; the client process of the enclave for asynchronous inter-process communication initiates communication connection to the communication manager in a synchronous inter-process communication mode, a corresponding service name is required to be provided when connection is initiated, and after connection is successful, the client enclave process acquires one token of the corresponding service from the communication manager. Upon successful acquisition, the serving enclave process of the communication maps its virtual address to the secure memory area using the same globally unique token acquired from the communication manager. And then, the client enclave process and the service enclave process communicate by using the secure shared memory without participation of a security monitor and a communication manager, so that a control plane and a data plane of communication are separated.

In some embodiments, encryption mechanisms for secure shared memory may also be used. Compared with the existing memory encryption mechanism, the method introduces a global shared key for encrypting and decrypting the safe shared memory in addition to the private key unique to each enclave process, wherein the key is provided by hardware or derived from the hardware key. In addition, a section of continuous virtual address space is reserved in the virtual address space of the enclave process and is specially used for mapping the virtual memory, the addresses and the sizes of the section of virtual address space are respectively stored in two introduced registers, when the accessed encrypted memory address is located in the shared memory virtual address interval, the global key is used for memory encryption and decryption operation, and otherwise, the private encryption and decryption key of the enclave process is used for memory encryption and decryption. In addition, the security monitor provides trusted memory management, each shared secure memory region is bound with a globally unique token, and only the enclave process having the corresponding token can map the secure memory region into the corresponding enclave process virtual address space region.

Fig. 6 shows a schematic block diagram of an apparatus for interprocess communication in accordance with an embodiment of the disclosure. The apparatus 600 includes a first allocation unit 610, a first mapping unit 610, a second allocation unit 630, a second mapping unit 640, and a communication performing unit 650. The first allocation unit 610 is configured to allocate at least one token to a service enclave process of a trusted execution environment. The first mapping unit 620 is configured to map the virtual address range of the serving enclave process to at least one secure memory area of the trusted execution environment based on the at least one token, each secure memory area being bound to one of the at least one token. The second allocation unit 630 is configured to allocate a token of the at least one token to a client enclave process of the trusted execution environment. The second mapping unit 640 is configured to map a virtual address range of the guest enclave process to a secure memory area bound to the token. The communication execution unit 650 is configured to perform inter-process communication of the service enclave process and the client enclave process based on the mapping of the virtual address range of the service enclave process and the virtual address range of the client enclave process to the secure memory area.

In some embodiments, the first allocation unit may be configured to initiate a communications manager enclave process for inter-process communications; in response to receiving a request to register a service for a service enclave process, a communication manager enclave process obtains at least one token for the service; and the communication manager enclave process assigning at least one token for the service to the service enclave process.

In some embodiments, the second allocation unit may be further configured to allocate a token of the at least one token to the client enclave process in response to receiving a request for service by the client enclave process.

In some embodiments, the communication manager enclave process is an enclave process running in a user state, wherein the communication manager enclave process assigns at least one token to the serving enclave process and assigns the token to the client enclave process based on control of a security monitor of the trusted execution environment.

In some embodiments, the first mapping unit may be further configured to: for each token in at least one token, creating a secure memory area bound with each token in a privilege state of a trusted execution environment to obtain at least one secure memory area; and mapping the virtual address range of the serving enclave process to at least one secure memory region.

In some embodiments, the apparatus 600 may further include a virtual address range determination unit. The virtual address range determination unit is configured to determine an address space for inter-process communication of the trusted execution environment based on a value of a register of the trusted execution environment; and determining a virtual address range of the serving enclave process and a virtual address range of the client enclave process in the address space.

In some embodiments, the apparatus 600 may further encrypt and decrypt the unit. The encryption and decryption unit is configured to generate a global shared key of the trusted execution environment; and in response to the service enclave process or the client enclave process accessing the secure memory region, encrypting and decrypting using the global shared key.

In some embodiments, the global shared key is generated based on or derived from hardware of the trusted execution environment, the encryption and decryption unit further being configured to encrypt and decrypt using the global shared key via hardware of the trusted execution environment.

In some embodiments, performing communication between the serving enclave process and the client enclave process includes: writing a service request of the client enclave process into the secure memory area based on the mapping of the virtual address range of the client enclave process to the secure memory area; updating the state of the secure memory area to indicate the presence of a service request; in response to the status indicating the presence of a service request, reading the service request by the service enclave process for processing based on a mapping of the virtual address range of the service enclave process to the secure memory area; writing a processing result of the service enclave process aiming at the service request into a safe memory area; and updating the state of the secure memory area to indicate that the processing is completed, so that the client enclave process obtains the processing result.

In some embodiments, the client enclave process is a first client enclave process, the token assigned to the first client enclave process is a first token, the secure memory area bound to the first token is a first secure memory area, and the second allocation unit may be further configured to: assigning a second token of the at least one token to a second client enclave process of the trusted execution environment; the virtual address range of the second client enclave process is mapped to a second secure memory area bound to the second token. The communication performing unit 650 may be further configured to perform communication between the serving enclave process and the second client enclave process based on the mapping of the virtual address range of the serving enclave process and the virtual address range of the second client enclave process to the second secure memory area.

In some embodiments, the communication execution unit 650 may be further configured to poll the first secure memory area and the second secure memory area; and responsive to the status of either the first secure memory area or the second secure memory area indicating the presence of a service request, the service enclave process reads the corresponding service request for processing.

Fig. 7 shows a schematic block diagram of an example device 7 that may be used to implement embodiments of the present disclosure. The apparatus 700 may be used to implement the processes 200 and 400 of fig. 2, 4 and the device 600 of fig. 6. As shown, the device 700 includes a Central Processing Unit (CPU) 701, and the central processing unit 701 may include a plurality of cores, each of which may perform various suitable actions and processes according to computer program instructions stored in a Read Only Memory (ROM) 702 or loaded from a storage unit 708 into a Random Access Memory (RAM) 703. In the RAM 703, various programs and data required for the operation of the device 700 may also be stored. The CPU 701, ROM 702, and RAM 703 are connected to each other through a bus 704. An input/output (I/O) interface 705 is also connected to bus 704.

Various components in device 1200 are connected to I/O interface 705, including: an input unit 706 such as a keyboard, a mouse, etc.; an output unit 707 such as various types of displays, speakers, and the like; a storage unit 708 such as a magnetic disk, an optical disk, or the like; and a communication unit 709 such as a network card, modem, wireless communication transceiver, etc. The communication unit 709 allows the device 700 to exchange information/data with other devices via a computer network, such as the internet, and/or various telecommunication networks.

The various processes and treatments described above, such as processes 200, 400, may be performed by one or more cores in the processing unit 701. For example, in some embodiments, the processes 200, 400 may be implemented as a computer software program tangibly embodied on a machine-readable medium, such as the storage unit 708. In some embodiments, part or all of the computer program may be loaded and/or installed onto device 1200 via ROM 702 and/or communication unit 709. When the computer program is loaded into RAM 703 and executed by CPU 701 or a core of the CPU, one or more of the acts of processes 200, 400 described above may be performed.

The present disclosure may be methods, apparatus, systems, and/or computer program products. The computer program product may include a computer readable storage medium having computer readable program instructions embodied thereon for performing aspects of the present disclosure.

The computer readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer-readable storage medium would include the following: portable computer disks, hard disks, random Access Memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static Random Access Memory (SRAM), portable compact disk read-only memory (CD-ROM), digital Versatile Disks (DVD), memory sticks, floppy disks, mechanical coding devices, punch cards or in-groove structures such as punch cards or grooves having instructions stored thereon, and any suitable combination of the foregoing. Computer-readable storage media, as used herein, are not to be construed as transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., optical pulses through fiber optic cables), or electrical signals transmitted through wires.

The computer readable program instructions described herein may be downloaded from a computer readable storage medium to a respective computing/processing device or to an external computer or external storage device over a network, such as the internet, a local area network, a wide area network, and/or a wireless network. The network may include copper transmission cables, fiber optic transmissions, wireless transmissions, routers, firewalls, switches, gateway computers and/or edge servers. The network interface card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium in the respective computing/processing device.

Computer program instructions for performing the operations of the present disclosure can be assembly instructions, instruction Set Architecture (ISA) instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, c++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions may be executed entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer (for example, through the Internet using an Internet service provider). In some embodiments, aspects of the present disclosure are implemented by personalizing electronic circuitry, such as programmable logic circuitry, field Programmable Gate Arrays (FPGAs), or Programmable Logic Arrays (PLAs), with state information of computer readable program instructions, which can execute the computer readable program instructions.

Various aspects of the present disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer-readable program instructions.

These computer readable program instructions may be provided to a processing unit of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processing unit of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable medium having the instructions stored therein includes an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer, other programmable apparatus or other devices implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The embodiments of the present disclosure have been described above, the foregoing description is illustrative, not exhaustive, and not limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the various embodiments described. The terminology used herein was chosen in order to best explain the principles of the embodiments, the practical application, or the improvement of technology in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A method for interprocess communication, comprising:

assigning at least one token to a service enclave process of a trusted execution environment;

mapping a virtual address range of the service enclave process to at least one secure memory area of the trusted execution environment based on the at least one token, each secure memory area being bound to one of the at least one token;

assigning a token of the at least one token to a client enclave process of the trusted execution environment;

mapping the virtual address range of the client enclave process to a secure memory area bound with the token; and

Inter-process communication of the service enclave process and the client enclave process is performed based on a mapping of the virtual address range of the service enclave process and the virtual address range of the client enclave process to the secure memory area.

2. The method of claim 1, wherein assigning at least one token to a service enclave process of the executable environment comprises:

starting a communication manager enclave process for inter-process communication;

in response to receiving a request to register for a service by the service enclave process, the communication manager enclave process obtains at least one token for the service; and

the communication manager enclave process assigns the at least one token for the service to the service enclave process.

3. The method of claim 2, wherein assigning the token to a client enclave process of the trusted execution environment comprises:

in response to receiving a request for the service by the client enclave process, the communication manager enclave process allocates the token of the at least one token to the client enclave process.

4. A method according to claim 2 or 3, wherein the communications manager enclave process is an enclave process running in a user state, wherein the communications manager enclave process allocates the at least one token to the serving enclave process and the token to the client enclave process based on control of a security monitor of the trusted execution environment.

5. The method of claim 1, wherein mapping the virtual address range of the service enclave process to at least one secure memory region of the trusted execution environment comprises:

for each token in the at least one token, creating a secure memory area bound with each token in the privilege state of the trusted execution environment to obtain the at least one secure memory area; and

mapping the virtual address range of the service enclave process to the at least one secure memory area.

6. The method of claim 1, further comprising:

determining an address space for inter-process communication of the trusted execution environment based on a value of a register of the trusted execution environment; and

a virtual address range of the serving enclave process and a virtual address range of the client enclave process are determined in the address space.

7. The method of claim 1, further comprising:

generating a global shared key of the trusted execution environment; and

encrypting and decrypting using the global shared key in response to the serving enclave process or the client enclave process accessing the secure memory region.

8. The method of claim 7, wherein the global shared key is generated based on or derived from hardware of the trusted execution environment, and encrypting and decrypting using the global shared key comprises:

encryption and decryption are performed using the global shared key via hardware of the trusted execution environment.

9. The method of claim 1, wherein performing communication between the serving enclave process and the client enclave process comprises:

writing a service request of the client enclave process into the secure memory area based on a mapping of a virtual address range of the client enclave process to the secure memory area;

updating the state of the secure memory area to indicate the presence of a service request;

in response to the status indicating a presence of a service request, reading, by the service enclave process, the service request for processing based on a mapping of a virtual address range of the service enclave process to the secure memory area;

writing a processing result of the service enclave process for the service request into the secure memory area; and

updating the state of the secure memory area to indicate that the processing is completed, so that the client enclave process obtains the processing result.

10. The method of claim 1, the client enclave process being a first client enclave process, the token assigned to the first client enclave process being a first token, the secure memory region bound to the first token being a first secure memory region, the method further comprising:

assigning a second token of the at least one token to a second client enclave process of the trusted execution environment;

mapping the virtual address range of the second client enclave process to a second secure memory area bound to the second token; and

communication between the service enclave process and the second client enclave process is performed based on the virtual address range of the service enclave process and the mapping of the virtual address range of the second client enclave process to the second secure memory area.

11. The method of claim 10, further comprising:

polling the first secure memory area and the second secure memory area; and

in response to the status of either of the first secure memory area and the second secure memory area indicating the presence of a service request, the service enclave process reads the corresponding service request for processing.

12. An apparatus for interprocess communication, comprising:

a first allocation unit configured to allocate at least one token to a service enclave process of the trusted execution environment;

a first mapping unit configured to map a virtual address range of the service enclave process to at least one secure memory area of the trusted execution environment based on the at least one token, each secure memory area being bound to one of the at least one token;

a second allocation unit configured to allocate a token of the at least one token to a client enclave process of the trusted execution environment;

a second mapping unit configured to map a virtual address range of the client enclave process to a secure memory area bound to the token; and

and a communication execution unit configured to execute inter-process communication of the service enclave process and the client enclave process based on the virtual address range of the service enclave process and the mapping of the virtual address range of the client enclave process to the secure memory area.

13. An electronic device comprising

A processor including a plurality of processing cores; and

A memory;

at least one of the plurality of processing cores is configured to execute instructions in the memory, causing the electronic device to perform the method of any one of claims 1-11.

14. A computer-readable storage medium having stored thereon one or more computer instructions, wherein execution of the one or more computer instructions by a processor causes the processor to perform the method of any of claims 1 to 8.

15. A computer program product comprising machine executable instructions which, when executed by a device, cause the device to perform the method of any one of claims 1 to 11.