Apparatus and method for processing stashing transactions

Abstract

An apparatus and method are provided, the apparatus comprising: an interconnect circuit coupling a device to one or more processing elements, each processing element operating in a trusted execution environment; and a secure stash decision circuit for receiving stashing transactions from the device and redirecting authorized stashing transactions to a given storage structure accessible to at least one of the one or more processing elements, wherein the secure stash decision circuit is configured to, in response to receiving the given stashing transaction, determine whether the given stashing transaction includes a trusted execution environment identifier associated with the given trusted execution environment, and treat the given stashing transaction as an authorized stashing transaction when a redirection requirement dependent on the trusted execution environment identifier is satisfied.

Description

Technical Field

[0001] This technique relates to the field of data processing.

[0002] In a data processing system, one or more processing elements may be coupled to one or more devices via an interconnect. For example, the devices may include a bus master device, a network interface controller, a display controller, etc. A device may issue a memory access request (also referred to as a device transaction) to the interconnect and request memory access to a specific location in memory accessible to the device and one or more processing elements.

[0003] Viewed from a first example of this technique, an interconnect circuit that couples a device to one or more processing elements configured to operate in at least one trusted execution environment, and a secure stashing decision circuit that receives a stashing transaction from the device and redirects the permitted stashing transaction to a given storage structure accessible to at least one of the one or more processing elements, The secure stashing decision circuit is configured to determine, in response to receiving a given stashing transaction, whether the given stashing transaction includes a trusted execution environment identifier associated with a given trusted execution environment, and to treat the given stashing transaction as a permitted stashing transaction when a redirection requirement depending on the trusted execution environment identifier is satisfied. An apparatus is provided.

[0004] Viewed from another example of this technique, a method of stashing a transaction, receiving a stashing transaction from a device coupled to one or more processing elements configured to operate in at least one trusted execution environment via an interconnect circuit, Redirecting an authorized stashing transaction to a given storage structure accessible to at least one of one or more processing elements, A method is provided that, in response to receiving a given stashing transaction, includes determining whether a given stashing transaction contains a trusted execution environment identifier associated with a given trusted execution environment, and treating the given stashing transaction as an authorized stashing transaction when redirection requirements that depend on the trusted execution environment identifier are met.

[0005] Further aspects, features, and advantages of this technique will become apparent from the following example description, which should be read in conjunction with the attached drawings. [Brief explanation of the drawing]

[0006] [Figure 1] A schematic example of a data processing device is shown below. [Figure 2] This indicates several regions in which the processing circuit can operate. [Figure 3] An example of a processing system that supports granule-protected lookup is shown. [Figure 4] This diagram schematically illustrates the aliasing of multiple physical address spaces within the system physical address space, which identifies their locations within the memory system. [Figure 5] This example demonstrates how to partition the effective hardware physical address space, thereby allowing different architectural physical address spaces to access their respective parts of the system physical address space. [Figure 6] This is a flowchart illustrating a method for determining the current operating range of a processing circuit. [Figure 7] This shows an example of the page table entry format for a page table entry used to translate a virtual address to a physical address. [Figure 8] This flowchart illustrates how to select the physical address space to be accessed by a given memory access request. [Figure 9] An example of a granular protection table entry is shown, which provides granular protection information indicating which physical address spaces are permitted to access a given physical address. [Figure 10] This is a flowchart showing how to perform a granule-protected lookup. [Figure 11] This shows several stages of address translation and granule protection information filtering. [Figure 12] This shows an example of a data processing system that includes multiple nodes connected via an interconnect. [Figure 13] Here is an example of a stashing transaction. [Figure 14] An example of a secure stashing decision circuit is shown. [Figure 15] An example of a target cache table that can be stored in the secure stashing decision circuit is shown. [Figure 16] This figure shows an example of how a secure stashing decision circuit can handle stashing transactions based on steering tags and realm IDs. [Figure 17] This is a flowchart illustrating the method for processing stashing transactions. [Figure 18] An example of an integrated circuit with a secure stashing decision circuit is shown.

[0007] Before discussing embodiments with reference to the attached drawings, the following description of exemplary embodiments and related advantages is provided.

[0008] According to one exemplary configuration, a device is provided comprising an interconnect circuit for coupling a device to one or more processing elements, each processing element operating in a trusted execution environment. In addition, a secure stashing decision circuit is provided to receive stashing transactions from the device and redirect authorized stashing transactions to a given storage structure accessible to at least one of the one or more processing elements. The secure stashing decision circuit is further configured to, in response to receiving a given stashing transaction, determine whether the given stashing transaction contains a trusted execution environment identifier associated with a given trusted execution environment, and to treat the given stashing transaction as an authorized stashing transaction if redirection requirements dependent on the trusted execution environment identifier are met.

[0009] In some systems, such as the data processing system described above, which comprises at least one processing element coupled to at least one device via an interconnect, a particular process running on either the processing element or the device may need to run securely and isolated from other processes. Such a system can support operation in several trusted execution environments (also called realms), each associated with one or more regions in memory that may only be accessible to processes running within that trusted execution environment. For example, a given processing element or device may operate within a trusted execution environment. Alternatively, different processes running on a given device or processing element may operate within different trusted execution environments.

[0010] By providing a trusted execution environment in this way, processes within a given trusted execution environment can be executed safely by preventing processes operating outside that trusted execution environment from accessing arbitrary data stored in the memory area associated with that trusted execution environment.

[0011] As described above, one or more devices within a data processing system can issue memory access requests (also called device transactions) to the interconnect, requesting access to a specific location in memory accessible to the device and one or more processing elements. For example, these may include write requests to write data to a target memory location, or read requests to read data from a target memory location. Typically, these device transactions are expected to complete within the memory system. For example, a write request is expected to be completed by writing data to the target memory region. Therefore, for one of the processing elements to access that data later, it will have to issue an access request for the processing element itself to retrieve the data from memory. Significant latency can exist associated with such memory access. Since memory may be isolated from processing elements by several structures, such as interconnects, latency can occur when retrieving data. In addition, memory may be large, which means that further latency may occur when the memory address of the requested data is accessed in memory.

[0012] Therefore, a processing element can access one or more storage structures (e.g., storage circuits such as a cache or other storage unit) that can store local copies of data that are also stored in memory. These storage structures may be isolated from memory by the interconnect so as to be on the same side of the interconnect as at least one processing element, allowing the processing element to access data without needing to access memory. This can provide a significant performance improvement by reducing the latency associated with accessing data. For example, the storage structure may be on the same side of the interconnect as the processing element so that data can be retrieved without needing to send signals through the interconnect circuit. In addition, the storage structure can be made significantly smaller than memory, resulting in faster access to the requested data.

[0013] However, if data in memory is updated, for example, due to a transaction issued by a device, the local copy (or multiple copies) of that data stored in one or more storage structures will no longer be up-to-date. This means that the processing element will need to retrieve the data from memory the next time it needs to access it. Therefore, when a memory location is updated in response to a device transaction, a knock-on effect on the performance of other processing elements that have access to that memory location may exist.

[0014] The apparatus of this technique attempts to address this problem by enabling several device transactions to be redirected to a given storage structure accessible to at least one processing element. These device transactions "stash" data within the given storage structure and are thus referred to as "stashing transactions" and accordingly end within the given storage structure rather than within memory. This enables data to be retrieved from the given storage structure rather than from memory, so that subsequent access to that data by at least one processing element can be performed with reduced latency.

[0015] However, the inventors of this technique have realized that this can pose potential security vulnerabilities if the storage structure to which stashing transactions are redirected is within (e.g., accessible within) a trusted execution environment different from the trusted execution environment of the device (or the process running on the device) that issued the transaction. This can potentially allow an untrusted process (e.g., from the perspective of the programmer of the process running on the device) to access confidential data related to the process running on the device.

[0016] Therefore, to provide improved security, a secure stashing decision circuit is provided to receive stashing transactions from a device and redirect authorized stashing transactions to a given storage structure accessible to at least one of one or more processing elements.

[0017] A device and one or more processing elements are coupled (e.g., connected) via an interconnect circuit, and at least one of the processing elements operates in a trusted execution environment. Further, a stashing transaction received by a secure stashing decision circuit can include a trusted execution environment identifier (e.g., a realm ID) associated with a particular trusted execution environment (e.g., a realm). The secure stashing decision circuit is configured to check whether a given stashing transaction includes a trusted execution environment identifier for the given stashing transaction, and to treat the given stashing transaction as an approved stashing transaction when a redirection requirement that depends on the trusted execution identifier is satisfied. For example, the redirection requirement can be based on whether a given stashing transaction includes a trusted execution environment identifier, and / or can be based on the value of the trusted execution identifier of a given transaction.

[0018] Thus, the technique provides improved performance without compromising the security of the system. In particular, by enabling at least some stashing transactions to be redirected to a storage structure accessible to a given processing element, the system performance can be improved by reducing the latency associated with subsequent accesses to data stored in response to a transaction. Additionally, the security of the system can be improved by redirecting only approved stashing transactions (which satisfy the redirection requirement that depends on the trusted execution identifier).

[0019] In some examples, each stashing transaction involves a request to access data associated with a location in memory. For example, memory may be a separate structure from a given storage structure, and may be isolated from one or more processing elements and the given storage structure by several components, such as interconnect circuits. Therefore, access to memory is likely to result in increased latency compared to access to a given storage structure. Thus, by redirecting permitted stashing transactions to trigger access to a given storage structure rather than the location in memory identified by the transaction, latency can be reduced when processing elements later access the data associated with that memory location. This can, in turn, lead to improved performance.

[0020] In some examples, a stashing transaction may include a write request to write data to a location associated with a location in memory, and a secure stashing decision circuit may be configured to write the data to a given storage structure when the redirection requirements are met. By writing the data to a given storage structure instead of writing it to a location in memory in this way, the latency associated with subsequent access to that data by processing elements that have access to that storage structure can be reduced, leading to improved performance.

[0021] In particular, if at least one processing element having access to a given storage structure is operating in a trusted execution environment, enabling data to be written directly to a given storage structure may seem counterintuitive to those skilled in the art, and enabling an external device to write data directly to a storage structure accessible to a processing element in a trusted execution environment may appear to potentially compromise the security of the system. However, the inventors have found that the performance benefits of redirecting stashing transactions can be achieved without significantly impacting the security of the system by providing a secure stashing decision circuit to check whether a stashing transaction contains a trusted execution environment identifier and redirect the stashing transaction to a given storage structure only when certain redirection criteria are met.

[0022] In some cases, whether a redirection requirement is met depends on whether a trusted execution environment identifier exists and / or the value of the trusted execution environment identifier. For example, whether a redirection requirement is met may depend on the value of the trusted execution environment identifier, except in cases where a trusted execution environment identifier does not exist. It will be understood that the redirection requirement may depend on other factors in addition to the conditions regarding the trusted execution environment identifier. For example, whether a redirection requirement is met may depend at least in part on whether the memory location targeted by the stashing transaction is in a trusted execution environment.

[0023] In some examples, the secure stashing decision circuit is configured to reject a given stashing transaction when a trusted execution environment identifier does not exist or is invalid, while a given storage structure is in a trusted execution environment. For example, if a given stashing transaction does not indicate a valid trusted execution environment identifier, the stashing transaction may be rejected if the given storage structure is in a trusted execution environment. This can provide improved security by ensuring that only stashing transactions from trusted devices (e.g., devices operating in a trusted execution environment) are allowed to access storage structures in a trusted execution environment.

