System for performing safety operation and method for performing safety operation by system

Abstract

An embodiment of the present invention provides a system for performing security operations, including: an I / O subsystem; a storage subsystem; and multiple processors, wherein multiple processes are executed in multiple trusted execution environments TEEs and multiple ordinary execution environments REEs, each of the multiple TEEs and the multiple REEs is identified by a corresponding access identifier AID and protected by a corresponding system resource protection unit SRPU, wherein the SRPU corresponding to the TEE includes instructions, and when the instructions are executed by the corresponding processor, the corresponding processor uses a data structure to control access to the TEE, wherein the data structure includes: an allowed AID and a pointer to a storage location accessible to the allowed AID.

Description

Technical Field

[0001] Embodiments of the present invention relate to a security mechanism for a computing system. Background Art

[0002] A traditional operating system (OS) is a set of software that manages system hardware resources for user applications to achieve better utilization, performance, or efficiency. Traditional operating systems have become insecure due to the increasing complexity and size of operating systems. In addition, traditional operating systems have become insecure due to the use of certain programming languages ​​(such as C / C++) in user programs. These programming languages ​​enable user programs to manipulate system resources (such as memory, where the memory can be internal memory). Therefore, the operating system and user programs may be involved in memory management, resulting in inconsistencies and causing insecurity.

[0003] Such as Trusted Execution Environments (TEEs) such as were developed in the early 2000s to enhance system security. TEEs have taken over a large number of system hardware resources (e.g., processors, storage bodies (such as memory), and I / O devices) from traditional OSes when such system resources need to be protected. TEEs also use other hardware (hardware that is completely under the control of TEEs) to boot the system. Therefore, traditional OSes, which are renamed REEs (Rich Execution Environments), are treated as applications and play no role in system security management. However, when an application requires more than one TEE and / or more than one REE, system security is challenged. Therefore, a reliable, effective, and scalable security mechanism for secure computing systems is needed. Summary of the invention

[0004] In one embodiment, a system for performing secure operations is provided. The system includes an I / O subsystem, a storage subsystem and a processor. The processor is operable to execute processes in a trusted execution environment (TEE) and a normal execution environment (REE). Each of the TEE and the REE is identified by a corresponding access identifier (AID) and protected by a corresponding system resource protection unit (SRPU). The corresponding SRPU of the TEE includes instructions that, when executed by the corresponding processor, cause the corresponding processor to control access to the TEE using a data structure that includes an allowed AID and a pointer to a storage location accessible to the allowed AID. In an optional embodiment, the storage may be a memory. The storage subsystem may be a memory subsystem. The subsequent embodiments are described in terms of "memory", and those skilled in the art may understand that the "memory" in the subsequent embodiments may be modified to "memory" to implement the present invention.

[0005] In another embodiment, a method for performing security operations by a system including an SRPU is provided. The method includes a target SRPU of a target entity receiving an access request indicating a source AID, a target AID, and a storage location of the target entity to be accessed. The source AID is assigned to a source entity including a source SRPU, and the target AID is assigned to the target entity. The method further includes: the target SRPU determines whether to allow or deny the access request based on information in a data structure including allowed AIDs and pointers to storage locations accessible to the allowed AIDs. The method further includes: denying the access request at least when the source AID is not one of the allowed AIDs. The source entity and the target entity are system entities that include at least one or more of a TEE and a REE provided by multiple processors, an I / O subsystem, and a storage subsystem. Each system entity is identified by a corresponding AID and protected by a corresponding SRPU. In an optional embodiment, the storage can be a memory. The storage subsystem can be a memory subsystem.

[0006] The system for performing security operations and the method for performing security operations provided by the embodiments of the present invention can effectively control access to a target entity or TEE based on information in a data structure.

[0007] Other aspects and features will become apparent to those of ordinary skill in the art by reading the following description of specific embodiments in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings in which like reference numerals indicate like elements. In addition, when a particular feature, structure, or characteristic is described in conjunction with an embodiment, it is contemplated that such feature, structure, or characteristic may be implemented in conjunction with other embodiments within the knowledge of those skilled in the art, whether or not such combination is explicitly described.

[0009] Figure 1 An example system is shown in which embodiments of the present invention may operate.

[0010] Figure 2 A data structure used by a system resource protection unit (SRPU) according to one embodiment is shown.

