CN114661380A

CN114661380A - Trusted execution environment-oriented system call processing method and device

Info

Publication number: CN114661380A
Application number: CN202210396789.1A
Authority: CN
Inventors: 王烁程; 闫守孟; 田洪亮; 顾宗敏
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2020-12-31
Filing date: 2020-12-31
Publication date: 2022-06-24
Also published as: CN112685101B; CN112685101A

Abstract

The embodiment of the specification provides a trusted execution environment-oriented system call processing method and device. The method can comprise the following steps: an IO class system call request initiated by an application running in a trusted execution environment is received. The system call request is then written to a shared memory region outside the trusted execution environment, and an IO request event is written to an IO request queue outside the trusted execution environment, where the IO request event includes a first address of the system call request in the shared memory region and a second address of the shared memory region for storing business data. In this way, the system kernel may process the system call request according to the IO request event, and write an IO completion event into an IO completion queue outside the trusted execution environment, where the IO completion event includes a processing result of the system kernel on the IO request. And finally, at least returning the processing result in the IO completion event to the application program in the trusted execution environment.

Description

Trusted execution environment-oriented system call processing method and device

The present application is a divisional application of an invention patent application with application number 202011638265.6 entitled "trusted execution environment-oriented system call processing method and apparatus", which is filed on 31/12/2020.

Technical Field

One or more embodiments of the present disclosure relate to the field of computers, and in particular, to a trusted execution environment-oriented system call processing method and apparatus.

Background

Software guard extensions (SGX) is a security extension under the Intel (Intel) chip architecture. SGX allows applications to run in a Trusted Execution Environment (TEE) called Enclave. Enclave is a trusted memory area, all contents in the Enclave are encrypted, and the contents in the Enclave can be decrypted only inside a Central Processing Unit (CPU), so that confidentiality is provided. Furthermore, integrity measurement is performed on the content in Enclave, thereby providing integrity. Based on the integrity and confidentiality provided by SGX, TEEs for security sensitive computing may be provided for applications.

Computer programs running in Enclave are called trusted code (trusted code) and computer programs running outside Enclave are called untrusted code (untrusted code). The trusted code and the untrusted code can be mutually called, so that the program function is realized under the condition that confidential calculation is guaranteed. Trusted code calls untrusted code is commonly referred to as OCall. Since Enclave is user mode, the application running in Enclave often needs to call an external system to implement the program function, i.e. needs to implement the program function through untrusted code. When the application program in the Enclave calls the system, an OCall needs to be carried out, call parameters are copied out of the Enclave, the Enclave is exited through an EEXIT instruction, then the system call is executed through an untrusted code, the Enclave is recovered after the execution is finished, a call result is copied into the Enclave, and the call result in the Enclave is provided for the application program.

Since about 8300-14100 CPU cycles are generally required for performing an OCall once and about 150 CPU cycles are required for performing a typical system call, a great deal of processing time is wasted in processing a system call request initiated by an application running in a trusted execution environment by performing an OCall in the trusted execution environment. However, the application program running in Enclave often needs to make high-frequency system calls, so implementing the system call through the OCall has a large negative impact on the overall performance of the application program running in Enclave.

A new technical scheme is expected to reduce the amount of ocalls when the system call is performed on the application program running in Enclave, so as to improve the overall performance of the application program running in Enclave.

Disclosure of Invention

One or more embodiments of the present specification provide a trusted execution environment-oriented system call processing method and apparatus.

In a first aspect, a trusted execution environment-oriented system call processing method is provided. The method may be performed by a system call processing apparatus deployed in a trusted execution environment. The method comprises the following steps: the method comprises the steps of firstly receiving a system calling request initiated by an application program running in a trusted execution environment, wherein the system calling request is used for requesting to write business data into a target file or request to read the business data from the target file. The system call request is then written to a shared memory region outside the trusted execution environment, and an IO request event is written to an IO request queue stored outside the trusted execution environment, where the IO request event includes a first address of the system call request in the shared memory region and a second address for storing business data in the shared memory region. Therefore, the system kernel can process the system call request according to the IO request event and write an IO completion event into an IO completion queue stored outside the trusted execution environment, where the IO completion event includes a processing result of the system kernel on the IO request. And finally, returning the processing result in the IO completion event at least to the application program in the trusted execution environment.

In a possible implementation manner, when the system call request is used to request to write service data to a target file, the method further includes: writing service data into the second address of the shared memory area according to the system call request; the system kernel is specifically configured to read the system call request from the first address of the shared memory area according to the IO request event, read the service data from the second address, and write the service data into a target file according to the system call request.

In a possible implementation manner, when the system call request is used to request to read service data from a target file, the system kernel is specifically configured to read the system call request from the first address of the shared memory region according to the IO request event, read service data from the target file according to the system call request, and write the service data into the shared memory region according to the second address;

the method further comprises the following steps: providing the service data in the shared memory area to the application program.

In one possible embodiment, the method further comprises: generating a unique identifier of the system call request, wherein the IO request event and the IO completion event further comprise the unique identifier; and polling the IO completion event in the IO completion queue according to the unique identifier.

In one possible implementation, before receiving a system call request initiated by an application running in a trusted execution environment, the method further includes: initializing the IO request queue, the IO completion queue and the shared memory area by operating a service program outside a trusted execution environment, and triggering a system kernel to start a polling thread for polling the IO request queue.

In one possible embodiment, the method further comprises: and acquiring configuration information for accessing the IO request queue, the IO completion queue and the shared memory area by a service program running outside a trusted execution environment.

In a possible implementation manner, the writing an IO request event to an IO request queue stored outside a trusted execution environment specifically includes: and acquiring a thread lock for accessing an IO request queue stored outside a trusted execution environment, and writing the IO request event into the IO request queue through the thread lock.

In one possible embodiment, the type of the system call request is any one of the following types: read, write, readv, writev, fsync, poll, send _ msg, recv _ msg, openat, close, accept, connect, epoll _ ctl, send, and recv.

In a second aspect, a trusted execution environment-oriented system call processing apparatus is provided, which may be deployed in a trusted execution environment. The device at least comprises: the request receiving unit is used for receiving a system calling request initiated by an application program running in a trusted execution environment; the system call request is used for requesting to write service data into a target file or requesting to read the service data from the target file. The data writing unit is used for writing the system call request into a shared memory area outside the trusted execution environment and writing an IO request event into an IO request queue stored outside the trusted execution environment; the IO request event comprises a first address of the system call request in the shared memory area and a second address used for storing business data in the shared memory area, so that a system kernel processes the system call request according to the IO request event and writes an IO completion event into an IO completion queue stored outside a trusted execution environment, wherein the IO completion event comprises a processing result of the system kernel on the IO request. And the data providing unit is used for providing the processing result in the IO completion event at least for the application program.

In a possible implementation manner, when the system call request is used to request to write service data into a target file, the data writing unit is further configured to write service data into the shared memory area according to the system call request; the system kernel is specifically configured to read the system call request and the service data from the shared memory area according to the IO request event, and write the service data into a target file according to the system call request.

In a possible implementation manner, when the system call request is used to request to read service data from a target file, the system kernel is specifically configured to read the system call request from the shared memory region according to the IO request event, read service data from the target file according to the system call request, and write the service data into the shared memory region according to the second address;

