Conversion table address storage circuit

Abstract

The apparatus includes an address translation circuit (16) that translates a target virtual address (VA) specified by a memory access request into a target physical address, first / second translation table address storage circuits (132, 142, 134, 144) that store first / second translation table addresses, respectively, and a protection area definition data storage circuit (130) that stores area definition data that specifies at least one protection area of ​​a virtual address space. In response to the memory access request, when the target VA is within the protection area(s), the address translation circuit (16) translates the target VA based on address translation data from a first translation table structure identified by the first translation table address. When the target VA is outside the protection area(s), the target VA is translated based on address translation data from a second translation table structure identified by the second translation table address.

Description

[Technical Field]

[0001] The present technique relates to the field of data processing, and more particularly to address translation.

[0002] The data processing apparatus may have an address translation circuit that translates a target virtual address specified by a memory access request into a target physical address. The address translation may be performed in one stage directly from the virtual address to the physical address, or as a two-stage address translation based on a stage 1 translation table structure used to map the virtual address to an intermediate address and a stage 2 translation table structure used to map the intermediate address to a physical address. The translation table address storage circuit may store a translation table address that identifies the translation table structure to use for the address mapping.

[0003] At least some examples provide an apparatus comprising: an address translation circuit that translates a target virtual address specified by a memory access request into a target physical address; a first translation table address storage circuit that stores first translation table addresses; a second translation table address storage circuit that stores second translation table addresses; and a protection area definition data storage circuit that stores area definition data specifying at least one protection area of ​​a virtual address space, wherein, in response to the memory access request, the address translation circuit is configured to translate the target virtual address based on address translation data from a first translation table structure identified by the first translation table address stored in the first translation table address storage circuit when the target virtual address is within the at least one protection area, and to translate the target virtual address based on address translation data from a second translation table structure identified by the second translation table address stored in the second translation table address storage circuit when the target virtual address is outside the at least one protection area.

[0004] At least some examples provide a method, including: in response to a memory access request specifying a target virtual address, translating the target virtual address based on address translation data from a first translation table structure identified by a first translation table address stored in a first translation table address storage circuit when the target virtual address is within at least one protection region specified by region definition data stored in a protection region definition data storage circuit; and translating the target virtual address based on address translation data from a second translation table structure identified by a second translation table address stored in a second translation table address storage circuit when the target virtual address is outside the at least one protection region.

[0005] At least some embodiments provide a computer program for controlling a host data processing apparatus that provides an instruction execution environment for executing target code, the computer program comprising: address translation program logic that translates a target virtual address specified by a memory access request into a target physical address; and state emulation logic that maintains state information emulating an architectural state of a target instruction set architecture associated with the target code, the state information specifying a first translation table address, a second translation table address, and region definition data that specifies at least one protection region of a simulated virtual address space; wherein, in response to a memory access instruction of the target code, the address translation program logic is configured to translate the target virtual address based on address translation data from a first translation table structure identified by the first translation table address when the target virtual address is within the at least one protection region, and to translate the target virtual address based on address translation data from a second translation table structure identified by the second translation table address when the target virtual address is outside the at least one protection region.

[0006] The computer-readable storage medium can store the above-mentioned computer program. The storage medium may be a non-transitory storage medium. [Brief explanation of the drawings]

[0007] Further aspects, features, and advantages of the present technology will become apparent from the following description of examples, read in conjunction with the accompanying drawings. [Figure 1] 1 illustrates a schematic example of a data processing device; [Figure 2] 1 illustrates some areas in which the processing circuitry can operate. [Figure 3] 1 illustrates an example processing system that supports granular protection lookup. [Figure 4] 1 illustrates schematically the aliasing of several physical address spaces onto a system physical address space that identifies locations within a memory system. [Figure 5] An example is given of partitioning the effective hardware physical address space so that different architectural physical address spaces have access to respective portions of the system physical address space. [Figure 6] FIG. 2 is a diagram illustrating an address conversion circuit. [Figure 7] FIG. 10 is a diagram illustrating an example of a multi-level conversion table structure. [Figure 8] FIG. 1 illustrates a method for controlling address translation in a realm domain. [Figure 9] FIG. 1 illustrates a method for controlling address translation in one of a root domain, a secure domain, and a less secure domain. [Figure 10] FIG. 10 illustrates a selection between first and second translation table addresses depending on whether the virtual address to be translated is within a protected area of ​​the virtual address space. [Figure 11] FIG. 10 illustrates exception handling in a realm domain. [Figure 12] FIG. 10 is a diagram illustrating processing of a TLB invalidation command issued from a less secure domain. [Figure 13] FIG. 1 illustrates several stages of address translation and granule protection information filtering. [Figure 14] Examples of simulators that may be used are given below. DETAILED DESCRIPTION OF THE INVENTION

[0008] The apparatus includes an address translation circuit that translates a target virtual address specified by a memory access request into a target physical address, first and second translation table address storage circuits (e.g., first and second translation table address registers) that store first and second translation table addresses, respectively, and a protection region definition data storage circuit that stores region definition data that specifies at least one protection region of a virtual address space. In response to the memory access request, when the target virtual address is within the at least one protection region, the target virtual address is translated based on address translation data from a first translation table structure identified by a first translation table address stored in the first translation table address storage circuit. When the target virtual address is outside the at least one protection region, the target virtual address is translated based on address translation data from a second translation table structure identified by a second translation table address stored in the second translation table address storage circuit.

[0009] The inventors recognized that it may be useful to provide first and second translation table address storage devices, where the address translation circuit selects which one to use to obtain the address of the translation table structure based on a comparison between the target virtual address and the region definition data stored in the protection region definition data storage circuit. This means that different translation table structures are referenced for addresses within and outside the protection region, respectively. The definition of the protection region is variable based on the region definition data stored in the protection region definition data storage circuit. This may be useful, for example, to support more efficient development of securely isolated computing environments associated with sandboxed components within a larger application. For such components, it may be desirable to provide code executing within the protection region with different translation table data than code of the same application located outside the protection region; for example, a translation table structure referenced for code within the protection region may allow access to some areas of the address space that are inaccessible to code outside the protection region. However, the sandboxed component may also need to reference data outside the protection region that may be shared with less secure code stored at addresses outside the protection region.

[0010] One approach might be to define an address table structure covering the entire virtual address space exclusively for use by sandboxed components associated with addresses within the protected region, but this approach might incur additional overhead in keeping translation tables associated with the protected region and other regions of the virtual address space synchronized for portions of the address space shared between secure and less secure portions of code. For example, this might require that entries in a translation table structure used by the less secure code be copied to a translation table structure used by code within the protected region, or that there be coordination in defining the table structures so that both tables point to the same locations for some levels of page tables. In use cases where it is desirable to provide a secure component associated with a protected region of virtual address space, this coordination of multiple table structures might be difficult to manage in practice (especially in multiprocessor systems) because management of the translation table structures used by the secure component and other code might be handled by different parties, and requiring coordination between those parties might be considered less practical, more costly, or involve a higher risk of security loss.

[0011] In the above-described technique, the address translation circuit selects whether to obtain a translation table address from the first or second translation table address storage circuit based on whether the virtual address is within or outside the protected address region of the virtual address space. This means that the party managing the translation data used for addresses within the protected region does not need to define translation data for addresses outside the protected region. For addresses outside the protected region, a different translation table is referenced, which may be, for example, the same translation structure used by code located outside the protected region for accessing data outside the protected region. This reduces the need to copy translation entries, saves memory capacity, and avoids the time / development costs of collaboration between parties as described above. Therefore, a processor architecture supporting the above-described first and second translation table address storage circuits, protection region definition data storage circuit, and address translation circuit can make software development of secure sandboxed components more efficient.

[0012] At least one translation lookaside buffer (TLB) may be provided to cache information derived from address translation data from one or more translation table structures. In response to a memory access request that misses in the at least one translation lookaside buffer, the address translation circuit may determine whether a target virtual address of the memory access request is within at least one protection region of the virtual address space specified by the region definition data, and perform a page table walk operation using a first translation table address stored in the first translation table address storage circuit when the target virtual address is within the at least one protection region and a second translation table address stored in the second translation table address storage circuit when the target virtual address is outside the at least one protection region.

[0013] Therefore, the selection between the first and second translation table address stores may be performed when handling a miss in the TLB when a page table walk operation is required to retrieve translation data from memory. A hit in the TLB may not need to check whether the virtual address is within the protection region, because the hit can return data previously allocated to the TLB based on one of the first and second translation table structures selected when handling the corresponding TLB miss.

[0014] A processing circuit may have different operational domains that may be associated with different access rights or capabilities, for example, in one domain a processing circuit may be permitted to perform some operations that are not permitted in another domain, or to access certain areas of memory that are inaccessible to another domain.

[0015] Not all domains use region definition data to determine which translation table address storage circuit to access. In some implementations, selecting a translation table address based on whether the target virtual address is within at least one protection region case may be performed only for a subset of domains and not for other domains that are not within the subset. Thus, when the processing circuit is in the first domain, the address translation circuit may translate the target virtual address using address translation data from one of the first translation table structure and the second translation table structure depending on whether the target virtual address is within at least one protection region. On the other hand, when the processing circuit is in the second domain, the address translation circuit may translate the target virtual address based on address translation data from a translation table structure identified by a translation table address obtained from a selected storage location regardless of whether the target virtual address is within or outside at least one protection region.

[0016] In some cases, when the processing circuitry is in the second domain, the address translation circuitry may obtain translation table addresses from a second translation table address storage circuit, i.e., the same storage device from which translation table addresses are obtained in the first domain for translating virtual addresses outside the protection region. In this approach, accesses from the first domain to addresses outside the protection region will, by definition, use the same translation tables as those used in the second domain, thereby reducing the amount of translation table data that needs to be maintained by code in the first domain because the first domain code can simply reuse the portions of the second domain's translation table structures associated with addresses outside the protection region.

[0017] However, another approach may be to provide an additional translation table address storage circuit for storing additional translation table addresses, such that when the processing circuit is in the second domain, the address translation circuit can obtain translation table addresses from the additional translation table address storage circuit, which may be different from the second translation table address storage circuit used in the first domain for at least one access outside the protection region. This approach may still support code in the first domain accessing the same translation table structure as code in the second domain for accesses within the protection region, but it requires that the address in the second translation table address storage circuit be set equal to the address in the additional translation table address storage circuit. While this may require some additional overhead in terms of storage circuitry and hardware and software instructions to set the address, this approach provides additional flexibility for the code in the first domain to choose whether its accesses outside the protection region should reuse the same translation table structure as the code in the second domain, or whether it should instead access an entirely different structure for its address translation data.

[0018] Exception handling circuitry may be provided to control the handling of exceptions, which may occur for a variety of reasons, for example, an address fault may occur if memory access to a given virtual address is requested and there is no valid translation table data defined for that address, or if the translation table data for that address specifies that access is not permitted. Exceptions may also occur for other reasons, such as an external interrupt, an undefined instruction, etc. When an exception occurs, some forms of exception may be attributed to a particular virtual address, for example, because an address fault occurred when accessing that virtual address to fetch an instruction or accessing data from memory, or because an exception occurred when processing an instruction associated with that virtual address.