[0011] Figure 3A , 3B and 3C show a method for constructing Figure 2 The data structure information.

[0012] Figure 4 is a flow chart illustrating operations performed by the SRPU according to one embodiment.

[0013] Figure 5 is a flow chart illustrating a process for initializing an access identifier (AID) according to one embodiment.

[0014] Figure 6 is a flow chart illustrating a process for creating a new AID during runtime according to one embodiment.

[0015] Figure 7 is a flow chart illustrating a process for revoking an existing AID at runtime according to one embodiment.

[0016] Figure 8 is a flow chart illustrating a process for disabling AID access according to one embodiment.

[0017] Fig. 9 is a flow chart illustrating a method for a system to perform security operations according to one embodiment. DETAILED DESCRIPTION

[0018] In the following description, many specific details are set forth. However, it should be understood that embodiments of the present invention can be practiced without these specific details. In other cases, well-known circuits, structures, and techniques are not shown in detail to avoid obscuring the understanding of this specification. However, those skilled in the art will understand that the present invention can be practiced without such specific details. Those of ordinary skill in the art will be able to achieve appropriate functionality without undue experimentation under the techniques described herein.

[0019] Embodiments of the present invention provide a security scheme for memory access and process execution. The security scheme is implemented by multiple system resource protection units (SRPUs) located in multiple system entities (also referred to as "entities") in the system. System entities include subsystems, execution environments, processing or collaborative processing modules, and other components in the system. Examples of system entities include, but are not limited to: trusted execution environment (TEE), rich execution environment (REE), I / O subsystem, memory subsystem, and collaborative processing module. Each system entity includes software elements and underlying firmware and hardware elements. Each system entity is assigned a unique access identifier (AID) and a memory address space for accessing memory and I / O. Each system entity also includes a SRPU that allows or denies access requests based on the requested memory address, source AID, and target AID. The security scheme is highly scalable. By using an SRPU in each system entity, the security of the system can be expanded with the size of the system.

[0020] In one embodiment, the security scheme described herein may be applied to a system located on a semiconductor chip, such as a system-on-a-Chip (SoC). However, it should be understood that the security scheme described herein is also applicable to a system located on more than one chip. Examples of systems include, but are not limited to, computing and / or communication devices (e.g., smartphones, tablets, laptops, desktops, servers, gateways, Internet-of-Thing (IoT) devices, wearable devices, infotainment devices, gaming devices, etc.).

[0021] Figure 1An example system 100 is shown in which embodiments of the present invention may be run. System 100 includes multiple system entities, such as TEE_1, TEE_2, TEE_3, REE_1, REE_2, I / O subsystem 106, and memory subsystem 107, all of which are coupled via bus 190 or another interconnection. It should be understood that system 100 may include any number of TEEs and REEs, and these TEEs and REEs may be hosted by any central processing unit (CPU), processor core, and co-processor, such as graphics processing unit (GPU), digital processing unit (DSP), artificial intelligence (AI) processor, etc. TEE_1 and TEE_2 are trusted execution environments hosted by CPU_1 and CPU_2, respectively, and more specifically, TEE_1 is hosted by CPU_1 firmware and hardware 121 and TEE_2 is hosted by CPU_2 firmware and hardware 122. A processor may host more than one execution environment of the same type (e.g., two or more TEEs, or two or more REEs), or more than one execution environment of different types (e.g., a combination of TEEs and REEs). For example, CPU_2 firmware and hardware 122 hosts both TEE_2 and REE_2. Furthermore, system 100 includes two cooperating processing modules 103 and 105, an I / O subsystem 106, and a memory subsystem 107. Although in Figure 1 A specific number of system entities are shown, but it should be understood that system 100 may include any number of CPUs, execution environments, co-processing modules, and subsystems.

[0022] Each system entity in the system 100 is assigned a unique AID (e.g., AID1-AID7) stored in a corresponding AID register. In one embodiment, the AID is generated by a system boot and AID initialization (SBAI) unit 181. In one embodiment, the SBAI unit 181 is a trusted process in a TEE (e.g., TEE_1) and is executed by one of the multiple CPUs in the system 100 (e.g., CPU_1). In one embodiment, the SBAI unit 181 may include a random number generator to generate an AID when the system 100 is powered on. In one embodiment, each AID may be a series of random numbers.