the data providing unit is further configured to provide the service data in the shared memory area to the application program.

In one possible embodiment, the apparatus further comprises: the identification management unit is used for generating a unique identification of the system calling request; wherein the IO request event and the IO completion event further include the unique identifier. And the queue polling unit is used for polling the IO completion event in the IO completion queue according to the unique identifier.

In one possible embodiment, the apparatus further comprises: and the initialization configuration unit is used for initializing the IO request queue, the IO completion queue and the shared memory area through a service program running outside a trusted execution environment, and triggering a system kernel to start a polling thread for polling the IO request queue.

In a possible implementation manner, the initialization configuration unit is further configured to obtain, through a service program running outside a trusted execution environment, configuration information for accessing the IO request queue, the IO completion queue, and the shared memory area.

In a possible implementation manner, the data writing unit is specifically configured to acquire a thread lock for accessing an IO request queue stored outside a trusted execution environment, and write the IO request event into the IO request queue through the thread lock.

In a third aspect, a trusted execution environment-oriented system call processing method is provided, which may be executed by a system call processing apparatus deployed in a trusted execution environment. The method at least comprises the following steps: acquiring a first address of a Virtual Dynamic Shared Object (VDSO) in a memory area outside a trusted execution environment, wherein the memory area further includes a data segment for storing a plurality of time data, and the VDSO includes a plurality of system call functions for accessing the data segment; secondly, loading the VDSO in the trusted execution environment according to the first address, and modifying the addressing mode of the VDSO in the trusted execution environment to the data segment according to the first address and the second address of the VDSO in the trusted execution environment; finally, a system call request initiated by the application program in the trusted execution environment is received through the modified VDSO, the current time data is read from the plurality of time data stored in the data segment according to the system call request, and the read current time data is provided for the application program in the trusted execution environment.

In one possible embodiment, before modifying VDSO in the trusted execution environment, the method further comprises: it is determined whether VDSO in the trusted execution environment is trusted.

In a possible implementation, determining whether the VDSO in the trusted execution environment is trusted specifically includes: recursively disassembling a plurality of system call functions included in a VDSO in a trusted execution environment to obtain instruction sets corresponding to the system call functions; and in the process of recursively disassembling any current system call function in the plurality of system call functions, when a current instruction acquired at the current moment meets any one of at least one preset condition, determining that the VDSO in the trusted execution environment is not trusted.

In a possible embodiment, the at least one preset condition comprises one or more of the following preset conditions: the current instruction is a control transfer instruction except the RET instruction, the addressing mode of the current instruction is direct addressing, the current instruction is an unallowed instruction, and errors exist in disassembling of the current instruction.

In one possible implementation, determining whether VDSO in the trusted execution environment is trusted further comprises: traversing any current instruction set in the instruction sets, and constructing a control flow graph which takes a basic block as a node and takes control transfer as an edge by using instructions included in the current instruction set; wherein the basic block is a set of consecutive instructions having one entry and having one exit. Processing the control flow graph through a predetermined algorithm in a traversing manner to determine whether a system call function corresponding to the current instruction set is a trusted function; when the untrusted function is not present, it is determined that the VDSO in the trusted execution environment is trusted.

In a possible implementation manner, the control flow graph is processed through a predetermined algorithm in a traversal manner to determine whether a system call function corresponding to the current instruction set is a trusted function, which specifically includes: in the process of traversing and processing the control flow graph through a preset algorithm, for any current node in the control flow graph, if stack structures of output states of a plurality of precursor nodes of the current node are not identical, a system call function corresponding to the current instruction set is determined to be an untrusted function.

In a possible implementation manner, the control flow graph is processed through traversal by a predetermined algorithm to determine whether a system call function corresponding to the current instruction set is a trusted function, which specifically includes: in the process of traversing the control flow graph through a preset algorithm, for any current node in the control flow graph, if the memory access of the current node is illegal, the system call function corresponding to the current instruction set is determined to be an untrusted function.

In one possible implementation, recursively disassembling a plurality of system call functions included in VDSO in a trusted execution environment includes: and recursively disassembling the system calling functions included by the VDSO in the trusted execution environment according to the address information corresponding to the system calling functions included by the VDSO in the trusted execution environment.

In a possible embodiment, modifying, according to the first address and the second address of the VDSO in the trusted execution environment, the manner in which the VDSO addresses the data segment in the trusted execution environment includes: determining an address offset for the first address and the second address; writing the address offset into an FS segment register and/or a GS segment register; and modifying the addressing mode of the VDSO in the trusted execution environment to the data segment into addressing through the FS segment register or the GS segment register.

In one possible implementation, the type of the system call request includes clock _ gettime, gettimeoffset, time.

In a fourth aspect, a trusted execution environment-oriented system call processing apparatus is provided, the apparatus being deployed in a trusted execution environment. The device at least comprises: the information acquisition unit is used for acquiring a first address of the VDSO in a memory area outside the trusted execution environment; the memory area further comprises a data segment for storing a plurality of time data, and the VDSO comprises a plurality of system call functions for accessing the data segment. And the loading processing unit is used for loading the VDSO in the trusted execution environment according to the first address. A modification processing unit for modifying the VDSO in the trusted execution environment according to the first address and a second address of the VDSO in the trusted execution environment; the modified VDSO is specifically configured to receive a system call request initiated by an application program in the trusted execution environment, read current time data from the multiple pieces of time data stored in the data segment according to the system call request, and provide the current time data read by the application program to the application program.

In one possible embodiment, the method further comprises: a trusted verification unit to determine whether the VDSO in the trusted execution environment is trusted.

In a possible implementation manner, the trusted verification unit is specifically configured to: recursively disassembling a plurality of system call functions included in a VDSO in a trusted execution environment to obtain instruction sets corresponding to the system call functions; and in the process of recursively disassembling any current system call function in the plurality of system call functions, when a current instruction acquired at the current moment meets any one of at least one preset condition, determining that the VDSO in the trusted execution environment is not trusted.

In a possible implementation, the trust verification unit is specifically configured to traverse any current instruction set in each of the instruction sets, and construct a control flow graph with a basic block as a node and a control transfer as an edge by using instructions included in the current instruction set, where the basic block is a set of consecutive instructions having an entry and having an exit; traversing the control flow graph through a preset algorithm to determine whether a system call function corresponding to the current instruction set is a trusted function; when the untrusted function is not present, it is determined that the VDSO in the trusted execution environment is trusted.

In a possible implementation manner, the trust verification unit is specifically configured to, in the process of processing the control flow graph through traversal by using a predetermined algorithm, determine, for any current node in the control flow graph, that a system call function corresponding to the current instruction set is an untrusted function if stack structures of output states of a number of predecessor nodes of the current node are not identical.

In a possible implementation manner, the trust verification unit is specifically configured to, in the process of processing the control flow graph through traversal by using a predetermined algorithm, determine, for any current node in the control flow graph, that a system call function corresponding to the current instruction set is an untrusted function if memory access of the current node is not legal.

In a possible implementation, the trusted verification unit is specifically configured to recursively disassemble the system call functions included in the VDSO in the trusted execution environment according to address information corresponding to the system call functions included in the VDSO in the trusted execution environment.