[0024] In some examples, the secure stashing decision circuit is configured to assert an error signal in response to rejecting a given stashing transaction. For example, the asserted error signal may record (e.g., log) the error in a set of error log registers. The error log registers may be located, for example, within the interconnect circuit and may hold a record of previous errors, including previous stashing transactions rejected by the secure stashing decision circuit. In certain examples, if the device is connected to the interconnect via a root port, the error log registers may be located within the root port.

[0025] In some examples, a given storage structure is selected depending on the permitted stashing transaction. For example, a given storage structure may be identified based on the memory location indicated by the transaction, the trusted execution identifier indicated by the transaction (if any), and / or any other identifier indicated by the transaction.

[0026] In some examples, the secure stashing decision circuit is configured to determine whether a given stashing transaction contains a steering tag indicating a given storage structure, and when the secure stashing decision circuit determines that a given stashing transaction contains a steering tag, whether the redirection requirement is met further depends on the steering tag. Thus, the steering tag may provide a mechanism that allows at least some transactions issued by the device to be stashed (e.g., redirected) to a storage structure accessible to the processing element, instead of being directed to memory. As described above, by allowing a stashing transaction to be redirected to a storage structure accessible to one or more processing elements, a significant performance benefit is provided in terms of the reduced latency associated with subsequent access to that data by the processing element(s).

[0027] In some examples, the secure stashing decision circuit is configured to reject a given stashing transaction when a given storage structure is in a first trusted execution environment and the trusted execution environment identifier is absent or invalid, and / or when a given storage structure is in a first trusted execution environment and the trusted execution environment identifier is associated with a different trusted execution environment, and / or when the steering tag is invalid. This technique allows the performance benefits associated with providing a steering tag to be achieved without compromising the security of the system. In particular, this example provides three conditions that can trigger the rejection of a stashing transaction.

[0028] (Condition 1) A given storage structure is located within a first trusted execution environment, and no trusted execution environment identifier exists or is invalid. This condition protects against access to the given storage structure by processes that do not have an identity and / or security certificate specified. If no valid trusted execution identifier is specified, it may be difficult for the secure stashing decision circuit to determine whether it is safe to allow a given stashing transaction to access the given storage structure, and therefore the safest approach may be to reject the stashing transaction.

[0029] (Condition 2) A given storage structure resides within a first trusted execution environment, and a trusted execution environment identifier is associated with a different trusted execution environment. This condition protects the given storage structure from access by processes running outside the trusted execution environment from which it is provided. This improves security by keeping processes operating within the first trusted execution environment isolated from processes outside that environment that may be untrustworthy from the perspective of processes within the first trusted execution environment. Furthermore, data associated with the trusted execution environment on which a device is running is similarly protected from access by processes within the first trusted execution environment. Whether this condition is met can be determined, for example, by comparing a steering tag with a trusted execution environment identifier.

[0030] (Condition 3) The steering tag is invalid. This condition may apply for any one of several reasons. For example, if the steering tag is invalid, the secure stashing decision circuit may have difficulty determining the identity of a given storage structure, and therefore the stashing transaction may be rejected to avoid data being mistakenly written to the wrong storage structure.

[0031] The above conditions may be applied in any combination, and it will be understood that this still provides a significant security improvement (for the reasons stated above). For example, any one of the above conditions may be provided alone, and the security benefits described above may still be provided for that particular condition. Alternatively, any combination of two of the three conditions may be provided, or in fact, all three conditions may be provided.

[0032] In some examples, a given storage structure is selected based on the value of a trusted execution environment identifier and / or the value of a steering tag. For example, if a valid steering tag exists, a given storage structure may be identified by the steering tag. Alternatively, a given storage structure may be determined based on a trusted execution environment. This may be advantageous as it provides more flexibility in how a given storage structure is identified.

[0033] In some specific examples, the secure stashing decision circuit is configured to select a given storage structure based on the value of the steering tag, unless the steering tag is absent. For example, if the steering tag is absent, the given storage structure may be determined to be a storage structure in a trusted execution environment identified by a trusted execution environment identifier. Thus, a trusted execution environment identifier can offer the additional benefit of eliminating the need for a steering tag in some systems. This can be useful because the encoding space within a transaction may be limited, and removing the steering tag may free up encoding space for other purposes.

[0034] Protecting data associated with a trusted execution environment can be useful by encrypting the data using an encryption key accessible only to processes running in that trusted execution environment. By encrypting the data, even if an attacker obtains the data, they will not be able to interpret it without also obtaining the encryption key. Therefore, it can be useful to identify the encryption key identifier based on the trusted execution environment identifier, so that the encryption key for the data is identified. Thus, in some examples, a given stashing transaction involves a request to access data at a given location in memory, and the secure stashing decision circuit is configured to identify an encryption key identifier that indicates the encryption key for encrypting the data stored at a given location in memory, based on the trusted execution environment identifier.

[0035] In some examples, when a stashing transaction involves a write request to write data to a location associated with a location in memory, the secure stashing decision circuit may be configured to write the encryption key identifier and the data to a given storage structure. For example, the encryption key identifier can be stored together with the data in a given storage structure, and as a result, when that data is subsequently stored in memory (e.g., due to being evicted from the storage structure), the encryption key can be found and used to encrypt the data. However, it will be understood that it is not essential for the encryption key identifier to be stored together with the data in a given storage structure; for example, the encryption key identifier can instead be looked up using a trusted execution identifier whenever it is needed (e.g., when the data is evicted from the given storage structure). Also, for example, if a given storage structure is entirely within a single trusted execution environment (e.g., a given storage structure holds only data associated with a single trusted execution environment), then the encryption key identifier may not be needed at all, as it may be implicit that any data stored in the given storage structure is encrypted using one or more encryption keys associated with that single trusted execution environment.

[0036] In some examples, a given storage structure includes a cache. A cache is typically a local storage structure separate from memory and is (logically) located closer to one or more processing elements in the system than memory. Therefore, accessing the cache is often significantly faster than accessing memory (e.g., associated with lower latency). Furthermore, a cache may be significantly smaller than memory, and therefore retrieving the required data in the cache may be significantly faster. Thus, copies of some data in memory (e.g., frequently accessed data) can be kept in one or more caches for reduced latency access. Enabling stashing transactions to access data in the cache rather than in memory can therefore result in performance improvements by reducing the latency associated with subsequent access to that data.

[0037] In a processing system, multiple levels of caching may be provided within the memory hierarchy, with some caches (usually smaller, though not necessarily) provided closer to the processing elements, and other caches (usually larger, though not necessarily) shared among multiple processing elements and provided closer to memory. Copies of data at a particular memory location may be held in multiple caches. For example, a data item may be held in both a level 1 cache closer to the processing element and a larger level 2 cache closer to memory, so that if the data is evicted from the level 1 cache, the processing element does not need to retrieve the data from memory and can still access it reasonably quickly from the level 2 cache. This is known as cache containment. However, sharing some caches among multiple processing elements can present security issues, and if not all of these processing elements operate within the same trusted execution environment, it may be undesirable to store data associated with one trusted execution environment in a cache accessible to processes running in other execution environments. Even if the data is encrypted or held in a portion of a shared cache inaccessible to processes in other trusted execution environments, this can still present security risks. For example, an attacker may be able to determine whether data is stored in a particular entry in the cache simply based on how quickly access requests to that entry are denied. This could give the attacker information about which memory locations have been recently accessed by a given process in different trusted execution environments, which in some situations may be enough to compromise the security of the system.

[0038] Therefore, it can be useful to control cache inclusion based on a trusted execution environment identifier indicated by a given stashing transaction, for example, by controlling whether a copy of a given data item is stored in multiple caches or in only one cache. This can provide improved security by preventing processes in other trusted execution environments from accessing the data or making assumptions based on the existence of that data in the cache. Thus, in some examples, a secure stashing decision circuit is configured to control, based on a trusted execution environment identifier, whether at least one given cache line in a cache is permitted to be held in at least one other cache as well.

[0039] In some examples, a device has a root port located at the first level of the device hierarchy, and the device is located within the device hierarchy and coupled to the interconnect via the root port. There are many ways in which a device can be coupled to an interconnect, but one example is providing a root port between the device and the interconnect. This can be particularly useful in networks with a large number of devices, as it allows the device to be placed in a hierarchy and one or more root ports are provided at the first level of the hierarchy (e.g., closest to the interconnect). The device in this technique may be directly connected to the root port (e.g., at the second level of the hierarchy) or connected to the root port via one or more other intervening devices.

[0040] In some examples, a device comprises a requester device within a packet network, which is configured to send stashing transactions to the root port according to the packet protocol of the packet network for forward propagation to the interconnect. The packet network is a specific type of network that a device may provide. However, it will be understood that this technique is applicable to any type of network in which a device is coupled to one or more processing elements via an interconnect circuit.

[0041] In some examples, the packet protocol may be the PCIe (Peripheral Component Interconnect Express) protocol. PCIe is a widely used packet protocol, and therefore, it is clearly advantageous that this technique is applicable within this standard. However, it should be understood that this technique is not limited to its use within this standard and can, in practice, be applied in any type of network where devices are coupled to one or more processing elements via interconnect circuits.

[0042] In some examples, the root port houses the secure stashing decision circuit. While there are many potential locations between the device and one or more processing elements for placing the secure stashing decision, one possibility is to house this circuit within the root port.

[0043] In some examples, the interconnect includes a home node circuit responsible for controlling access to a portion of the memory, and the home node circuit includes a secure stashing decision circuit. Therefore, another possible location for the secure stashing decision circuit is within the interconnect itself, and in such exemplary implementations, the secure stashing decision circuit may be provided within the home node of the interconnect.

[0044] It will be understood that both the root node and the home node are merely examples of locations where a secure stashing decision circuit may be placed, enabling the application of this technique within an existing system. However, it will be understood that in other examples, the secure stashing decision circuit may be located elsewhere.

[0045] Here, an embodiment of this technique will be described with reference to the drawings.

[0046] Figure 1 schematically illustrates an example of a data processing system 2 having at least one requester device 4 and at least one completer device 6. An interconnect 8 provides communication between the requester device 4 and the completer device 6. The requester device can issue memory access requests requesting memory access to a specific addressable memory system location. The completer device 6 is the device responsible for processing the memory access requests directed to it. Although not shown in Figure 1, some devices may be able to function as both a requester device and a completer device. The requester device 4 may include, for example, a processing element such as a central processing unit (CPU) or a graphics processing unit (GPU), or other master devices such as a bus master device, a network interface controller, or a display controller. The completer device may include a memory controller responsible for controlling access to the corresponding memory storage device, a peripheral controller for controlling access to peripheral devices, etc. Figure 1 shows one exemplary configuration of a requester device 4 in more detail, but it will be understood that other requester devices 4 may have similar configurations. Alternatively, other requester devices may have a different configuration from requester device 4 shown on the left side of Figure 1.

[0047] The requester device 4 has a processing circuit 10 for performing data processing in response to an instruction by referring to data stored in register 12. Register 12 may include not only general-purpose registers for storing operands and the results of processed instructions, but also control registers for storing control data that configures how the processing is performed by the processing circuit. For example, the control data may include a current region indicator 14 used to select which operating region is the current region, and a current exception level indicator 15 indicating which exception level is the current exception level on which the processing circuit 10 is operating.