[0023] Each system entity includes a corresponding SRPU (e.g., SRPUs 151-157). In one embodiment, each SRPU includes a combination of hardware components and software components to implement secure memory access. Each SRPU contains a data structure to track the AIDs that are allowed to access the memory locations assigned to the system entity corresponding to the SRPU. The term "data structure" in this document refers to a collection of tables, lists, and / or other data organizations. This will be discussed later in conjunction with Figure 2 Provides more details about the structure of the data.

[0024] In one embodiment, the data structure is constructed by scheduler 191, which can be a trusted process in a TEE (e.g., TEE_1) and is executed by one of the multiple CPUs in system 100 (e.g., CPU_1). Scheduler 191 schedules tasks and assigns tasks (e.g., processes and / or trusted processes) to system entities or across multiple system entities. For example, scheduler 191 can assign processes for a task to multiple system entities, such as multiple TEEs or multiple REEs. Scheduler 191 configures the data structures of these multiple system entities to allow access between multiple system entities to perform tasks. Figure 1 As shown, system 100 may include a single SBAI unit 181 and a single scheduler 191 .

[0025] In one embodiment, each TEE includes a corresponding monitor (e.g., monitor 171, 172, or 173). Monitors 171-173 can perform communication between multiple TEEs to allow multiple TEEs to communicate with each other. In other features, each monitor 171-173 can determine whether an attack on its own host entity (e.g., TEE_1 is the host entity of monitor 171) has occurred or may have occurred. When an attack or potential attack is detected, monitors 171-173 can request scheduler 191 to revoke the AID of the attacked entity (i.e., the attacked entity). Revoking the AID can isolate the attacked entity from other system entities. When the threat of the attack is eliminated, the attacked entity can rejoin the system 100 later.

[0026] Each of the collaborative processing modules 103 and 105 may contain one or more TEEs, REEs, a combination of both, or neither TEE nor REE. In this example, the collaborative processor firmware and hardware 123 hosts TEE_3, and the collaborative processor firmware and hardware 125 hosts REE_1. TEE_3 is assigned AID3 and has a corresponding SRPU 153, and REE_1 is assigned AID5 and has a corresponding SRPU 155.

[0027] The I / O subsystem 106 may include I / O devices such as a display, a camera, a speakerphone, a touchpad, a network interface, a radio-frequency (RF) component, etc. The I / O subsystem 106 provides the system 100 with access to a network such as a public network, a proprietary network, a wireless network, a wired network, or any combination thereof, such as a cellular network, the Internet, a wide area network, a Wi-Fi network, a local area network, a personal area network, etc. The I / O subsystem 106 may include one or more TEEs, REEs, or a combination of both, or neither a TEE nor a REE. In this example, an AID (e.g., AID6) is assigned to the I / O subsystem 106, and the I / O subsystem has a corresponding SRPU 156 hosted by the I / O subsystem firmware and hardware 126. The I / O subsystem 106 has an allocated memory address space (e.g., I / O memory 116), which may be a memory-mapped I / O whose location is described by a memory page address. Alternatively, the I / O memory 116 may include a set of I / O buffers identified by respective buffer pointers.

[0028] The memory subsystem 107 includes memory devices (e.g., RAM such as dynamic random access memory (DRAM) devices, static random access memory (SRAM) devices, and / or other volatile or non-volatile memory devices) collectively referred to as memory 117. The memory subsystem 107 is assigned an AID (e.g., AID7) and has a corresponding SRPU 157. In one embodiment, the SRPU 157 can be part of memory control logic (not shown) that controls access to secure portions of the memory 117.

[0029] The memory address space of system 100 can be allocated to some or all system entities. For example, different parts of the memory address space can be assigned to TEE_1 memory 111, TEE_2 memory 112, REE_2 memory 113, TEE_3 memory 114, REE_1 memory 115, I / O memory 116, and memory 117. Although memories 111-117 are shown as separate blocks, some of memories 111-117 can be located in the same physical memory device. Access to each memory 111-117 is protected by the corresponding SRPU 151-157. The memory address space can also be referred to as a system resource.