In a possible implementation, the modification processing unit is specifically configured to determine an address offset of the first address and the second address; writing the address offset into an FS segment register and/or a GS segment register; and modifying the addressing mode of the VDSO in the trusted execution environment to the data segment into addressing through the FS segment register or the GS segment register.

In a fifth aspect, there is provided a computer readable storage medium having stored thereon a computer program/instructions which, when executed in a computing device, the computing device performs the method of any of the first or third aspects.

In a sixth aspect, there is provided a computing device comprising a memory having stored therein a computer program/instructions and a processor executing the computer program/instructions to implement the method of any one of the first or third aspects.

Through the method and the apparatus provided in one or more embodiments of the present specification, on one hand, when an application running in a trusted execution environment initiates an IO-class system call request and a time-class system call request, that is, when the application running in the trusted execution environment initiates a system call request for requesting to write service data into a target file or to read service data from the target file, and initiates a system call request for requesting to read time data, a program function that the system call request is expected to implement can be completed more quickly without performing OCALL, which is beneficial to improving the performance of the application running in the trusted execution environment.

Drawings

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

FIG. 1 is one of the system frameworks of the solutions provided in the embodiments of the present specification;

fig. 2 is a schematic flowchart of a trusted execution environment-oriented system call processing method provided in an embodiment of the present specification;

fig. 3 is a flowchart of another trusted execution environment-oriented system call processing method provided in an embodiment of the present specification;

fig. 4 is a schematic structural diagram of a system call processing apparatus oriented to a trusted execution environment provided in an embodiment of the present specification;

FIG. 5 is a second system framework of the solution provided in the embodiments of the present description;

fig. 6 is a flowchart of another trusted execution environment-oriented system call processing method provided in an embodiment of the present specification;

fig. 7 is a flowchart of another trusted execution environment-oriented system call processing method provided in an embodiment of the present specification;

fig. 8 is a schematic diagram of a process of modifying VDSO in a trusted execution environment in an embodiment of the present description;

fig. 9 is a schematic structural diagram of another system call processing apparatus oriented to a trusted execution environment provided in an embodiment of this specification.

Detailed Description

Various non-limiting embodiments provided by the present specification are described in detail below with reference to the attached figures.

Fig. 1 is one of system framework diagrams of the technical solutions provided in the embodiments of the present specification. As shown in fig. 1, in order to improve the security of a system kernel (kernel) of an operating system adopted by a computing device or a virtual computing node, an operating system is generally required to divide a memory resource into two parts, namely a kernel space and a user space. The system kernel is independent of the normal computer program running in user space, and can access the protected kernel space while having all the rights to access the underlying hardware devices, such as reading/writing a target file stored in a non-volatile memory, or reading/writing a temporary target file on a memory resource. The trusted execution environment is a trusted memory area in the user space, and the user space other than the trusted execution environment is generally referred to as a process space for descriptive convenience.

An application running in a trusted execution environment may initiate a system call request to the system kernel requesting the system kernel to provide a service that requires higher permissions to run. The system call request may include, but is not limited to, an IO class system call request and a time class system call request. The IO-class system call request refers to various system call requests for requesting a system kernel to perform network read-write and disk read-write, for example, requests to write service data into a target file or read service data from the target file, where the target file may be a local file stored in a disk/nonvolatile memory or a temporary/network file on a memory resource. The time class system call request refers to a system call request for requesting to read time data and related information thereof.

As described above, when the application running in the trusted execution environment implements system call through the OCall, because the OCall needs to consume a long time, the application running in the trusted execution environment often needs to make high-frequency system call, which has a great impact on the overall performance of the application running in the trusted execution environment.

In one possible solution, the shared memory area may be configured outside the trusted execution environment, and a number of work threads may be run outside the trusted execution environment. When an application program in the trusted execution environment needs to perform system call, the system call request can be written into the shared memory area, and the execution condition of the system call request in the shared memory area is continuously checked; and the working thread outside the trusted execution environment continuously checks whether the system call request exists in the shared memory area, processes the found system call request if the system call request is found, and writes the processing result into the shared memory area. After the application program in the trusted execution environment checks that the system call request is successfully processed, the processing result is read from the shared memory area to complete one system call.

In the technical scheme, the working thread and the application program in the trusted execution environment can poll the shared memory area. However, it is substantially difficult to determine the number of the working threads, and too few working threads may cause the system call request to be executed quickly, which may cause the overall performance of the application program to be degraded; too many threads of work waste computing resources and may also result in a reduction in the overall performance of the application.

In view of the foregoing, at least one embodiment of the present specification provides a method and an apparatus for processing a system call oriented to a trusted execution environment.

Fig. 2 is a flowchart of a trusted execution environment-oriented system call processing method provided in an embodiment of the present specification. The method may be performed by a system call processing apparatus deployed in a trusted execution environment.

As shown in fig. 2, the method may include: step 201, receiving a system call request initiated by an application program running in a trusted execution environment; the system call request is used for requesting to write the service data into the target file or requesting to read the service data from the target file. Step 202, writing a system call request into a shared memory region outside the trusted execution environment, and writing an IO request event into an IO request queue stored outside the trusted execution environment, where the IO request event includes a first address of the system call request in the shared memory region and a second address used for storing service data in the shared memory region, so that the system kernel processes the system call request according to the IO request event, and writes an IO completion event into an IO completion queue stored outside the trusted execution environment, where the IO completion event includes a processing result of checking the IO request in the system kernel. Step 203, at least providing the processing result in the IO completion event to the application program.

Through the technical scheme provided in the embodiment of the present specification, when an application program running in a trusted execution environment initiates an IO-type system call request, that is, when a system call request for requesting to write service data into a target file or to read service data from the target file is initiated, a program function that the system call request is expected to achieve can be completed more quickly without performing OCALL, which is beneficial to improving the performance of the application program running in the trusted execution environment.

The trusted execution environment-oriented system call processing method is described in the following with reference to the system framework shown in fig. 1. As shown in fig. 1, a system call processing apparatus is deployed in the trusted execution environment, and a business program cooperating with the system call processing apparatus runs in a process space outside the trusted execution environment.

Fig. 3 is a flowchart of another trusted execution environment-oriented system processing method provided in an embodiment of the present specification. The method may include some or all of steps 3011 through 3112 as shown in fig. 3.

First, in step 3011, the system call processing device sends a call request to a service program running in a process space.

Next, the service program, in response to the received call request, performs steps 3012 to 3014: step 3012, initialize the shared memory area, IO request queue and IO completion queue in the process space; step 3013, triggering the system kernel to start a polling thread for polling the IO request queue; step 3014, send the configuration information of the shared memory area, the IO request queue, and the IO completion queue to the system call processing device.

The shared memory region may also be referred to as a data buffer, and is used to store a system call request (or a data structure of the system call request) initiated by an application program in the trusted execution environment to the system call processing device in a subsequent process, service data that the system call request desires to write into a target file, and service data that the system call request desires to read. The use of memory addresses in the shared memory area is managed by the system call processing means.