[0048] The processing circuit 10 may issue a memory access request specifying a virtual address (VA) that identifies the addressable location to be accessed, and a domain identifier (domain ID or "security state") that identifies the current region. The address translation circuit 16 (e.g., a memory management unit (MMU)) translates the virtual address to a physical address (PA) through one of several stages of address translation, based on page table data defined in a page table structure stored in the memory system. The translation lookaside buffer (TLB) 18 acts as a lookup cache to cache a portion of the page table information for faster access than if the page table information had to be fetched from memory each time address translation was needed. In this example, in addition to generating a physical address, the address translation circuit 16 also selects one of several physical address spaces associated with the physical address and outputs a physical address space (PAS) identifier that identifies the selected physical address space. The selection of the PAS will be discussed in more detail below.

[0049] The PAS filter 20 functions as a requester filtering circuit to determine, based on the translated physical address and PAS identifier, whether the physical address is permitted to be accessed within the physical address space identified and specified by the PAS identifier. This lookup is based on granule protection information stored in a granule protection table structure stored in the memory system. Granule protection information can be cached in a granule protection information cache 22, similar to the cache of page table data in the TLB 18. In the example in Figure 1, the granule protection information cache 22 is shown as a separate structure from the TLB 18, but in other examples, these types of lookup caches can be combined as a single lookup cache structure, and as a result, a single lookup of entries in the combined structure provides both page table information and granule protection information. The granule protection information defines information that restricts the physical address space in which a given physical address can be accessed, and based on this lookup, the PAS filter 20 determines whether it is possible to proceed with issuing a memory access request to one or more caches 24 and / or interconnect 8. If the specified PAS for a memory access request is not permitted to access the specified physical address, the PAS filter 20 may block the transaction and signal the malfunction.

[0050] Figure 1 shows an example of a system having multiple requester devices 4, but the characteristics shown for the single requester device on the left side of Figure 1 can also be found in systems with only one requester device, such as a single-core processor.

[0051] Figure 1 shows an example where the PAS selection for a given request is performed by the address translation circuit 16. In other examples, the address translation circuit 16 can output information to the PAS filter 20 along with the PA to determine which PAS to select, and the PAS filter 20 can select a PAS and check whether the PA can be accessed within the selected PAS.

[0052] The provision of PAS filters 20 helps support a system that can operate in multiple operating regions, each associated with its own isolated physical address space. Here, for at least a portion of the memory system (for example, for some cache or coherence enforcement mechanisms such as snoop filters), separate physical address spaces are treated as if they pointed to a different set of addresses that identified entirely different memory system locations, even though the addresses in those address spaces actually pointed to the same physical location in the memory system. This can be useful for security purposes.

[0053] Figure 2 shows examples of different operating states and domains in which the processing circuit 10 can operate, as well as examples of types of software that can run at different exception levels and domains (it should be understood that, naturally, the specific software installed on the system is selected by the party managing the system and is therefore not an essential feature of the hardware architecture).

[0054] The processing circuit 10 can operate with several different exception levels 80, four exception levels labeled EL0, EL1, EL2, and EL3 in this embodiment, where EL3 refers to the highest privileged exception level and EL0 refers to the lowest privileged exception level. In other architectures, it will be understood that the reverse numbering may be chosen, and the exception level with the highest number may be considered to have the lowest privilege. In this embodiment, the lowest privileged exception level EL0 is for application-level code, the next highest privileged exception level EL1 is used for operating system-level code, the next highest privileged exception level EL2 is used for hypervisor-level code that manages switching between several virtual operating systems, and the highest privileged exception level EL3 is used for monitor code that manages switching between each region and the allocation of physical addresses to the physical address space, as will be described later.

[0055] When an exception occurs at a specific exception level while processing software, for some types of exceptions, the exception is accepted at a higher (more privileged) exception level, and the specific exception level to which the exception is accepted is selected based on the attributes of the specific exception that occurred. However, in some situations, other types of exceptions may be accepted at the same exception level associated with the code that was being processed when the exception was accepted. When an exception is accepted, information characterizing the state of the processor at the time the exception was accepted can be stored, including, for example, the current exception level at the time the exception was accepted. Therefore, once an exception handler is processed to address the exception, processing can return to the previous processing, and the stored information can be used to identify the exception level to which processing should return.

[0056] In addition to different exception levels, the processing circuit also supports several operating regions, including the root region 82, the secure (S) region 84, the less secure region 86, and the realm region 88. For ease of reference, the less secure region will be described below as the “unsecure” (NS) region, but it should be understood that this is not intended to imply a particular level (or lack thereof) of security. Instead, “unsecure” simply indicates that the unsecure region is intended for code that is less secure than the code operating in the secure region. The root region 82 is selected when the processing circuit 10 is at the highest exception level, EL3. When the processing circuit is at one of the other exception levels, EL0 through EL2, the current region is selected based on the current region indicator 14, which indicates which of the other regions 84, 86, and 88 is active. For each of the other regions 84, 86, and 88, the processing circuit can be at any of the exception levels EL0, EL1, or EL2.

[0057] During startup, several boot codes (e.g., BL1, BL2, OEM boot) may be executed, for example, within a higher privileged exception level, such as EL3 or EL2. Boot codes BL1 and BL2 may be associated with the root area, for example, while the OEM boot code may operate in a secure area. However, once the system is started, during execution, the processing circuit 10 can be considered to operate in one of areas 82, 84, 86, and 88 at a time. Each of areas 82-88 is associated with its own associated physical address space (PAS). This allows for the isolation of data from different areas within at least a portion of the memory system. This will be explained in more detail below.

[0058] The non-secure area 86 can be used for normal application-level processing and for operating system and hypervisor activities to manage such applications. Therefore, application code 30 running in EL0, operating system (OS) code 32 running in EL1, and hypervisor code 34 running in EL2 may reside within the non-secure area 86.

[0059] The secure region 84 allows specific system-on-chip security, media, or system services to be isolated in a physical address space separate from the physical address space used for non-secure processing. Secure and non-secure regions are not equivalent in that non-secure region code cannot access resources associated with the secure region 84, while the secure region can access both secure and non-secure resources. An example of a system that supports such partitioning of secure and non-secure regions 84, 86 is a system based on the TrustZone® architecture provided by Arm® Limited. The secure region can run trusted applications 36 in EL0, trusted operating systems 38 in EL1, and optionally a secure partition manager 40 in EL2. If secure partitioning is supported, EL2 can use a stage 2 page table to support isolation between different trusted operating systems 38 running within the secure region 84 in a similar manner to how a hypervisor 34 can manage isolation between virtual machines or guest operating systems 32 running within the non-secure region 86.

[0060] Extending a system to support a secure region 84 has become common in recent years because it allows a single hardware processor to support isolated secure processing and avoids the need for processing to be performed on another hardware processor. However, as the use of secure regions has become more popular, many practical systems with such secure regions now support a relatively high degree of mixed environments of services provided by a wide range of different software providers within the secure region. For example, the code running within the secure region 84 may contain different software, and its providers may include (among others) silicon providers that manufacture integrated circuits, original equipment manufacturers (OEMs) that assemble integrated circuits provided by silicon providers into electronic devices such as mobile phones, operating system vendors (OSVs) that provide operating systems 32 for devices, and / or cloud platform providers that manage cloud servers that support services for several different customers via the cloud.

[0061] However, there is a growing demand for a secure computing environment that provides reliable assurance that providers of user-level code (which would typically be expected to run as applications 30 in the non-secure region 86) will not leak information to other parties running their code on the same physical platform. Such a secure computing environment may be desirable to be dynamically scalable during execution and guaranteed and verifiable so that users can verify whether sufficient security assurances are provided on the physical platform before entrusting the processing of potentially sensitive code or data to the device. Users of such software may not want to trust providers of feature-rich operating systems 32 or hypervisors 34 that would typically run in the non-secure region 86 (or, even if the providers themselves are trustworthy, users may want to protect themselves from unauthorized access to the operating system 32 or hypervisor 34 by attackers). Furthermore, while a secure region 84 is available for such user-provided applications that require secure processing, in practice this creates problems for both users providing code that requires a secure computing environment and providers of existing code running within the secure region 84. For providers of existing code operating within Secure Area 84, the addition of arbitrary user-provided code to the Secure Area increases the attack surface for potential attacks against that code. This may be undesirable, and therefore, users may be strongly advised not to allow users to add code to Secure Area 84. On the other hand, users providing code that requires a secure computing environment may find it difficult to audit and verify all separate codes provided by different software providers operating within Secure Area 84, especially if assurance and proof of the code operating in a particular area are required as a prerequisite for the user-provided code to perform processing. They may therefore be reluctant to entrust access to their data or code to all different code providers operating within Secure Area 84.This could limit the opportunity for third parties to provide more secure services.

[0062] Therefore, as shown in Figure 2, an additional region 88 called the realm region is provided and can be used by user-introduced code to provide a secure computing environment orthogonal to any secure computing environment associated with a component operating in the secure region 24. In the realm region, the software being executed can contain several realms, each realm can be isolated from other realms by a realm management module (RMM) 46 operating at exception level EL2. The RMM 46 can control the isolation between each realm 42, 44 running in the realm region 88 by defining access permissions and address mappings in a page table structure, for example, in the way that a hypervisor 34 manages the isolation between different components operating in the non-secure region 86. In this example, the realms include an application-level realm 42 running at EL0 and an encapsulated application / operating system realm 44 running across exception levels EL0 and EL1. It will be understood that it is not mandatory to support both EL0 and EL0 / EL1 type realms, and multiple realms of the same type can be established by the RMM 46.

[0063] Realm region 88, like secure region 84, has its own physical address space allocated to the realm region. However, while the realm region and secure regions 88 and 84 can each access the non-secure PAS associated with non-secure region 86, the realm region and secure regions 88 and 84 cannot access each other's physical address spaces. This means that the realm region is orthogonal to secure region 84. This means that the code running in realm region 88 and secure region 84 have no dependencies on each other. Code in the realm region only needs to trust the hardware, RMM46, and the code running in root region 82, which manages switching between regions. This means that proof and assurance are more feasible. Proof allows given software to require verification that the code installed on a device matches certain expected characteristics. This can be done by checking whether the hash of the program code installed on the device matches an expected value signed by a trusted party using a cryptographic protocol. RMM46 and monitor code 29 can be verified, for example, by checking whether the hash of this software matches an expected value signed by a trusted party, such as the silicon provider that manufactured the integrated circuit including processing system 2, or the architecture provider that designed the processor architecture that supports region-based memory access control. This allows user-provided codes 42 and 44 to verify whether the integrity of the region-based architecture is trustworthy before executing any secure or confidential functions.

[0064] Therefore, as indicated by the dotted lines showing the gaps in the non-secure region where these processes would have previously been executed, the code associated with realms 42 and 44, which would have previously been running in the non-secure region 86, can now be moved to a realm region where they can have stronger security guarantees, as their data and code are now inaccessible to other code running in the non-secure region 86. However, the fact that realm region 88 and secure region 84 are orthogonal and therefore cannot see each other's physical address spaces means that providers of code in the realm region do not need to trust providers of code in the secure region, and vice versa. Code in the realm region can simply trust the firmware that provides the monitor code 29 for root region 82 and RMM46, which may be provided by the silicon provider or the provider of the instruction set architecture supported by the processor. These providers may need to be inherently trusted from the outset when the code is running on their device, and as a result, no further trust relationships with other operating system vendors, OEMs, or cloud hosts are required by the user in order for the user to be able to provide a secure computing environment.