[0019] For at least one type of exception associated with a given virtual address, the exception handling circuitry can select whether to perform a first exception handling action or a second exception handling action (different from the first exception handling action) depending on whether the exception is associated with a virtual address within or outside the at least one protection region. While this determination need not be made for all types of exceptions, for at least some types, it may be useful to trigger different handling of the exception when the given virtual address is within the at least one protection region compared to when the given virtual address is outside the at least one protection region. This allows an exception handler for handling the exception to respond differently depending on whether the exception is associated with protected code within a protected code region or unprotected code outside a protection region.

[0020] In one example, the exception handling circuit may determine whether an exception should be handled in a first domain or a second domain based on whether a given virtual address is within or outside at least one protection region, and the first / second exception handling action may trigger an exception to be handled in the first / second domain, respectively.

[0021] Another option may be that the first exception handling action includes setting syndrome information indicating that the exception is associated with a virtual address within at least one protection domain, and the second exception handling action includes setting syndrome information indicating that the exception is associated with a virtual address outside at least one protection domain. The syndrome information may be information accessible by an exception handler that indicates information about the cause of the exception. The syndrome information may be referenced by the exception handler to determine how to handle the exception. In this approach, if at least one type of exception occurs during processing in the first domain, the exception may be captured in the first domain regardless of whether the exception is associated with a virtual address within or outside the at least one protection domain, but the exception handler executing in the first domain may use the syndrome information to determine whether to address the cause of the exception itself or forward the exception for handling in the second domain.

[0022] In either way, these features enable the exception handling circuitry to handle exceptions directly or indirectly in different domains depending on whether the exception is associated with an address within or outside at least one protection domain. This may be particularly useful for address fault exceptions that are generated when an access to a given virtual address finds that there is no valid translation table data defined in the translation table structure looked up for that access, or, while there is valid translation table data, the translation table data specifies access permissions that deny access for that particular request (e.g., because it is a write access to a read-only region of memory, or because the domain or other operating conditions of the processing circuitry at the time of issuing the request indicate that access to that virtual address is not permitted). As mentioned above, one use case for providing separate translation table address storage for use within and outside protection domains when in a first domain may be that this may allow a translation table structure associated with a second domain to be reused for accesses outside the protection domain. Thus, in the case of an address fault, it may be preferable for an exception that occurs when making an access outside the protection region to be directed (either directly by the exception handling circuitry or indirectly via an exception handler running in the first domain) to an exception handler handled in the second domain (e.g., associated with an operating system or hypervisor running in the second domain that defines a translation table structure used by code in the second domain), while an address fault that occurs in the first domain when accessing a region within the protection region may instead be handled by the first domain, which may manage a separate translation table structure identified by an address in the first translation table address register.

[0023] On the other hand, for at least one type of exception, if it occurs during processing in the second domain, the exception may be handled in the second domain regardless of whether the virtual address is within or outside the protection region, and the syndrome information may not distinguish whether the virtual address is within or outside the protection region. Thus, the decision on how to handle the exception may depend on a comparison of the given virtual address with the protection region definition data of the first domain rather than the second domain. While an example of an address fault is given above, this technique of controlling whether an exception is handled in the first domain or the second domain may also be performed for other types of exceptions caused by a particular virtual address.

[0024] In one example, the above-mentioned first / second / further translation table address storage circuits may be first / second / further registers for storing corresponding translation table addresses.

[0025] The translation table address stored in any one of these registers may be the base address of the translation table, and the address of the entry in that translation table used to translate the target virtual address may be obtained by adding the base address and an offset derived from a portion of the target virtual address.

[0026] The translation table structure includes data stored in memory at an address identified using an address stored in the translation table address storage circuit. For example, the translation table structure may be a multi-level translation table structure in which an address in the translation table address storage circuit identifies the address of a first-level translation table. A portion of the target virtual address provides an offset used to select the address of a particular entry in the first-level translation table, and that entry can be used to identify the address of a further translation table in the next level of the tree, from which a further entry can be selected based on another portion of the target virtual address, and so on, until a leaf translation entry is obtained in the final level of the translation table that provides a mapped intermediate or physical address corresponding to the target virtual address.

[0027] Because performing a translation table walk to step through all of the translation table structures at those levels can be slow, some systems may provide at least one translation lookaside buffer (TLB) that includes buffer entries for caching information derived from address translation data from one or more translation table structures. For example, the buffer entries may cache translation table entries identified in a previous translation table walk, or may cache information derived from those translation table entries (e.g., entries may directly map a looked-up virtual address to an intermediate address or physical address instead of storing each of the individual translation table entries used to identify that mapping when a multi-level page table walk is performed).

[0028] In some cases, because the TLB may be shared between domains, it may be useful to associate each buffer entry with a domain identifier that identifies a corresponding one of the processing circuit's domains, so that a lookup into the TLB based on a virtual address will hit in the TLB when the TLB contains an entry that matches the virtual address and the processing's current domain, and will not hit an entry associated with a domain different from the current domain.

[0029] The processing circuit may need to issue a translation invalidation command that can be used to request that the TLB invalidate a particular buffer entry for which at least one invalidation criterion specified by the command is met. These commands may be issued, for example, when the processing circuit modifies page table data in one of the translation table structures to prevent the TLB from continuing to cache stale information. It can be expected that a translation invalidation command issued from a particular domain should only trigger the invalidation of cached translation table entries that specify that domain's domain identifier. However, as noted above, the technique described above (a first domain may have its own translation table structure for a protected region overlaid on a translation table structure referenced using a second translation table address storage circuit) may be useful for enabling code associated with a first domain to reuse translation data defined in a translation structure managed by code in a second domain. This means that when a translation invalidation command is issued from a second domain, translation data modified by the second domain code may also be used by the first domain and cached in the TLB associated with the domain identifier identifying the first domain. Thus, in response to a translation invalidation command issued while in the second domain, the TLB can invalidate buffer entries that meet the specified invalidation criteria, regardless of whether they are associated with a domain identifier that identifies the first domain or the second domain.

[0030] The techniques described above may be particularly useful in implementations in which, based at least on a current domain of the processing circuitry, the address translation circuitry translates a target virtual address to a target physical address in one of two or more different physical address spaces selected based on the current domain.

[0031] In some processing systems, all virtual addresses may be mapped by address translation circuitry onto a single physical address space used by the memory system to identify the location in memory to be accessed. In such systems, control over whether a particular software process can access a particular address may be provided solely based on the translation table structure used to provide the address translation mapping. However, such page table structures may typically be defined by the operating system and / or hypervisor. Compromise of the operating system or hypervisor could result in a security breach that could allow an attacker to access sensitive data or code.

[0032] Thus, to support a desire for a particular process to execute securely in isolation from other processes, a system may support operation in several domains, and several separate physical address spaces may be supported. For at least some components of a memory system, memory access requests in which a virtual address is translated to a physical address in a different physical address space are treated as if they were accessing an entirely separate address in memory, even if the physical address in the respective physical address space actually corresponds to a memory system location. Isolating accesses to separate physical address spaces from different operational domains of processing circuitry, as seen by some memory system components, can provide stronger security guarantees that are not dependent on page table permission information established by an operating system or hypervisor.

[0033] Typically, in a system supporting separate physical address spaces accessible to different domains, one would expect each domain to be associated with a completely separate set of translation table data (page table structures). However, it is increasingly desirable for an application that typically runs in one domain to provide certain portions of that application to operate in another domain using a different physical address space to provide additional security. In such use cases, the technique described above using first / second translation table address storage circuits may be particularly useful in simplifying the development of sandboxed components that operate in separate physical address spaces in different domains, as it reduces the need for synchronization between translation table structures that may be stored at physical addresses in different physical address spaces.

[0034] More specifically, the first and second domains described above are associated with first and second physical address spaces, respectively. The first physical address space may be accessible from the first domain but inaccessible from the second domain. The second physical address space may be accessible from both the first and second domains. Thus, the first domain is the more secure domain, having access to the physical address spaces of both domains, while the second domain has no access to the physical address space of the first domain. Thus, it is the first domain, which has greater access rights to the respective physical address spaces, that can select between the first and second translation table addresses for use in the page table walk. This recognizes that it may be appropriate for the first domain to reuse a translation table associated with the second domain, but it may not be appropriate for the second domain to reuse the translation table of the first domain.

[0035] Some systems may support additional domains in addition to the first and second domains described above. For example, there may be a third domain with a third physical address space associated with it. The third physical address space may be accessible to the third domain but inaccessible to the first and second domains. For example, the third domain may be a root domain responsible for managing switching between the first and second domains. Alternatively, the third domain may be an additional domain orthogonal to the first domain, having a third physical address space inaccessible to the second domain, like the first domain, but inaccessible to the third domain, and the first physical address space inaccessible to the third domain, thereby providing two separate processing environments, both more secure than the second domain but without the need to trust each other's code.

[0036] Regardless of the particular form of the third domain, when the processing circuitry is in the third domain, the address translation circuitry may translate the target virtual address based on address translation data from a translation table structure identified by a translation table address obtained from a selected storage location independent of determining whether the target virtual address is within or outside the at least one protection region. For example, a third translation table address storage circuitry may be provided to store the third translation table address, and when the processing circuitry is in the third domain, the processing circuitry may obtain the translation table address from the third translation table address storage circuitry.

[0037] Alternatively, when in the third domain, one of the first and second translation table address storage circuits may be used to provide the translation table address (although the address stored in that storage may change on domain switching so that the third domain can still reference a different translation table structure).

[0038] Therefore, it is not mandatory for all domains to use the above mechanism for selecting which translation table address to use based on whether the target virtual address is within a protected region.

[0039] In some implementations, the protection region definition data storage circuit may be configured to store region definition data defining a single protection region. Other approaches may support region definition data having a format capable of indicating two or more discontinuous protection regions. For each protection region, the region definition data may specify, for example, a base address of the protection address region and a size of the protection address region. The size may be identified by specifying a size value representing the offset of the end address of the protection address region relative to the base address, or by explicitly specifying the end address as an absolute address.

[0040] As described above, some systems are capable of performing two-stage address translation based on a first-stage translation table structure that specifies a mapping from a target virtual address to a target intermediate address and a second-stage translation table structure that specifies a mapping from the target intermediate address to a target physical address. To select which translation table address to use for the first-stage translation table structure (at least when in the first domain as described above), the address translation circuit can select the first / second translation table structure based on whether the target virtual address is within a protection region. Thus, the first / second translation table address storage circuit can store a first-stage table address used to identify a translation table structure selectable as the first-stage translation table structure. The address translation circuit may obtain a first-stage translation table address identifying the first-stage translation table structure from one of the first translation table address storage circuit and the second translation table address storage circuit, selected based on whether the target virtual address is within or outside at least one protection region.

[0041] Similarly, the selection of the second stage translation table structure may depend on whether the target virtual address is within or outside at least one protection region (at least during processing in the first domain as described above). Thus, a second stage translation table address identifying the second stage translation table structure may be obtained from one of the first two-stage translation table address storage circuit and the second two-stage translation table address storage circuit, selected based on a determination of whether the target virtual address is within or outside at least one protection region. The first / second second stage translation table address storage circuit may, for example, comprise further registers provided in addition to the registers used in the first / second (first stage) translation table address storage circuit as described above.