The service program can utilize the existing interface device of the system kernel to initialize the IO completion queue and the IO request queue, and trigger the system kernel to start the polling thread for polling the IO request queue. Or, a corresponding interface device may be extended in the system kernel, and the service program uses the extended interface device to initialize the IO completion queue and the IO request queue, and triggers the system kernel to start a polling thread for polling the IO request queue.

For example, the system kernel of the operating system employed by the computing device or the virtual computing node is a Linux system kernel. The Linux system kernel provides an asynchronous IO interface device IO _ ring. After the business program finishes initializing the shared memory area, IO _ urning can be initialized according to the working mechanism of IO _ urning, and an IO request queue and an IO completion queue are maintained in a process space through IO _ urning. The operating mode of IO _ aging is then configured as IORING _ SETUP _ SQPOLL mode, and IO _ aging, which is configured as IORING _ SETUP _ SQPOLL mode, will request the system kernel to start a kernel thread (i.e., polling thread) for polling the IO request queue.

When the system kernel processing device receives the configuration information of the shared memory region, the IO request queue and the IO completion queue, the data structures of the shared memory region, the IO request queue and the IO completion queue may be configured, so that the shared memory region, the IO request queue and the IO completion queue may be accessed and managed through the configured data structures in the following. It should be noted that, when the IO request queue and the IO completion queue are initialized by IO _ ending, the configuration information of the IO request queue and the IO completion queue is the configuration information of IO _ ending, and the data structures of the IO request queue and the IO completion queue are the data structures of IO _ ending.

The system call processing means may operate in a single thread mode or a multi-thread mode. When the system call processing device works in a multithreading mode, thread locks can be respectively configured on the IO request queue, the IO completion queue and the shared memory area. The thread lock is a code block for accessing a corresponding service object (an IO request queue, an IO completion queue, or a shared memory area), and only a single thread that obtains the thread lock is allowed to access the corresponding service object at the same time.

After the processing procedures in steps 3011 to 3014 are completed, the application running in the trusted execution environment may initiate a system call request to the system call processing device. Correspondingly, in step 302, the system call processing apparatus receives a system call request initiated by an application running in the trusted execution environment.

The system call request from the application program includes an IO system call request that is expected to implement program functions such as network read-write and disk read-write, and is specifically used for requesting to write service data into a target file or to read service data from the target file. The target file may be a local file stored in a non-volatile memory such as a disk, or may be a temporary file on a memory resource.

Specifically, the types of the system call request may include: read, write, readv, writev, fsync, poll, send _ msg, recv _ msg, openat, close, accept, connect, epoll _ ctl, send, or recv.

Next, in step 3031, the system call processing apparatus writes the received system call request to the shared memory area.

Specifically, the system call processing apparatus may allocate a first address for storing the system call request and allocate a second address for storing the service data in the shared memory area. The system call request is then written to the assigned first address.

When the system call request is for requesting to read the service data from the target file, the system call processing means directly performs step 304 or step 305 after completing the step 3031.

When the system call request is used to request to write the service data into the target file, the system call processing device may further perform step 3032, and after performing step 3032, perform step 304 or step 305.

In step 3032, the system call processing device writes the service data into the shared memory area.

The system call processing device may write the service data in the trusted execution environment into a second address for storing the service data in the shared memory region according to an indication of the system call request.

At step 304, the system call processing device generates a unique identification for the system call request.

Next, in step 305, the system call processing apparatus writes an IO request event corresponding to the system call request to the IO request queue.

The IO request event includes a first address of the system call request in the shared memory region, and includes a second address for storing business data in the shared memory region, optionally including a unique identifier of the system call request.

Take the IO request queue initialized by IO _ ending as an example. The system call processing device may compose an IO request event including the first address and the second address according to a data structure required by IO _ urning, record a unique identifier of the system call request (or the IO request event) in a user data field (user _ data) of the IO request event, and finally submit the IO request event to an IO request queue initialized by IO _ urning.

It should be noted that, when the system call processing device operates in the multithreading mode, the thread receiving the IO completion event may first obtain a thread lock for accessing the IO request queue, and write the IO request event into the IO request queue through the thread lock.

It should be noted that part or all of the information included in the system call request may be included in the IO request event. For example, the request type of the system call request and/or a file descriptor for accessing the target file may be included in the IO request event.

It should be noted that for io _ urning of some specific kernel versions, if an application program requests to access a target file for the first time, the target file also needs to be registered in a file set allowed by io _ urning.

Since the system kernel already starts a polling thread for polling the IO request queue, the system kernel can discover an IO request event written into the IO request queue by the system calling device through the polling thread. Accordingly, when the system kernel finds the IO request event in the IO request queue by the polling thread, step 306 may be executed to read the IO request event from the IO request queue.

Next, in step 3071, the system kernel reads the system call request from the shared memory area according to the first address in the IO request event read by the system kernel.

When the system call request is used to request to read the service data from the target file, the system kernel may directly perform step 308 after completing step 3071.

The system call request is used to request to write service data into the target file, and after the system kernel completes execution of step 3071, step 3072 may also be executed, and after execution of step 3072, step 308 is executed.

In step 3072, the service data is read from the shared memory region according to the second address in the IO request event read by the shared memory region.

In step 308, the system kernel processes the system call request it reads and obtains the processing result.

Specifically, when the system call request is used to request to write service data into a target file, the system kernel may write the service data read from the shared memory area into the target file according to the system call request, and obtain a processing result of the system call request. When the system call request is used for requesting to read the service data from the target file, the system kernel can read the service data from the target file according to the system call request and obtain a processing result of the system call request.

The processing result is used for indicating the processing condition of the system kernel to the system call request, such as the byte number of the service data which is used for indicating the successful reading/writing of the system kernel.

Next, at step 3091, the system kernel writes the IO completion event to the IO completion queue.

The IO completion event includes a processing result of the system call request, and optionally further includes a unique identifier of the system call request.

When the system call request is used to request to read the service data from the target file, the system kernel may further perform step 3092, and write the read service data into the shared memory region according to the second address in the IO request event read by the system kernel.

Next, at step 3101, the system call processing device reads the IO completion event from the IO completion queue.

Specifically, the system call processing device polls the IO completion queue after completing writing the IO request event into the IO request queue. When the system call processing device works in a single-thread mode, the system call processing device only submits one IO request event to an IO request queue each time, then, the system call processing device starts to poll the IO completion queue to wait for the system call to be processed by a system kernel, at most one IO completion event exists in the IO completion queue, and the system call processing device can read the IO completion event corresponding to the IO request event/system call request submitted in advance. When the system call processing device works in a multithreading mode, the IO request queue may include a plurality of IO request events, the IO completion queue may include a plurality of IO completion events, and the arrangement sequence of the plurality of IO request events may not be consistent with the arrangement sequence of the plurality of IO completion events, at this time, a thread lock for accessing the IO completion queue needs to be set; any current thread in the multiple threads corresponding to the system call processing device can read the corresponding IO completion event from the IO request queue through the obtained thread lock according to the unique identifier of the corresponding system call request after obtaining the thread lock for accessing the IO completion queue.

The system call request is used to request to write service data into the target file, and after the system call processing device completes the read IO completion event, the step 3111 may be continuously executed to complete processing the system call request. In addition, the first address and the second address in the shared memory area can be released.