[0065] This is useful for a variety of applications and use cases, including, for example, mobile wallet and payment applications, anti-fraud and anti-copyright infringement mechanisms in games, operating system platform security extensions, secure virtual machine hosting, confidential computing, networking, or gateway processing for the Internet of Things. Users will understand that they may find many other applications where Realm Support is useful.

[0066] To support the security assurances provided to the Realm, the processing system can support a certification reporting function, which measures the image and configuration of the firmware, for example, the image and configuration of the monitor code or the image and configuration of the RMM code, at startup or during execution. During execution, the content and configuration of the Realm are measured, so that the Realm owner can trace back relevant certification reports against known implementations and assurances and make a confidence decision about whether it will work on that system.

[0067] As shown in Figure 2, a separate root region 82 is provided to manage region switching, and this root region has its own isolated root physical address space. Creating a root region and isolating resources from the secure region allows for a more robust implementation, even in systems that have only non-secure and secure regions 86, 84 and no realm region 88, but can also be used in implementations that support the realm region 88. The root region 82 can be implemented using monitoring software 29 provided (or guaranteed) by the silicon provider or architecture designer and can be used to provide secure boot functionality, trusted boot measurement, system-on-chip configuration, debug control, and firmware update management for firmware components provided by other parties such as the OEM. The code for the root region can be developed, guaranteed, and deployed by the silicon provider or architecture designer without any dependency on the final device. In contrast, the secure region 84 can be managed by the OEM to implement specific platform and security services. The management of the non-secure area 86 can be controlled by the operating system 32 that provides operating system services, while the realm area 88 is isolated from the existing secure software environment in the secure area 84, and at the same time, it enables the development of new forms of trusted execution environments that can be dedicated to the user or third-party applications.

[0068] Figure 3 schematically shows another example of processing system 2 to support these technologies. Elements that are the same as those in Figure 1 are indicated by the same reference numbers. Figure 3 shows more detail of the address translation circuit 16, including the Stage 1 memory management unit 50 and the Stage 2 memory management unit 52. The Stage 1 MMU 50 may be involved in translations from virtual addresses to physical addresses (when the translation is triggered by an EL2 or EL3 code) or to intermediate addresses (when the translation is triggered by an EL0 or EL1 code in an operating state where further Stage 2 translation by the Stage 2 MMU 52 is required). The Stage 2 MMU can translate intermediate addresses to physical addresses. The Stage 1 MMU may be based on a page table controlled by the operating system for translations initiated from EL0 or EL1, a page table controlled by the hypervisor for translations from EL2, or a page table controlled by monitor code 29 for translations from EL3. The Stage 2 MMU 52, on the other hand, may be based on a page table structure defined by the hypervisor 34, RMM 46, or secure partition manager 14, depending on which region is being used. By separating the translation into these two stages, operating systems can manage address translation for themselves and for applications, under the assumption that they are the only operating systems running on the system, while RMM46, hypervisor34, or SPM40 can manage isolation between different operating systems running in the same area.

[0069] As shown in Figure 3, the address translation process using the address translation circuit 16 can, in combination with the current exception level 15 and the current region 14 (or security state), return a security attribute 54 that allows a section of a particular physical address space (identified by a PAS identifier or "PAS TAG") to be accessed in response to a given memory access request. The physical address and PAS identifier can be looked up in the granular protection table 56 that provides the aforementioned granular protection information. In this example, the PAS filter 20 is shown as a granular memory protection unit (GMPU) that verifies whether the selected PAS is authorized to access the requested physical address, and if so, allows the transaction to be passed to any cache 24 or interconnect 8 that is part of the system fabric of the memory system.

[0070] GMPU20 enables the allocation of memory to separate address spaces while simultaneously providing strong hardware-based isolation guarantees, offering not only spatial and temporal flexibility in how physical memory is allocated to these address spaces, but also an efficient sharing scheme. As mentioned earlier, execution units within the system are logically divided into virtual execution states (regions or "worlds") where a single execution state (root world) located at the highest exception level (EL3) resides, and the root world manages the allocation of physical memory to these worlds.

[0071] A single system physical address space is virtualized into multiple “logical” or “architectural” physical address spaces (PAS), each such PAS being an orthogonal address space with independent coherency attributes. System physical addresses are mapped to a single “logical” physical address space by extending it with PAS tags.

[0072] A given world is granted access to a subset of the logical-physical address space. This is accomplished by a hardware filter 20, which can be attached to the output of the memory management unit 16.

[0073] The world defines the security attributes (PAS tags) of access using fields in the translation table descriptor of the page table used for address translation. The hardware filter 20 has access to a table (granule protection table 56, or GPT) that defines granule protection information (GPI) for each page in the system physical address space, where the granule protection information indicates the PAS TAG to which it is associated, and (optionally) other granule protection attributes.

[0074] The hardware filter 20 checks the world ID and security attributes of the granule's GPI to determine whether access may be permitted, and in this way forms a detailed memory protection unit (GMPU).

[0075] GPT56 can reside, for example, in on-chip SRAM or off-chip DRAM. When stored off-chip, GPT56 can be protected for integrity by an on-chip memory protection engine that can use encryption, integrity, and freshness mechanisms to maintain the security of GPT56.

[0076] By positioning GMPU20 on the system's requester side (e.g., on the MMU output) rather than the completer side, interconnect 8 can assign access permissions in page detail while allowing continuous page hashing / striping across multiple DRAM ports.

[0077] The PAS TAG remains tagged because the transaction propagates throughout the system fabric 24,8 until it reaches a location defined as a physical aliasing point 60. This allows the filter to be placed on the master side without weakening security guarantees compared to slave-side filtering. As the transaction propagates throughout the system, the PAS TAG can be used as a detailed security mechanism for address isolation. For example, a cache can add the PAS TAG to address tags in the cache to prevent access made using the wrong PAS TAG for the same PA from hitting the cache, thereby improving side-channel resistance. The PAS TAG can also be used as a context selector for a protection engine attached to a memory controller that encrypts data before it is written to external DRAM.

[0078] A Physical Alias ​​Point (PoPA) is a location within the system where a PAS TAG is detached and the address returns from a logical physical address to a system physical address. A PoPA can be located below the cache on the completer side of the system, where access to physical DRAM is performed (using the cryptographic context resolved via the PAS TAG). Alternatively, it may be located above the cache to simplify the system implementation at the expense of security.

[0079] At any given time, the world can request to transition a page from one PAS to another. The request is made by EL3 to monitor code 29, which checks the current state of the GPI. EL3 may allow only a specific set of transitions to occur (e.g., from a non-secure PAS to a secure PAS, rather than from a realm PAS to a secure PAS). To provide a clean transition, a new instruction "delete data and invalidate up to the physical aliasing point" is supported by the system, and EL3 can submit this before transitioning the page to the new PAS. This ensures that any residual state associated with the previous PAS is flushed from any cache upstream of PoPA60 (closer to the requester side).

[0080] Another characteristic that can be achieved by installing GMPU20 on the master side is the efficient sharing of memory between worlds. It may be desirable to allow a subset of N worlds shared access to a physical granule while preventing other worlds from accessing it. This can be achieved by adding the semantic "limited sharing" to the granule protection information and enforcing the use of a specific PAS TAG. As an example, GPI may indicate that a physical granule can only be accessed by "realm world" 88 and "secure world" 84 while it is tagged with the PAS TAG of secure PAS 84.

[0081] The above example of characteristics leads to a rapid change in the visibility characteristics of a particular physical granule. Consider a case where each world is assigned a private PAS that is accessible only to that world. For a particular granule, a world can request that it be made visible to non-secure worlds at any time without changing the PAS association by changing its GPI from "exclusive" to "limitedly shared with non-secure worlds". In this way, the visibility of that granule can be increased without requiring costly cache maintenance or data copy operations.

[0082] Figure 4 illustrates the concept of renaming each physical address space on the physical memory provided in the hardware. As mentioned above, each of regions 82, 84, 86, and 88 has its own physical address space 61.

[0083] At the point when the physical address is generated by the address translation circuit 16, the physical address has a value within a specific numerical range 62 supported by the system, which is the same regardless of which physical address space is selected. However, in addition to generating the physical address, the address translation circuit 16 may also select a specific physical address space (PAS) based on the current region 14 and / or information in the page table entries used to derive the physical address. Alternatively, instead of the address translation circuit 16 performing the PAS selection, an address translation circuit (e.g., an MMU) may output the physical address and information derived from the page table entries (PTEs) used for PAS selection, which can then be used by a PAS filter or GMPU 20 to select a PAS.

[0084] The selection of PAS for a given memory access request may be limited according to the rules defined in the table below, depending on the current region in which the processing circuit 10 is operating when it issues the memory access request.

[0085] [Table 1]

[0086] For regions where multiple physical address spaces are available for selection, the system uses information from accessed page table entries used to provide the physical address to select from among the available PAS options.

[0087] Therefore, by the time the PAS filter 20 outputs a memory access request to the system fabric 24,8 (assuming it has passed any filtering checks), the memory access request is associated with a physical address (PA) and a selected physical address space (PAS).

[0088] From the perspective of memory system components (caches, interconnects, snoop filters, etc.) operating before the Physical Aliasing (PoPA) point 60, each physical address space 61 is considered a completely separate address range corresponding to a different system location in memory. This means that, from the perspective of pre-PoPA memory system components, the address range identified by a memory access request is actually four times the size of the range 62 that can be output in address translation. This is because, in effect, the PAS identifier is treated as an additional address bit alongside the physical address itself, and therefore, depending on the selected PAS, the same physical address PAx can be mapped to a number of aliased physical addresses 63 in separate physical address spaces 61. Although all of these aliased physical addresses 63 actually correspond to the same memory system location implemented in the physical hardware, pre-PoPA memory system components treat aliased addresses 63 as different addresses. Therefore, if there is a pre-PoPA cache or snoop filter allocating entries to such addresses, the aliased addresses 63 will be mapped to different entries with different cache hit / miss decisions and different coherency management. This reduces the likelihood or effectiveness of attackers using caches or coherence channels as a mechanism to explore the behavior of other domains.

[0089] The system may include two or more PoPAs 60 (for example, as shown in Figure 14 discussed below). In each PoPA 60, the aliased physical address is folded into a single unaliased address 65 in the system physical address space 64. The unaliased address 65 is provided downstream of any post-PoPA component, and as a result, the system physical address space 64 that actually identifies the memory system location is again the same size as the range of physical addresses that can be output in the address translation performed on the requester side. For example, in a PoPA 60, the PAS identifier may be detached from the address, and for downstream components, the address can be identified simply using the physical address value without specifying the PAS. Alternatively, in some cases where some completer-side filtering of memory access requests is desired, the PAS identifier may still be provided downstream of the PoPA 60, but may not be interpreted as part of the address. As a result, the same physical address appearing in different physical address spaces 60 will be interpreted downstream of the PoPA to point to the same memory system location. However, the supplied PAS identifier can still be used to perform completer-side security checks.