[0042] The above described techniques can be implemented in a data processing apparatus having hardware circuitry providing first / second address storage circuits (and, if provided, third / further address storage circuits), region definition data storage circuits, and address translation circuits as described above.

[0043] However, the same technique can also be implemented in a computer program executed on a host data processing device to provide an instruction execution environment for execution of target code. Such a computer program can control the host data processing device to simulate an architectural environment provided on a hardware device that actually supports target code according to a particular instruction set architecture, even if the host data processing device itself does not support that architecture. Thus, the computer program can include address translation program logic supporting address translation from target virtual addresses to target physical addresses, emulating the operation of the address translation circuit described above. Also, instead of providing hardware storage for storing first and second translation table addresses and region definition data, the computer program can include state emulation logic that maintains state information emulating the architectural state of a target instruction set architecture associated with the target code, the state information specifying the first and second translation table addresses and region definition data. In response to a memory access instruction in the target code, the address translation program logic can translate the target virtual address based on either the first or second translation table structure identified by the first or second translation table address, depending on whether the target virtual address is within a protected region, similar to the function of the address translation circuit described above.

[0044] In the case of a simulated computer program, the address translation program logic may translate a target virtual address into a simulated target physical address that is expected to refer to a physical location in memory (in terms of a translation table structure defined in accordance with the target instruction set architecture), but when the target code is executed by the instruction execution environment provided by the simulation program, the translated address actually represents a simulated physical address that has been mapped by the simulation to a portion of the virtual address space within the host virtual address space of the host processor executing the simulator program.

[0045] Such simulation programs are useful, for example, when legacy code written for one instruction set architecture is being executed on a host process that supports a different instruction set architecture. Also, because running software on a simulation execution environment can enable testing of the software in parallel with the ongoing development of hardware that supports the new architecture, simulation can allow software development for a new version of an instruction set architecture to begin before the hardware that supports the new architecture version is available.

[0046] The simulation program may be stored on a storage medium, which may be a non-transitory storage medium.

[0047] Description of the Examples FIG. 1 schematically illustrates an example 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. A requester device can issue memory access requests requesting memory access to specific addressable memory system locations. The completer device 6 is a device responsible for processing memory access requests directed to it. Although not shown in FIG. 1, some devices may be capable of functioning as both a requester device and a completer device. The requester device 4 may include processing elements such as a central processing unit (CPU) or a graphics processing unit (GPU) or other master devices such as bus master devices, network interface controllers, display controllers, etc. The completer device may include a memory controller responsible for controlling access to corresponding memory storage units, a peripheral controller for controlling access to peripheral devices, etc. While FIG. 1 illustrates one example configuration of a requester device 4 in more detail, it should be understood that other requester devices 4 may have similar configurations. Alternatively, other requestor devices may have a different configuration than requestor device 4 shown on the left side of FIG.

[0048] Requester device 4 has processing circuitry 10 for performing data processing responsive to instructions by referencing data stored in registers 12. Registers 12 may include general-purpose registers for storing operands and results of processed instructions, as well as control registers for storing control data for configuring how processing is performed by the processing circuitry. For example, the control data may include a current domain indication 14 used to select which operating domain is the current domain, and a current exception level indication 15 indicating which exception level is the current exception level at which processing circuit 10 is operating.

[0049] Processing circuit 10 may be capable of issuing memory access requests specifying a virtual address (VA) that identifies the addressable location to be accessed and a domain identifier (region ID or “security state”) that identifies the current region. Address translation circuit 16 (e.g., a memory management unit (MMU)) translates the virtual address into a physical address (PA) through one of many stages of address translation based on page table data defined in page table structures stored in the memory system. Translation lookaside buffer (TLB) 18 functions 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 an address translation was needed. In this example, in addition to generating a physical address, 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. PAS selection is discussed in more detail below.

[0050] Based on the translated physical address and the PAS identifier, the PAS filter 20 functions as a requester filtering circuit to determine whether the physical address is permitted to be accessed within the specified physical address space identified by the PAS identifier. This lookup is based on granule protection information stored in a granule protection table structure stored within the memory system. Granule protection information may be cached in a granule protection information cache 22, similar to the caching of page table data within the TLB 18. In the example of FIG. 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 may be combined into a single lookup cache structure, such that a single lookup of an entry in the combined structure provides both page table information and granule protection information. The granule protection information restricts the physical address space in which a given physical address can be accessed and, based on this lookup, defines information that the PAS filter 20 uses to determine whether a memory access request is allowed to proceed to be issued 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 a fault.

[0051] While Figure 1 shows an example of a system having multiple requestor devices 4, the features shown for the single requestor device on the left side of Figure 1 may also be included in systems where there is only one requestor device, such as a single-core processor.

[0052] While FIG. 1 shows an example in which the selection of a PAS for a given request is performed by the address translation circuit 16, in other examples, information for determining which PAS to select along with the PA can be output by the address translation circuit 16 to the PAS filter 20, which can select a PAS and verify whether the PA can be accessed within the selected PAS.

[0053] The provision of PAS filter 20 helps support a system that can operate in several operating domains, each associated with its own isolated physical address space, where, for at least a portion of the memory system (e.g., for some caches or coherency enforcement mechanisms such as snoop filters), separate physical address spaces are treated as if they refer to separate sets of addresses that identify entirely separate memory system locations, even if the addresses within those address spaces actually refer to the same physical location within the memory system. This can be useful for security purposes.

[0054] FIG. 2 shows examples of different operating states and domains in which processing circuitry 10 can operate, as well as examples of the types of software that may run at different exception levels and domains (it will, of course, be understood that the particular software installed on a system is selected by the party managing that system and is therefore not an essential feature of the hardware architecture).

[0055] Processing circuit 10 is capable of operating at several different exception levels 80, in this example four exception levels labeled EL0, EL1, EL2, and EL3, where EL3 refers to the most privileged exception level and EL0 refers to the least privileged exception level. It will be appreciated that other architectures may choose the reverse numbering, with the exception level with the highest number being considered to be the least privileged. In this example, the least privileged exception level EL0 is for application-level code, the next most privileged exception level EL1 is used for operating system-level code, the next most privileged exception level EL2 is used for hypervisor-level code that manages switching between several virtual operating systems, and the most privileged exception level EL3 is used for monitor code that manages switching between the respective domains and the allocation of physical addresses to the physical address space, as will be described below.

[0056] When an exception occurs at a particular exception level while processing software, for some types of exceptions, the exception is accepted to a higher (more privileged) exception level, and the particular exception level at which the exception is accepted is selected based on attributes of the particular exception that occurred. However, in some circumstances, other types of exceptions may be accepted at the same exception level as the 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 saved, including, for example, the current exception level at the time the exception was accepted. Thus, once an exception handler is processed to address the exception, processing can return to the previous processing, and the saved information can be used to identify the exception level to which processing should return.

[0057] In addition to different exception levels, the processing circuit also supports several operating regions, including a root region 82, a secure (S) region 84, a less-secure region 86, and a realm region 88. For ease of reference, the less-secure region is described below as a “non-secure” (NS) region, although it will be understood that this is not intended to imply a particular level (or lack thereof) of security. Instead, “non-secure” simply indicates that the non-secure region is intended for code that is less secure than 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-EL2, the current region is selected based on a current region indicator 14, which indicates which of the other regions 84, 86, 88 is active. For each of the other regions 84, 86, 88, the processing circuit can be at either exception level, EL0, EL1, or EL2.

[0058] At power-up, some boot code (e.g., BL1, BL2, OEM boot) may execute within, for example, the more privileged exception levels EL3 or EL2. Boot code BL1, BL2 may be associated with, for example, the root region, and OEM boot code may operate in the secure region. However, once the system is booted, during execution, processing circuit 10 may be considered to operate in one of regions 82, 84, 86, and 88 at a time. Each of regions 82-88 is associated with its own associated physical address space (PAS). This allows for isolation of data from different regions within at least a portion of the memory system, as will be described in more detail below.

[0059] Non-secure region 86 may be used for normal application level processing and operating system and hypervisor activity for managing such applications. Thus, within non-secure region 86 there may be application code 30 running at EL0, operating system (OS) code 32 running at EL1, and hypervisor code 34 running at EL2.

[0060] The secure region 84 allows certain 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. The secure and non-secure regions are not equivalent in the sense 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 a division of secure and non-secure regions 84, 86 is a system based on the TrustZone® architecture offered by Arm® Limited. The secure region can run trusted applications 36 at EL0, trusted operating systems 38 at EL1, and optionally a secure partition manager 40 at EL2. EL2, when secure partitioning is supported, can use two page tables to support isolation between different trusted operating systems 38 running within the secure region 84, in a manner similar to how the hypervisor 34 can manage isolation between virtual machines or guest operating systems 32 running within the non-secure region 86.

[0061] Extending systems to support secure domains 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 occur on a separate hardware processor. However, as the use of secure domains has grown in popularity, many practical systems with such secure domains now support a relatively high degree of heterogeneity of services within the secure domain provided by a wide range of different software providers. For example, the code running within secure domain 84 may include different software providers, including (among other providers) silicon providers that fabricate integrated circuits, original equipment manufacturers (OEMs) that assemble integrated circuits provided by the 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 many different customers via the cloud.

[0062] However, there is a growing demand for providers of user-level code (which might typically be expected to run as applications 30 in non-secure world 86) to be provided with a secure computing environment that can be trusted not to leak information to other parties running code on the same physical platform. It may be desirable for such a secure computing environment to be dynamically allocable during runtime and to be guaranteed and provable, allowing users to verify whether sufficient security guarantees are provided on the physical platform before entrusting the device with processing potentially sensitive code or data. Users of such software may not want to trust providers of feature-rich operating systems 32 or hypervisors 34 that might typically run in non-secure world 86 (or, even if those providers themselves are trustworthy, users may want to protect themselves from unauthorized access to the operating systems 32 or hypervisors 34 by attackers). While secure world 84 can be used for such user-provided applications requiring secure processing, in practice this creates problems for both users who provide code requiring a secure computing environment and providers of existing code running in secure world 84. For providers of existing code running in secure area 84, the attack surface for potential attacks against their code increases with the addition of arbitrary user-provided code within the secure area. This may be undesirable, and users may therefore be strongly discouraged from allowing code to be added to secure area 84. On the other hand, users who provide code that requires a secure computing environment may be reluctant to trust access to their data or code to all of the different code providers running in secure area 84, as it may be difficult to audit and certify all of the separate code provided by different software providers running in secure area 84 if assurances and certifications of the code running in a particular area are required as a prerequisite for the user-provided code to perform operations.This may limit opportunities for third parties to offer more secure services.

[0063] Thus, as shown in FIG. 2, an additional realm 88, called a realm realm, is provided and can be used by such user-introduced code to provide a secure computing environment orthogonal to any secure computing environment associated with components operating in the secure realm 24. In the realm realm, the executing software can include several realms, each of which 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 the respective realms 42, 44 executing in the realm realm 88 by defining access permissions and address mappings within page table structures, for example, similar to how the hypervisor 34 manages the isolation between different components operating in the non-secure realm 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 appreciated that supporting both EL0 and EL0 / EL1 type realms is not required, and multiple realms of the same type can be established by the RMM 46.