When the system call request is used to request to read the service data from the target file, the system kernel may perform step 3102, and then perform step 3111 and step 3112 to complete processing the system call request. In addition, the first address and the second address in the shared memory area can be released.

In step 3102, the system call processing device reads the service data from the shared memory region according to the second address.

In step 3111, the system call processing means provides the processing result to the application program.

In step 3112, the system call processing device provides the service data it reads to the application.

It should be noted that step 3111 and step 3112 may be combined into one step, and the system call processing apparatus provides the system call result to the application program. When the system call request is used for requesting to read the service data from the target file, the system call result may include a processing result, and the service data read by the system call processing device or address information of the service data in the trusted execution environment. When the system call request is used to request to write the service data into the target file, the system call result may include a processing result.

It should be noted that, after the application program in the trusted execution environment is completely run, the system call processing device may also release the shared memory area, the IO request queue, and the IO completion queue through the service program. Such as by the service closing io _ warning and releasing the shared memory region.

Based on the embodiments shown in fig. 2 and fig. 3, when the IO request queue and the IO completion queue are initialized by IO _ ending, because an adaptive workload mechanism is provided inside IO _ ending, computing resources can be saved while improving efficiency.

Based on the embodiments shown in fig. 2 and fig. 3, when the IO request queue and the IO completion queue are initialized by IO _ ending, since IO _ ending hides the complex mechanism inside it, developers do not need to implement the complex mechanism themselves, and only the IO _ ending specification interface is used, so that the technical scheme is easy to implement.

Based on the embodiments shown in fig. 2 and fig. 3, when the IO request queue and the IO completion queue are initialized by IO _ urning, IO _ urning itself is an asynchronous IO mechanism of a Linux system kernel, and when IO class system calls in an asynchronous IO mode are processed, the technical scheme based on IO _ urning is obviously superior to a synchronous IO scheme or other asynchronous IO schemes in performance, and especially under the conditions of single core, multiple devices, and 4KB random reading, the technical scheme based on IO _ urning has obvious performance advantages.

Based on the same concept as the method embodiments shown in fig. 2 and fig. 3, the embodiment of this specification further provides a system call processing apparatus oriented to a trusted execution environment, where the system call processing apparatus is deployed in the trusted execution environment. As shown in fig. 4, the apparatus includes: a request receiving unit 401, configured to receive a system call request initiated by an application running in a trusted execution environment; the system call request is used for requesting to write the service data into the target file or requesting to read the service data from the target file. A data writing unit 402, configured to write the system call request into a shared memory area outside the trusted execution environment, and write an IO request event into an IO request queue stored outside the trusted execution environment; the IO request event comprises a first address of the system call request in the shared memory area and a second address used for storing business data in the shared memory area, so that a system kernel processes the system call request according to the IO request event and writes an IO completion event into an IO completion queue stored outside a trusted execution environment, wherein the IO completion event comprises a processing result of the system kernel on the IO request. A data providing unit 403, configured to provide the processing result in the IO completion event to the application program.

In a possible implementation manner, when the system call request is used to request to write service data into a target file, the data writing unit 402 is further configured to write service data into the second address of the shared memory area according to the system call request; the system kernel is specifically configured to read the system call request from the first address of the shared memory area according to the IO request event, read the service data according to the second address, and write the service data into a target file according to the system call request.

In a possible implementation manner, when the system call request is used to request to read service data from a target file, the system kernel is specifically configured to read the system call request from the first address in the shared memory region according to the IO request event, read service data from the target file according to the system call request, and write the service data into the shared memory region according to the second address. The data providing unit 403 is further configured to provide the service data in the shared memory area to the application program.

In one possible embodiment, the apparatus further comprises: an identifier management unit 404, configured to generate a unique identifier of the system call request; the IO request event and the IO completion event further comprise the unique identifier. A queue polling unit 405, configured to poll the IO completion event in the IO completion queue according to the unique identifier.

In one possible embodiment, the apparatus further comprises: an initialization configuration unit 406, configured to initialize the IO request queue, the IO completion queue, and the shared memory region by a service program running outside a trusted execution environment, and trigger a system kernel to start a polling thread for polling the IO request queue.

In a possible implementation manner, the initialization configuration unit 406 is further configured to obtain, through a service program running outside a trusted execution environment, configuration information for accessing the IO request queue, the IO completion queue, and the shared memory area.

In a possible implementation manner, the data writing unit 402 is specifically configured to acquire a thread lock for accessing an IO request queue stored outside a trusted execution environment, and write the IO request event into the IO request queue through the thread lock.

Fig. 5 is a second system framework diagram of the solution provided in the embodiment of the present specification. As shown in fig. 5, in order to improve the security of a system kernel (kernel) of an operating system adopted by a computing device or a virtual computing node, an operating system is generally required to divide a memory resource into two parts, namely a kernel space and a user space. The system kernel is independent of the normal computer program running in user space, and can access the protected kernel space while having all the rights to access the underlying hardware devices, such as reading/writing target files stored in non-volatile memory, or reading/writing temporary target files on memory resources. The trusted execution environment is a trusted memory area in the user space, and the user space other than the trusted execution environment is generally referred to as a process space for descriptive convenience.

When the computing device or the virtual computing node runs, a Virtual Dynamic Shared Object (VDSO) may run in a process space, and a data segment of the VDSO is further included in the process space, and the data segment is used for storing several pieces of time data. The system kernel may update several time data stored in the data segment.

In a possible technical solution, the VDSO supported by the system kernel may be directly transplanted into the trusted execution environment, and meanwhile, a data segment of the VDSO is maintained on a memory resource outside the trusted execution environment, where the data segment stores a plurality of time data, and the system kernel is responsible for updating the time data in the data segment in real time. A VDSO in the trusted execution environment may receive a time class system call request initiated by an application running in the trusted execution environment, read time data from a data segment outside the trusted execution environment according to the system call request it receives, and return to the application to complete a system call.

In the technical scheme, the VDSO is originally a component of a system kernel and can change along with the change of the system kernel version. The VDSO is directly transplanted into the trusted execution environment, the VDSO of different versions needs to be transplanted according to the version of the system kernel adopted by the computing device or the virtual computing node, and the VDSO transplanted into the trusted execution environment needs to be updated continuously aiming at the system kernel of a new version, so that the maintainability is extremely poor.

In view of the above problems, embodiments of the present specification provide a trusted execution environment-oriented system call processing method and apparatus.

Fig. 6 is a flowchart of another trusted execution environment-oriented system call processing method provided in an embodiment of the present specification. The method may be performed by a system call processing device in the trusted execution environment.

As shown in fig. 6, the method includes: step 601, acquiring a first address of a VDSO in a memory area outside a trusted execution environment; the memory area further comprises a data segment for storing a plurality of time data, and the VDSO comprises a plurality of system call functions for accessing the data segment. Step 602, loading VDSO in the trusted execution environment according to the first address. Step 603, modifying the addressing mode of the data segment by the VDSO in the trusted execution environment according to the first address and the second address of the VDSO in the trusted execution environment. Step 604, receiving a system call request initiated by an application program in the trusted execution environment through the modified VDSO, reading current time data from the plurality of time data stored in the data segment according to the system call request, and providing the current time data read by the application program to the application program.