[0030] exist Figure 1In the embodiment of the present invention, CPU_1 and CPU_2 execute multiple operating systems. Trusted operating systems 101 and 102 are secure operating systems that manage system resources of TEE_1 and TEE_2, respectively. Common operating system (Rich OS) 104 (e.g. etc.) manages system resources of REE_2. In some embodiments, CPU_1 and / or CPU_2 may host a hypervisor that runs a virtual machine. CPU_1 and CPU_2 may execute multiple processes, including a trusted process 161 in TEE1, a trusted process 162 in TEE_2, and a process 164 in REE_2, respectively. In one embodiment, when executing processes 161, 162, or 164, CPU_1 and CPU_2 may send commands or requests to a coprocessor (e.g., coprocessor firmware and hardware 123 and 125), an I / O subsystem 106, and a memory subsystem 107.

[0031] The secure user application can be executed by the system 100 in the TEE, for example, by CPU_1 and / or CPU_2. The secure user application may include one or more trusted processes 161 and 162. In one embodiment, an AID alias is assigned to each secure user application in the TEE, which can be obtained from the AID of the TEE. For example, the trusted OS 102 in TEE_2 can generate AID aliases from AID2 (the AID of TEE_2) and assign each AID alias to a secure user application running in TEE_2. The trusted OS 102 can also generate access control information for each secure user application to indicate memory address space allocation and access restrictions to the secure user application. In the example of TEE_2, the SRPU 152 uses the access control information of each application to determine whether the source entity can access the allocated memory address space of the secure user application in TEE_2. In one embodiment, the SRPU 152 first uses a data structure (for example, in Figure 2 150) determines whether the source entity is allowed to access the target entity (e.g., TEE_2) based on the data structure 200 described in . If the source entity is allowed to access TEE_2 according to the data structure, the SRPU 152 also determines whether the source entity can access the memory address space of the target user application in TEE_2 based on the access control information of the target user application.

[0032] In this way, system resources owned by a user application in any TEE (e.g., allocated to the user application) belong entirely to the user application and cannot be accessed by any other application in the same TEE, other TEEs, or REE. In one embodiment, system resources are allocated to user applications only during their execution. The allocation is released after the user application is executed. When a user application resides in multiple TEEs, the multiple TEEs collaborate to ensure continuous access across the system resources allocated to the user application. These allocated system resources cannot be accessed by other applications in any TEE or REE. In one embodiment, these system resources are allocated to user applications for a period of time and then released.

[0033] According to one embodiment, Figure 2 Shows Figure 1 For ease of description, Figure 1 TEE_2 in FIG. 2 is used as an example of a target entity that hosts the SRPU 152 and the data structure 200. The data structure 200 includes an AID_allowed table 210 that stores information about entities that are allowed to access memory locations that have been allocated to the target entity (e.g., TEE_2 in this example). It should be understood that in Figure 1 The same or similar data structures may be used in any TEE, REE, co-processing module, I / O subsystem, and memory subsystem in system 100.

[0034] The AID_allowed table 210 includes at least three fields: an AID field, a privilege field, and a pointer to a directory field. These fields can be arranged in three columns of the AID_allowed table 210. However, alternative arrangements can be used. The SRPU 152 uses the AID_allowed table 210 to identify entities (by their AIDs) that are allowed to access the TEE_2 memory 112. For each AID in the first column of the AID_allowed table 210, the privilege of the AID is also identified. In one embodiment, there may be four privilege levels, from low to high: privilege level = 0 for user code / data, privilege level = 1 for Rich OS, privilege level = 2 for the hypervisor, and privilege level = 3 for the monitor of the TEE. The privilege level provides information about the requester (i.e., the entity that sends the access request). The target entity (particularly the target SRPU) that receives the access request can use this information to determine whether to allow or deny the access request.

[0035] For simplicity of description and in accordance with common usage in the art, the term "user data" is used hereinafter to collectively refer to "user code and / or data". In addition, the term "highly privileged software" refers to software having a higher privilege than the privilege of user data. In one embodiment, "highly privileged software" is indicated by a privilege level greater than 0, because user data has a privilege level of 0.