[0064] The realm region 88 has its own physical address space assigned to it, just like the secure region 84. However, the realm region is orthogonal to the secure region 84 in the sense that while the realm region and the secure region 88, 84 each have access to the non-secure PAS associated with the non-secure region 86, the realm region 88 and the secure region 84 cannot access each other's physical address space. This means that code running in the realm region 88 and the secure region 84 have no dependencies on each other. Code within the realm region only needs to trust the hardware, the RMM 46, and the code running in the root region 82, which manages switching between regions, meaning that attestation and certification are more feasible. Attestation allows given software to request verification that code installed on a device matches certain expected characteristics. This can be done by checking whether a hash of program code installed on the device matches an expected value signed by a trusted party using a cryptographic protocol. The RMM 46 and monitor code 29 may be attested by, for example, checking whether a hash of this software matches an expected value signed by a trusted party, such as the silicon provider that manufactured the integrated circuit that includes the processing system 2, or the architecture provider that designed the processor architecture that supports region-based memory access control. This allows the user-provided code 42, 44 to verify that the integrity of the region-based architecture can be trusted before performing any secure or sensitive functions.

[0065] Thus, as shown by the dotted lines indicating gaps in the non-secure realm where these processes would previously have executed, it can be seen that code associated with realms 42, 44 that would previously have executed in the non-secure realm 86 can now be moved to the realm realm where they may have stronger security guarantees because their data and code cannot be accessed by other code running in the non-secure realm 86. However, due to the fact that the realm realm 88 and the secure realm 84 are orthogonal and therefore cannot see each other's physical address space, this means that providers of code in the realm realm do not need to trust providers of code in the secure realm, and vice versa. Code in the realm realm can simply trust the firmware that provides the root realm 82 and the monitor code 29 of the RMM 46, 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 start when code is running on their device, so that no additional trust relationships with other operating system vendors, OEMs, or cloud hosts are required by users in order for them to be provided with a secure computing environment.

[0066] This is useful for a variety of purpose applications and use cases, including, for example, mobile wallet and payment applications, fraud and piracy prevention mechanisms in games, operating system platform security extensions, secure virtual machine hosting, confidential computing, networking, or gatewaying for the Internet of Things. Users will appreciate that they may find many other applications in which Realm support is useful.

[0067] To support the security assurances provided to a Realm, a processing system may support an attestation reporting function, whereby firmware images and configurations, e.g., monitor code images and configurations, or RMM code images and configurations are measured at boot time or during runtime. During runtime, the contents and configurations of the Realm are measured, allowing the Realm Owner to trace back relevant attestation reports to known implementations and assurances and make trust decisions about whether to operate on that system.

[0068] As shown in FIG. 2, a separate root region 82 is provided to manage region switching, with the root region having 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 with only non-secure and secure regions 86 and 84 and no realm region 88, but it can also be used in implementations that support the realm region 88. The root region 82 can be implemented using monitor software 29 provided (or certified) by the silicon provider or architecture designer and can be used to provide secure boot functionality, trusted boot measurements, system-on-chip configuration, debug control, and firmware update management for firmware components provided by other parties, such as the OEM. Code in the root region can be developed, certified, and deployed by the silicon provider or architecture designer without dependency on the final device. In contrast, the secure region 84 can be managed by the OEM to implement specific platform and security services. Management of the non-secure realm 86 may be controlled by the operating system 32, which provides operating system services, while the realm realm 88 is mutually isolated from existing secure software environments in the secure realm 84 while allowing the development of new forms of trusted execution environments that may be dedicated to user or third-party applications.

[0069] FIG. 3 schematically illustrates another example of a processing system 2 for supporting these techniques. Elements that are the same as in FIG. 1 are designated by the same reference numerals. FIG. 3 illustrates address translation circuitry 16 in greater detail, including a stage 1 memory management unit 50 and a stage 2 memory management unit 52. Stage 1 MMU 50 can be involved in translating either virtual addresses to physical addresses (if the translation is triggered by EL2 or EL3 code) or to intermediate addresses (if the translation is triggered by EL0 or EL1 code, with further stage 2 translation by Stage 2 MMU 52 being necessary). Stage 2 MMU can translate the intermediate addresses to physical addresses. Stage 1 MMU can be based on page tables controlled by the operating system for translations starting from EL0 or EL1, page tables controlled by the hypervisor for translations from EL2, or page tables controlled by monitor code 29 for translations from EL3. Stage 2 MMU 52, on the other hand, can be based on page table structures defined by the hypervisor 34, RMM 46, or secure partition manager 14, depending on which region is being used. Separating the translation into two stages in this manner allows operating systems to manage address translation for themselves and for applications, assuming they are the only operating systems running on the system, while RMM 46, hypervisor 34, or SPM 40 can manage isolation between different operating systems running within the same realm.

[0070] 3, the address translation process using address translation circuitry 16 can return security attributes 54 that, in combination with the current exception level 15 and the current region 14 (or security state), allow a particular section of 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 a granular protection table 56, which provides the granular protection information described above. In this example, PAS filter 20 is shown as a granular memory protection unit (GMPU) that verifies whether the selected PAS can access the requested physical address and, if so, allows the transaction to be passed to any caches 24 or interconnects 8 that are part of the system fabric of the memory system.

[0071] The GMPU 20 allows memory to be allocated to separate address spaces while at the same time providing strong hardware-based isolation guarantees, providing spatial and temporal flexibility in how physical memory is allocated to these address spaces, as well as an efficient sharing scheme. As previously mentioned, the execution units in the system are logically divided into virtual execution states (regions or "worlds"), with one execution state (root world) located at the highest exception level (EL3), called the "root world," and the root world manages the allocation of physical memory to these worlds.

[0072] A single system physical address space is virtualized into multiple "logical" or "architectural" physical address spaces (PAS), where each such PAS is an orthogonal address space with independent coherency properties. A system physical address is mapped into a single "logical" physical address space by extending it with a PAS tag.

[0073] A given world is allowed access to a subset of the logical-physical address space. This is enforced by a hardware filter 20 that can be attached to the output of the memory management unit 16.

[0074] The world defines the security attributes (PAS tags) of the 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, which indicates the PASTAG with which it is associated, and (optionally) other granule protection attributes.

[0075] The hardware filter 20 checks the world ID and security attributes for the GPI of the granule to determine whether access can be granted, thus forming a Granular Memory Protection Unit (GMPU).

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

[0077] Locating GMPU 20 on the requester side of the system (e.g., on the MMU output) rather than on the completer side allows Interconnect 8 to assign access permissions at page granularity while allowing continuous hashing / striping of pages across multiple DRAM ports.

[0078] Transactions remain tagged with a PAS TAG as they propagate throughout the system fabric 24, 8 until they reach a location defined as the physical aliasing point 60. This allows filters to be placed on the master side without weakening security guarantees compared to slave-side filtering. As transactions propagate throughout the system, the PAS TAG can be used as a security mechanism in-depth for address isolation. For example, a cache can add a PAS TAG to an address tag in the cache to prevent accesses made with an incorrect PAS TAG to the same PAS 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.

[0079] The Point of Physical Aliasing (PoPA) is the location in the system where the PAS TAG is stripped and addresses change from logical physical addresses back to system physical addresses. The PoPA can be located below the cache on the completer side of the system, where accesses to physical DRAM are made (using the cryptographic context resolved via the PAS TAG). Alternatively, it may be located above the cache to simplify system implementation at the expense of weakened security.

[0080] At any point, a world can request that a page be transitioned from one PAS to another. The request is made at EL3 to monitor code 29, which examines the current state of the GPI. EL3 may allow only a specific set of transitions to occur (e.g., non-secure PAS to secure PAS, but not realm PAS to secure PAS). To provide a clean transition, a new instruction, "Delete Data and Invalidate to Physical Aliasing Point," is supported by the system and can be submitted by EL3 before transitioning the page to the new PAS. This ensures that any residual state associated with the previous PAS is flushed from any caches upstream of PoPA 60 (closer to the requester).

[0081] Another property that can be achieved by attaching the GMPU 20 to the master side is 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 a "limited sharing" semantic to the granule protection information and enforcing it to use a specific PAS TAG. As an example, a GPI can indicate that a physical granule can only be accessed by the "realm world" 88 and the "secure world" 84 while tagged with the PAS TAG of the secure PAS 84.

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

[0083] 4 illustrates the concept of aliasing the respective physical address spaces on the physical memory provided in the hardware. As previously mentioned, each of the regions 82, 84, 86, 88 has its own respective physical address space 61.

[0084] At the time a physical address is generated by address translation circuitry 16, the physical address has a value within a particular numeric 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, address translation circuitry 16 may also select a particular physical address space (PAS) based on information in the current region 14 and / or the page table entry used to derive the physical address. Alternatively, instead of address translation circuitry 16 performing the PAS selection, the address translation circuitry (e.g., an MMU) can output a physical address and information derived from a page table entry (PTE) that is used to select the PAS, and this information can then be used by the PAS filter or GMPU 20 to select the PAS.

[0085] The selection of a PAS for a given memory access request may be limited depending on the current domain in which processing circuit 10 operates when issuing the memory access request, according to the rules defined in the table below.

[0086] [Table 1] For regions where there are multiple physical address spaces available to choose from, information from the accessed page table entry used to provide the physical address is used to select between the available PAS options.