Through the technical scheme provided in the embodiment of the present specification, when an application program running in a trusted execution environment initiates a time-based system call request, that is, when a system call request for requesting to read time data is initiated, a program function that the system call request is expected to realize can be completed more quickly without performing OCALL, which is beneficial to improving the performance of the application program running in the trusted execution environment.

The trusted execution environment-oriented system call processing method is exemplarily described below in conjunction with the system framework shown in fig. 5. As shown in fig. 5, a system call processing device is deployed in the trusted execution environment, a service program cooperating with the system call processing device runs in a process space outside the trusted execution environment, and the system kernel can update a data segment of the VDSO running in the process space, specifically, the system kernel can update a plurality of time data stored in the data segment in the process space.

Fig. 7 is a flowchart of another processing method of a system oriented to a trusted execution environment provided in an embodiment of the present specification. The method may include some or all of steps 701 through 7065 as shown in fig. 7.

First, in step 701, the system call processing apparatus sends a call request to a service program running in a process space.

Next, the service program responds to the received call request, and executes step 702, sending the first address of the VDSO in the process space to the system call processing device.

The process space also comprises a data segment for storing a plurality of time data.

VDSO includes several system call functions for accessing the data segment. Wherein, the plurality of system call functions may include one or more of the following system call functions: vdso _ clock _ gettime, vdso _ gettimeoffday (), vdso _ time ().

Next, in step 703, the system call processing apparatus loads the VDSO in the trusted execution environment according to the first address, and obtains address information corresponding to each of a plurality of system call functions included in the VDSO in the trusted execution environment.

In particular, VDSO is typically of ELF format, and VDSO may be loaded in the trusted execution environment based on ELF format information and the first address of VDSO in the process space. In addition, a Symbol table (Symbol table) of ". dynsym" may also be obtained from the ELF dynamic link library, and then address information corresponding to each of several system call functions included in the VDSO in the trusted execution environment is extracted from the Symbol table of ". dynsym", where the address information may be a start address and an address length of the corresponding system call function in the trusted execution environment.

Next, at step 704, the system call processing device determines whether VDSO in the trusted execution environment is trusted. If VDSO in the trusted execution environment is trusted, then step 7051 is performed.

In other words, it is desirable to ensure that the VDSO in the trusted execution environment is not a malicious computer program that may pose a security risk to the trusted execution environment, and that the VDSO in the trusted execution environment is determined to be trusted when it is determined that the VDSO in the trusted execution environment is not a malicious computer program.

After the inventor analyzes a large number of versions of VDSO, it is found that assembly instructions corresponding to the authentic VDSO need to satisfy the following conditions: the instruction is simple, and generally only comprises a part of instructions and a part of instruction modes; no other indirect control transfer instruction is included other than the RET instruction; memory access is not performed using direct memory addresses, and typically involves only three modes of memory access: reading or writing function parameters, reading a data segment of the VDSO, and reading/writing a legal stack; loop or internal function calls can modify the stack pointer inside the loop or inside the function, but the stack pointer must be restored internally after it is modified; buffer access (buffer access) to the stack is not involved, otherwise there may be buffer overflow or stack overflow when VDSO is running.

Based on the above findings, at least one preset condition for determining whether VDSO is authentic may be configured for the assembler instructions of VDSO. Accordingly, as shown in fig. 8, step 704 may include at least step 7041: recursively disassembling a plurality of system call functions included in a VDSO in a trusted execution environment to obtain instruction sets corresponding to the plurality of system call functions. Step 7042, in the process of recursively disassembling any current system call function of the plurality of system call functions, when a current instruction obtained at a current time meets any one of at least one preset condition, it is determined that the VDSO in the trusted execution environment is not trusted.

In one example, the plurality of system call functions included in the VDSO in the trusted execution environment may be recursively disassembled according to address information corresponding to each of the plurality of system call functions included in the VDSO in the trusted execution environment.

In one example, the at least one preset condition includes one or more of the following preset conditions: the current instruction is a control transfer instruction other than the RET instruction, the addressing mode of the current instruction is direct addressing (that is, the current instruction accesses the memory by using a direct memory address), the current instruction is an unallowable instruction/instruction pattern (that is, an instruction or an instruction pattern which is not included in VDSO found in the foregoing analysis process), and an error exists in disassembling the current instruction (for example, a program control flow jumps to an instruction which is already disassembled).

In the event that the instruction sets corresponding to the system call functions are successfully obtained and the VDSO is not determined to be untrusted, further analysis may be performed on the instruction sets corresponding to the system call functions to determine whether the VDSO is trusted. Specifically, referring to fig. 8, step 704 may further include:

step 7043, traverse any current instruction set in each instruction set, and construct a Control Flow Graph (CFG) with a Basic Block (Basic Block) as a node and a Control transfer as an Edge (Edge) by using instructions included in the current instruction set.

A basic block is a set of consecutive instructions having one entry and one exit.

The entries for all possible basic blocks in the current instruction set may include: a function start address, a target instruction of a direct control branch instruction, a target instruction of a conditional control branch instruction, a next instruction of the conditional control branch instruction, and a function call instruction.

The exits of all possible basic blocks in the current instruction set may include: the last instruction of the entry of the basic block, the control transfer instruction, the function call instruction, and the program return instruction.

Based on the above-described features of the basic blocks, in step 7043, the control flow graph may be constructed by performing one or more traversals of the current instruction set. For example, first go through the current instruction set for the first time, mark the entries of all possible basic blocks; then, traversing the current instruction set for the second time, and marking the exits of all possible basic blocks; thirdly, traversing, and connecting edges of all possible basic blocks according to the control transfer information; and finally, connecting the Entry basic block Entry with a basic block where a starting instruction of the current instruction set (namely a starting instruction of a system call function corresponding to the current instruction set) is located, and connecting the Exit basic block Exit with a basic block where a function return instruction in the current instruction set is located.

Step 7044, the control flow graph is processed through a predetermined algorithm in a traversal manner to determine whether a system call function corresponding to the current instruction set is a trusted function.

For each basic block as a node IN the control flow graph, the basic block has an input state IN which it enters the basic block and an output state OUT which it exits the basic block. The input state and the output state comprise the state of each register and the state of the stack, the state of the register is a set of possible values and types, and the state of the stack is a set of possible values and types at each position in the stack. In the initial state, initializing the output state OUT of the Entry basic block Entry, initializing the state of the register to the initial value of each register, and initializing the state of the stack to be null; the state of the registers and stack is secure in the initial state, as the state at this point is provided by a computer program in the trusted execution environment when a system call function contained in VDSO is called.

In a more specific example, the predetermined Algorithm may comprise a modified Work list Algorithm (Work list Algorithm). That is, in step 7044, the data flow analysis may be performed on the control flow diagram of the current instruction set through the improved work list algorithm, so as to detect whether the system call function corresponding to the current instruction set is a trusted function. The algorithm flow of the improved work list algorithm is as follows:

referring to the foregoing algorithm flow, in each cycle of the improved work list algorithm, the state of the stack of the output states OUT of all predecessor nodes of the basic block BB needs to be checked to ensure that the stack structures of the output states OUT of all predecessor nodes are consistent, and if the stack structures are inconsistent, the verification fails, so that it can be determined that the system call function corresponding to the current instruction set is an untrusted function. In other words, for any current node in the control flow graph, if stack structures of output states of several predecessor nodes of the current node are not identical, it may be determined that a system call function corresponding to the current instruction set is an untrusted function.

When the basic block is simulated and executed, whether memory access is legal or not needs to be checked according to the register state information and the stack state information, and if the verification fails, the system call function corresponding to the current instruction set can be determined to be an untrusted function. In other words, in the process of traversing and processing the control flow graph through the predetermined algorithm, for any current node in the control flow graph, if the memory access of the current node is not legal, it may be determined that the system call function corresponding to the current instruction set is an untrusted function.

It should be noted that, when checking the current node, a direct conclusion whether the memory is legal may not be obtained, and at this time, it is stated that the memory access may not be legal. If the memory access is not legal, the register state information and the stack state information are used for deducing the memory access type (reading or writing a function parameter, reading a VDSO data segment or reading/writing a legal stack), and recording the current node so as to insert the pile into the current node when the VDSO is rewritten subsequently and add a check instruction for the memory address range.

And if the improved working list algorithm is successfully operated and is finished, checking the state of the Exit basic block Exit to determine whether the system call function corresponding to the current instruction set correctly returns. If so, determining that the system calling function corresponding to the current instruction set is a trusted function, otherwise, determining that the system calling function corresponding to the current instruction set is an untrusted function.

At step 7045, it is determined that VDSO in the trusted execution environment is trusted when the untrusted function is not present.

In other words, the VDSO in the trusted execution environment may be determined to be trusted if each of the system call functions contained by the VSDO in the trusted execution environment is not determined to be an untrusted function.

When it is determined that VDSO in the trusted execution environment is trusted, returning to fig. 7, at step 7051, an address offset of the first address and the second address of VDSO in the trusted execution environment is determined. At step 7052, the address offset is written to the FS segment register and/or the GS segment register. In step 7053, the addressing of the data segment by the VDSO in the trusted execution environment is modified to be addressing through the FS segment register or the GS segment register.

Rewriting VDSO in the process space according to the first address of VDSO in the process space and the second address of VDSO in the trusted execution environment is completed through the foregoing steps 7051 to 7053.

Specifically, after VDSO is loaded into the trusted execution environment, the address offset between each system call function contained by VDSO in the trusted execution environment and the data segment in the process space changes. The FS segment register and/or the GS segment register are set as the address difference value/address offset of the VDSO in the trusted execution environment and the VDSO in the process space, and the addressing mode of the VDSO in the trusted execution environment to the data segment is modified to be the addressing mode through the FS segment register or the GS segment register, so that each system calling function contained in the modified VDSO can normally access the data segment in the process space.

It should be noted that, if the foregoing step 7044 marks that there may be a case where the memory access is not legal, when modifying the VDSO, it may also perform instrumentation on the code segment/instruction segment corresponding to the marked basic block (node), check whether the memory address to be accessed is within a legal range before the code segment performs the memory access, ensure that the subsequent processing can be performed only when the memory address to be accessed is within the legal range, and otherwise end the current service flow.

It should be noted that adapting VDSO in the trusted execution environment (e.g., adapting the addressing of VDSO in the trusted execution environment) may change the size of each system call function included in VDSO. Thus, the ELF configuration information of the rewritten VDSO may also be continuously modified, such as updating the size of each system call function included in the VDSO in the trusted execution environment in the ELF configuration information.

It should be noted that, since the application program in the trusted execution environment is usually developed based on a system library (e.g., C standard library) provided by the operating system, the modified VDSO calling method may be configured, so that the application program running in the trusted execution environment can initiate a time-class system call request to the modified VDSO through the system library.

In some embodiments, an application in the trusted execution environment may also directly invoke the rewritten VDSO through the system call processing device. Specifically, please continue to refer to fig. 7.

At step 7061, the system call processing device receives a system call request initiated by an application running in the trusted execution environment.

The system call request is for requesting read time data.

In step 7062, the system call processing device sends a system call request to the rewritten VDSO.

In step 7063, the rewritten VDSO reads the current time data from the plurality of time data stored in the data segment according to the system call request.

At step 7064, the rewritten VDSO returns the current time data to the system call processing device.

At step 7065, the system call processing means provides the current time data to the application.

Based on the embodiments shown in fig. 6 and fig. 7, the VDSO supported by the system kernel is adaptively modified in the trusted execution environment, the computer program does not need to be continuously updated according to the version of the system kernel, and the system kernel which is released or obtained after being updated in the future is compatible, so that the maintainability of the technical scheme is excellent.

Based on the embodiments shown in fig. 6 and 7, the rewritten VDSO is trusted and can operate normally in the trusted execution environment without bringing security risk to the trusted execution environment.

Based on the same concept as the method embodiments shown in fig. 6 and fig. 7, in this specification embodiment, a system call processing apparatus facing a trusted execution environment is further provided, and the system call processing apparatus is deployed in the trusted execution environment. As shown in fig. 9, the apparatus includes: an information obtaining unit 901, configured to obtain a first address of a VDSO in a memory area outside a trusted execution environment; the memory area further comprises a data segment for storing a plurality of time data, and the VDSO comprises a plurality of system call functions for accessing the data segment. A load processing unit 902, configured to load the VDSO in the trusted execution environment according to the first address. A modification processing unit 903, configured to modify, according to the first address and a second address of the VDSO in the trusted execution environment, an addressing manner of the data segment by the VDSO in the trusted execution environment; the modified VDSO is specifically configured to receive a system call request initiated by an application program in a trusted execution environment, read current time data from a plurality of time data stored in the data segment according to the system call request, and provide the current time data read by the application program to the application program.

In one possible embodiment, the method further comprises: a trusted verification unit 904 to determine whether VDSO in the trusted execution environment is trusted.

In a possible implementation, the trusted verification unit 904 is specifically configured to: recursively disassembling a plurality of system call functions included in a VDSO in a trusted execution environment to obtain instruction sets corresponding to the system call functions; and in the process of recursively disassembling any current system call function in the plurality of system call functions, when a current instruction acquired at the current moment meets any one of at least one preset condition, determining that the VDSO in the trusted execution environment is not trusted.

In a possible implementation, the trust verification unit 904 is further configured to traverse any current instruction set in each of the instruction sets, and construct a control flow graph with a basic block as a node and a control branch as an edge by using instructions included in the current instruction set, where the basic block is a group of consecutive instructions having one entry and one exit; processing the control flow graph through a predetermined algorithm in a traversing manner to determine whether a system call function corresponding to the current instruction set is a trusted function; when the untrusted function is not present, it is determined that the VDSO in the trusted execution environment is trusted.

In a possible implementation manner, the trust verification unit 904 is specifically configured to, in the process of processing the control flow graph through traversal by using a predetermined algorithm, determine, for any current node in the control flow graph, that a system call function corresponding to the current instruction set is an untrusted function if stack structures of output states of several predecessor nodes of the current node are not identical.