[0090] Figure 5 illustrates how the system physical address space 64 can be divided into chunks allocated for access within the physical address space 61 on a particular architecture using a granule protection table 56. The granule protection table (GPT) 56 defines which parts of the system physical address space 65 are accessible from the physical address space 61 on each architecture. For example, the GPT 56 may contain several entries corresponding to granules of physical addresses of a certain size (e.g., 4K pages), and may define the PAS to which that granule is allocated, which can be selected from non-secure, secure, realm, and root regions. By design, if a particular granule or set of granules is allocated to a PAS associated with one of the regions, it can only be accessed within the PAS associated with that region and not within the PAS of other regions. However, it should be noted that even though a granule allocated to a secure PAS (for example) cannot be accessed from within the root PAS, the root region 82 can still access that granule at a physical address by specifying PAS selection information in its page table to ensure that the virtual address associated with the page mapped to that region of physically addressed memory is translated to a physical address in the secure PAS instead of the root PAS. Thus, data sharing between regions (to the extent permitted by the accessibility rules defined in the table above) can be controlled at the time of selecting the PAS for a given memory access request.

[0091] However, in some implementations, in addition to enabling access to granules of physical addresses within an assigned PAS as defined by GPT, GPT can use other GPT attributes to mark a region of the address space (for example, an address space associated with a lower or orthogonal privilege region that is not normally permitted to select the assigned PAS for an access request to that region) as shared with another address space. This can facilitate the temporary sharing of data without the need to change the PAS assigned to a given granule. For example, in Figure 5, region 70 of the realm PAS is defined in GPT to be assigned to a realm region, and since non-secure region 86 cannot select the realm PAS for its access request, it is normally inaccessible from non-secure region 86. Since non-secure region 26 cannot access the realm PAS, non-secure code would normally not be able to see the data in region 70. However, if a realm primarily desires to share some of its data within an allocated memory region with an insecure region, it can request monitor code 29, operating in the root region 82, to update GPT56 to indicate that region 70 is shared with the insecure region 86. This makes region 70 accessible from the insecure PAS shown on the left side of Figure 5 without needing to change which region is allocated to region 70. When a realm region points to a region of its address space as being shared with an insecure region, a memory access request issued from the insecure region targeting that region may initially specify an insecure PAS, but the PAS filter 20 can remap the request's PAS identifier to specify the realm PAS instead. This allows downstream memory system components to treat the request as if it had been issued from the realm region from the beginning. This sharing can improve performance because the operation of allocating different regions to a particular memory region may be more performance-intensive, involving a higher degree of cache / TLB invalidation and / or data zeroing in memory or data copying between memory regions.This may not be justifiable if the sharing is expected to be only temporary.

[0092] Figure 6 is a flowchart showing how the current operating region is determined, which may be performed by the processing circuit 10, or by the address translation circuit 16 or the PAS filter 20. In step 100, it is determined whether the current exception level 15 is EL3, and if so, then in step 102, it is determined that the current region is the root region 82. If the current exception level is not EL3, then in step 104, it is determined that the current region is one of the non-secure, secure, and realm regions 86, 84, or 88, as indicated by at least two region indicator bits 14 in the processor's EL3 control register (since the root region is indicated by the current exception level being EL3, it is not necessary to have a code for the region indicator bit 14 corresponding to the root region, and therefore the code for at least one region indicator bit can be reserved for other purposes). The EL3 control register is writable when operating at EL3 and cannot be written from other exception levels EL2 to EL0.

[0093] Figure 7 shows an example of a page table entry (PTE) that can be used by the address translation circuit 16 for page table entries in a page table structure used for mapping from virtual addresses to physical addresses, from virtual addresses to intermediate addresses, or from intermediate addresses to physical addresses (depending on whether the translation is performed in an operating state where a Stage 2 translation is required in the first place, and if a Stage 2 translation is required, whether the translation is Stage 1 or Stage 2). Generally, a given page table structure may be defined as a multilevel table structure in which the first level of the page table is implemented as a page table tree identified based on a base address stored in the processor's translation table base address register, and the index for selecting a particular level 1 page table entry in the page table is derived from a subset of bits of the input address from which the translation lookup is performed (the input address may be a virtual address for Stage 1 translation, or an intermediate address for Stage 2 translation). A level 1 page table entry may be a “table descriptor” 110 that provides a pointer 112 to the next level of the page table from which further page table entries may be selected based on a further subset of bits of the input address. Finally, after one or more lookups into successive levels of page tables, it is possible to identify blocks or page descriptors PTEs 114, 116, 118 that provide the output address 120 corresponding to the input address. The output address may be an intermediate address (for stage 1 translations performed in an operating state where further stage 2 translations are also performed) or a physical address (for stage 2 translations, or stage 1 translations when stage 2 is not required).

[0094] To support the separate physical address spaces described above, the page table entry format may specify several additional states for use in physical address space selection, in addition to the next level page table pointer 112 or output address 120 and any attributes 122 for controlling access to the corresponding block in memory.

[0095] For table descriptor 110, the PTE used by any realm other than the non-secure realm 86 includes a non-secure table indicator 124 that indicates whether the next level of page tables should be accessed from the non-secure physical address space or the physical address space of the current realm. This helps facilitate more efficient management of page tables. Often, the page table structure used by the root, realm, or secure realm 24 may only need to define special page table entries for a portion of the virtual address space, and the same page table entries used by the non-secure realm 26 may be available for the other portion. Thus, by providing the non-secure table indicator 124, a realm / secure-only table descriptor can be provided at a higher level of the page table structure, while at some point in the page table tree, the root realm or secure realm can switch to using page table entries from the non-secure realm for portions of the address space where higher security is not required. Other page table descriptors in other parts of the page table tree can still be fetched from the associated physical address space associated with the root, realm, or secure realm.

[0096] On the other hand, block / page descriptors 114, 116, and 118 may contain physical address space selection information 126, depending on which region they are associated with. A non-secure block / page descriptor 118 used within a non-secure region 86 does not contain any PAS selection information, since the non-secure region can only access non-secure PAS. However, for other regions, block / page descriptors 114 and 116 contain PAS selection information 126 used to select the PAS that translates the input address. For the root region 22, the EL3 page table entry may have PAS selection information 126 containing at least two bits to indicate the PAS associated with one of the four regions 82, 84, 86, and 88 as the selected PAS to which the corresponding physical address is translated. In contrast, for realm and secure regions, the corresponding block / page descriptor 116 must contain only one bit of PAS selection information 126, thereby selecting between the realm and a non-secure PAS for the realm region, and between a secure PAS and a non-secure PAS for the secure region. To improve the efficiency of circuit implementation and avoid increasing the size of page table entries, for realm and secure regions, the block / page descriptor 116 can code the PAS selection information 126 at the same location in the PTE regardless of whether the current region is a realm or secure, thus allowing the PAS selection bits 126 to be shared.

[0097] Therefore, Figure 8 is a flowchart showing how to select a PAS based on the current region and information 124, 126 from the block / page PTE used to generate a physical address for a given memory access request. PAS selection can be performed by the address translation circuit 16, or by a combination of the address translation circuit 16 and the PAS filter 20, if the address translation circuit sends the PAS selection information 126 to the PAS filter 20.

[0098] In step 130 of Figure 8, the processing circuit 10 issues a memory access request specifying a given virtual address (VA) as the target VA. In step 132, the address translation circuit 16 looks up any page table entry (or cache information derived from such a page table entry) in its TLB 18. If any of the required page table information is unavailable, the address translation circuit 16 initiates a page table walk to memory to fetch the required PTE (potentially requiring a series of memory accesses to step through each level of the page table structure and / or multiple stages of address translation to obtain mappings from VA to intermediate addresses (IPAs) and from IPAs to PAs). Any memory access request issued by the address translation circuit 16 in the page table walk operation may itself be subject to address translation and PAS filtering. Therefore, it should be noted that the request received in step 130 may be a memory access request issued to request a page table entry from memory. Once the relevant page table information is identified, the virtual address is translated to a physical address (possibly in two stages via IPAs). In step 134, the address translation circuit 16 or the PAS filter 20 determines which region is the current region using the method shown in Figure 6.

[0099] If the current area is an insecure area, then in step 136, the output PAS selected for this memory access request is an insecure PAS.

[0100] If the current region is a secure region, in step 138 an output PAS is selected based on the PAS selection information 126 contained in the block / page descriptor PTE that provided the physical address, and the output PAS is selected as either a secure PAS or a non-secure PAS.

[0101] If the current region is a realm region, in step 140 an output PAS is selected based on the PAS selection information 126 contained in the block / page descriptor PTE from which the physical address was derived, in which case the output PAS is selected as either a realm PAS or a non-secure PAS.

[0102] If step 134 determines that the current region is the root region, step 142 selects an output PAS based on the PAS selection information 126 in the root block / page descriptor PTE 114 from which the physical address was derived. In this case, the output PAS is selected as one of the physical address spaces associated with the root, realm, secure, and non-secure regions.

[0103] Figure 9 shows an example of a GPT56 entry for a given granule of a physical address. The GPT entry 150 includes an assigned PAS identifier 152 that identifies the PAS assigned to the granule of the physical address, and includes a further attribute 154 which optionally includes the aforementioned shared attribute information 156 that is visible in one or more other PAS other than the PAS to which the granule of the physical address is assigned. The setting of the shared attribute information 156 may be performed by the root region at the request of code running in the region associated with the assigned PAS. The attribute may also include a pass-through indicator field 158 that indicates whether a GPT check (to determine whether the PAS selected for a memory access request can access the granule of the physical address) should be performed by the PAS filter 20 on the requester side, or by the completer-side filtering circuit on the interconnect's completer device side, as will be further described below. If the passthrough indicator 158 has a first value, a requester-side filtering check may be required by the requester-side PAS filter 20, and if these fail, the memory access request may be blocked and a problem may be signaled. However, if the passthrough indicator 158 has a second value, a requester-side filtering check based on GPT56 may not be required for a memory access request specifying a physical address in the granule of the physical address corresponding to its GPT entry 150, in which case the memory access request may be passed through to the cache 24 or interconnect 8, regardless of whether the selected PAS is one of the permitted PAS that are allowed to access that granule of the physical address, and instead any such arbitrary PAS filtering check is then performed later on the completer side.

[0104] Figure 10 is a flowchart illustrating the requester-side PAS filtering check performed by the PAS filter 20 on the requester side of interconnect 8. In step 170, the PAS filter 20 receives a memory access request associated with a physical address and an output PAS that may be selected as shown in Figure 8 above.

[0105] In step 172, the PAS filter 20 obtains the GPT entry corresponding to the specified PA by issuing a request to memory to fetch the required GPT entry from the granule protection information cache 22, if available, or from a table structure stored in memory. Once the required GPT entry is obtained, in step 174, the PAS filter determines whether the output PAS selected for the memory access request is the same as the allocated PAS 152 defined in the GPT entry obtained in step 172. If so, in step 176, the memory access request (specifying the PA and output PAS) can be passed to the cache 24 or interconnect 8.

[0106] If the output PAS is not the assigned PAS, in step 178 the PAS filter determines whether the output PAS is indicated in the shared attribute information 156 from the obtained GPT entry as an authorized PAS that is allowed to access the granule at the address corresponding to the specified PA. If so, in step 176 again the memory access request is allowed to be passed to the cache 24 or interconnect 8. The shared attribute information can be encoded as a unique bit (or set of bits) in the GPT entry 150, or as an encoding of one or more fields in the GPT entry 150 where other encodings of the same field may indicate other information. If in step 178 the shared attribute determines that an output PAS other than the assigned PAS is allowed to access the PA, then in step 176 the PAS specified in the memory access request passed to the cache 24 or interconnect 8 is the assigned PAS, not the output PAS. The PAS filter 20 transforms the PAS specified by the memory access request to match the allocated PAS, and as a result, downstream memory system components treat it the same as if it were a request issued with the allocated PAS specified.