[0036] In one embodiment, the third column of the AID_allowed table 210 includes a pointer to a memory page address directory. In one embodiment, the memory page address is a physical address. In another embodiment, the memory page address may be a memory address range. For each AID in the first column of the AID_allowed table 210, the pointer points to the head of the memory page address directory (e.g., by providing the address of the memory page address directory). For example, the first row of the AID_allowed table 210 includes AID_p, privilege level = 0, and a pointer Ptr_1 pointing to list_memory_page 220 (also referred to as "directory 220"). That is, user processes or applications in the system entity identified by AID_p are allowed to access memory pages in directory 220. Figure 2 In the example of , directory 220 includes four memory page entries, also referred to as entries (for simplicity, only the first entry 225 is labeled). Each entry in directory 220 includes a supervisor AID 235, the address of the memory page, and an allow / disallow indicator ("A / D indicator 230"). The supervisor AID 235 in the entry (e.g., AID_p or AID_q) identifies the entity that owns (i.e., is allocated) the memory page. The default setting of A / D indicator 230 is "allow" (e.g., represented by a value of "1"), which indicates that the memory page in the same entry can be accessed. A user or system administrator can change the default setting of A / D indicator 230 to indicate "disallow" (e.g., represented by a value of "0") via an application programming interface (API). The "disallow" indication can be applied to access requests from highly privileged entities, software, or processes. For example, when the A / D indicator 230 for a given memory page of user data is 0, the target SRPU denies all access requests for the given memory page from entities with privilege levels 1, 2, and 3. For example, in the AID_allowed table 210, since the privilege level of AID_s (privilege level=3) is 3, the access request to the user data from AID_s is denied. Therefore, the user data can be protected from access by highly privileged software.

[0037] In a cloud service scenario, company A may rent system resources (e.g., processing power, memory, storage devices, etc.) from a cloud provider to provide services to company A's customers. Customers' data and code need to be protected from unauthorized access, including access by the cloud provider. To prevent the cloud provider's software from accessing company A's customers' data and code, an administrator of company A may instruct the system not to allow highly privileged software to access user data stored in the memory address space allocated by company A. In response to the administrator's instruction, a scheduler (e.g., Figure 1 The scheduler 191) can perform an AID_disallow operation to set the A / D indicators of those memory pages storing user data of Company A to zero.

[0038] In one embodiment, the SRPU performs access checks on both incoming and outgoing access requests. For example, when a source entity (AID_j) sends a request to a target entity (AID_k) to access memory_page_k, the source SRPU at the source entity allows the request if AID_k and memory_page_k are in the source entity's AID_allowed table. Upon receiving the request, the target SRPU at the target entity also checks its AID_allowed table to determine (1) whether AID_j is in the table, (2) whether the list_memory_page corresponding to AID_j includes memory_page_k, and (3) whether AID_j has a privilege level equal to 0, or (4) whether the A / D indicator 230 of memory_page_k indicates "allowed" when the privilege level of AID_j is greater than 0 and memory_page_k stores user data. If (1), (2) and (3) are all true, or if (1), (2) and (4) are all true, then the target SRPU is allowed access to memory_page_k.

[0039] In some I / O subsystems 106 ( Figure 1 ) is not memory mapped, the pointer to the directory field in the AID_allowed table 210 may further include a pointer to list_buffer_pointer. Each entry in list_buffer_pointer identifies a buffer, not a memory page in list_memory_page.