[0087] Thus, by the time the PAS filter 20 outputs a memory access request to the system fabric 24, 8 (assuming it passes 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 seen as an entirely separate address range corresponding to a different system location in memory. This means that from the perspective of the 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 may be output in the address translation. This is because the PAS identifier is effectively treated as additional address bits alongside the physical address itself, so that the same physical address PAx may be mapped to several aliased physical addresses 63 within the separate physical address spaces 61, depending on the PAS selected. These aliased physical addresses 63 all actually correspond to the same memory system location implemented in physical hardware, but the pre-PoPA memory system components treat the aliased addresses 63 as separate addresses. Therefore, if there is a pre-PoPA cache or snoop filter that allocates entries to such addresses, the aliased addresses 63 will be mapped to different entries with separate cache hit / miss determinations and separate coherency management. This reduces the likelihood or effectiveness of an attacker using cache or coherency side channels as a mechanism to probe the behavior of other domains.

[0089] A system may include two or more PoPAs 60 (e.g., as shown in FIG. 14, discussed below). In each PoPA 60, aliased physical addresses are folded into a single unaliased address 65 within the system physical address space 64. The unaliased address 65 is provided to any post-PoPA components downstream, so that the system physical address space 64, which actually identifies a 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 PoPA 60, the PAS identifier may be stripped from the address, and for downstream components, the address can be identified simply using the physical address value without specifying a PAS. Alternatively, if some completer-side filtering of memory access requests is desired, the PAS identifier may still be provided downstream of 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 provided PAS identifier may still be used to perform completer-side security checks.

[0090] 5 illustrates how system physical address space 64 can be divided into chunks allocated for access within a particular architectural physical address space 61 using a granule protection table 56. Granule protection table (GPT) 56 defines which portions of system physical address space 65 are accessible from each architectural physical address space 61. For example, GPT 56 may contain several entries, each corresponding to a particular size granule of physical addresses (e.g., 4K pages), and may define the granule's assigned PAS, which may be selected from among non-secure, secure, realm, and root regions. By design, if a particular granule or set of granules is assigned to a PAS associated with one of the regions, it can only be accessed within the PAS associated with that region and cannot be accessed within the PASs of other regions. However, note that even though (for example) granules allocated to the secure PAS are not accessible from within the root PAS, the root region 82 can still access that granule of physical addresses by specifying PAS selection information in its page table to ensure that virtual addresses associated with pages mapped to that area of ​​physically addressed memory are translated to physical addresses 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 a PAS for a given memory access request.

[0091] However, in some implementations, in addition to enabling access to granules of physical addresses within the assigned PAS defined by the GPT, the GPT can use other GPT attributes to mark a region of address space (e.g., an address space associated with a region of lower or orthogonal privilege that would not normally be permitted to select the assigned PAS for access requests for that region) as shared with another address space. This can facilitate temporary sharing of data without having to change the assigned PAS for a given granule. For example, in FIG. 5 , realm PAS region 70 is defined in the GPT to be assigned to the realm region and is normally inaccessible from non-secure region 86 because non-secure region 86 cannot select the realm PAS for its access requests. Because non-secure region 26 does not have access to the realm PAS, non-secure code would not normally be able to see data in region 70. However, if a realm wants to temporarily share some of its data in its allocated region of memory with a non-secure region, it can request that monitor code 29 running in root region 82 update GPT 56 to indicate that region 70 is shared with non-secure region 86, thereby making region 70 accessible from the non-secure PAS shown on the left side of FIG. 5 without having to change which regions are allocated to region 70. When a realm region designates a region of its address space as shared with a non-secure region, a memory access request issued from the non-secure region and targeting that region may initially specify a non-secure PAS, but PAS filter 20 can remap the request's PAS identifier to instead specify a realm PAS. Downstream memory system components then treat the request as if it had originally issued from the realm region. This sharing can improve performance because the operations to assign a different region 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 copying data between memory regions.This may not be justifiable if the sharing is expected to be only temporary.

[0092] 6 illustrates address translation circuitry 16 in more detail. Address translation circuitry 16 includes translation request processing circuitry 100, TLB control circuitry 102, and page table walk control circuitry 104. While shown in FIG. 6 as being located within address translation circuitry 16, in other embodiments, address translation circuitry 16 may also access several translation control registers 106 that may be located within register bank 12 accessed by processing circuitry 10 for general purpose operands.

[0093] The request processing circuit 100 receives a translation request from the processing circuit 10, which specifies a target virtual address to be translated and a domain ID that identifies the current operating domain. In response to the translation request, the request processing circuit 100 controls the TLB control circuit to perform a lookup in the TLB 18 to determine whether the TLB contains a buffer entry corresponding to the target virtual address and the current domain. The buffer entry in the TLB may be tagged with a corresponding domain identifier that indicates the domain that was the current domain at the time the TLB entry was allocated in the TLB 18, and the lookup in the TLB may be qualified by the current domain to prevent an access from one domain from hitting translation data allocated in the TLB in response to a request associated with another domain. If the request hits in the TLB, the matching TLB entry may return an address mapping for mapping the target virtual address to the translated address (as well as the access permission and / or PAS selection information described above). The request processing circuit 100 may use the returned information to determine whether the memory access is permitted. If the memory access is not permitted (based on the access permission), an address fault occurs, preventing the memory access from being performed. If memory access is permitted, the request handling circuit 100 returns the translated address (in the system shown in FIG. 1, the translated address (physical address) is forwarded to the PAS filter 20 to perform the granule protection lookup / PAS filtering step).

[0094] If the lookup in the TLB fails, resulting in no corresponding buffer entry being found for the requested target virtual address and domain identifier, the TLB control circuit 102 controls the page table walk control circuit 104 to issue one or more page table walk requests to request one or more page table entries from a translation table structure (also known as a page table structure) stored in memory.

[0095] As shown in FIG. 7, a page table structure may be implemented using multiple levels of page tables 120, 122, 124, 126 that may be traversed in a page table walk operation to identify the address mapping of a particular target address. As shown in FIG. 7, a given set of index bits L0I may be used to index into a level 0 (L0) page table 120, whose location in memory is identified by a level 0 (L0) base address 121. As described in more detail below, the L0 base address 121 is selected based on information in the translation control register 106. The indexed entry in the L0 table 120 identifies an L1 base address that identifies a location in memory of an L1 page table 122. A different subset of the index bits L1I from the target address table selects one of the entries in the L1 page table 122, which in turn identifies an L2 base address that identifies a memory location in an L2 page table 124. Another subset of the index bits L2I from the target address table is indexed into the L2 page table 26 to identify an L3 base address that identifies a location in an L3 page table 124. A further subset of bits L3I of the target address then selects a particular entry in L3 page table 126 that provides the actual address mapping for mapping the target address to a translation address, such as a physical address (as well as any associated access permission and / or PAS selection information). Thus, L3 page table 126 is the final page table, providing leaf page table entries that provide the actual address mapping information, while higher level page tables 120, 122, 124 provide intermediate entries that identify the base addresses of the next level page tables.

[0096] It will be understood that providing four levels of page tables is merely an example, and others may use different numbers of levels of page tables. Also, if larger blocks of address space share the same translation mappings and other information, one of the entries in a higher-level page table 120, 122, 124 may specify that it is a leaf entry that directly provides the address mapping, so that there is no need to further step through subsequent levels (while other entries in the same higher-level page table 120, 122, 124 can still function as branch entries that contain base addresses that point to lower-level page tables).

[0097] Dividing the page table into different levels in this manner reduces the total amount of memory storage required to store the entire page table structure by not having to locate the address mapping for translating a given amount of address space in a region of memory having a size equivalent to the size of the address being mapped, and by taking advantage of the fact that often large chunks of address space do not yet have mappings defined by the operating system or other process that sets up address translation data. While Figure 7 shows an example in which the index bits L0I, L1I, etc. are used directly as an index to select the corresponding page table entry, the index may also be the result of a hash function applied to the index bits.

[0098] In some systems, the TLB 18 may include separate cache structures for caching translation entries from different levels of page tables. For example, the TLB 18 may include a main TLB structure for caching leaf entries from the last-level page table 126, as well as a walk cache structure for caching higher-level page table entries from the page tables 120, 122, and 124. Meanwhile, other embodiments may provide a TLB that caches address translation data from multiple levels of page tables using a shared cache structure. Other embodiments may cache only leaf entries that may be looked up to provide an address mapping corresponding to a given VA, but may not carry branch entries from the higher-level page tables 120, 122, and 124. Any of these approaches may be used. While FIG. 6 shows a single TLB 18, some implementations may include multiple levels of TLB cache structures in the cache hierarchy to trade off capacity for access latency (e.g., fewer entries stored in the level 0 TLB for faster access, and more entries stored in the level 1 TLB for slower access in case of a level 0 TLB miss).

[0099] In some operating states of processor 10, the address translation process may also include multiple stages of address translation (whether one or two stages of address translation are required may depend on the current exception level 15 and / or configuration information set in register 12). For example, a VA used to identify a memory location by instructions executed by an application or operating system running on CPU 4 may be translated to an intermediate physical address (IPA) in stage 1 translation. A stage 1 address translation structure for controlling stage 1 address translation may be set, for example, by the operating system or another process operating at EL1. From the operating system's perspective, the IPA generated in stage 1 address translation can be assumed to be the physical address of the actual memory location being accessed. However, to support virtualization and prevent conflicts between identical IPAs used by different operating systems coexisting on the same device, a hypervisor or other process operating at EL2 may provide the memory system with an additional, second-stage address translation between IPA and PA. As described above with reference to FIGS. 4 and 5, these PAs may be PAs within selected physical address spaces, and some pre-PoPA memory system components may treat identical PA values ​​in different physical address spaces as if they point to different physical locations. Thus, there may be a second stage translation table structure defined by code running in EL2 to control stage 2 address translation.

[0100] Note that each of the two stages of address translation can use multiple levels of page tables, as shown in Figure 7. Thus, a full page table walk to identify the address mapping of a given block of addresses identified by the target VA may require that each base address of a page table used in the Stage 1 address translation pass through a Stage 2 address translation before accessing the corresponding level of the Stage 1 page table. That is, in an example where both the Stage 1 and Stage 2 tables include four levels of page tables, as shown in Figure 7, the full page table walk process may include accessing the multiple levels of page tables in the following order: Stage 2 translation of the Stage 1 Level 0 page table base address 121 to PA (the Stage 1 translation structure is constructed by code running at EL1, so the Stage 1 Level 0 base address can be an IPA address). The Stage 2 translation involves four lookups (Stage 2, Level 0; Stage 2 Level 1; Stage 2 Level 2; Stage 2 Level 3). Stage 1 Level 0 lookup based on the Level 0 index portion L0I of the target VA to identify the Stage 1 Level 1 Base Address (IPA). Stage 2 translation of Stage 1 Level 1 base address to PA (again, involving 4 lookups). Stage 1 Level 1 lookup based on the Level 1 index portion L1I of the target VA to identify the Stage 1 Level 2 Base Address (IPA) Stage 2 translation of Stage 1 Level 2 base address to PA (also involves 4 lookups) Stage 1 Level 2 lookup based on the Level 2 Index portion L2I of the target VA to identify the Stage 1 Level 3 Base Address (IPA). Stage 2 translation of Stage 1 Level 3 base address to PA (again involving 4 lookups). Stage 1 level 3 lookup based on the level 3 index portion L3I of the target virtual address to identify the target IPA corresponding to the target VA. Stage 2 translation of the target IPA to a target PA that can be returned as the translated address corresponding to the original target VA (again, involving four lookups).

[0101] Thus, without caching, the translation involves a total of 24 lookups. As can be seen from the above sequence, performing the entire page table walk process can be very slow, as it may require numerous accesses to memory to step through each level of the page tables for each stage of the address translation. This is why it is often desirable to cache not only the last-level address mapping, but also information from entries from the upper-level page tables of the Stage 1 and Stage 2 tables in the TLB 18. This allows at least some steps of the full page table walk to be bypassed even if the last-level address mapping for a given target address is not currently in the address translation cache.

[0102] In systems that support two stages of address translation, some TLBs 18 may be implemented as split TLBs, with separate cache structures provided for caching information from the stage 1 and stage 2 page table structures, respectively. In this case, two separate TLB lookups may be required to process a translation request that specifies a VA: one lookup in the stage 1 TLB to identify the corresponding IPA, and one lookup in the stage 2 TLB to identify the PA corresponding to that IPA. Alternatively, a page table walk operation for an address request that undergoes two stages of address translation may require separate lookups in the stage 1 and stage 2 page table structures to first identify the mapping of the VA to the IPA and then the mapping of the IPA to the PA; once this is done, the combined stage 1 and stage 2 TLBs may be populated with an entry that directly maps the VA to the PA, so that future accesses to the same VA can retrieve the PA from TLB 18 without having to perform two separate lookups.

[0103] The translation control registers 106 are used to control the selection of the level 0 base address 121 for the stage 1 or stage 2 page table structure. The translation control registers 106 include a protection address region (PAR) register 130 and several translation table base registers (TTBRs) 132, 134, 136, 138, 142, 144, 146, and 148. Although not shown in FIG. 6 , the translation control registers 106 may also include other control registers to provide control parameters that may be banked per exception level. For example, these other control parameters may define information that affects how the translation or page table walk is performed, such as the address size or page granule size.

[0104] The PAR register (protection region definition data storage circuit) 130 stores region definition data that specifies at least one protection region of the virtual address space. For example, the region definition data may specify a base address of the protection region (by specifying an absolute end address or by specifying the size as a relative offset of the end address to the base address) and a size of the protection region. Some systems may support multiple PAR registers 130 to indicate multiple protection address regions, but for simplicity, the following examples describe the use of the PAR register 130 with reference to one protection address region. When multiple protection address regions are implemented, a comparison is performed for each set of region definition data associated with the multiple protection address regions.

[0105] Each of TTBRs 132, 134, 136, 138, 142, 144, 146, and 148 stores the base address of the level 0 page table in the corresponding page table structure. TTBRs 132, 134, 136, 138, 142, 144, 146, and 148 can be updated by software to change which page table structure is referenced when a page table walk is required.

[0106] A non-secure stage 1 TTBR, S1_TTBR_N, 132, is provided to store the level 0 base address 121 used for stage 1 address translation when the current domain is a non-secure domain. Similarly, a non-secure stage 2 TTBR, S2_TTBR_N, 142 stores the level 0 base address 121 used for stage 2 address translation when the current domain is a non-secure domain. As described below, S1_TTBR_N 132 and S2_TTBR_N 142 can also be referenced by realm domain when the VA of an address request that misses in TLB 18 is outside the protected address region defined by PAR register 130. Both S1_TTBR_N 132 and S2_TTBR_N 142 are examples of second translation table address storage circuitry as described above, or in embodiments where S1_TTBR_R2 138 or S2_TTBR_R2 148 are provided as examples of further translation table address storage circuitry. S1_TTBR_N 132 may be readable and writable by software operating at EL1 or higher in any of the domains. S2_TTBR_N 142 may be readable and writable by software operating at EL2 or higher in any of the domains.

[0107] When the current domain is a Realm domain and the target VA is within the protection address range defined by the PAR register 130, a Realm stage 1 TTBR, S1_TTBR_R, 134 (an example of a first translation table address storage circuit) is provided to store the level 0 base address 121 used for stage 1 address translation. The S1_TTBR_R 134 may be readable and writable by software operating at EL1 or higher in the Realm domain or the Root domain. Similarly, when the current domain is a Realm domain and the target VA is within the protection address range defined by the PAR register 130, a Realm stage 2 TTBR, S2_TTBR_R, 144 (also an example of a first translation table address storage circuit or a first second stage translation table address storage circuit) is provided to store the level 0 base address 121 used for stage 2 address translation. The S2_TTBR_R 144 may be readable and writable by software operating at EL2 or higher in the Realm domain or the Root domain.

[0108] Optionally, an additional stage 1 TTBR 136, shown in FIG. 6 as combined into a single register for simplicity but which may be split into two separate registers, may be provided associated with the root and / or secure domains. S1_TTBR_Root and / or S1_TTBR_S 136 are examples of the third translation table address storage circuit described above. The associated one of S1_TTBR_Root and S1_TTBR_S 136 may refer to a page table walk triggered by a stage 1 address translation when operating in the corresponding one of the root domain and the secure domain. S1_TTBR_Root is readable and writable only from the root domain. S1_TTBR_S 136 may be readable and writable by software operating at EL1 or above in the secure domain or the root domain. Similarly, an optional additional stage 2 TTBR 146, labeled S2_TTBR_S, may be provided associated with the secure domain (the root domain does not require a stage 2 TTBR because it requires only one stage of address translation). Therefore, S2_TTBR_S146 can be referenced for page table walks triggered by stage 2 address translation when operating in the secure domain. S2_TTBR_S146 may be readable and writable by software operating at EL2 or higher in the secure domain.

[0109] Alternatively, S1_TTBR_Root and / or S1_TTBR_S136 may be omitted, in which case the TTBR used for stage 1 address translation in the root and / or secure domain may instead be the S1_TTBR_N132 register shared with the non-secure domain. Similarly, S2_TTBR_S146 may be omitted, in which case the TTBR used for stage 2 address translation in the secure domain may instead be S2_TTBR_N142. In this case, when switching domains, the root domain code may update the contents of S1_TTBR_N132 or S2_TTBR_N142 to change which address translation structure is referenced depending on the domain being entered.

[0110] Also, in some cases, some implementations may provide a second Realm Stage 1 TTBR 138 (S1_TTBR_R2) and / or a second Realm Stage 2 TTBR 148 (S2_TTBR_R2) as an alternative to the second translation table address storage circuit. These registers may provide alternative base addresses to use for Stage 1 or Stage 2 translation for Realm domain accesses to addresses outside the protection address range defined by PAR 130. If S1_TTBR_R2 138 is provided, it may be readable and writable by software operating at EL1 or above in the Realm domain or the Root Domain. If S2_TTBR_R2 148 is provided, it may be readable and writable by software operating at EL2 or above in the Realm domain or the Root Domain.

[0111] 8 illustrates a method for processing address translation for a request issued from a Realm domain. In step 150, the request processing circuit 100 controls the TLB control circuit 102 to perform a lookup in the TLB 18 based on the target VA of the memory access request (and based on the current domain identifier). In step 152, the TLB control circuit 102 determines whether a TLB hit has been identified. A hit is identified if the TLB 18 contains a valid entry corresponding to the specified memory access request and the current domain identifier (although the Realm domain may be permitted to reuse translation table structures associated with a non-secure domain, an access from the Realm domain may be considered to hit a TLB entry tagged with a non-secure domain identifier). If there is no valid entry corresponding to the specified memory access request, a TLB miss occurs.

[0112] If a TLB miss occurs, then in step 156, the page table walk control circuit 104 compares the target VA with the region definition data stored in the PAR register 130 to determine whether the target VA is within a guard address region (PAR).

[0113] If the target VA is outside a PAR, then in step 158, the page table walk control circuitry 104 initiates a page table walk operation using the level 0 base address 121 of the stage 1 page table structure, which is shared with the non-secure domain and obtained from S1_TTBR_N 132. If needed for stage 2 translation, the level 0 base address 121 of the stage 2 page table structure is obtained from S2_TTBR_N 142. Thus, for VAs outside a PAR, the same stage 1 or stage 2 translation data is used as is used for accesses to those VAs by requests made from the non-secure domain. This is particularly useful for the R0 realm 42, as shown in FIG. 2, which represents a carve-out from an application 30 running in the non-secure domain 86. The carved-out realm enclave 42 can allocate its code and secure data to VAs within a PAR, and accesses to data outside the PAR can share the same address translation data used by the non-secure domain 86 to avoid the RMM 46 having to manage synchronization of the realm page tables with the non-secure page tables maintained by the OS 32.

[0114] On the other hand, if step 156 determines that the target VA is within a PAR, then in step 162, page table walk control circuitry 104 initiates a page table walk operation, and the level 0 base address 121 of the stage 1 page table structure is obtained from S1_TTBR_R 134. If a stage 2 translation is required, the stage 2 level 0 base address is obtained from S2_TTBR_R 144. Thus, accesses within a PAR access a different page table structure than those used by the non-secure domain, and as a result, special access permissions may be defined for the secure enclave represented by R0 realm 42 within realm domain 88.

[0115] Thus, in steps 158 and 162, several page table walk requests are issued to memory specifying addresses derived from S1_TTBR_R134, S1_TTBR_N132, S2_TTBR_R144, or S2_TTBR_N142 in combination with the offset bits of the VA / IPA, or to addresses derived from further address pointers stored in page table entries identified by previous page table walk memory accesses. Note that the page table walk memory accesses themselves are subject to PAS filtering checks performed by the PAS filter, as described above. Also, in systems where the TLB includes at least one walk cache TLB structure for caching higher-level entries of page table structures, steps 158 and 162 may not need to perform the full page table walk operations outlined above, as some steps may be skipped if the associated higher-level entry is cached in the walk cache structure.

[0116] Once the stage 1 and / or stage 2 entries necessary to identify the VA to PA mapping have been retrieved from memory, regardless of whether the VA was in a PAR, one or more new TLB entries may be allocated in TLB 18 to cache the retrieved translation data in step 160. As noted above, TLBs can be implemented in several ways, so the exact format of the cached data may vary significantly. When a TLB entry is allocated following a Realm domain access, the new TLB entry may specify a domain identifier tag that indicates the Realm domain, whether it contains information retrieved from a non-secure or Realm page table identified using S1 / S2_TTBR_N (132 or 142) or S1 / S2_TTBR_R (134 or 144). Although the Realm domains share the same non-secure domain page table for accessing addresses outside of the PAR, it may be undesirable for the non-secure domain to hit an entry allocated in the TLB by code operating in the R0 realm 42 because code in the non-secure domain 86 could otherwise use a TLB side channel based on access timing measurements to probe addresses allocated in the TLB by the Realm domain, which could leak information about secure activity in the R0 realm 42.

[0117] Also, in step 160, the VA is converted to PA using the obtained conversion data and returned in the conversion response (or provided along with the PAS selection to the PAS filter 20).

[0118] If a TLB hit is identified in step 152, then in step 164 the target VA is translated to a PA based on cache address translation data previously allocated in the TLB. Thus, the target VA is translated based on translation data previously obtained from one of the first / second translation table structures identified by one of S1_TTBR_R 134 and S1_TTBR_N 132, selected based on whether the target VA is within a PAR (for stage 1), or one of S2_TTBR_R 144 and S2_TTBR_N 142, selected based on whether the target VA is within a PAR (for stage 2). However, because this comparison of the target VA and the PAR would have been performed in step 156 when processing the TLB miss, it does not need to be performed again in step 164. This is because a TLB hit to an entry that provides an address translation mapping may simply read the previously obtained translation data from TLB 18, without needing to check PAR register 130 or TTBRs 132-148 (although a split stage 1 / stage 2 TLB approach may require separate determinations of whether there is a hit in the stage 1 TLB and the stage 2 TLB).

[0119] Figure 9 shows a method for controlling address translation for accesses from the root, secure domain, or non-secure domain. Steps 150 and 152 are the same as those in Figure 8, except that the lookup in the TLB is based on a current domain identifier that specifies the relevant domain: the root, secure domain, or non-secure domain. If a TLB miss is detected, then in step 170, a TTBR to use to identify the level 0 page table for stage 1 or stage 2 is selected based on the current domain. For stage 1 translations in the non-secure domain, S1_TTBR_N 132 is used. For stage 1 translations in the root or secure domain, if a dedicated S1_TTBR 136 for that domain is implemented, that S1_TTBR 136 is used to provide the level 0 base address; if a separate S1_TTBR 136 is not implemented, S1_TTBR_N is used. The L0 base address for stage 2 translation is obtained from S2_TTBR_N142 if the current domain is a non-secure domain, or from S2_TTBR_S146 if the current domain is a secure domain (alternatively, if the secure domain-only S2_TTBR_S146 is not implemented, the secure access can use the S2_TTBR_N142 register to obtain the level 0 base address for stage 2 translation). The root domain does not require stage 2 translation.

[0120] In step 172, a page table walk operation is performed based on the level 0 base address obtained from the selected S1_TTBR to obtain stage 1 address translation data. If stage 2 translation is required, the stage 2 address translation data is obtained based on an access to an address derived via a stage 2 L0 base address obtained from one of S2_TTBR_N 142 and S2_TTBR_S 146.

[0121] In step 174, similar to step 160 of FIG. 8, the retrieved translation data is cached in a TLB tagged with the current domain identifier, and the VA is translated to a PA using the retrieved translation data.

[0122] On the other hand, if a TLB hit is identified in step 152, then in step 176, the VA is translated based on the cache address translation data read from TLB 18, similar to step 162 of FIG. 8, but this time the cache address translation data was previously obtained from the selected translation table structure independent of the comparison between the VA and the PAR defined by PAR register 130.

[0123] Figure 10 shows how translations are handled from the normal (non-secure) domain 86 and the realm domain 88. For non-secure domain accesses, the TTBR used to point to the level 0 page table is S1_TTBR_N 132 for stage 1 and S2_TTBR_N 142 for stage 2 (for simplicity, Figure 10 shows only a single translation stage, which can be either stage 1 or stage 2).

[0124] For realm domain accesses, if the VA is within PAR 180, S1_TTBR_R 134 provides the level 0 page table base address for stage 1, and S2_TTBR_R 144 provides the level 0 page table base address for stage 2. If the VA is outside PAR 180, S1_TTBR_N 132 is used to provide the L0 base address for stage 1, and S2_TTBR_N 142 provides the level 0 page table base address for stage 2, which points to the same L0 stage 1 or stage 2 page table 182 used by normal world 86. This helps implement the EL0 realm 42 shown in FIG. 2, allowing the EL0 region (R0) 42 to transparently share the non-secure address space of the enclosing application 30 in the non-secure domain with reduced software input.

[0125] That is, a typical EL0 application 30 may have a virtual address space provided by its operating system 32, e.g., 1 GB in size, beginning at address 0. An EL0 realm 42 may be defined as having a protected address range (PAR) 180 that is a subset of the application's virtual address space, e.g., 128 MB, e.g., 512 MB in size, beginning at a selected offset address. Memory within realm PAR 180 should not be accessible to other parts of the EL0 application 30 (or other agents). In the case of R0 realm 42, its private memory resides within protected address range 180 and shares data with the rest of the application 30 by having direct read / write access to non-PAR application virtual memory outside of PAR 180.

[0126] For example, it is possible to implement PAR carving using existing virtual memory techniques and MMUs, using shadow page tables where a realm maintains a separate page table structure into which it copies the page table structure of the non-secure domain. However, this requires good coordination between the controlling parties (e.g., synchronizing page table updates and TLB invalidations, which may require trapping or paravirtualization of these operations). These measures may have performance impacts on unrelated code. Also, copying page table structures wastes memory storage capacity. Furthermore, in a hostile environment (where there is no trust between the entities, as described above), this cooperation between entities cannot be relied upon. Realm security guarantees (confidentiality and integrity) cannot depend on the goodwill of the other parties.

[0127] These issues can be addressed using the “PAR Overlay” technique shown in FIG. 10 , which provides a mechanism for implementing the PAR region 180 with separate address translation data while reusing existing page table structures for accesses outside the PAR region 180. Thus, the non-secure page tables are shared with the Realm domain, which has access to (at least) two TTBRs: TTBR_R 134, 144, which points to the Realm “overlay” page table structures, and TTBR_N 132, 142, which is shared with the non-secure domain and points to the “underlay” page table structures. This approach means that Realm code cannot access physical addresses mapped by the non-secure page tables to virtual addresses within the range corresponding to the PAR region 180, but non-secure code can access these physical addresses. To maintain security, when accessing a virtual address in response to a parameter passed by non-secure code, it may be desirable for the Realm code to check whether the address is within the PAR region 180 before triggering a memory access conditional on an address outside the PAR region. Otherwise, Realm code, under the control of parameters passed from non-secure code, may be fooled into accessing its own internal data in physical addresses mapped by the Realm page tables to the PAR region 180, which could be a security risk. For example, Realm code may be asked to walk data structures mapped by the non-secure page tables to the underlay range of the PAR region, but when those virtual addresses are accessed within the Realm domain, the Realm code will access physical addresses that store sensitive information that should be protected from access by the non-secure domain, which can be prevented by first sanitizing the address. This sanitized address check may not be performed by any architectural feature of the processor (a check that is recommended to be performed by software for security purposes, but is not implemented as a hardware feature of the processor).

[0128] Alternatively, instead of reusing the same physical register TTBR_N 132 to provide a base address for Realm domain "underlay" accesses outside of PAR 180, a second Realm domain TTBR 138, 148 (S1_TTBR_R2 or S2_TTBR_R2) is provided that can be used by the Realm domain when the VA is outside of PAR 180. In this case, there is more flexibility because the address stored in S1 / S2_TTBR_R2 138, 148 can be updated to match the address stored in S1 / S2_TTBR_N 132, 142, or to specify a different address when a different page table structure is accessed by EL0 Realm (R0) 42.

[0129] 11 illustrates a method for handling exceptions that occur in the realm domain 86. In step 200, an exception is retrieved from the realm domain. The exception is associated with a given VA. For example, the exception may be an address fault, which is signaled when an attempt to perform address translation for an instruction fetch, data access, or page table walk access is found to have no address translation mapping defined in the page table structure for that VA, or the access permissions prohibit the requested memory access. An exception may also be caused by the PAS filter 20 denying a memory access.

[0130] In step 202, it is determined whether a given VA is in a PAR 180 defined by PAR register 130. If so, in step 204, a first exception handling action is performed, e.g., the exception is handled in the Realm domain 88, and the syndrome information is set to indicate that the VA was in PAR 180. If the given VA is outside PAR 180, in step 206, a second exception handling action is performed, e.g., the exception is handled in the Realm domain, and the syndrome information is set to indicate that the VA was outside PAR 180. An exception handler executing in the Realm domain in response to the exception can then use the syndrome information to determine how to handle the exception. If the VA was within PAR 180, the exception handler itself can address the cause of the fault. If the VA was outside PAR 180, the exception handler can transfer the exception to the non-secure domain, and the non-secure exception handler can address the cause of the fault. This is useful when a fault is associated with translation data defined by code in the non-secure domain due to the realm domain sharing the page table structure of the non-secure domain, in which case the exception can be better handled by an exception handler associated with the OS 32 or hypervisor 34 in the non-secure domain.

[0131] An alternative approach may be that the first exception handling action in step 204 may include exception handling in the Realm domain, while the second exception handling action in step 206 may include exception handling in the non-secure domain. In this case, the exception handling circuitry may cause the exception to be taken directly in the Realm domain or the non-secure domain, depending on whether the VA was in a PAR or not.

[0132] However, if, at the time of exception handling, state stored in registers 12 is potentially sensitive and should be protected from access by the non-secure domain, it may be preferable to use the approach shown in Figure 11, in which any exception that occurs in the Realm domain is first captured in the Realm domain before the Realm software exception handler can choose to forward it to the non-secure domain if necessary. This allows the Realm software exception handler to save to memory the subset of register state 12 that should be protected from non-secure access and to initiate a state save operation to overwrite the contents of those registers 12 before forwarding the exception to the non-secure domain.

[0133] 12 illustrates a method for processing a TLB invalidate command issued when the processing circuitry is within the non-secure domain 86. In step 210, a TLB invalidate command is issued. The TLB invalidate command causes the TLB 18 to search for valid entries that satisfy the invalidation criteria specified by the TLB invalidate command (e.g., these criteria may specify the VA or VA range for which the invalidation should be performed). When the TLB invalidate command is issued from the non-secure domain, in step 212, the TLB invalidates cache entries that satisfy the invalidation criteria(s) and specify a domain identifier tag that indicates either the non-secure domain or the realm domain. In contrast, in the case of a TLB invalidation issued from one of the root domain, the secure domain, or the realm domain, the TLB invalidate command may cause TLB entries whose domain identifier tag specifies that particular domain but not another domain. Because the Realm domain may have entries cached in TLB 18 that provide information derived from the page tables of the non-secure domain, when those non-secure page tables are updated, stale data from such page tables should be flushed from TLB 18 even if it was allocated by the Realm domain, so it is useful for TLB invalidation to cause invalidation of Realm domain TLB entries as well as non-secure domain TLB entries.

[0134] As mentioned above, the use of two separate TTBRs 132, 134 can be useful for an EL0 realm 42 that represents a secure enclave within an EL0 application 30 running in a non-secure domain 86. However, as shown in FIG. 2, a realm domain 88 can also support an encapsulated EL0 / EL1 realm 44 (e.g., realm R1 shown in FIG. 2) that executes both application-level code at EL0 and a corresponding operating system at EL1 within the realm domain. For such an EL0 / EL1 realm 44, there is no need to use the PAR register 130 and the TTBR_N register 132 because a single L0 base address can be used for the entire virtual address space accessed by the EL0 / EL1 region. Therefore, for such a combined EL0 / EL1 realm 44, there is no need to compare the VA to the PAR-defined data to determine which TTBR to use for the page table walk.

[0135] Therefore, it is not mandatory that all Realm Domain accesses use the region "overlay" technique shown above. In some cases, some configuration information specified in a control register can specify whether Realm Domain accesses should use a single TTBR to obtain the L0 base address for the stage 1 page table walk, regardless of whether the VA is in the PAR or not, or whether to select a TTBR based on a comparison of the VA and the PAR.

[0136] Figure 13 summarizes the operation of the address translation circuit 16 and PAS filter. PAS filtering 20 can be considered an additional stage 3 check performed after the stage 1 (and optionally stage 2) address translation performed by the address translation circuit. The stage 1 translation provides PAS selection information "NS" (based on the leaf entry accessed in the stage 1 page table structure selected based on the TTBR as described above), which controls whether accesses from the realm or secure domain access the PAS associated with that domain or the non-secure PAS. Regardless of the PAS selection, accesses from the non-secure domain access the non-secure PAS. For accesses from the root domain in EL3, the stage 1 page table entry provides two bits of address-based selection information (labeled NS, NSE) that together encode which of the four PASs shown in Figure 4 should be selected for a given root domain memory access. The PAS filter 20 performs a granular protection check based on the selected PAS, the current "security state" (i.e., the domain ID that identifies the current domain), and the information in the Granular Protection Table (GPT) described above to determine whether the access should proceed.

[0137] FIG. 14 illustrates a simulator implementation that may be used. While the above embodiments implement the present invention in terms of apparatus and methods for operating specific processing hardware supporting the technology, it is also possible to provide an instruction execution environment according to the embodiments described herein implemented using a computer program. Such computer programs are often referred to as simulators, insofar as they provide a software-based implementation of a hardware architecture. Various simulator computer programs include emulators, virtual machines, models, and binary translators, including dynamic binary translators. Typically, simulator implementations may run on a host processor 430, optionally running a host operating system 420 that supports the simulator program 410. In some configurations, there may be multiple layers of simulation between the hardware and the provided instruction execution environment, and / or there may be multiple different instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations that run at reasonable speeds, but such an approach may be justified in certain situations, such as when it is desirable to execute code native to another processor for compatibility or reuse reasons. For example, a simulator implementation may provide an instruction execution environment with additional features not supported by the host processor hardware, or may provide an instruction execution environment typically associated with a different hardware architecture. An overview of simulation is given in "Some Efficient Architecture Simulation Techniques," Robert Bedichek, Winter 1990 USENIX Conference, pp. 53-63.

[0138] While embodiments have been described above with reference to particular hardware configurations or features, equivalent functionality may be provided in the simulated embodiments through appropriate software configurations or features. For example, particular circuits may be implemented as computer program logic in the simulated embodiments. Similarly, memory hardware such as registers or caches may be implemented as software data structures in the simulated embodiments. In configurations where one or more of the hardware elements referenced in the foregoing embodiments reside in host hardware (e.g., host processor 430), some simulated embodiments may use the host hardware where appropriate.

[0139] Simulator program 410 may be stored on a computer-readable storage medium (which may be a non-transitory medium) and provides a program interface (an instruction execution environment) for target code 400 (which may include applications, an operating system, and a hypervisor), which is the same as the interface of the hardware architecture modeled by simulator program 410. Thus, program instructions of target code 400 may be executed from within the instruction execution environment using simulator program 410, so that a host computer 430 that does not actually have the hardware features of device 2 described above can emulate these features. This may be useful, for example, to enable testing of target code 400 being developed for a new version of a processor architecture before hardware devices that actually support that architecture are available, since the target code can be tested by running it within a simulator that runs on a host device that does not support the new version of the processor architecture.

[0140] The simulator code emulates the behavior of processing circuit 10, including, for example, instruction decode program logic that decodes instructions in target code 400, maps the instructions to a sequence of corresponding instructions in a native instruction set supported by host hardware 430, and includes processor program logic 412 that performs functions equivalent to the decoded instructions. Processor program logic 412 also simulates the processing of code at different exception levels and domains, as described above. Register emulation program logic 413 (an example of state emulation logic) maintains data structures in the host address space of the host processor that emulate architectural register state defined according to the target instruction set architecture associated with target code 400. Thus, rather than such architectural state being stored in hardware registers 12 as in the embodiment of FIG. 1 , it is instead stored in the memory of host processor 430, and register emulation program logic 413 maps register references in instructions in target code 400 to corresponding addresses for retrieving simulated architectural state data from host memory. This architecture state may include the current domain indication 14 and current exception level indication 15 previously described, as well as various translation table addresses corresponding to TTBRs 132-148 and region definition data corresponding to PAR registers 130 as previously described.

[0141] The simulation code includes address translation program logic 414 and filtering program logic 416 that emulate the functions of the address translation circuit 16 and PAS filter 20, respectively, by referencing the same page table structure and GPT 56 as described above. Thus, the address translation program logic 414 translates virtual addresses specified by the target code 400 into simulated physical addresses (pointing to physical locations in memory from the perspective of the target code) in one of the PASs, but these simulated physical addresses are actually mapped onto the (virtual) address space of the host processor by the address space mapping program logic 415. Similar to the PAS filter described above, the filtering program logic 416 performs a lookup of granule protection information to determine whether a memory access triggered by the target code is allowed to proceed. As described above, the address translation program logic 414 selects a TTBR 132, 134, 142, 144 to use for a realm domain access based on whether the target VA to be translated is within a PAR.

[0142] In this application, the term "configured to..." is used to mean that elements of an apparatus have a configuration that is capable of performing a defined operation. In this context, "configuration" refers to a way of arranging or interconnecting hardware or software. For example, an apparatus may have dedicated hardware that provides the defined operation, or a processor or other processing device may be programmed to perform the function. "Configured to" does not imply that the apparatus elements need to be modified in any way to provide the defined operation.

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

Claims

1. 1. An apparatus comprising: an address translation circuit that translates a target virtual address designated by a memory access request into a target physical address; a first conversion table address storage circuit for storing a first conversion table address; a second conversion table address storage circuit for storing a second conversion table address; a protection area definition data storage circuit for storing area definition data that specifies at least one protection area in a virtual address space; Equipped with In response to the memory access request, the address translation circuit translating the target virtual address based on address translation data from a first translation table structure identified by the first translation table address stored in the first translation table address storage circuit in response to the target virtual address being within the at least one protected region of a virtual address space; translating the target virtual address based on address translation data from a second translation table structure identified by the second translation table address stored in the second translation table address storage circuit in response to the target virtual address being outside the at least one protected region of a virtual address space. The apparatus is configured to:

2. at least one translation lookaside buffer for caching information derived from address translation data from one or more translation table structures; Equipped with In response to a memory access request that misses in the at least one translation lookaside buffer, the address translation circuitry: determining whether the target virtual address of the memory access request is within the at least one protection region of the virtual address space specified by the region definition data; The page table walk operation is the first translation table address stored in the first translation table address storage circuit when the target virtual address is within the at least one protection region; and the second translation table address stored in the second translation table address storage circuit when the target virtual address is outside the at least one protection region.

3. processing circuitry for performing data processing in one of a plurality of operational domains; 3. The apparatus of claim 1, wherein when the processing circuitry is in a first domain, the address translation circuitry is configured to translate the target virtual address using address translation data from one of the first translation table structure and the second translation table structure depending on whether the target virtual address is within the at least one protection region.

4. 4. The apparatus of claim 3, wherein when the processing circuitry is in the second domain, the address translation circuitry is configured to translate the target virtual address based on address translation data from a translation table structure identified by a translation table address obtained from a selected storage location independent of a determination of whether the target virtual address is within or outside the at least one protection region.

5. 5. The apparatus of claim 4, wherein when the processing circuitry is in the second domain, the address translation circuitry is configured to obtain the translation table address from the second translation table address storage circuitry.

6. a further translation table address storage circuit for storing further translation table addresses; Equipped with 5. The apparatus of claim 4, wherein when the processing circuitry is in the second domain, the address translation circuitry is configured to obtain the translation table address from the further translation table address storage circuitry.

7. Exception handling circuitry for controlling the handling of exceptions Equipped with For at least one type of exception occurring for processing in the first domain, in response to the at least one type of exception associated with a given virtual address, the exception handling circuitry: performing a first exception handling action if the given virtual address is within the at least one protection region; performing a second exception handling action different from the first exception handling action if the given virtual address is outside the at least one protection region; 7. The device according to claim 3, wherein the device is configured to:

8. the first exception handling action includes setting syndrome information indicating that the exception is associated with a virtual address within the at least one protection domain; 8. The apparatus of claim 7, wherein the second exception handling action comprises setting the syndrome information to indicate that the exception is associated with a virtual address outside the at least one protection domain.

9. the first exception handling action includes triggering handling of the exception in the first domain; The apparatus of claim 7 , wherein the second exception handling action includes triggering handling of the exception in a second domain.

10. at least one translation lookaside buffer including buffer entries for caching information derived from address translation data from one or more translation table structures, each buffer entry associated with a domain identifier that identifies a corresponding one of the plurality of domains; In response to a translation invalidation command issued while the processing circuitry is in the second domain, the at least one translation lookaside buffer: invalidating buffer entries where at least one invalidation criterion specified by the translation invalidation command is met and the domain identifier identifies the first domain; invalidating a buffer entry where the at least one invalidation criterion is met and the domain identifier identifies the second domain; 10. The device according to claim 3, wherein the device is configured to:

11. 11. The apparatus of claim 3, wherein the address translation circuitry is configured to translate the target virtual address to the target physical address in one of a plurality of physical address spaces selected based on at least a current domain of the processing circuitry.

12. the plurality of physical address spaces include at least a first physical address space associated with the first domain and a second physical address space associated with a second domain; the first physical address space is accessible from the first domain and inaccessible from the second domain; The apparatus of claim 11 , wherein the second physical address space is accessible from both the first domain and the second domain.

13. the plurality of physical address spaces also includes a third physical address space associated with a third domain; The apparatus of claim 12 , wherein the third physical address space is accessible from the third domain and is inaccessible from the first domain and the second domain.

14. 14. The apparatus of claim 13, wherein when the processing circuitry is in the third domain, the address translation circuitry is configured to translate the target virtual address based on address translation data from a translation table structure identified by a translation table address obtained from a selected storage location independent of a determination of whether the target virtual address is within or outside the at least one protection region.

15. a third conversion table address storage circuit for storing a third conversion table address; 15. The apparatus of claim 14, wherein when the processing circuitry is in the third domain, the address translation circuitry is configured to obtain the translation table address from the third translation table address storage circuitry.

16. 16. The apparatus of claim 1, wherein for a given protection area of ​​the at least one protection area, the area definition data specifies a base address of the given protection area and a size of the given protection area.

17. the address translation circuitry is configured to perform two-stage address translation based on a first stage translation table structure specifying a mapping from the target virtual address to a target intermediate address and a second stage translation table structure specifying a mapping from the target intermediate address to the target physical address; the address translation circuit is configured to obtain a first stage translation table address identifying the first stage translation table structure from one of the first translation table address storage circuit and the second translation table address storage circuit, the first stage translation table address identifying the first stage translation table structure being selected based on a determination of whether the target virtual address is within or outside the at least one protection region; 17. The apparatus of claim 1, wherein the address translation circuitry is configured to obtain a second stage translation table address identifying the second stage translation table structure from one of a first second stage translation table address storage circuit and a second second stage translation table address storage circuit selected based on a determination of whether the target virtual address is within or outside the at least one protection region.

18. 1. A method comprising: In response to a memory access request specifying a target virtual address, translating the target virtual address based on address translation data from a first translation table structure identified by a first translation table address stored in a first translation table address storage circuit in response to the target virtual address being within at least one protection region of a virtual address space specified by region definition data stored in a protection region definition data storage circuit; translating the target virtual address based on address translation data from a second translation table structure identified by a second translation table address stored in a second translation table address storage circuit in response to the target virtual address being outside the at least one protected region of virtual address space; A method comprising:

19. 1. A computer program for controlling a host data processing apparatus to provide an instruction execution environment for executing target code, comprising: The computer program is address translation program logic that translates a target virtual address specified by a memory access request into a target physical address; state emulation logic for maintaining state information emulating an architectural state of a target instruction set architecture associated with the target code, the state information comprising: a first translation table address; a second translation table address; region definition data specifying at least one protection region of the simulated virtual address space; the state-emulating logic specifying Equipped with In response to a memory access instruction of the target code, the address translation program logic: translating the target virtual address based on address translation data from a first translation table structure identified by the first translation table address in response to the target virtual address being within the at least one protected region of a simulated virtual address space; translating the target virtual address based on address translation data from a second translation table structure identified by the second translation table address in response to the target virtual address being outside the at least one protected region of a simulated virtual address space. A computer program configured to:

20. 20. A computer-readable storage medium storing the computer program of claim 19.

Images