[0107] If the output PAS is not indicated in shared attribute information 156 as being permitted to access a specific physical address (or, alternatively, in implementations where shared attribute information 156 is not supported, step 178 is skipped), step 180 determines whether the pass-through indicator 158 in the obtained GPT entry for the target physical address identifies that the memory access request can be passed through to the cache 24 or interconnect 8, regardless of the checks performed by the requester-side PAS filter 20. If a pass-through indicator is specified, step 176 allows the memory access request to proceed again (by specifying the output PAS as the PAS associated with the memory access request). Alternatively, if none of the checks in steps 174, 178, and 180 identify that the memory access request is permitted, step 182 blocks the memory access request. Thus, the memory access request is not passed to the cache 24 or interconnect 8, a fault is signaled, and exception handling to address the fault may be triggered.

[0108] Steps 174, 178, and 180 are shown sequentially in Figure 10, but these steps can also be performed in parallel or in a different order, if desired. Furthermore, steps 178 and 180 are not mandatory, and some implementations may not support the use of shared attribute information 156 and / or pass-through indicators 158.

[0109] Figure 11 summarizes the operation of the address translation circuit 16 and the PAS filter. The PAS filtering 20 can be considered an additional Stage 3 check performed after the address translation of Stage 1 (and optionally Stage 2) performed by the address translation circuit. It should also be noted that the EL3 translation is based on page table entries that provide selection information based on a 2-bit address (labeled NS and NSE in the embodiment of Figure 11), while the single-bit selection information "NS" is used to select a PAS of other states. The security state shown in Figure 11 as input to the granule protection check refers to the domain ID that identifies the current region of processing element 4.

[0110] Figure 12 shows an example of a network of devices to which this technique may be applied. In particular, Figure 12 shows several processor blocks (processor cores) 206, an encryption engine 208, and several devices 200 connected to a memory 210 via a root port 202 and an interconnect 204. The interconnect 204 is an example of an interconnect circuit that connects a device (such as one of the devices 200 shown in the figure) to one or more processing elements (such as processing circuits 212A, 212B, 212C shown within processor blocks 206A, 206B, 206C shown in the figure). For example, the interconnect 204 may have the same or a similar configuration as the interconnect 8 shown in Figure 1.

[0111] The interconnect and its connected components (such as the root port 202 and processor block 206) can exchange messages with each other using the interconnect communication protocol. However, devices that operate according to alternative communication protocols and can therefore be considered external devices to the subsystem including the interconnect can also connect to the interconnect via the root port 202, for example, as shown in Figure 12. For example, devices 200A and 200B shown in Figure 12 can communicate with the root port 202 using a packet network and can use the packet protocol of that packet network, such as the PCIe (Peripheral Component Interconnect Express) protocol. Thus, the root port acts as a bridge between the protocol used by the external devices 200A and 200B and the protocol used by the interconnect and its connected components.

[0112] Access to memory 210 can be controlled by a memory controller (not shown in Figure 12), such as the memory controller MC shown in Figure 3. The encryption engine 208 is provided to encrypt the data before it is stored in memory 210, or to decrypt the data when it is retrieved from memory 210.

[0113] Each of the processor blocks 206 may be identical to the processing circuit 10 shown in Figure 1, and includes a processing circuit 212 configured to execute program instructions, including (for example) load / store instructions, for accessing data stored in memory 210.

[0114] Each set of processing circuits 212 has access to multiple caches, each cache storing several copies of the data stored in memory 210. In some examples, the cache shown in Figure 12 may be equivalent to the cache 24 between the PAS filter 20 and the interconnect 8 in Figure 1.

[0115] In particular, each processor block 206 includes a level 1 data cache 214 for storing copies of data stored in memory 210 and a level 1 instruction cache 216 for storing copies of instructions stored in memory 210. Each processor block 206 may also have access to an integrated level 2 cache 218 for storing copies of both data and instructions. Each integrated level 2 cache 218 may be accessible to only one processor block 206, as in the example of processor block 206C which incorporates its own level 2 cache 218C, or it may be shared among multiple processor blocks 206, as in the example of processor blocks 206A and 206B which are in the same cluster 220 of processor blocks and are thought to share a level 2 cache 218A.

[0116] Therefore, the memory system of the network shown in Figure 12 may have a hierarchical structure with multiple levels of cache provided between each of the sets of memory 210 and processing circuits 212. Caches 214, 216, and 218 can store copies of data or instructions stored in memory 210, as described above. Data or instructions stored in the caches can be accessed by the processing circuits 212 with reduced latency. This reduced latency is partly a result of the caches being significantly smaller than the main memory 210, and consequently, looking up an address in the cache can be significantly faster than looking up an address in memory. In addition, the caches are closer to the processing circuits 212 than to memory 210, and in particular, memory 210 is isolated from the processing circuits 212 by other components such as the interconnect 204, while caches 214, 216, and 218 are not isolated, which also reduces the latency associated with accessing data held in the caches. Therefore, allowing some data (especially data frequently accessed by processing circuits) to be stored in a local cache allows for improved performance of each processor block 206 by reducing the latency associated with data access.

[0117] As mentioned above, the system shown in Figure 12 has multiple levels of cache. This is not mandatory, and providing a single cache to the processing element would also provide some performance benefits, but it can be particularly advantageous as it allows significantly more data to be stored closer to the processing circuit without having to increase the size of the Level 1 cache 214. Typically, the Level 1 cache 214 stores data that has been most recently accessed by the processing circuit 212 (and therefore is very likely to be accessed again), and each subsequent level of the cache stores data that has not been accessed more recently than the data stored in the previous cache level.

[0118] Caches can be inclusive, meaning that data stored in one cache is also stored in each subsequent cache level. In practice, this means that each cache above level 1 stores all the data (including instructions) stored in the previous cache level, plus some additional data. This means that when a data item is evicted from one cache (for example, due to a cache replacement policy such as an LRU (least recently used) policy), it is likely that the data item will remain in the caches of subsequent levels. For example, if data is evicted from level 1 data cache 214, that data will remain in level 2 cache 218 for at least some time after being evicted from level 1 data cache 214. This means that if the processing circuit needs to access that data again after it has been evicted from level 1 data cache 214 (but before it is evicted from level 2 cache), it can still access the data without having to retrieve it from memory, although the latency will be greater than if the data had been in level 1 data cache 214.

[0119] Alternatively, the cache may be exclusive, meaning that a given data item is stored only at the cache level at a given time.

[0120] The choice between an inclusive or exclusive cache is an implementation detail and can be made based on the system's needs. Furthermore, not all caches in a system need to be inclusive or exclusive. In fact, a given data item in an inclusive cache can be treated as exclusive so that it is stored in only one cache.

[0121] Figure 12 shows only two levels of cache between memory 210 and processing circuit 212, but it will be understood that any number of cache levels may be provided. Furthermore, the cache levels in Figure 12 are numbered such that the smallest number corresponds to the cache closest to the processing circuit (i.e., level 1 is closest to processing circuit 212, and level 2 is further from processing circuit 212 than level 1), but it will be understood that this is merely a label and any other option of labeling can be used without implying different functions.

[0122] The processes executed by the processing circuits 212 of each processor block 206 may run within one of the aforementioned regions (worlds). For example, processes may run within the secure region 84, the less secure region 86, the realm region 88, or the root region 82, and access to memory by these processes can be controlled according to the techniques described in detail above. For example, a separate physical address space (PAS) may be provided for each of these regions.

[0123] Furthermore, processes executed by processing circuits may run in different trusted execution environments, and processes running in one trusted execution environment are isolated from processes running in other trusted execution environments. For example, a given processing element may operate entirely within a single trusted execution environment, such that any processes running on that processing element run within the trusted execution environment associated with that processing element. Processing elements may operate in different trusted execution environments at different times. Alternatively, different processes running on the processing circuit 212 of a given processing element may run in different trusted execution environments. These trusted execution environments may, for example, correspond to realms provided within the realm domain, as described above. However, it will be understood that it may also be possible to provide trusted execution environments in other domains, such as the secure domain or the root domain. Furthermore, it is also possible to provide trusted execution environments in systems that do not have separate execution domains.

[0124] As described above, the processor block 206 is connected to the interconnect 204, which allows the processor block to communicate with memory 210 via the cryptographic engine 208 and with device 200 via the root port. In this example, the interconnect 204 includes at least one home node 222 configured to control access to a portion of memory 210 by any of the devices connected to the interconnect (e.g., the processor block 206 or device 200).

[0125] Each of the devices 200 may be, for example, the requester device 4 as shown in Figure 1. Alternatively, each of the devices 200 may be any other device that can send a transaction to the interconnect 204 and request access to data stored in memory 210. Each of the devices may operate within a given trusted execution environment and therefore may be permitted to access data associated with that trusted execution environment. For example, a particular process running on one of the devices may be considered to be running within a particular trusted execution environment. Alternatively, a particular device itself may be considered to be within a given trusted execution environment, and as a result, any process running on that device is also considered to be within that trusted execution environment. According to the techniques described herein, a transaction issued by one of the devices 200 may include a trusted execution environment identifier (also referred to herein as a realm identifier or realm ID) that identifies the trusted execution environment to which the process issuing the transaction belongs.

[0126] Device 200 is connected to interconnect 202 via root port 202. In particular, device 200 and root port 202 are arranged in a hierarchical structure, where the root port 202 of a first-level device is directly connected to interconnect 204, and device 200 is connected to the interconnect via its root port. Although only a single root port is shown in Figure 12, it will be understood that multiple root ports may be provided. Furthermore, although the device network in Figure 12, which includes device 200 and root port 202, shows only two levels of devices, there may be further levels of devices between device 200 and root port 202, and each device at a given level is connected to one of the devices at the previous level in a tree structure. In other examples, device 200 may be directly connected to the interconnect without an intervening root port.

[0127] One type of transaction that may be issued by device 200 is a stashing transaction. A stashing transaction involves a request to access data in a storage structure accessible to one of the processing elements, rather than accessing data in memory 210. In the example in Figure 12, the storage structure comprises one of the caches 214, 216, and 218. However, in a system without a cache, it will be understood that this could refer to any storage structure other than memory 210, for example, any storage structure on the same side of at least one of the processor blocks 206 and interconnect 204.

[0128] There can be various ways in which a given stashing transaction indicates the cache to which it is routed. In some examples, a steering tag is used to indicate the cache to which the transaction should be routed, while in others, this can be determined based on a trusted execution identifier indicated by the stashing transaction.

[0129] This allows transactions to be steered to the cache, resulting in stashing transactions being able to write data directly to one of the caches instead of memory, thus improving system performance. In particular, latency associated with subsequent access to that data by one of the processing elements can be reduced, for example, because the data already resides in the cache, and latency associated with retrieving data from memory can be avoided.

[0130] However, especially when processor blocks 206 and their caches are operating within a trusted execution environment, allowing a device-issued transaction to directly write data to a cache accessible to processor blocks 206 might seem counterintuitive. A person skilled in the art would anticipate that allowing an external device to directly access a cache within a given trusted execution environment could pose a security risk.