In a possible implementation manner, the trust verification unit 904 is specifically configured to, in the process of processing the control flow graph through traversal by using a predetermined algorithm, determine, for any current node in the control flow graph, that a system call function corresponding to the current instruction set is an untrusted function if memory access of the current node is not legal.

In a possible implementation, the trusted verification unit 904 is specifically configured to recursively disassemble the system call functions included in the VDSO in the trusted execution environment according to address information corresponding to each of the system call functions included in the VDSO in the trusted execution environment.

In a possible implementation, the modification processing unit 903 is specifically configured to determine address offsets of the first address and the second address; writing the address offset into an FS segment register and/or a GS segment register; and modifying the addressing mode of the VDSO in the trusted execution environment to the data segment into addressing through the FS segment register or the GS segment register.

Those skilled in the art will recognize that in one or more of the examples described above, the functions described in this specification can be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, a computer program corresponding to these functions may be stored in a computer-readable medium or transmitted as one or more instructions/codes on the computer-readable medium, so that when the computer program corresponding to these functions is executed by a computer, the method described in any one of the embodiments of the present specification is implemented by the computer.

Also provided in an embodiment of the present specification is a computer-readable storage medium on which a computer program is stored, wherein when the computer program is executed in a computing device, the computing device executes the system call processing method for a trusted execution environment provided in any one of the embodiments of the present specification.

The embodiment of the present specification further provides a computing device, which includes a memory and a processor, where the memory stores executable codes, and when the processor executes the executable codes, the trusted execution environment-oriented system call processing method provided in any one embodiment of the present specification is implemented.

The embodiments in the present description are described in a progressive manner, and the same and similar parts in the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the apparatus embodiment, since it is substantially similar to the method embodiment, the description is relatively simple, and reference may be made to the partial description of the method embodiment for relevant points.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

The above-mentioned embodiments, objects, technical solutions and advantages of the present invention are further described in detail, it should be understood that the above-mentioned embodiments are only exemplary embodiments of the present invention, and are not intended to limit the scope of the present invention, and any modifications, equivalent substitutions, improvements and the like made on the basis of the technical solutions of the present invention should be included in the scope of the present invention.

Claims

1. A trusted execution environment-oriented system call processing method comprises the following steps:

receiving a system call request initiated by an application program running in a trusted execution environment; the system calling request is used for requesting to write service data into a target file or requesting to read the service data from the target file;

writing the system call request into a shared memory area outside a trusted execution environment, and writing an IO request event into an IO request queue stored outside the trusted execution environment; the IO request event comprises a first address of the system call request in the shared memory region and a second address used for storing business data in the shared memory region, so that a system kernel processes the system call request according to the IO request event and writes an IO completion event into an IO completion queue stored outside a trusted execution environment, wherein the IO completion event comprises a processing result of the IO request by the system kernel;

and at least providing the processing result in the IO completion event to the application program.

2. The method of claim 1, wherein when the system call request is for requesting writing of business data to a target file, the method further comprises: writing service data into the second address of the shared memory area according to the system call request; the system kernel is specifically configured to read the system call request from the first address of the shared memory area according to the IO request event, read the service data from the second address, and write the service data into a target file according to the system call request.

3. The method according to claim 1, wherein when the system call request is used to request to read service data from a target file, the system kernel is specifically configured to read the system call request from the first address of the shared memory region according to the IO request event, read service data from a target file according to the system call request, and write the service data into the shared memory region according to the second address;

4. The method of claim 1, further comprising:

generating a unique identifier of the system call request; the IO request event and the IO completion event further comprise the unique identifier;

and polling the IO completion event in the IO completion queue according to the unique identifier.

5. The method of claim 1, wherein prior to receiving an application-initiated system call request running in a trusted execution environment, further comprising: initializing the IO request queue, the IO completion queue and the shared memory area by operating a service program outside a trusted execution environment, and triggering a system kernel to start a polling thread for polling the IO request queue.

6. The method of claim 5, further comprising: and acquiring configuration information for accessing the IO request queue, the IO completion queue and the shared memory area by a service program running outside a trusted execution environment.

7. The method according to claim 1, wherein the writing of the IO request event to the IO request queue stored outside the trusted execution environment specifically includes: and acquiring a thread lock for accessing an IO request queue stored outside a trusted execution environment, and writing the IO request event into the IO request queue through the thread lock.

8. The method of any of claims 1 to 7, wherein the type of the system call request is any of various types: read, write, readv, writev, fsync, poll, send _ msg, recv _ msg, openat, close, accept, connect, epoll _ ctl, send, and recv.

9. A trusted execution environment oriented system call processing apparatus, comprising:

the request receiving unit is used for receiving a system calling request initiated by an application program running in a trusted execution environment; the system call request is used for requesting to write service data into a target file or requesting to read the service data from the target file;

the data writing unit is used for writing the system call request into a shared memory area outside the trusted execution environment and writing an IO request event into an IO request queue stored outside the trusted execution environment; the IO request event comprises a first address of the system call request in the shared memory area and a second address used for storing business data in the shared memory area, so that a system kernel processes the system call request according to the IO request event and writes an IO completion event into an IO completion queue stored outside a trusted execution environment, wherein the IO completion event comprises a processing result of the system kernel on the IO request;

and the data providing unit is used for providing the processing result in the IO completion event at least for the application program.

10. The apparatus according to claim 9, wherein when the system call request is used to request to write service data to a target file, the data writing unit is further configured to write service data to the second address of the shared memory region according to the system call request; the system kernel is specifically configured to read the system call request from the first address of the shared memory area according to the IO request event, read the service data from the second address, and write the service data into a target file according to the system call request.

11. The apparatus according to claim 9, wherein when the system call request is for requesting to read service data from a target file, the system kernel is specifically configured to read the system call request from the first address of the shared memory region according to the IO request event, read service data from a target file according to the system call request, and write the service data into the shared memory region according to the second address;

12. The apparatus of claim 9, further comprising:

the identification management unit is used for generating a unique identification of the system calling request; the IO request event and the IO completion event further comprise the unique identifier;

and the queue polling unit is used for polling the IO completion event in the IO completion queue according to the unique identifier.

13. The apparatus of claim 9, further comprising: and the initialization configuration unit is used for initializing the IO request queue, the IO completion queue and the shared memory area through a service program running outside a trusted execution environment, and triggering a system kernel to start a polling thread for polling the IO request queue.

14. The apparatus of claim 13, wherein the initialization configuration unit is further configured to obtain configuration information for accessing the IO request queue, the IO completion queue, and the shared memory region through a service program running outside a trusted execution environment.

15. The apparatus according to claim 9, wherein the data writing unit is specifically configured to acquire a thread lock for accessing an IO request queue stored outside a trusted execution environment, and write the IO request event to the IO request queue through the thread lock.

16. The apparatus according to any one of claims 9 to 15, wherein the type of the system call request is any one of various types: read, write, readv, writev, fsync, poll, send _ msg, recv _ msg, openat, close, accept, connect, epoll _ ctl, send, and recv.

17. A computer-readable storage medium having stored thereon a computer program which, when executed in a computing device, performs the method of any of claims 1-8.

18. A computing device comprising a memory having executable code stored therein and a processor that, when executing the executable code, implements the method of any of claims 1-8.