[0040] Scheduler (e.g. Figure 1The scheduler 191 in ( ) may update the data structure 200 from time to time, for example, when the allocation of the memory address space of the system entity is changed. In some embodiments, system resources may be allocated to a group of TEEs for a period of time and then the system resources may be released. System resources allocated to a REE or a group of REEs may be temporarily "borrowed" (e.g., reallocated) by a TEE or a group of TEEs. During the "borrowing" period, only the TEE can securely access the system resources until the system resources are released. In addition, the data structure 200 may be used to indicate the following: the TEE is allowed to access the system resources allocated to the REE, the REE cannot access the system resources allocated to the TEE unless permission is obtained, and other TEEs cannot access the system resources allocated to the TEE unless permission is obtained.

[0041] Figure 3A , 3B and 3C show a method for constructing Figure 2 Example information of data structure 200. Figure 3A shows an example of a process control block (PCB), which is provided by the operating system to dictate memory allocation for each process (identified by a process ID (PID)). Figure 3B The mapping between PID and AID is shown. The mapping can be one-to-one or many-to-one. That is, one PID can be mapped to one AID, or many PIDs can be mapped to one AID. Figure 3C An example of connection information is shown, which shows the dependencies between PIDs, for example, which process calls which other process. The connection information can be provided by the compiler. Figure 3C The example shows a collection of linear connections between PIDs. However, connectivity can be represented by graphs of different shapes. Figure 3A , the information shown in 3B and 3C and the privilege information for each AID, the scheduler can build an AID_allowed table for all SRPUs in the system.

[0042] Figure 4 is a flow chart illustrating operations performed by an SRPU according to one embodiment. Specifically, the operations are performed by a source SRPU at a source entity, which is a system entity that sends an access request, and a target SRPU at a target entity, which is a system entity that receives an access request. In addition, the source entity is identified by a source AID, and the target entity is identified by a target AID. The source SRPU and the target SRPU may perform an address translation from a virtual address to a corresponding physical address to determine a memory location to be accessed.

[0043] At step 410, the source SRPU detects an access request from a source entity to access a memory location assigned to a target entity. At step 420, the source SRPU checks the memory access information corresponding to the target AID in the AID_allowed table of the source entity. At step 430, the source SRPU determines whether the source entity can access the memory location assigned to the target entity; for example, if the target AID and the memory location to be accessed are in the AID_allowed table, then access is allowed. If the source SRPU determines that the access request is not allowed, then the access request is denied at step 440. If the source SRPU determines that the access request is allowed, then at step 450, the source entity sends the access request to the target entity.

[0044] In step 460, the target SRPU checks the memory access information corresponding to the source AID in the AID_allowed table of the target entity. In step 470, based on this information, the target SRPU determines whether the source entity can access the memory location assigned to the target entity, for example, if the source AID and the memory location to be accessed are in the AID_allowed table, the access is allowed. Otherwise, it is determined that the access is not allowed. In addition, if the privilege level of the source AID is greater than 0 and the A / D indicator corresponding to the memory location is 0 ("not allowed"), access may be prohibited, wherein the memory location stores user data. If the target SRPU determines to deny the access request, it denies the access request in step 480. If the target SRPU determines to allow the access request, it allows the access request to the target entity in step 490.

[0045] Figure 5 is a flow chart showing an AID initialization process 500 (ie, AID_init) according to one embodiment. Figure 1 When the system 100 is powered on, the SBAI unit 181 receives a power-on indication at step 510. In response to the indication, at step 520, the SBAI unit 181 generates K random numbers for initializing K AID registers, where K is the number of system entities. After initializing the AIDs, new system entities can be added to the system 100 and existing system entities can be removed, such as by combining the AIDs with the system entities. Figure 6 and Figure 7 to describe.

[0046] Figure 66 is a flow chart illustrating a process 600 (i.e., AID_dynamic) for creating a new AID during runtime according to one embodiment. At step 610, SABI unit 181 receives a request to create a new AID for a system entity. At step 620, SABI unit 181 generates a new AID and assigns the new AID to the AID register of the system entity. At step 630, scheduler 191 creates an AID_allowed table for the system entity, including a privilege level and a pointer to a memory page corresponding to the AID listed in the AID_allowed table.

[0047] Figure 7 7 is a flow chart illustrating a process 700 of revoking an existing AID during runtime (i.e., AID_revoke) according to one embodiment. At step 710, a monitor in a TEE detects an attack on the TEE. The TEE is also referred to as an attacked entity. At step 710, the monitor requests the scheduler to perform AID_revoke. In response to the request, at step 720 the scheduler deletes the AID of the attacked entity and the memory page entry corresponding to the AID of the attacked entity from all AID_allowed tables used by all SRPUs in the system.

[0048] Figure 8 is a flow chart illustrating a process 800 of disabling an access request from a source entity (ie, AID_disallow) according to one embodiment. In process 800, an A / D indicator is set to indicate and used to determine whether to allow high privileged software to access user data of a target entity.

[0049] At step 810, the scheduler receives an indication that highly privileged software is prohibited from accessing user data of a target entity. The highly privileged software is executed by a source entity identified by a source AID. In one embodiment, a user or administrator may provide an indication via an API that access to the system is not allowed. At step 820, the scheduler performs AID_disallow on a data structure of the target entity (referred to as a "target data structure") by setting the A / D indicator corresponding to the source AID to 0. Specifically, AID_disallow overwrites the default setting of the A / D indicator corresponding to the source AID in the target data structure. For example, the default setting may be 1 to indicate "allowed", while the new setting may be 0 to indicate "not allowed". The target SRPU controls access from highly privileged software based at least in part on the setting of the A / D indicator. At step 830, the target SRPU determines whether to disallow the access request based on the A / D indicator corresponding to the source AID and the requested memory location and the privilege of the source AID. For example, the access request may indicate (source AID, target AID, requested memory_page_address). The target SRPU finds from the target data structure that the privilege level of the source AID = 3 and the A / D indicator of the requested memory_page_address is 0. Therefore, the SRPU denies the access request to protect user data from access by high-privileged software.

[0050] Fig. 9 900 is a flow chart of a method 900 for performing a security operation according to an embodiment of the present invention. The system includes a plurality of SRPUs. As an example, the method 900 may be performed by Figure 1 Specifically, the system 100 may be executed by Figure 1 SRPU 151-157 to execute.

[0051] When a target SRPU of a target entity receives an access request indicating a source AID, a target AID, and a memory location of the target entity to be accessed, the method 900 begins at step 910. The source AID is assigned to the source entity including the source SRPU, and the target AID is assigned to the target entity. At step 920, the target SRPU determines whether to allow or deny the access request based on information in a data structure including allowed AIDs and pointers to memory locations accessible to the allowed AIDs. At step 930, the target SRPU denies the access request at least when the source AID is not one of the allowed AIDs.

[0052] Referring to method 900, the source entity and the target entity are system entities including at least an I / O subsystem, a memory subsystem, and TEEs and REEs provided by multiple processors. Each system entity is identified by a corresponding AID and protected by a corresponding SRPU. In some embodiments, the system entity also includes one or more collaborative processing modules, each of which is executed by a corresponding collaborative processor. In one embodiment, based on the access control information of the secure user application in the TEE, the corresponding SRPU of the TEE is operable to deny other user applications in the TEE and REE access to the memory address space allocated to the secure user application.

[0053] In one embodiment, a data structure (e.g., Figure 2 The data structure 200 also includes the privilege level of each allowed AID. Each memory location accessible by multiple allowed AIDs is marked by an A / D indicator to indicate whether the memory location can be accessed by a process with a higher privilege than user code and data.

[0054] It is understandable that the present invention is described above by taking the “storage body” as “memory” as an example, but the present invention is not limited thereto.

[0055] Already referenced Figure 1 The exemplary embodiments describe Figure 4-9 However, it should be understood that Figure 4-9 The operations of the flowchart can be performed by Figure 1 to perform in accordance with embodiments other than the embodiments of Figure 1 Embodiments of the invention may perform operations different from those discussed with reference to the flowcharts. Figure 4-9 The flowcharts show a specific order of operations performed by certain embodiments of the present invention, but it should be understood that such order is exemplary (for example, alternative embodiments may perform operations in a different order, combine certain operations, overlap certain operations, etc.).

[0056] Various functional components or blocks have been described herein. As will be appreciated by those skilled in the art, the functional blocks will preferably be implemented by circuits (special purpose or general purpose circuits operating under the control of one or more processors and coded instructions). The circuits typically include transistors configured to control the operation of the circuits according to the functions and operations described herein.

[0057] Although the present invention has been described according to several embodiments, those skilled in the art will recognize that the present invention is not limited to the described embodiments and can be implemented with modification and variation within the spirit and scope of the appended claims. Therefore, the description should be considered illustrative rather than restrictive.

Claims

1. A system for performing a security operation, characterized in that: include: At least one processor executes a plurality of processes in at least one trusted execution environment TEE and at least one normal execution environment REE, each of the at least one TEE and the at least one REE being identified by a corresponding access identifier AID and protected by a corresponding system resource protection unit SRPU, The SRPU corresponding to the TEE includes instructions that, when executed by a corresponding processor, cause the corresponding processor to control access to the TEE using a data structure, wherein the data structure includes: an allowed AID and a pointer to a storage location accessible to the allowed AID; The corresponding processor uses the data structure to control access to the TEE, including: when the source AID is not one of the allowed AIDs, denying another TEE or REE identified by the source AID access to the storage location allocated to the TEE.

2. The system according to claim 1, characterized in that Also includes: I / O subsystem and storage subsystem; the at least one processor is multiple processors, the at least one TEE is multiple TEEs, the at least one REE is multiple REEs, and the storage is a memory.

3. The system according to claim 2, characterized in that The SRPU corresponding to the TEE is also used to deny other user applications in the multiple TEEs and the multiple REEs from accessing the storage address space allocated to the secure user application in the TEE based on the access control information of the secure user application.

4. The system according to claim 2, characterized in that When executed by a corresponding one of the plurality of processors, the monitoring process in each TEE is operable to detect an attack on the TEE and cause the AID of the TEE to be removed from all data structures used by all SRPUs in the system.

5. The system according to claim 2, characterized in that When executed by a respective one of the plurality of processors, the scheduling process is operable to assign the processing of tasks to a plurality of system entities and configure data structures of the plurality of system entities to allow access between the plurality of system entities for performing the tasks.

6. The system according to claim 5, characterized in that The plurality of system entities include a combination of entities selected from the plurality of TEEs, the plurality of REEs, the I / O subsystem, the storage subsystem, and one or more collaborative processing modules including corresponding collaborative processors.

7. The system according to claim 5, characterized in that During operation of the system, the scheduling process is operable to delete existing AIDs from all data structures in the system and add new AIDs to the system.

8. The system according to claim 2, characterized in that When the scheduling process is executed by a corresponding one of the plurality of processors, the scheduling process is operable to update the data structure when the allocation of the storage address space accessible to the allowed AID is changed, wherein updating the data structure comprises updating a pointer to the storage location accessible to the allowed AID.

9. The system according to claim 2, characterized in that When the I / O subsystem is assigned a first SRPU and a first AID, the first SRPU is operable to control access to a storage body assigned to the I / O subsystem, and when the storage subsystem is assigned a second SRPU and a second AID, the second SRPU is operable to control access to a secure portion of the storage subsystem, wherein the storage subsystem is a memory subsystem.

10. The system according to claim 2, characterized in that Also includes: The collaborative processing module is assigned a third SRPU and a third AID, the third SRPU being operable to control access to and from the collaborative processing module via a corresponding collaborative processor.

11. The system according to claim 2, characterized in that When executed by a corresponding one of the plurality of processors, the system boot and AID initialization process is operable to generate an AID and initialize an AID register using the generated AID when the system is powered on.

12. The system according to claim 2, characterized in that The data structure further includes: a privilege level for each allowed AID.

13. The system of claim 2, wherein: Each memory location accessible to the allowed AID is marked with an allowed / not allowed (A / D) indicator to indicate whether the memory location is accessible to processes with higher privileges than user code and data.

14. The system of claim 13, wherein: An application programming interface (API) is further included, through which a user of the system sets the A / D indicator to indicate that access to the memory location is not allowed.

15. The system according to claim 1, characterized in that Each memory location accessible to the allowed AIDs is tagged by a host AID that identifies the system entity to which the memory location is assigned.

16. A method for a system to perform a security operation, the system comprising a plurality of system resource protection units SRPU, characterized in that: include: A target SRPU of a target entity receives an access request indicating a source access identifier AID, a target AID, and a memory location of the target entity to be accessed, wherein the source AID is assigned to a source entity including the source SRPU, and the target AID is assigned to the target entity; The target SRPU determines whether to grant or deny the access request based on information in a data structure, wherein the data structure includes an allowed AID and a pointer to a memory location accessible to the allowed AID; and denying the access request at least when the source AID is not one of the allowed AIDs, The source entity and the target entity are system entities including at least one trusted execution environment TEE and at least one ordinary execution environment REE provided by at least one processor, an I / O subsystem, and one or more storage subsystems, each system entity is identified by a corresponding AID and protected by a corresponding one of the multiple SRPUs.

17. The method according to claim 16, characterized in that Also includes: A monitoring process is executed in each TEE to detect an attack on the TEE and cause the AID of the TEE to be removed from all data structures used by all SRPUs in the system.

18. The method according to claim 16, characterized in that Further including: A scheduling process is executed to distribute the process of the task to a plurality of system entities, and data structures of the plurality of system entities are configured to allow access between the plurality of system entities to execute the task.

19. The method according to claim 16, characterized in that The plurality of system entities further include one or more cooperative processing modules, and the one or more cooperative processing modules have corresponding cooperative processors.

20. The method according to claim 16, characterized in that Also includes: When the memory location accessible to the allowed AID is changed, a scheduling process is performed to update the data structure.

21. The method according to claim 16, characterized in that Each memory location accessible by the allowed AIDs is marked with an allowed / not allowed (A / D) indicator to indicate whether the memory location is accessible to processes with higher privileges than user code and data.

Images