[0131] However, the inventors of this technique realized that this security risk could be mitigated by providing a secure stashing decision circuit 224 to receive stashing transactions from a device (or multiple devices 200) and redirect authorized stashing transactions to a given storage structure (e.g., one of caches 214, 216, and 218) accessible to at least one of one or more processor blocks 206. Specifically, the secure stashing decision circuit 224 is configured to, in response to receiving a given stashing transaction, determine whether the given stashing transaction contains a trusted execution environment identifier associated with a given trusted execution environment, and treat the given stashing transaction as an authorized stashing transaction when redirection requirements dependent on the trusted execution environment identifier are met. This provides improved security and, as a result, can provide the performance benefits associated with stashing transactions without compromising the security of the system.

[0132] As shown in Figure 12, the secure stashing decision circuit 224 can be provided within the root port 202. However, the secure stashing decision circuit 224 can also be provided in a different location, such as within the home node 222 in the interconnect 204.

[0133] One way the secure stashing decision circuit 224 can determine whether a stashing transaction is an authorized stashing transaction is based on either or both of the trusted execution environment identifier (realm ID) and the steering tag associated with the stashing transaction (or, in practice, based on the absence of either of these identifiers).

[0134] Figure 13 shows an example of a stashing transaction 300, including a steering tag 302 and a realm ID 304. As described above, the realm ID 304 indicates the trusted execution environment in which the device issuing the transaction is running, and the steering tag 302 indicates a specific storage structure (e.g., a cache) to which the transaction is redirected (if permitted by the secure stashing decision circuit). The stashing transaction shown in Figure 13 also includes a payload 306, which is the data to be written to the identified storage structure and its associated memory address. Although the stashing transaction is intended to be redirected to a cache rather than memory, it can still provide a memory address so that the appropriate entry in a given cache can be identified.

[0135] Figure 14 shows an example of the secure stashing decision circuit 224 shown in Figure 12. As described above, the secure stashing decision circuit 224 is configured to receive stashing requests from at least one of the devices 200, determine whether they are authorized stashing transactions, and redirect authorized transactions to one of the system's caches.

[0136] In the example shown in Figure 14, the secure stashing decision circuit 224 includes a target cache table 400 and is configured to determine whether an incoming stashing transaction is an authorized stashing transaction by looking up the target cache table 400.

[0137] Figure 15 shows an example of a target cache table 400. In this particular example, each entry in the target cache table 400 specifies a steering tag, the target cache associated with that steering tag, and a realm ID that identifies the trusted execution environment in which the cache operates. This table can be referenced using the steering tag to determine the associated target cache and its realm ID, or using the realm ID to determine which caches are in that realm. The values ​​looked up in the table may depend on the format of a given stashing transaction received by the secure stashing decision circuit. For example, upon receiving a stashing transaction, the secure stashing decision circuit can determine whether the transaction contains a steering tag and a realm ID.

[0138] If the received stashing transaction contains a valid steering tag and a valid realm ID, the secure stashing decision circuit can use either the steering tag or the realm ID to refer to the target cache table 400. In one particular example, the secure stashing decision circuit looks up the steering tag in the target cache table 400 and finds the target cache associated with the steering tag and its associated realm ID. If the realm ID of the target cache matches the realm ID of the received stashing transaction, the secure stashing decision circuit redirects the received stashing transaction to the identified target cache.

[0139] If an incoming stashing transaction contains a valid steering tag but does not contain a realm ID, the secure stashing decision circuit may look up the steering tag in the target cache table 400. If the realm ID associated with that steering tag indicates that the associated target cache is in the realm, the stashing transaction is rejected by the secure stashing decision circuit. Otherwise, the secure stashing decision circuit redirects the stashing transaction to the identified target cache.

[0140] If an incoming stashing transaction contains a valid realm ID but does not contain a steering tag, the secure stashing decision circuit can look up the realm ID in the target cache table 400 and redirect the stashing transaction to the target cache associated with that realm ID.

[0141] The target cache table 400 shown in Figure 15 is merely one example of how the target cache table 400 may be configured, and it should be understood that other examples are possible. For example, a separate table may be provided for each realm, and the table to be looked up may be selected based on the realm ID. Alternatively, a separate table may be provided for each steering tag.

[0142] Figure 15 also shows an example of a realm key ID table 500 that may be optionally provided within the secure stashing decision circuit. In some examples of this technique, a realm ID can be identified using a realm ID specified by a stashing transaction, and then a realm encryption key can be identified using the realm key ID to encrypt data associated with a particular realm before it is stored in memory. Providing a realm key ID table 500 within the secure stashing decision circuit allows the secure stashing decision circuit to identify a realm key ID for a given stashing transaction based on the realm ID. The realm key ID can then be used in several different ways. For example, the realm key ID may be sent to the target cache along with the stashing transaction, and in at least some situations, it may be written to the target cache along with the data identified by the stashing transaction.

[0143] Optionally, the secure stashing decision circuit may also be configured to control cache containment with respect to a given authorized stashing transaction. As described above, the processing system may have multiple levels of caches in a hierarchical structure, and at least some of the caches may be “container,” meaning that a copy of data in one cache is also held in lower-level caches in the hierarchy (e.g., data in a level 1 cache is also held in a level 2 cache). However, if a particular data item is intended to be accessible only to a specific process, for example, if the data item is associated with a particular realm, it may be undesirable for this data item to be stored in multiple caches. In particular, these can be security risks associated with storing sensitive data (e.g., data associated with a realm) in a cache shared among multiple processing elements, such as several level 2 caches. Therefore, improved security can be provided by enabling the secure stashing decision circuit to control cache containment based on a realm ID. For example, the secure stashing decision circuit may be configured to prevent a copy of data associated with a given stashing transaction from being stored in two or more caches when a realm ID exists or when the realm ID has a predetermined value.

[0144] However, it will be understood that the ability of the secure stashing decision circuit to identify realm key IDs, or to control the cache inclusion of permitted stashing transactions, is an optional feature that can be provided or omitted without affecting the ability of the secure stashing decision circuit to control which stashing transactions to redirect and which to reject.

[0145] While several options for how stashing can be controlled by the secure stashing decision circuit based on steering tags and realm IDs have been described above, Figure 16 provides an overview of how the secure stashing decision circuit can respond to a given combination of steering tags and / or realm IDs. The table in Figure 16 does not show controlling cache containment in the manner described above or identifying realm key IDs, but it will be understood that either (or both) of these optional features may be provided in addition to the responses shown in the table. Figure 16 also shows how the secure stashing decision circuit can handle stashing transactions when the target cache and / or memory address identified in the request is within the realm, and it will be understood that the secure stashing decision circuit can handle other stashing transactions in various ways.

[0146] The secure stashing decision circuit of this technique is configured to, in response to receiving a stashing transaction, determine whether the stashing transaction contains a realm ID (trusted execution environment identifier) ​​and, at least in this example, whether the stashing transaction contains a steering tag. Then, based on the realm ID and the steering tag (or its absence), the secure stashing decision circuit can determine how to handle the stashing transaction.

[0147] Several possible actions by the secure stashing decision circuit are shown in the table in Figure 16. However, these are merely examples, and it should be understood that the actual implementation of this technique may differ. For example, in some situations where a stashing transaction is treated as an permitted transaction (e.g., when a steering tag does not exist but a realm ID exists and is valid), the stashing transaction may instead be rejected in some implementations. It should also be understood that the examples shown in this table are not considered applicable when the cache targeted by the received stashing transaction is not within the realm (e.g., when the cache is in a less secure area).

[0148] According to the table in Figure 16, a stashing transaction is rejected if a realm ID does not exist, or if a realm ID exists but is invalid, regardless of whether a steering tag exists. In this situation, the absence of a realm ID means that it is not easy to determine whether the process or device sending the transaction is trusted to access data in any of the provided realms. Therefore, the transaction is rejected to protect data associated with any of the realms from access by potentially untrusted or malicious actors.

[0149] When a realm ID exists and is valid, it can be assumed that the process or device issuing the stashing transaction is trusted to access any cache within the realm identified by the realm ID. Therefore, the action taken depends on the steering tag.

[0150] In particular, if a realm ID exists and is valid, but a steering tag does not exist, the transaction is redirected to a cache in the realm associated with the transaction's realm ID (at least in this example). In this situation, it may not be known which cache was intended to be targeted, but it may be more efficient for the secure stashing decision circuit to assume that the target cache is a cache in the identified realm rather than rejecting the transaction so that it needs to be reissued. This allows the data to be stored in a cache accessible to the processing element running the process within that realm, which provides the performance benefits described in detail above (e.g., reduced latency associated with subsequent access to the data). If it is later found that the assumption about which cache is the target cache was incorrect, the security of the system is not compromised, as the valid realm ID indicated that the device / process issuing the transaction has permission to access the data within that realm.

[0151] On the other hand, if a realm ID exists and is valid, but a steering tag exists but is invalid, the transaction is rejected. The presence of a steering tag indicates that the process / device issuing the transaction intended a specific cache to be the target cache, but this response may be appropriate because the secure stashing decision circuit cannot determine which cache is the target cache. However, in other examples, the secure stashing decision circuit may instead choose to treat the transaction as if the steering tag did not exist and redirect it to a cache in the realm associated with the realm ID.

[0152] Finally, if both the realm ID and steering tag exist and are valid, the secure stashing decision circuit is configured to check whether the target cache identified by the steering tag is in the same realm as the realm identified by the realm ID. If both realms are the same, the transaction is redirected. Otherwise, the transaction is rejected. In this way, the performance benefits of enabling cache stashing can be achieved without compromising the security of the system. In particular, any transaction attempting to access a cache in a realm to which access is not permitted will be rejected.

[0153] If access is denied, the secure stashing decision circuit can assert an error signal, which may log the error to a set of registers accessible to the secure stashing decision circuit. For example, these registers may be located in the root port or the interconnect.

[0154] Next, referring to Figure 17, this figure is a flowchart illustrating an example of a method performed by the secure stashing decision circuit according to this technique. The method shown in Figure 17 includes step 702, which waits for a stashing transaction to be received. Once the stashing transaction is received by the secure stashing decision circuit, the method proceeds to step 704, which determines whether the stashing transaction contains a realm ID. If a realm ID does not exist, the method includes step 706, which checks whether the transaction contains a valid steering tag. If a valid steering tag does not exist, the transaction is rejected because the secure stashing decision circuit cannot identify a cache to which the transaction should be redirected (708). On the other hand, if a valid steering tag exists, the secure stashing decision circuit looks up the target cache associated with the steering tag and determines whether the target cache is in a realm (710). If the target cache is in a realm, the transaction is rejected because the transaction does not contain a realm ID corresponding to the realm of the target cache (708). On the other hand, if the target cache is not in a realm, the transaction is redirected to the cache identified by the steering tag (712).

[0155] Returning to step 704, if it is determined that a realm ID exists, the method proceeds to step 714, which determines whether the realm ID is valid. If the realm ID is invalid, the transaction is rejected (708). On the other hand, if the realm ID is valid, the method proceeds to step 716, which determines whether the transaction includes a steering tag.

[0156] If no steering tag exists, the transaction is redirected to a cache within the realm identified by the realm ID (718). If a steering tag exists, the method proceeds to step 720, which determines whether the steering tag is valid.

[0157] If the steering tag is invalid, the transaction is rejected (708). On the other hand, if a steering tag exists, the method proceeds to step 722, which determines whether the cache identified by the steering tag is in the realm identified by the realm ID. If the cache is in the same realm as the realm identified by the realm ID, in step 712, the transaction is redirected to the identified cache. On the other hand, if the cache is not in the realm identified by the realm ID, the transaction is rejected in step 708.

[0158] Although not shown in Figure 17, it will be understood that several additional steps can be provided as an option. For example, steps 718 and 712 may also include controlling cache inclusion based on the realm ID. Additionally, an additional step may be provided between steps 716 and 718, and / or between steps 722 and 712, to look up the realm key ID for the realm identified by the transaction.

[0159] This method allows stashing transactions issued by one or more devices to be redirected to a system cache (or other storage structure on the same side of the interconnect as one or more processing elements), provided that specific redirection requirements dependent on the realm ID are met. This provides significant performance benefits by enabling subsequent access to data written in response to authorized stashing transactions, where the data is accessed from the cache rather than retrieved from memory, thereby reducing the latency associated with access. In addition, system security can be maintained by redirecting only stashing transactions for which the redirection requirements are met. In particular, by making the redirection requirements dependent on the realm ID, isolation of each realm within the realm region can be maintained (for example). Therefore, this technique provides improved performance without sacrificing security.

[0160] Figure 18 schematically shows an example of a system 800 in which this technique may be implemented. The system 800 comprises a plurality of sockets 802, each holding at least one processing element 803 (which may comprise the processing circuit 212 shown in Figure 12). In this example, each socket includes a system-on-a-chip (SoC). Each processing element 803 has access to at least one cache 214 (although not shown in this figure, it will be understood that there may be other caches at further levels of the memory hierarchy, as described in detail above). Socket A 802A also holds a shared device 200 coupled to the processing element 803 by an interconnect 204. In particular, a root port 202 is provided to couple the device 200 to the interconnect 204. Memory 210 accessible to the processing element 803 and device 200 is also provided via the interconnect 204. An encryption engine 208 is also provided to encrypt the data before it is stored in memory 210.

[0161] The shared device 200 runs a set of processes that define virtual devices, which are assumed to be operating within a specific realm. The shared device 200 is configured to issue transactions, including stashing transactions, to the interconnect 204, which are generated by the virtual devices. As described above, it may be particularly advantageous to allow the stashing transactions issued by device 200 to be redirected to one of the system caches 214 so that the data contained in the transactions can be accessed later by one of the processing elements 803 with reduced latency.

[0162] In this example, some of the processing elements 803A and 803B are running processes within a specific realm (the same realm as in the case of virtual devices), and therefore their associated caches 214A and 214B are considered private caches within that realm. On the other hand, one of the processing elements 803C is under the control of the attacker, and therefore, at least the cache 214C associated with that processing element is accessible to the attacker. This means that any data stored in this particular cache 214C is visible to the attacker and therefore insecure.

[0163] Furthermore, the link 806 between socket A 802A and socket B 802B is insecure (or, more specifically, less secure than preferred security standards), and therefore, a probe 804 under the attacker's control can intercept signals transmitted over the insecure link 806. Consequently, data accessed within the cache 214D on socket B is also accessible to the attacker.

[0164] Therefore, redirecting stashing transactions issued by shared device 200 to either cache 214A or 214B within the realm is permissible (because the virtual devices running on shared device 200 are operating within the same realm), but redirecting any of these stashing transactions to either cache 214C or 214D under the control of an attacker is inappropriate, as it would give the attacker access to potentially sensitive data associated with the realm.

[0165] In practice, it is usually not clear whether one or more processing elements 803C are under the attacker's control, or whether a probe under the attacker's control is intercepting signals via an insecure link 806. Therefore, preventing an attacker from accessing sensitive data is not as easy as preventing the attacker from writing sensitive data to a cache under their control.

[0166] Therefore, the system in Figure 18 allows a sensitive process (e.g., a process that prefers a secure environment) to run within an isolated realm, and a process running within one realm is isolated from processes running within other realms, and from any processes running outside of either realm. In the example in Figure 18, threads A and B run within a realm and are therefore isolated from any other processes outside the realm. The two caches 214A and 214B are also considered to be within the same realm, and only processes within that realm are allowed to access the caches. Therefore, processes outside the realm (e.g., any process running on processing element 803C controlled by an attacker) are prevented from accessing any sensitive data associated with thread A or thread B. This maintains the security of these threads even if some of the less secure processing components of system 800 are compromised by an attacker.

[0167] Within such a realm-based system, it is also possible to provide performance benefits associated with stashing transactions. In particular, as mentioned above, stashing transactions can be tagged with a realm ID that indicates the realm in which device 200 is running. A secure stashing decision circuit 224 is then provided to control whether the stashing transaction is redirected to one of the caches 214. The secure stashing decision circuit 224 can be provided within the root port 224 as shown in Figure 12, or within the interconnect circuit 204. For example, as shown in Figure 18, the secure stashing decision circuit can be located in the home node 222 of the interconnect 204. Although the secure stashing decision circuit 224 is shown in both the root node 202 and the home node 222, this is purely for illustrative purposes, and it will be understood that in practice, the secure stashing decision circuit may be located in either the root port 224 or the home node 222, but does not necessarily have to be in both locations.

[0168] The secure stashing decision circuit 224 is configured to determine whether a stashing transaction issued by device 200 is an authorized transaction by considering redirection requirements that depend on the realm ID specified by the stashing transaction. The authorized transaction may then be directed to one of the caches 214A, 214B within the realm.

[0169] Figure 18 also shows an example of a secure stashing decision circuit 224 in more detail. In this example, the secure stashing decision circuit 224 includes an effectiveness and enforcement circuit 808 configured to receive a realm ID and steering tag of a given stashing transaction as input, and to determine the identity of the target cache and, optionally, the realm key ID of the realm, by referring to the target cache table for authorized stashing transactions.

[0170] Therefore, the system 800 in Figure 18 provides a specific example of how this technique can be implemented to provide the aforementioned benefits of improved performance without compromising security.

[0171] In this application, the term "configured to..." is used to mean that an element of the device has a configuration capable of performing a defined operation. In this context, "configuration" means the arrangement or interconnection of hardware or software. For example, the device may have dedicated hardware to provide the defined operation, or a processor or other processing device may be programmed to perform the function. "Configured to..." does not mean that any modifications must be made to the device element to provide the defined operation.

[0172] While exemplary embodiments of the present invention are described in detail herein with reference to the accompanying drawings, it should be understood that the present invention is not limited to these precise embodiments, and various changes and modifications can be made to these embodiments by those skilled in the art without departing from the scope and spirit of the invention as defined by the appended claims.

Claims

1. An interconnect circuit configured to connect a device to one or more processing elements, wherein at least one of the one or more processing elements is configured to operate in a reliable execution environment, A secure stashing decision circuit configured to receive stashing transactions from the device and redirect authorized stashing transactions to a given storage structure accessible to at least one of the one or more processing elements, Equipped with, The device is configured such that, in response to receiving a given stashing transaction, the secure stashing decision circuit determines whether the given stashing transaction contains a trusted execution environment identifier associated with a given trusted execution environment, and treats the given stashing transaction as an authorized stashing transaction when redirection requirements, including the fact that the given stashing transaction contains the trusted execution environment identifier, are met.

2. The apparatus according to claim 1, wherein each of the stashing transactions includes a request to access data associated with a location in memory.

3. Each of the stashing transactions includes a write request to write data to a location associated with a location in memory, The apparatus according to claim 1 or 2, wherein the secure stashing decision circuit is configured to write the data to the given storage structure when the redirection requirement is met.

4. The apparatus according to any one of claims 1 to 3, wherein whether the redirection requirement is met depends on the value of the trusted execution environment identifier.

5. The apparatus according to any one of claims 1 to 4, wherein the secure stashing decision circuit is configured to reject the given stashing transaction when the given storage structure is in a trusted execution environment and the trusted execution environment identifier does not exist or is invalid.

6. The apparatus according to claim 5, wherein the secure stashing decision circuit is configured to assert an error signal in response to rejecting a given stashing transaction.

7. The apparatus according to any one of claims 1 to 6, wherein the given storage structure is selected according to the permitted stashing transaction.

8. The apparatus according to any one of claims 1 to 7, wherein the secure stashing decision circuit is configured to determine whether the given stashing transaction includes a steering tag indicating the given storage structure, and when the secure stashing decision circuit determines that the given stashing transaction includes the steering tag, whether the redirection requirement is met further depends on the steering tag.

9. The apparatus according to claim 8, wherein the secure stashing decision circuit is configured to reject the given stashing transaction when the given storage structure is in a first trusted execution environment and the trusted execution environment identifier does not exist or is invalid; when the given storage structure is in a first trusted execution environment and the trusted execution environment identifier is associated with a different trusted execution environment; or when the steering tag is invalid.

10. The apparatus according to claim 8 or 9, wherein the given storage structure is selected according to the value of the trusted execution environment identifier and / or the value of the steering tag.

11. The apparatus according to claim 10, wherein the secure stashing determination circuit is configured to select a given storage structure according to the value of the steering tag, except when the steering tag is not present.

12. The apparatus according to any one of claims 1 to 11, wherein the given stashing transaction includes a request to access data located at a given location in memory, and the secure stashing decision circuit is configured to identify an encryption key identifier indicating an encryption key for encrypting the data stored at the given location in memory, based on the trusted execution environment identifier.

13. Each of the stashing transactions includes a write request to write data to a location associated with a location in memory, The apparatus according to claim 12, wherein the secure stashing decision circuit is configured to write the encryption key identifier and the data to the given storage structure.

14. The apparatus according to any one of claims 1 to 13, wherein the given storage structure comprises a cache.

15. The apparatus according to claim 14, wherein the secure stashing decision circuit is configured to control, based on the trusted execution environment identifier, whether at least one given cache line of the cache is permitted to be held in at least one other cache as well.

16. The apparatus according to any one of claims 1 to 15, comprising a root port provided at a first level of a device in a hierarchical structure of multiple devices, wherein the device is provided in the hierarchical structure of the multiple devices and is coupled to the interconnect via the root port.

17. The apparatus according to claim 16, wherein the device comprises a requester device in a packet network, the requester device is configured to transmit the stashing transaction to the root port in accordance with the packet protocol of the packet network for forward propagation to the interconnect.

18. The apparatus according to claim 17, wherein the packet protocol is the PCIe (Peripheral Component Interconnect Express) protocol.

19. The apparatus according to any one of claims 16 to 18, wherein the root port is equipped with the secure stashing determination circuit.

20. The apparatus according to any one of claims 1 to 18, wherein the interconnect includes a home node circuit that controls access to a portion of the memory, and the home node circuit includes the secure stashing decision circuit.

21. A method for stashing a transaction, wherein the method is A step of receiving a stashing transaction from a device coupled to one or more processing elements via an interconnect circuit, wherein at least one of the one or more processing elements is configured to operate in a trusted execution environment. The steps include redirecting an authorized stashing transaction to a given storage structure accessible to at least one of the one or more processing elements, Steps include: In response to receiving a given stashing transaction, determining whether the given stashing transaction contains a trusted execution environment identifier associated with a given trusted execution environment, and treating the given stashing transaction as an authorized stashing transaction when a redirection requirement is met, including that the given stashing transaction contains the trusted execution environment identifier; A method that includes this.

Images