Apparatus and method for using multiple physical address spaces

Abstract

The processing circuit (10) performs processing in one of at least three regions (82, 84, 86, 88). The address translation circuit (16) translates a virtual address of a memory access performed from a current region into a physical address in one of a plurality of physical address spaces (61) selected based on at least the current region. The regions include a root region (82) for managing switching between the regions. The physical address space (61) includes a root physical address space associated with the root region (82) that is separate from the physical address spaces associated with the other regions.

Description

[Technical Field]

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

[0002] The data processing system may have address translation circuitry for translating a virtual address of a memory access request into a physical address corresponding to the location being accessed within the memory system.

[0003] At least some examples provide an apparatus comprising: processing circuitry for performing processing in one of at least three regions; and address translation circuitry for translating a virtual address of a memory access performed from a current region into a physical address in one of a plurality of physical address spaces selected based on at least the current region, wherein the at least three regions include a root region for managing switching between a plurality of other regions of the at least three regions, and the plurality of physical address spaces includes a root physical address space associated with the root region that is separate from physical address spaces associated with the plurality of other regions.

[0004] At least some examples provide a data processing method that includes performing processing in one of at least three regions and translating a virtual address of a memory access performed from the current region into a physical address in one of a plurality of physical address spaces selected based on at least the current region, wherein the at least three regions include a root region for managing switching between a plurality of other regions of the at least three regions, and the plurality of physical address spaces includes a root physical address space associated with the root region that is separate from physical address spaces associated with the plurality of other regions.

[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: processing program logic for simulating processing of the target code in one of at least three regions; and address translation program logic for translating a virtual address of a memory access performed from a current region into a physical address in one of a plurality of simulated physical address spaces selected based on at least the current region, the at least three regions including a root region for managing switching between a plurality of other regions of the at least three regions, and the plurality of simulated physical address spaces including a simulated root physical address space associated with the root region that is separate from simulated physical address spaces associated with the plurality of other regions.

[0006] At least some examples provide a computer-readable storage medium that stores the above-mentioned computer program. The computer-readable storage medium may be a non-transitory storage medium or a 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] FIG. 1 is a diagram illustrating an example of a data processing system. [Figure 2] FIG. 2 illustrates some areas in which a processing circuit may operate. [Figure 3] FIG. 1 illustrates an example processing system that supports granule protection lookup. [Figure 4] FIG. 1 is a diagram illustrating the aliasing of several physical address spaces onto a system physical address space that identifies locations within a memory system. [Figure 5]FIG. 1 illustrates an example of partitioning the effective hardware physical address space whereby different architectural physical address spaces have access to respective portions of the system physical address space. [Figure 6] FIG. 1 is a flow diagram illustrating a method for determining a current operating region of a processing circuit. [Figure 7] FIG. 2 illustrates an example page table entry format for a page table entry used to translate a virtual address to a physical address. [Figure 8] FIG. 1 is a flow diagram illustrating a method for selecting a physical address space to be accessed by a given memory access request. [Figure 9] FIG. 2 illustrates an example of an entry in a granule protection table for providing granule protection information indicating which physical address spaces can access a given physical address. [Figure 10] FIG. 10 is a flow diagram illustrating a method for performing a granule protection lookup. [Figure 11] FIG. 1 illustrates several stages of address translation and granule protection information filtering. [Figure 12] FIG. 10 is a flow diagram illustrating processing of a cache invalidation instruction. [Figure 13] FIG. 10 is a flow diagram illustrating processing of a cache invalidation instruction up to a PoPA (Physical Point of Aliasing). [Figure 14] FIG. 1 illustrates an example of a data processing system. [Figure 15] FIG. 1 illustrates an example of a simulator that may be used.

[0008] Controlling access to physical address space A data processing system may support the use of virtual memory, and address translation circuitry is provided to translate a virtual address specified by a memory access request into a physical address associated with a location in the memory system being accessed. The mapping between the virtual address and the physical address may be defined in one or more page table structures. Page table entries in the page table structures may also define certain access permission information that may control whether a given software process executing on the processing circuitry can access a particular virtual address.

[0009] In some processing systems, all virtual addresses may be mapped by address translation circuitry onto a single physical address space that is used by the memory system to identify locations in memory to be accessed. In such systems, control over whether a particular software process can access a particular address is provided solely based on a page table structure used to provide the virtual-to-physical 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 can result in an information leak that may allow an attacker to access sensitive information.

[0010] Thus, in some systems where certain processes need to be executed securely in isolation from other processes, the system may support operation in several regions, and several separate physical address spaces may be supported, and for at least some components of the memory system, memory access requests where a virtual address is translated to a physical address in a different physical address space are treated as if they were accessing entirely different addresses in memory, even if the physical addresses in the respective physical address spaces actually correspond to the same location in memory. Isolating accesses to the separate physical address spaces from different operating regions of the processing circuitry, as is the case for some memory system components, can provide stronger security guarantees that are not dependent on page table permission information set by an operating system or hypervisor.

[0011] The processing circuitry may support processing within the root region involved in managing switching between other regions in which the processing circuitry may operate. Providing a dedicated root region for controlling switching may help maintain security by limiting the extent to which code executing in one region can trigger a switch to another region. For example, the root region may perform various security checks when a region switch is requested.

[0012] Thus, the processing circuitry may support processing being performed in one of at least three regions: a root region and at least two other regions. The address translation circuitry may translate a virtual address of a memory access performed from the current region to a physical address in one of a plurality of physical address spaces selected based on at least the current region.

[0013] In the embodiment described below, the multiple physical address spaces include a root physical address space associated with the root region, separate from the physical address spaces associated with the other regions. Thus, the root region has its own physical address space allocated to it, rather than using one of the physical address spaces associated with one of the other regions. Providing a dedicated root physical address space isolated from the physical address spaces associated with the other regions can provide stronger security guarantees for the data or code associated with the root region, which may be considered paramount to security when considering managing entry to the other regions. Providing a dedicated root physical address space distinct from the physical address spaces of the other regions can also simplify system development because the allocation of physical addresses within each physical address space can be simplified to specific units of hardware memory storage. For example, by identifying a separate root physical address space, it may be simpler to preferentially store data or program code associated with the root region in protected on-chip memory rather than less secure off-chip memory, and the overhead of determining the portion associated with the root region is less than if the root region's code or data were stored in a common address space shared with another region.

[0014] The root physical address space may be exclusively accessible from the root region. Thus, if the processing circuitry is operating in one of the other regions, the processing circuitry may not be able to access the root physical address space. This improves security by ensuring that code running in one of the other regions cannot tamper with data or program code that the root region relies on to manage switching between regions or to control the rights that the processing circuitry has in one of the other regions.

[0015] On the other hand, a root region may have access to all of multiple physical address spaces. Because code running in a root region must be trusted by any party that provides code running in one of the other regions, and the code in the root region is responsible for switching to the particular region in which that party's code is running, the root region essentially may be trusted to access any physical address space. Having access to all of the physical address space from the root region allows functions such as transitioning memory areas in and out of a region, copying code and data into a region, for example during boot, and providing services to that region.

[0016] The address translation circuitry may restrict which physical address spaces are accessible depending on the current region. If a particular physical address space is accessible to the current region, this means that the address translation circuitry can translate a virtual address specified for a memory access originating from the current region into a physical address within that particular physical address space. This does not necessarily mean that the memory access is permitted, because even if a particular memory access translates its virtual address into a physical address in a particular physical address space, there may be further checks performed to determine whether the physical address is actually permitted to be accessed within that particular physical address space. This is discussed further below with reference to granule protection information that defines the division of physical addresses among the respective physical address spaces. Nevertheless, restricting which subsets of the physical address space are accessible to the current region can provide stronger security guarantees.

[0017] In some examples, the processing circuit may support two additional regions in addition to the root region. For example, the other regions may include a secure region associated with a secure physical address space and a less secure region associated with a less secure physical address space. The less secure physical address space may be accessible from each of the less secure region, the secure region, and the root region. The secure physical address space may be accessible from the secure region and the root region, but not from the less secure region. The root region may be accessible to the root region, but the less secure region and the secure region may not be accessible to the root region. This therefore allows code executing in the secure region to protect its code or data from access by code operating in the less secure region with stronger security guarantees than if page tables were used as the only security control mechanism. For example, portions of code requiring stronger security may be executed in a secure region managed by a trusted operating system that is separate from a non-secure operating system running in the less secure region. An example of a system that supports such secure and less secure domains may be a processing system that operates according to a processing architecture that supports the TrustZone® architecture features provided by Arm® Limited (Cambridge, UK). In conventional TrustZone® implementations, monitor code for managing switching between secure and less secure domains uses the same secure physical address space used by the secure domain. In contrast, as described above, providing a root domain for managing switching between other domains and allocating dedicated root physical address space for use by the root domain helps improve security and simplify system development.

[0018] However, in other examples, the other region may include additional regions, for example, at least three other regions in addition to the root region. These regions may include the secure region and less secure region described above, but may also include at least one additional region associated with an additional physical address space. The less secure physical address space may also be accessible from the additional region, while the additional physical address space may be accessible from the additional region and the root region but not from the less secure region. Thus, like the secure region, the additional region may be considered more secure than the less secure region and may allow further division of code into respective worlds associated with separate physical address spaces and limit their interactions.

[0019] In some examples, each region is associated with a hierarchy of increasing privilege levels as the system ascends from less secure regions, through secure regions and further regions to the root region, where the further regions are considered to have higher privileges than the secure regions and therefore may have access to secure physical address space.

[0020] However, it is increasingly desirable to provide software providers with a secure computing environment that limits their need to trust other software providers in relation to other software running on the same hardware platform. For example, there may be applications in several fields where a provider of software code may be unwilling to trust the provider of the operating system or hypervisor (components that may traditionally be considered trusted), such as mobile payments and banking, implementing anti-cheat or anti-piracy mechanisms in computer games, security extensions for operating system platforms, secure virtual machine hosting in cloud systems, confidential computing, etc. In systems such as those based on the above-mentioned TrustZone® architecture, which support secure and less secure areas with their respective physical address spaces, as secure components operating in the secure area become more and more prevalent, the set of software that typically operates in the secure area expands to include several software that may be provided by a number of different software providers, including, for example, the following parties: The three parties involved in secure domains are: original equipment manufacturers (OEMs) that assemble processing devices (such as mobile phones) from components including silicon integrated circuit chips provided by specific silicon providers; operating system vendors (OSVs) that provide the operating systems that run on the devices; and cloud platform operators (or cloud hosts) that maintain server farms that provide server space to host virtual machines on the cloud. Therefore, implementing domains in a strict order of increasing privileges can be problematic. That is, application providers who provide application-level code may want to be provided with a secure computing environment but may not want to trust the parties (OSVs, OEMs, or cloud hosts) that would traditionally provide the software that runs the secure domains.However, similarly, a party providing code that operates in a secure domain would not want to trust an application provider to provide code that operates in a higher privilege domain that allows access to data associated with a lower privilege domain. It is therefore recognized that a strict hierarchy of domains of successively increasing privilege may not be appropriate.

[0021] Thus, in the more detailed examples below, the further region may be considered orthogonal to the secure region. The further region and the secure region each have access to a less secure physical address space, respectively, but the further physical address space associated with the further region is inaccessible from the secure region, and at the same time, the secure physical address space associated with the secure region is inaccessible from the further region. The root region can still access the physical address spaces associated with both the secure region and the further region.

[0022] Thus, in this model, the further realm (an example of which is the realm realm described in the examples below) and the secure realm do not have dependencies on each other and therefore do not need to trust each other. The secure realm and further realm only need to trust the root realm, which is inherently trusted because it controls entry to other realms.

[0023] While the following example describes a single instance of a further region (a realm region), it will be appreciated that the principle of the further region being orthogonal to the secure region can be extended to provide multiple further regions, such that the secure region and at least two further regions each have access to a less secure physical address space, cannot access the root physical address space, and cannot access each other's associated physical address space.

[0024] The less secure physical address space may be accessible from all regions supported by the processing circuitry. This is useful because it facilitates the sharing of data or program code between software running in different regions. If a particular item of data or code is to be accessible in different regions, it can be allocated in the less secure physical address space so that it can be accessed from any region.

[0025] When translating a virtual address into a physical address, the address translation circuit may perform the translation based on at least one page table entry. If at least the current region is one of a subset of at least three regions supported by the processing circuit, the address translation circuit may select which physical address space should be used as the physical address space into which the physical address should be translated for a given memory access based on the current region and physical address space selection information specified in at least one page table entry used for translating the virtual address into a physical address. Thus, information defined in the page table structure may influence which physical address space is selected for a memory access when a given memory access is issued from the current region. For some regions, this selection based on the physical address space selection information specified in the page table entry may not be necessary. For example, if the current region is the less secure region described above, the less secure physical address space may be selected regardless of any information specified in the at least one page table entry used for address translation because the less secure region is inaccessible from all other address spaces.

[0026] However, for other regions, it is possible that the region can choose between two or more different physical address spaces, and therefore for these regions it may be useful to define in the page table entry information for a given block of addresses that indicates which physical address space should be used for that access, so that different parts of the virtual address space seen by a given piece of software can be mapped onto different physical addresses.

[0027] For example, if the current region is a root region, the address translation circuitry may translate the virtual address to a physical address based on a root region page table entry whose physical address space selection information includes at least two bits of physical address space selection information for selecting among at least three physical address spaces accessible from the root region. For example, in an implementation that supports a root region, a less secure region, and a secure region, the physical address space selection information in the root region page table entry may select among any of these three physical address spaces. In an implementation that also has at least one additional region, the physical address space selection information may select among any of the root physical address space, the secure physical address space, the less secure physical address space, and at least one additional physical address space.

[0028] On the other hand, if the current region is a secure region or a further region, the selection of physical address spaces may be more restricted, and therefore fewer bits of physical address space selection information may be required compared to the root region. For example, in a secure region, the physical address space selection information may select between a secure address space and a less secure address space (because the root physical address space and the further physical address space may be inaccessible). When the current region is a further region, the physical address space selection information may be used to select between the further physical address space and a less secure physical address space (because the secure physical address space and the root physical address space may be inaccessible). For page table entries used to select the physical address space to be used when the current region is a secure region or a further region, the physical address space selection indicator used to make this selection may be encoded in the same position within at least one page table entry, regardless of whether the current region is a secure region or a further region. This makes the encoding of page table entries more efficient, allows hardware interpretation to reuse that portion of the page table entry for both the secure region and the further region, and reduces circuit area.

[0029] The memory system may include a Point of Physical Aliasing (PoPA), which is a point at which aliased physical addresses from different physical address spaces corresponding to the same memory system resource are mapped to a single physical address that uniquely identifies that memory system resource. The memory system may include at least one pre-PoPA memory system component located upstream of the PoPA, which treats the aliased physical addresses as if they correspond to different memory system resources.

[0030] For example, at least one pre-PoPA memory system component may include a cache or translation lookaside buffer, which may cache data, program code, or address translation information for aliased physical addresses in separate entries, such that when the same memory system resource is requested to be accessed from different physical address spaces, the access allocates separate cache or TLB entries. The pre-PoPA memory system component may also include coherency control circuitry, such as a coherent interconnect, snoop filters, or other mechanisms for maintaining coherency between cached information at each master device. The coherency control circuitry may assign separate coherency states to each aliased physical address in the different physical address spaces. Thus, the aliased physical addresses are treated as separate addresses for purposes of maintaining coherency, even when they actually correspond to the same underlying memory system resource. While at first glance, tracking coherency separately for aliased physical addresses might seem like it could cause coherency problems, in reality, this is not a problem if processes operating in different realms are actually intended to share access to a particular memory system resource, because they can access that resource using a less secure physical address (or use the limited sharing feature described below to access the resource using one of the other physical address spaces). Another example of a pre-PoPA memory system component would be a memory protection engine provided to protect data stored in off-chip memory from loss of confidentiality and / or tampering. Such a memory protection engine might, for example, encrypt data associated with a particular memory system resource separately using different encryption keys depending on the physical address space from which the resource is accessed, thereby treating the aliased physical addresses as if they effectively correspond to different memory system resources (e.g., an encryption scheme could be used that makes the encryption address dependent, and a physical address space identifier could be considered part of the address for this purpose).

[0031] Regardless of the form of the pre-PoPA memory system component, it may be useful for such PoPA memory system components to treat aliased physical addresses as if they correspond to different memory system resources, because this provides hardware-enforced isolation between accesses issued to different physical address spaces, so that information associated with one region cannot be leaked to another region due to features such as cache timing side channels or side channels triggered by coherency control circuits and involving coherency changes.

[0032] In some implementations, aliased physical addresses in different physical address spaces may be represented using a different numeric physical address value for each different physical address space. This approach may require a mapping table in PoPA to determine which different physical address values ​​correspond to the same memory system resource. However, this overhead of maintaining a mapping table may be considered unnecessary, and in some implementations it may be simpler if the aliased physical addresses include physical addresses represented using the same numeric physical address value in each of the different physical address spaces. When this approach is taken, it may be sufficient at the physical aliasing point to simply discard the physical address space identifier that identifies which physical address space is accessed using the memory access and then provide the remaining physical address bits downstream as the unaliased physical address.

[0033] Thus, in addition to the pre-PoPA memory system component, the memory system may also include a PoPA memory system component configured to unalias multiple aliased physical addresses to obtain unaliased physical addresses that are provided to at least one downstream memory system component. The PoPA memory system component may be a device that accesses a mapping table to find the unaliased address that corresponds to an aliased address within a particular address space, as described above. However, the PoPA component may simply be a location in the memory system where a physical address tag associated with a given memory access is discarded, so that a physical address provided downstream uniquely identifies the corresponding memory system resource, regardless of which physical address space it is provided from. Alternatively, in some cases, the PoPA memory system component may still provide a physical address space tag to at least one downstream memory system component (e.g., for purposes of enabling completer-side filtering, as discussed further below). However, PoPA marks a point in the memory system beyond which downstream memory system components no longer treat aliased physical addresses as different resources and may map the same memory system resource considering each of the aliased physical addresses. For example, when a memory controller or hardware memory storage device downstream of a PoPA receives the physical address tag and physical address of a given memory access request, if that physical address corresponds to the same physical address as a previously seen transaction, any hazard checking or performance improvement steps performed for each transaction accessing the same physical address (such as merging accesses to the same address) may be applied, even if each transaction specifies a different physical address space tag. In contrast, for memory system components upstream of a PoPA, such hazard checking or performance improvement steps taken for transactions accessing the same physical address may not be invoked if those transactions specify the same physical address in different physical address spaces.

[0034] As mentioned above, the at least one pre-PoPA memory system component may include at least one pre-PoPA cache, which may be a data cache, an instruction cache, or a unified level 2, level 3, or system cache.

[0035] The processing circuit may support up-to-PoPA cache invalidation instructions that specify a target address (which may be a virtual address or a physical address). In response to the up-to-PoPA cache invalidation instruction, the processing circuit may issue at least one invalidation command to request that at least one pre-PoPA cache invalidate one or more entries associated with a target physical address value corresponding to the target address. In contrast, when the at least one invalidation command is issued, at least one post-PoPA cache located downstream of the PoPA may be permitted to hold one or more entries associated with the target physical address value. For the at least one pre-PoPA cache, the cache may invalidate one or more entries associated with the target physical address value specified by the at least one invalidation command, regardless of which physical address space is associated with those entries. Thus, even if physical addresses having the same address value in different physical address spaces are treated by the pre-PoPA cache as if they represent different physical addresses, the physical address space identifier may be ignored for purposes of processing invalidations triggered by the up-to-PoPA cache invalidation instruction.

[0036] Thus, a form of cache invalidation instruction can be defined that enables a processing circuit to request that any cache entries associated with a particular physical address corresponding to a target virtual address be invalidated in any cache up to the physical aliasing point. This form of invalidation instruction can be different from other types of invalidation instructions that may request invalidation of cache entries that affect caches up to other points in the memory system, such as a coherency point (a point at which all observers (e.g., processor cores, direct memory access engines, etc.) are guaranteed to see the same copy of data associated with a given address). Providing a form of instruction dedicated to requesting invalidation up to the physical aliasing point can be useful, particularly for root region code that can manage changes in address allocation for its respective region. For example, when updating granule protection information that defines which physical addresses are accessible within a given physical address space or when reallocating a particular block of physical addresses to a different physical address space, root region code can use a cache invalidation up to PoPA instruction to ensure that any data, code, or other information residing in the cache that depends on the outdated granule protection information for accessibility is invalidated and that subsequent memory accesses are correctly controlled based on the new granule protection information. In some examples, in addition to invalidating a cache entry, at least one pre-PoPA cache may also remove data from that cache entry and write any dirty versions of the data associated with the invalidated entry back to a location in the memory system beyond the PoPA. In some cases, different versions of the up-to-PoPA cache invalidation instruction may be supported to indicate whether removal is required.

[0037] A memory encryption circuit responsive to a memory access request specifying a selected physical address space and a target physical address within the selected physical address space may be provided to encrypt or decrypt data associated with the protected area based on one of several encryption keys selected according to the selected physical address space when the target physical address is within the protected address area. In some examples, the protected address area may be the entire physical address space, while in other examples, encryption / decryption may be applied only to a specific subarea as the protected address area. Allocating a dedicated root physical address space separate from the physical address space associated with other areas simplifies the memory encryption circuit's selection of a different encryption key for the root area compared to other areas to improve security. Similarly, selecting a different encryption key for all other areas allows for stronger isolation of code or data assets associated with a particular area.

[0038] In one particular example, the device may have at least one on-chip memory on the same integrated circuit as the processing circuit, and all valid physical addresses in the root physical address space may be mapped to the at least one on-chip memory so as to be separate from the off-chip memory. This helps improve the security of the root region. It will be appreciated that information from other regions may also be stored in on-chip memory. Providing a separate root physical address space simplifies memory allocation. In an example in which the root region shares a secure physical address space with the secure region, there may be so much data associated with the secure region that it may be difficult to keep it all in on-chip memory, and it may be difficult to determine which specific data is associated with the root region, whereas it is much easier to separate and retrieve the data (or code) of the root region when it is flagged with a separate physical address space identifier.

[0039] Yet, in other instances, some addresses in the root physical address space may be mapped to off-chip memory. Memory encryption, integrity, and freshness mechanisms may be used to protect root region data stored off-chip.

[0040] The above-described techniques can be implemented in a hardware device having hardware circuit logic for implementing the above-described functions. Accordingly, the processing circuit and the address translation circuit may include hardware circuit logic. However, in other examples, a computer program controlling a host data processing device to provide an instruction execution environment for executing target code may be provided with processing program logic and address translation program logic that perform equivalent functions in software to the processing circuit and address translation circuit described above. This may be useful, for example, to enable target code written for a particular instruction set architecture to be executed on a host computer that may not support that instruction set architecture. Accordingly, functionality expected by an instruction set architecture not provided by the host computer may instead be emulated by the simulation software providing an equivalent instruction execution environment for the target code as would be expected if the target code were executed on a hardware device that actually supports the instruction set architecture. Accordingly, the computer program providing the simulation may include processing program logic that simulates processing in one of the at least three regions described above and address translation program logic that translates virtual addresses into physical addresses in one of several simulated physical address spaces selected based on at least the current region. As in a hardware device, the at least three regions may include a root region for managing switching between the other regions, and the root region may have a root simulated physical address space associated with it that is separate from the simulated physical address spaces associated with the other regions. In an approach where simulation of the architecture is provided, the respective physical address spaces selected by the address translation program logic are simulated physical address spaces because they do not actually correspond to physical address spaces identified by hardware components of the host computer, but are mapped to addresses within the host's virtual address space.Providing such a simulation can be useful for a variety of purposes, such as enabling older code written for one instruction set architecture to run on a different platform that supports a different instruction set architecture, or to assist in software development of new software that runs for a new version of an instruction set architecture when hardware devices that support that version are not yet available (thereby allowing development of software for the new version of an architecture to begin in parallel with development of hardware devices that support the new version of the architecture).

[0041] Granule Protection Lookup In systems where the virtual address of a memory access request can be mapped to a physical address in one of two or more separate physical address spaces, granule protection information can be used to restrict which physical addresses are accessible within a particular physical address space. This can be useful to ensure that access to a particular physical memory location, implemented in either on-chip or off-chip hardware, can be restricted to a particular physical address space, or to a particular subset of the physical address space, if desired.

[0042] In one approach to managing such restrictions, an implementation that does not care whether a given physical address is accessible from a particular physical address space may be implemented using completer-side filtering circuitry provided at or near a completer device for processing memory access requests. For example, the completer-side filtering circuitry may be associated with a memory controller or peripheral controller. In such an approach, issuance of memory access requests to a cache or to an interconnect for routing transactions from a requester device to the completer device may not rely on any lookup of information to define which physical addresses are accessible within a given physical address space.

[0043] In contrast, in the embodiment described below, the granule protection lookup is performed by a requester-side filtering circuit that determines whether a memory access request can be passed to a cache or an interconnect based on a lookup of granule protection information indicating at least one permitted physical address space associated with the target granule of the physical address being accessed. The granule of physical address space to which each item of granule protection information is defined may be of a specific size, which may be the same as or different from the size of a page used in the page table structure used in the address translation circuit. In some cases, the granule may be larger in size than the page that defines the address translation mapping of the address translation circuit. Alternatively, the granule protection information may be defined at the same page-level granularity as the address translation information in the page table structure. Defining the granule protection information at the page-level granularity may be convenient because it allows for more fine-grained control over which areas of the memory storage hardware are accessible from a particular physical address space, and therefore from a particular operating region of the processing circuit.

[0044] Thus, the apparatus may include an address translation circuit for translating a target virtual address specified by a memory access request issued by the requester circuit into a target physical address, and a requester-side circuit for performing a granule protection lookup based on the target physical address and a selected physical address space associated with the memory access request, thereby determining whether to allow the memory access request to be passed to a cache or to an interconnect for communication with a completer device for processing. The selected physical address space may be one of a plurality of physical address spaces. In the granule protection lookup, the requester-side filtering circuit may be configured to obtain granule protection information corresponding to a target granule of physical addresses including the target physical address, the granule protection information indicating at least one allowed physical address space associated with the target granule, and to block the memory access request when the granule protection information indicates that the selected physical address space is not one of the at least one allowed physical address spaces.

[0045] An advantage of performing granule protection lookups on the requester side of the interconnect rather than the completer side is that it may allow for finer-grained control over which physical addresses are accessible from a given physical address space than would be practical on the completer side, since the completer side may typically have relatively limited ability to access the entire memory system. For example, a memory controller for a given memory unit may only be able to access locations within that memory unit and may not be able to access other areas of the address space. Providing finer-grained control may rely on more complex tables of granule protection information that may be stored in the memory system, and it may be more practical to access such tables from the requester side, which has more flexibility to issue memory access requests to a wider subset of the memory system.

[0046] Also, performing granule protection lookup on the requester side may be useful to enable the ability to dynamically update granule protection information during runtime, which may not be practical for completer-side filtering circuits that may be limited to accessing a relatively small amount of statically defined data that is defined at startup.

[0047] Another advantage of requester-side filtering circuitry is that it allows the interconnect to distribute different addresses within the same granule to different completer ports that communicate with different completer-side devices (e.g., different DRAM (Dynamic Random Access Memory) units), which is performance efficient but may be impractical if the entire granule needs to be directed to the same completer unit so that granule protection lookups can be performed on the completer side to verify whether the memory access is allowed.

[0048] Thus, there may be many advantages to performing granule protection lookups at the requester side, rather than at the completer side, to determine whether a particular physical address can be accessed from the particular physical address space selected for a given memory access request.

[0049] Granule protection information can be represented in various ways. In one example, granule protection may be defined in a single linearly indexed table stored in a single contiguous address block, with the specific entry to be accessed within the block selected based on the target physical address. However, in practice, granule protection information may not be defined for the entire physical address space, and therefore, it may be more efficient to use a multi-level table structure for storing granule protection information, similar to the multi-level page tables used for address translation. In such a multi-level structure, a portion of the target physical address may be used to select a level 1 granule protection table entry, which may provide a pointer to a location in memory that stores a further level of granule protection table. Another portion of the target physical address may then select which entry of that further granule protection table to retrieve. After sequentially iterating through one or more levels beyond the first level of the table, a granule protection table entry may eventually be retrieved that provides granule protection information associated with the target physical address.

[0050] Regardless of the particular structure selected for the table that stores the granule protection information, the granule protection information can represent in several ways which of the physical address spaces are at least one permitted physical address. One approach may be to provide a series of fields that each indicate whether one of the corresponding physical address spaces has access to the granule of physical addresses that includes the target physical address. For example, a bitmap may be defined within the granule protection information, with each bit in the bitmap indicating whether the corresponding physical address space is a permitted or disallowed physical address space for that granule.

[0051] In practice, however, in most use cases, it may be relatively unlikely that a significant number of physical address spaces are expected to be permitted to access a given physical address. As discussed in the previous section on controlling access to physical address spaces, less secure physical address spaces are available for selection in all regions and can therefore be used when data or code is shared between several regions. As such, it may not be necessary for a particular physical address to be mapped to all or even many portions of the available physical address space.

[0052] Thus, a relatively efficient approach is for the granule protection information to specify an assigned physical address space assigned to a target granule of the physical address, and for the at least one permitted physical address space to include at least the assigned physical address space pointed to by the granule protection information for that particular target granule. In some implementations, the granule protection information may specify a single physical address space as the assigned physical address space. Thus, in some cases, the granule protection information may include an identifier for one particular physical address space that serves as the assigned physical address space that is permitted to access that target granule of the physical address.

[0053] In some implementations, the only physical address space permitted to access a target granule of a physical address may be the assigned physical address space, and the target granule of a physical address may not be permitted to be accessed from any other physical address space. This approach may be efficient for maintaining security. Access to a particular physical address space from different regions may instead be controlled via an address translation function, in which case the granule of a physical address may not need to be shared among multiple physical address spaces because the address translation circuitry may be able to select which particular physical address space should be used for a given memory access. If only the assigned physical address space is permitted to access the target granule of a physical address, it may be necessary to update which physical address space is the assigned physical address space to allow that granule of a physical address to be accessed from other physical address spaces. For example, this may require the aforementioned root region to perform some processing to switch the assigned physical address space for a given granule of a physical address. This processing may have a certain performance cost. This may include, for example, overwriting (for security purposes) each location within a given granule of physical addresses with NULL data or other data unrelated to the previous contents of those physically addressed locations, thereby ensuring that processes accessing newly allocated physical address space cannot learn anything from data previously stored in locations associated with the given granule of physical addresses.

[0054] Therefore, another approach may be that in addition to identifying the assigned physical address space, the granule protection information may also include shared attribute information indicating whether at least one other physical address space other than the assigned physical address space is one of the at least one permitted physical address spaces. Thus, if the shared attribute information indicates that at least one other physical address space has permission to access a corresponding granule of physical addresses, that granule of physical addresses may be accessible from multiple physical address spaces. This may be useful for temporarily allowing code in a region associated with one physical address space to have one of its assigned granules of physical addresses visible to regions associated with a different physical address space. This may make temporary sharing of data or code more efficient, since potentially costly operations need not be instituted to change which physical address space is the assigned physical address space. The shared attribute information may be set directly by code executing in a region associated with the assigned physical address space, or may be set by the root region in response to a request from code executing in a region associated with the assigned physical address space.

[0055] When shared attribute information is supported, in addition to using the shared attribute information to verify whether an address assigned to one physical address space can be accessed by a request specifying a different address space, the requester-side filtering circuitry may also modify the physical address space selected for a memory access request issued to a downstream cache or interconnect based on the shared attribute information. Thus, if the granule protection lookup determines that the selected physical address space is a physical address space other than the assigned physical address space, which is one of the at least one permitted physical address spaces indicated by the shared attribute information, the requester-side filtering circuitry may enable the cache or interconnect to pass the memory access request specifying the assigned physical address space instead of the selected physical address space. This means that, for purposes of accessing downstream memory, pre-PoPA components treat the memory access as if it was originally issued specifying the assigned physical address space, and as a result, cache entries or snoop filter entries tagged with the assigned physical address space may be accessed for the memory access request.

[0056] In some implementations, the requester-side filtering circuitry may retrieve the granule protection information used for the granule protection lookup from memory each time a memory access request is checked against the granule protection information. This approach may require lower hardware costs on the requester side. However, obtaining the granule protection information from memory may be relatively time-consuming.

[0057] Therefore, to improve performance, the requester-side filtering circuit may have access to at least one lookup cache that can cache granule protection information, such that granule protection lookups can be performed within the at least one lookup cache, eliminating the need to fetch the required granule information from memory if it is already stored in the at least one lookup cache. The at least one lookup cache may, in some cases, be a separate cache from a translation lookaside buffer (TLB) used by the address translation circuit to cache page table data that provides mapping between virtual addresses and physical addresses. However, in other examples, the at least one lookup cache may combine caching of page table data with caching of granule protection information. Thus, in some cases, the at least one lookup cache may store at least one combined translation and granule protection entry that specifies information according to both the granule protection information and at least one page table entry used by the address translation circuit to map a target virtual address to a target physical address. Whether the TLB and granule protection cache are implemented as separate structures or as a single combined structure is an implementation choice and either may be used.

[0058] Regardless of which technique is used for the at least one lookup cache, the at least one lookup cache may respond to at least one lookup cache invalidation command. The lookup cache invalidation command may specify an invalidation target physical address to invalidate lookup cache entries that store information dependent on granule protection information associated with a granule of physical addresses that includes the invalidation target physical address. In conventional processing systems with a TLB, the TLB typically supports invalidation commands that specify a virtual address or (in systems that support two-stage address translation, an intermediate address), but it is not typically necessary for the TLB to be able to identify which entries are to be invalidated using a physical address. However, when at least one lookup cache is provided to cache granule protection information, it may be useful to be able to invalidate any entries that depend on the granule protection information for a given granule of physical addresses if that information changes. Thus, the command may identify a specific physical address at which entries containing information dependent on the granule protection information are to be invalidated.

[0059] If the granule protection information cache is implemented separately from the TLB, the TLB may not need the ability to search for entries by physical address. In this case, the granule protection information cache can respond to cache invalidation commands that specify a physical address, but the commands may be ignored by the TLB.

[0060] However, if at least one lookup cache includes a combined translation / granule protection cache, whose entries are searched based on a virtual address or an intermediate address and return both page table information associated with the virtual / intermediate address and granule protection information associated with the corresponding physical address, it may be useful to provide a further scheme for searching entries based on a physical address, whereby at least one lookup cache invalidation command specifying an invalidation target physical address can be processed. Such a search by physical address may not be necessary for a normal lookup of the combined cache, because if the entries are combined, a search by virtual address or a search by intermediate address may be sufficient to access all of the combined information for performing both the address translation lookup and the granule protection lookup. However, because the cache invalidation command relies on the granule protection information for the specified physical address, the combined cache can be searched based on the physical address, thereby identifying any entries that need to be invalidated.

[0061] The memory system may have a PoPA memory system component, at least one pre-PoPA memory system component, and at least one post-PoPA memory system component, as described above for the previous embodiment. Thus, aliased physical addresses in different physical address spaces may correspond to the same memory system resource identified using a non-aliased physical address when a memory access request crosses a physical aliasing point, in the same manner as described above. Pre-PoPA, the at least one pre-PoPA memory system component may treat aliased physical addresses from different physical address spaces as if they correspond to different memory system resources, thereby improving security. Again, while it may theoretically be possible to identify physical addresses in different physical address spaces using different numeric address values, this may be relatively complex to implement and may be simpler if the aliased physical addresses are represented using the same physical address value in the different physical address spaces.

[0062] If the at least one pre-PoPA memory system component includes at least one pre-PoPA cache, the processing circuitry may, in response to a cache invalidation instruction up to the PoPA specifying the target virtual address, trigger invalidation with the target physical address for any pre-PoPA caches upstream of the physical aliasing point, while allowing any post-PoPA caches (as described above) to hold data with the target physical address.

[0063] The selected physical address space associated with the memory access can be selected in various ways. In some examples, the selected physical address space may be selected (by address translation circuitry or requestor-side filtering circuitry) based at least on a current region of operation of the requestor circuitry to which the memory access request was issued. The selection of the selected physical address space may also depend on physical address space selection information specified in at least one page table entry used to translate the target virtual address to a target physical address. The selection of which physical address space is the selected physical address space may be performed as described above for previous embodiments.

[0064] The regions and physical address spaces available for selection within a given system may be as described above and may include less secure regions, secure regions, root regions, and further regions, each with a corresponding physical address space, as described above. Alternatively, the regions / physical address spaces may include subsets of these regions. Thus, any features associated with any of the aforementioned regions may be included in a system having requestor-side filtering circuitry.

[0065] In implementations in which the root region has a corresponding root physical address space as described above, the requester-side filtering circuitry can bypass the granule protection lookup when the current region is the root region. Because the root region can be trusted to access all ranges of physical addresses, the granule protection lookup can be unnecessary when the current region is the root region, and thus power can be saved by skipping the granule protection lookup when in the root region.

[0066] Granule protection information may be modifiable by software running in the root region. Thus, granule protection information may be dynamically updateable during execution. This may be advantageous for some of the discussed Realm use cases, where Realms providing secure execution environments may be dynamically created during execution, and corresponding areas of allocated memory may be reserved for the Realms. Using completer-side filtering alone, such an approach may often be impractical. In some implementations, the root region may be the only region permitted to modify granule protection information; as a result, if another region requires a change to the granule protection information to be implemented, the other region may request that the root region modify the granule protection information, and the root region may then check whether to allow the request made from another region.

[0067] While it may be beneficial to provide requester-side filtering circuitry to perform granule protection lookups at the requester side before a memory access request is passed to a cache or interconnect, there may be other scenarios in which it may be preferable for protection information (defining which physical addresses may be accessed from a given physical address space) to be checked on the completer side of the interconnect instead. For example, in some portions of the address space, it may be desirable to provide fine-grained page-level detail in the memory hardware, dividing it into regions of physical addresses accessible from different physical address spaces, while for other portions of the memory system, it may be preferable to allocate large blocks of contiguous addresses to a single physical address space, in which case the overhead of accessing a (potentially multi-level) granule protection structure stored in memory may not be justified. If an entire memory unit (e.g., a particular DRAM module) is allocated to a single physical address space, it may be simpler to handle enforcement of access restrictions to that memory unit via checks on the completer side.

[0068] Thus, in some implementations, in addition to providing a requestor-side filtering circuit, there may also be a completer-side filtering circuit that responds to memory access requests received from the interconnect that specify a target physical address and a selected physical address space. The completer-side filtering circuit performs a completer-side protection lookup of completer-side protection information based on the target physical address and the selected physical address space to determine whether the memory access request is allowed to be processed by the completer device. Providing a hybrid approach that allows portions of memory to be protected via requestor-side filtering and other portions to be protected by completer-side filtering allows a balance between better performance and flexibility in memory usage allocation than can be achieved through either requestor-side filtering or completer-side filtering alone.

[0069] Thus, in some implementations, the granule protection information may specify a pass-through indicator that indicates that at least one allowed physical address space should be resolved by the completer-side filtering circuitry.

[0070] Thus, if the granule protection information specifies a pass-through indicator, the requester-side filtering circuitry can determine whether to pass the memory access request to a cache or an interconnect independently of any checks as to whether the selected physical address space is one of at least one permitted physical address space of the target granule of the physical address. On the other hand, if the accessed granule protection information for the target granule does not specify a pass-through indicator, the determination of whether the memory access request can be passed to a cache or an interconnect may depend on a check as to whether the selected physical address space is one of at least one permitted physical address space, since in this case, after the memory access request is permitted to proceed to the cache or interconnect, subsequent completer-side filtering may not occur. Thus, the pass-through indicator can enable control over the division of address space between granules of physical addresses for which checks should be performed on the requester side and granules for which these checks should be performed on the completer side, providing additional flexibility to system designers.

[0071] The completer-side protection information used by the completer-side filtering circuit need not have the same format as the granule protection information used by the requester-side filtering circuit. For example, the completer-side filtering circuit may be defined with coarser detail than the granule protection information used for granule protection lookup by the requester-side filtering circuit. The granule protection information may be defined in a multi-level table structure, with each level of the table providing entries corresponding to blocks of memory with a given address number corresponding to a power of two. Thus, an entry at a given level of the table required to check a given target physical address may be indexed by simply adding a subset of certain bits from the target physical address to the base address associated with that level of the table, avoiding the need to compare the contents of the accessed entry with the target physical address to determine whether it is the correct entry. In contrast, the completer-side protection information may define a smaller number of entries, each specifying a starting address and an ending address (or a starting address and size) of an area of ​​memory that may correspond to an address number other than a power of two. While this may be more suitable for defining relatively coarse-grained blocks in the completer-side protection information, this approach may require comparing the target physical address to the upper and lower bounds of each range of physical addresses defined in each completer-side protection information entry to determine whether any of them match the specified physical address. The indexed multi-level table approach used for the requester-side granular protection information can support a relatively large number of separate entries, thereby supporting a fine-grained mapping of physical addresses to the physical address space. This may typically be impractical when utilizing the approach of defining upper and lower bounds for each range in the completer-side protection information due to the comparison overhead of looking up each of these entries to check whether the target address falls within the bounds of that entry.However, completer-side protected information may be more efficient in terms of memory storage and may have a smaller variance in performance because the penalty for a miss in the lookup cache is less. Of course, this is just one example of how lookup information may be implemented on the requestor and completer sides.

[0072] The requestor-side protection information may be dynamically updatable during run-time, and the completer-side protection information may be statically defined by hardware on the system-on-chip and configured at boot time, or dynamically reconfigured during run-time.

[0073] With respect to the foregoing embodiments, the techniques described above for granule protection lookup may be implemented in a system having dedicated hardware logic for performing the functions of the address translation circuitry and requester-side filtering circuitry, although equivalent functionality may also be implemented in software within a computer program to control the host data device and provide an instruction execution environment for execution of the target code for reasons similar to those described above. Accordingly, address translation program logic and filtering program logic may be provided to emulate the functionality of the address translation circuitry and requester-side filters described above. With respect to the foregoing embodiments, at least one of the following may be true for the computer program providing the instruction execution environment: Granule protection information is dynamically updatable by the target code during execution; Granule protection information is defined at page-level granularity;

[0074] 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 an example configuration of one of the requester devices 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.

[0075] 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.

[0076] Processing circuit 10 may be capable of issuing memory access requests that specify a virtual address (VA) that identifies an addressable location to be accessed and a region 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 is 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.

[0077] Based on the translated physical address and the PAS identifier, the PAS filter 20 functions as a requester-side 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 defines information that limits the physical address space within which a given physical address can be accessed, and based on this lookup, the PAS filter 20 determines whether the 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 can block the transaction and signal a failure.

[0078] 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.

[0079] 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.

[0080] 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 entirely separate sets of addresses that identify locations in separate memory systems, 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.

[0081] FIG. 2 shows examples of various operating states and domains in which processing circuitry 10 can operate, as well as examples of the types of software that may run at various 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).

[0082] 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 in this example. 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.

[0083] When an exception occurs at a particular exception level while processing software, for some types of exceptions, the exception is accepted at 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.

[0084] 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 a 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.

[0085] At power-on, 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 powered on, and 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.

[0086] 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.

[0087] 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 partitioning 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 stage 2 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.

[0088] 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 to run processing 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 highly mixed environment of services provided within the secure domain by a wide variety of 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 the devices, and / or cloud platform providers that manage cloud servers that support services for many different customers via the cloud.

[0089] 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). Also, 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 within secure domain 84, the addition of arbitrary user-provided code within the secure domain increases the attack surface for potential attacks against their code. This may be undesirable, and users may therefore be strongly discouraged from allowing code to be added to secure domain 84. On the other hand, users who provide code that requires a secure computing environment may be unwilling to entrust access to their data or code to all of the different code providers running in secure domain 84 if assurances and certifications of the code running in a particular domain are required as a prerequisite for the user-provided code to perform operations.Auditing and verifying all of the separate code provided by different software providers running in secure domain 84 can be difficult and can limit opportunities for third parties to offer more secure services.

[0090] Thus, as shown in FIG. 2, an additional region 88 called a realm region is provided. The realm region may be used by such user-installed code to provide a secure computing environment that is orthogonal to any secure computing environment associated with components operating in the secure region 24. In the realm region, the executing software may include several realms, each of which may be isolated from other realms by a realm management module (RMM) 46 operating at exception level EL2. The RMM 46 may control the isolation between the respective realms 42, 44 executing in the realm region 88 by defining access permissions and address mappings within page table structures, for example, similar to how the hypervisor 34 manages the isolation between various components operating in the non-secure region 86. In this example, the realms include an application-level realm 42 that runs at EL0 and an encapsulated application / operating system realm 44 that runs 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 may be established by the RMM 46.

[0091] 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 do not have access to 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, for example, by 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.

[0092] Thus, as shown by the dotted lines indicating the 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 devices, 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.

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

[0094] 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.

[0095] 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 its 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 dependencies 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 to provide operating system services, while the realm realm 88 is mutually isolated from existing secure software environments in the secure realm 84 while enabling the development of new forms of trusted execution environments that may be dedicated to user or third-party applications.

[0096] FIG. 3 shows a schematic diagram of 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 shows more details of the address translation circuit 16, including a stage 1 memory management unit 50 and a stage 2 memory management unit 52. The 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 the stage 2 MMU 52 being necessary). The stage 2 MMU can translate the intermediate addresses to physical addresses. The 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 the monitor code 29 for translations from EL3. Meanwhile, the stage 2 MMU 52 can be based on page table structures defined by the hypervisor 34, the RMM 46, or the 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.

[0097] 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 is authorized to 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.

[0098] The GMPU 20 allows for the allocation of memory in separate address spaces while simultaneously 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.

[0099] 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 attributes. A system physical address is mapped into a single "logical" physical address space by extending it with a PAS tag.

[0100] 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.

[0101] The world defines the security attributes (PAS tag) 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 PAS tag and (optionally) other granule protection attributes with which it is associated.

[0102] 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 fine-grained memory protection unit (GMPU).

[0103] 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.

[0104] Locating GMPU 20 on the requester side of the system (e.g., on the MMU output) rather than on the completer side allows access permissions to be assigned at the page level while allowing Interconnect 8 to hash / striping pages continuously across multiple DRAM ports.

[0105] Transactions remain tagged with a PAS TAG as they propagate throughout the system fabric 24, 8 until they reach a location defined as a 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 PA from hitting the cache, thereby improving side-channel resistance. The PAS TAG can also be used as a context selector for a protection engine attached to a memory controller that encrypts data before it is written to external DRAM.

[0106] 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.

[0107] 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).

[0108] 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 shared access to a physical granule to a subset of N worlds while preventing other worlds from accessing it. This can be achieved by adding a "limited sharing" semantic to the granule protection information while forcing 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.

[0109] The above example characteristics 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.

[0110] 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.

[0111] 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 the physical address and information derived from the page table entry (PTE) used to select the PAS, which can then be used by the PAS filter or GMPU 20 to select the PAS.

[0112] 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. [Table 1]

[0113] 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.

[0114] 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).

[0115] 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 a pre-PoPA memory system component, 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 an additional address bit 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.

[0116] 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 a system physical address space 64. The unaliased address 65 is provided downstream to any post-PoPA components, 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 at the requester. For example, in a PoPA 60, the PAS identifier may be stripped from the address, so that for downstream components, the address can be identified simply using the physical address value without specifying a PAS. Alternatively, in some cases where some completer-side filtering of memory access requests is desired, the PAS identifier may still be provided downstream of the PoPA 60, but may not be interpreted as part of the address. As a result, the same physical address appearing in different physical address spaces 60 will be interpreted downstream of the PoPA to point to the same memory system location. However, the supplied PAS identifier may still be used to perform completer-side security checks.

[0117] 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.

[0118] However, in some implementations, in addition to allowing 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 the address space as shared with another address space (e.g., an address space associated with a region of lower or orthogonal privilege that would not normally be allowed to select the assigned PAS for access requests in that region). This may facilitate temporary sharing of data without having to change the PAS assigned to a given granule. For example, in Figure 5, area 70 of the realm PAS is defined in the GPT as assigned to the realm region and is normally inaccessible to non-secure region 86 because non-secure region 86 cannot select the realm PAS for its access requests. Because non-secure region 86 does not have access to the realm PAS, non-secure code would normally not be able to see the data in area 70. However, if a realm wants to temporarily share some of the data in its allocated area 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 area 70 is shared with non-secure region 86, thereby making area 70 accessible to the non-secure PAS shown on the left side of Figure 5 without having to change which regions are assigned to area 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 the non-secure PAS, but PAS filter 20 can remap the request's PAS identifier to instead specify the realm PAS, causing downstream memory system components to treat the request as if it had originally issued from the realm region. This sharing may 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.

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

[0120] 7 illustrates example page table entries (PTEs) that can be used by address translation circuitry 16 for page table entries in a page table structure used for virtual-to-physical address mapping, virtual-to-intermediate address mapping, or intermediate-to-physical address mapping (depending on whether the translation is occurring in an operational state that requires a stage 2 translation at all, and if a stage 2 translation is required, whether the translation is stage 1 or stage 2). In general, a given page table structure may be defined as a multi-level table structure implemented as a page table tree where the first level of the page table is identified based on a base address stored in a translation table base address register of the processor, and the index that selects a particular level 1 page table entry in the page table is derived from a subset of bits of the input address against which the translation lookup is performed (the input address may be the virtual address for the stage 1 translation of the intermediate address for the stage 2 translation). The level 1 page table entry may be a “table descriptor” 110 that provides a pointer 112 to the next level page table, from which further page table entries may be selected based on further subsets of bits of the input address. Finally, after one or more lookups into successive levels of page tables, a block or page descriptor PTE 114, 116, 118 can be identified that provides an output address 120 corresponding to the input address. The output address may be an intermediate address (for stage 1 translations performed in operational states where a further stage 2 translation is also performed) or a physical address (for stage 2 translations, or for stage 1 translations when stage 2 is not required).

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

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

[0123] On the other hand, block / page descriptors 114, 116, 118 may include physical address space selection information 126 depending on which region they are associated with. The non-secure block / page descriptor 118 used within the non-secure region 86 does not include any PAS selection information because the non-secure region has access only to the non-secure PAS. However, for other regions, the block / page descriptors 114, 116 include PAS selection information 126 used to select the PAS to translate the input address. For the root region 22, the EL3 page table entry may have PAS selection information 126 including at least two bits to indicate the PAS associated with any of the four regions 82, 84, 86, 88 as the selected PAS to which the corresponding physical address will be translated. In contrast, for the realm and secure regions, the corresponding block / page descriptor 116 need only include one bit of PAS selection information 126, which selects between the realm and non-secure PAS for the realm region and between the secure and non-secure PAS for the secure region. To improve the efficiency of circuit implementation and avoid increasing the size of the page table entry, for realm and secure regions, the block / page descriptor 116 can share the PAS selection information 126 because the PAS selection information 126 can be coded in the same location in the PTE regardless of whether the current region is realm or secure.

[0124] 8 is a flow diagram illustrating a method for selecting a PAS based on information 124, 126 from the current region and block / page PTEs used in generating a physical address for a given memory access request. The PAS selection may be performed by the address translation circuitry 16, or by a combination of the address translation circuitry 16 and the PAS filter 20 if the address translation circuitry sends PAS selection information 126 to the PAS filter 20.

[0125] In step 130 of FIG. 8 , processing circuit 10 issues a memory access request specifying a given virtual address (VA) as the target VA. In step 132, address translation circuit 16 looks up any page table entries (or cache information derived from such page table entries) in its TLB 18. If any necessary page table information is not available, address translation circuit 16 initiates a page table walk to memory to fetch the necessary PTE (potentially requiring a series of memory accesses to step through each level of the page table structure and / or multiple stages of address translation to obtain the mapping from VA to intermediate address (IPA) and from IPA to PA). Any memory access request issued by address translation circuit 16 in a page table walk operation may itself be subject to address translation and PAS filtering. Note that the request received in step 130 may therefore be a memory access request issued to request a page table entry from memory. Once the relevant page table information is identified, the virtual address is translated to a physical address (possibly in two stages via the IPA). In step 134, the address translation circuit 16 or PAS filter 20 determines which region is the current region using the technique shown in FIG.

[0126] If the current region is a non-secure region, then in step 136 the output PAS selected for this memory access request is a non-secure PAS.

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

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

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

[0130] 9 illustrates an example of a GPT 56 entry for a given granule of physical addresses. GPT entry 150 includes assigned PAS identifier 152, which identifies the PAS assigned to the granule of physical addresses, and optionally includes further attributes 154, which may include, for example, the aforementioned shared attribute information 156, which is visible to one or more other PASs other than the PAS to which the granule of physical addresses is assigned. Setting of shared attribute information 156 may be performed by the root region in response to a request from code executing within a region associated with the assigned PAS. The attributes may also include a pass-through indicator field 158, which indicates whether a GPT check (to determine whether the PAS selected for a memory access request has access to the granule of physical addresses) should be performed on the requester side by PAS filter 20 or by completer-side filtering circuitry on the completer device side of the interconnect, as described further below. If pass-through indicator 158 has a first value, requester-side filtering checks may be required in PAS filter 20 on the requester side, and if these fail, the memory access request may be blocked and a failure signaled. However, if pass-through indicator 158 has a second value, requester-side filtering checks based on GPT 56 may not be required for memory access requests that specify a physical address within a granule of physical addresses corresponding to that GPT entry 150; in this case, the memory access request may be passed through to cache 24 or interconnect 8 without regard to checking whether the selected PAS is one of the permitted PASs allowed to access that granule of physical addresses; instead, any such PAS filtering checks are then performed later on the completer side.

[0131] 10 is a flow diagram illustrating the requestor-side PAS filtering checks performed by PAS filter 20 on the requestor side of interconnect 8. In step 170, PAS filter 20 receives a memory access request associated with a physical address and an output PAS that may be selected as shown in FIG.

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

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

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

[0135] 10, these steps may also be performed in parallel or in a different order, if desired. It should also be understood that steps 178 and 180 are not required, and some implementations may not support the use of shared attribute information 156 and / or pass-through indicator 158.

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

[0137] 12 is a flow diagram illustrating the processing of a stage 3 lookup cache invalidation instruction that may be used by monitor code 29 running in the root region 82 to trigger the invalidation of any lookup cache entries that depend on a GPT entry associated with a particular physical address. This may be useful when the root region is changing the allocation of which physical address space a given system PA is assigned to, preventing any lookup cache 22 from holding outdated information.

[0138] Thus, in step 200, processing circuitry 10 within a given processing element (requester device) 4 may execute a stage 3 lookup cache invalidation instruction. The instruction specifies a physical address.

[0139] In step 202, in response to the stage 3 lookup cache invalidation instruction, processing circuit 10 checks whether the current exception level is EL3, and if not, may reject the instruction and / or signal an exception (such as an undefined instruction exception) in step 204. This prevents a malicious party from triggering performance degradation by forcing the invalidation of granule protection information from lookup cache 22 as triggered by other exception levels, by limiting execution of stage 3 lookup cache invalidation instructions to monitor code 29 associated with the root region.

[0140] If the current exception level is EL3, then in step 206, in response to the instruction executed in step 200, the processing element issues at least one lookup cache invalidation command that is sent to any lookup caches 18, 22 that may contain information according to the granule protection table entry associated with the physical address identified by the instruction. These caches may include not only the granule protection information cache 22 as shown in FIG. 1, but also, in some implementations, a combined TLB / granule protection cache that combines information from the page table structure and the GPT into a single entry. For such a combined TLB / GPT cache, the combined cache may require the ability to be looked up by both virtual and physical addresses.

[0141] In step 208, in response to the issued command, the GPT cache 22 or combined TLB / GPT cache invalidates any entries that rely on granule protection information from the GPT entry associated with the granule at the physical address corresponding to the physical address specified by the lookup cache invalidation command.

[0142] Because caches in a memory system may tag entries with an identification of the PAS associated with the cache located before the PoPA, even if the root region code 29 changes which PAS is associated with a particular granule of physical addresses by updating the GPT 56, there may still be data cached in a pre-PoPA cache tagged with the incorrect PAS for that granule of physical addresses. To prevent subsequent accesses issued after the GPT update from hitting cache entries that should no longer be accessible to the region issuing these requests, it may be useful to provide an instruction that ensures that any cache entries associated with a particular physical address are invalidated in any cache before the PoPA 60. This instruction may be different from other types of cache invalidation instructions that may affect caches in different subsets of the memory system, such as caches before a coherency point or caches local to a particular processing element. Thus, the processing circuitry may support a cache invalidation instruction up to the PoPA where invalidation is observed by caches in the system and whose range corresponds to a portion of the memory system upstream of the PoPA. That is, for this instruction, the PoPA is the boundary of the range within which cache invalidation should be observed.

[0143] FIG. 13 is a flow diagram illustrating the processing of a cache invalidation up to PoPA instruction. In step 220, a cache invalidation up to PoPA instruction is executed by processing circuitry 10 of a given requester device 4. The instruction specifies a virtual address, which is mapped to a physical address in step 222. However, in some cases, similar to the instructions shown in FIG. 12, execution of instructions against a cache invalidated up to PoPA may be restricted to execution within EL3. In step 224, the processing element that executed the instruction issues invalidation commands specifying a physical address, and these commands are sent to any pre-PoPA caches 24 in the system. This may include caches upstream of PoPA within the requester device 4, as well as within the interconnect 8 or other requester devices 4 or other memory system components located at points where a separate physical address space 61 is treated as another range of addressed memory locations.

[0144] The cache invalidation instruction to PoPA may, in some cases, be a "delete and invalidate" instruction that not only requests that data associated with the specified PA be invalidated from the pre-PoPA cache, but also that the data be deleted by writing any dirty data back to a location beyond PoPA 60 before the invalidation. Thus, in step 226, if the instruction is a delete and invalidate instruction, the pre-PoPA cache receiving the command triggers a writeback of dirty data from any entries associated with the specified physical address. This data may be written to a cache beyond PoPA or to main memory. If the instruction is not a delete and invalidate instruction, or if delete and invalidate instructions are not supported, step 226 can be omitted, and the method can proceed directly to step 228, which would also be executed if step 226 was executed. In step 228, the pre-PoPA cache receiving the command in step 224 invalidates entries associated with the specified physical address. Cache entries associated with the specified physical address are invalidated regardless of which PAS tags are associated with those entries.

[0145] Therefore, cache invalidation instructions up to PoPA can be used to ensure that after a GPT update, the cache does not continue to tag entries associated with a given physical address with an incorrect PAS identifier.

[0146] FIG. 14 shows a more detailed example of a data processing system in which some of the techniques described above can be implemented. Elements that are the same as in previous embodiments are designated with the same reference numerals. The example of FIG. 14 shows processing element 4 in more detail, in that cache 24 is shown in more detail, including a level 1 instruction cache, a level 1 data cache, a level 2 cache, and optionally a shared level 3 cache 24 shared between processing elements, in addition to processing circuitry 10, address translation circuitry 16, TLB 18, and PAS filter 20. An interrupt controller 300 can control the handling of interrupts by each processing element.

[0147] 14 , processing elements 4 capable of executing program instructions to trigger accesses to memory are not the only type of requesting device that may include a requester-side PAS filter 20. In another example, a system MMU 310 (provided to provide address translation functionality for requesting devices 312, 314 that do not support their own address translation functionality, such as on-chip devices 312, such as network interface controllers or display controllers, or off-chip devices 314 that may communicate with the system via a bus) may include a PAS filter 20 to perform requester-side checks of GPT entries, similar to the PAS filter 20 in a processing element 4. Other requesting devices may include a debug access port 316 and a control processor 318, which may also have PAS filters 20 associated with them to check whether memory accesses issued by requesting devices 316, 318 to a particular physical address space are allowed under the PAS assignments defined in the GPT 56.

[0148] The interconnect 8 is shown in more detail in FIG. 14 as a coherent interconnect 8 and includes, in addition to the routing fabric 320, a snoop filter 322 for managing coherency between the caches 24 in each processing element, and one or more system caches 324 that may perform caching of shared data shared among requesting devices. The snoop filter 322 and system caches 324 may be located upstream of the PoPA 60 and therefore may tag their entries with a PAS identifier selected by the MMU 16, 310 for a particular master. Requesting devices 316, 318 that are not associated with an MMU may be expected, by default, to always issue requests for a particular region, such as the non-secure region (or the root region, if they are trusted).

[0149] FIG. 14 shows a memory protection engine (MPE) 330 provided between the interconnect 8 and a given memory controller 6 for controlling access to off-chip memory 340 as another example of a pre-PoPA component that treats physical address aliasing within each PAS as if they point to different address locations. The MPE 330 can be responsible for encrypting data written to the off-chip memory 340 to maintain confidentiality and decrypting the data when read. The MPE can also prevent tampering with data stored in the off-chip memory by generating integrity metadata when writing data to memory and using the metadata to verify whether the data has changed when read from the off-chip memory. When encrypting data or generating memory integrity hashes, different keys can be used depending on which physical address space is being accessed, even if accessing aliased physical addresses that actually correspond to the same location in the off-chip memory 340. This improves security by further isolating data associated with different operating domains.

[0150] In this example, PoPA 60 is between memory protection engine 330 and memory controller 6, so that when the request reaches memory controller 6, physical addresses are no longer treated as mapping to different physical locations in memory 340 depending on the physical address space in which they are accessed.

[0151] 14 shows another example of a completer device 6, which may be a peripheral bus or non-coherent interconnect used to communicate with peripherals 350 or areas of on-chip memory 360 (e.g., implemented as static random access memory (SRAM)). The peripheral bus or non-coherent interconnect 6 may also be used to communicate with secure elements 370, such as a cryptographic unit that performs cryptographic operations, a random number generator 372, or specific fuses 374 that store statically hardened information. Various power / reset / debug controllers 380 may also be accessible via the peripheral bus or non-coherent interconnect 6.

[0152] For on-chip SRAM 360, it may be useful to provide a slave-side (completer-side) PAS filter 400. The PAS filter 400 can perform completer-side filtering of memory accesses based on completer-side protection information that defines which physical address space can access a given block of physical addresses. This completer-side information may be more coarsely defined than the GPT used by the requester-side PAS filter 20. For example, the slave-side information may simply indicate other regions, such as an entire SRAM unit 361 being dedicated for use by the realm region, another SRAM unit 362 being dedicated for use by the root region, and so on. Thus, relatively coarsely defined blocks of physical addresses may be addressed to different SRAM units. This completer-side protection information may be statically defined by boot loader code loading information into the completer-side PAS filter at startup, which cannot be changed during runtime. As such, it is less flexible than the GPT used by the requester-side PAS filter 20. However, for use cases where the division of each region of a physical address into specific accessible zones is known at startup, remains unchanged, and does not require fine-grained division, it may be more efficient to use the slave-side PAS filter 400 instead of the requester-side PAS filter 20. This is because the power and performance cost of retrieving a GPT entry and comparing the assigned PAS and shared attribute information with the information for the current memory access request may be eliminated at the requester side. Also, if the pass-through indicator 158 can be indicated in a top-level GPT entry (or other table descriptor entry at a level other than the last level) in a multi-level GPT structure, accesses to further levels of the GPT structure (which may be performed to find more fine-grained information about the assigned PAS for requests that are subject to requester-side checking) may be avoided for requests that target one of the zones of physical addresses mapped to on-chip memory 360 monitored by the completer-side PAS filter 400.

[0153] Therefore, supporting a hybrid approach that allows both requestor-side and completer-side checking of protection information can be useful for performance and power efficiency. The system designer can define which approach should be taken for a particular memory area.

[0154] FIG. 15 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.

[0155] 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.

[0156] 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 those 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 executing it within a simulator running on a host device that does not support that architecture.

[0157] The simulator code includes processor program logic 412 that 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 the native instruction set supported by host hardware 430, and 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 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 architectural state may include the aforementioned current domain indication 14 and current exception level indication 15.

[0158] 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, 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 target code's perspective) in one of the PASs, but these simulated physical addresses are actually mapped onto the host processor's (virtual) address space by 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.

[0159] Further examples are described in the following clauses. (1) An apparatus comprising: an address translation circuit for translating a target virtual address specified by a memory access request issued by a requester circuit into a target physical address; and a requester-side filtering circuit for performing a granule protection lookup based on the target physical address and a selected physical address space associated with the memory access request to determine whether to allow the memory access request to be passed via an interconnect to a completer device for processing, wherein the selected physical address space is one of a plurality of physical address spaces; and in the granule protection lookup, the requester-side filtering circuit obtains granule protection information corresponding to a target granule of a physical address including the target physical address, the granule protection information indicating at least one allowed physical address space associated with the target granule; and is configured to block the memory access request when the granule protection information indicates that the selected physical address space is not one of the at least one allowed physical address spaces. (2) The apparatus of clause (1), wherein the granule protection information specifies an allocated physical address space assigned to a target granule of the physical address, and the at least one allowed physical address space includes at least the allocated physical address space. (3) The apparatus described in clause (2), wherein the granule protection information also includes shared attribute information indicating whether at least one other physical address space other than the assigned physical address space is one of the at least one permitted physical address space. (4) The device described in clause (3), wherein when the granule protection lookup determines that the selected physical address space is a physical address space other than an assigned physical address space that is one of the at least one permitted physical address space indicated by the shared attribute information, the requester-side filtering circuit is configured to allow the memory access request to be passed to the cache or interconnect specifying the assigned physical address space instead of the selected physical address space. (5) The apparatus described in any of clauses (1) to (4), wherein the requester-side filtering circuit is configured to perform granule protection lookups in at least one lookup cache configured to cache granule protection information. (6) The apparatus of clause (5), wherein the at least one lookup cache is configured to store at least one combined translation and granule protection entry that specifies information that depends on both the granule protection information and at least one page table entry used by the address translation circuitry to map a target virtual address to a target physical address. (7) The device described in either of clauses (5) and (6), wherein at least one lookup cache invalidates, in response to at least one lookup cache invalidation command specifying an invalidation target physical address, lookup cache entries that store information dependent on granule protection information associated with a granule of a physical address that includes the invalidation target physical address. (8) An apparatus described in any of clauses (1) to (7), comprising: a Point of Physical Aliasing (PoPA) memory system component configured to unalias multiple aliased physical addresses from different physical address spaces corresponding to the same memory system resource and map any of the multiple aliased physical addresses to unaliased physical addresses provided to at least one downstream memory system component; and at least one pre-PoPA memory system component provided upstream of the PoPA memory system component, wherein the at least one PoPA memory system component is configured to treat the aliased physical addresses from the different physical address spaces as if the aliased physical addresses correspond to different memory system resources. (9) The apparatus of clause (8), wherein the aliased physical addresses are represented using the same physical address value in different physical address spaces. (10) The apparatus described in either of clauses (8) and (9), wherein the at least one pre-PoPA memory system component includes at least one pre-PoPA cache, and the apparatus includes processing circuitry responsive to a cache invalidation instruction to the PoPA specifying a target address to issue at least one invalidation command to request that the at least one pre-PoPA cache invalidate one or more entries associated with a target physical address value corresponding to the target virtual address. (11) The apparatus of any of clauses (1) to (10), wherein at least one of the address translation circuit and the requester-side filtering circuit is configured to select the selected physical address space based at least on a current operating region of the requester circuit from which the memory access request was issued, the current region including one of a plurality of operating regions. (12) The apparatus of clause (11), wherein the address translation circuitry is configured to translate a target virtual address into a target physical address based on at least one page table entry, and wherein, if at least the current region is one of a subset of a plurality of regions, at least one of the address translation circuitry and the requester-side filtering circuitry is configured to select a selected physical address space based on physical address space selection information specified in the current region and the at least one page table entry. (13) The apparatus described in either clause (11) or (12), wherein the plurality of regions includes at least a secure region associated with a secure physical address space and a less secure region associated with a less secure physical address space, wherein the less secure physical address space is selectable as the selected physical address space when the current region is a less secure region or a secure region, and the secure physical address space is selectable as the selected physical address space when the current region is a secure region and is prohibited from being selected as the selected physical address space when the current region is a less secure region. (14) The apparatus of clause (13), wherein the plurality of regions also includes a further region associated with a further physical address space, and wherein when the current region is the further region, a less secure physical address space is selectable as the selected physical address space, and when the current region is the further region, the further physical address space is selectable as the selected physical address space, but when the current region is a secure region or a less secure region, it is prohibited from being selected as the selected physical address space, and when the current region is the further region, the secure address space is prohibited from being selected as the selected physical address space. (15) The device according to any one of clauses (11) to (14), wherein the plurality of regions includes a root region for managing switching between the other regions, the root region being associated with a root physical address space. (16) The device described in clause (15), wherein at least one of: when the current region is a root region, all of the physical address spaces are selectable as the selected physical address space; and when the current region is a region other than the root region, the root physical address space is prohibited from being selected as the selected physical address space. (17) The apparatus according to any one of clauses (15) and (16), wherein the granule protection information is modifiable by software executed in the root region. (18) The apparatus according to any one of clauses (1) to (17), wherein the granule protection information is defined at page level detail. (19) The device according to any one of clauses (1) to (18), wherein the granule protection information is dynamically updatable during execution. (20) The apparatus described in any of clauses (1) to (19), wherein if the granule protection information specifies a pass-through indicator indicating that at least one permitted physical address space is resolved by the completer-side filtering circuit, the requester-side filtering circuit is configured to determine whether to pass the memory access request to the interconnect independently of checking whether the selected physical address space is one of the at least one permitted physical address space. (21) An apparatus described in any of clauses (1) to (20), comprising a completer-side filtering circuit responsive to a memory access request received from an interconnect specifying a target physical address and a selected physical address space, and performing a completer-side protection information lookup based on the target physical address and the selected physical address space to determine whether the memory access request is permitted to be processed by the completer-side device. (22) A data processing method including: translating a target virtual address specified by a memory access request issued by a requester circuit into a target physical address; and performing, in a requester-side filtering circuit, a granule protection lookup based on the target physical address and a selected physical address space associated with the memory access request to determine whether to pass the memory access request to a completer device via an interconnect for processing, wherein the selected physical address space is one of a plurality of physical address spaces; and in the granule protection lookup, the requester-side filtering circuit obtains granule protection information corresponding to a target granule of a physical address including the target physical address, the granule protection information indicating at least one allowed physical address space associated with the target granule; and blocking the memory access request when the granule protection information indicates that the selected physical address space is not one of the at least one allowed physical address spaces. (23) A computer program for controlling a host data processing apparatus to provide an instruction execution environment for executing target code, the computer program comprising: address translation program logic for translating a target simulated virtual address specified by a memory access request into a target simulated physical address; and filtering program logic for performing a granule protection lookup based on the target simulated physical address and a selected simulated physical address space associated with the memory access request to determine whether the memory access request can be processed, wherein the selected simulated physical address space is one of a plurality of simulated physical address spaces; and in the granule protection lookup, the filtering program logic obtains granule protection information corresponding to a target granule of the simulated physical address that includes the target simulated physical address, the granule protection information indicating at least one allowed simulated physical address space associated with the target granule; and the computer program is configured to prevent the memory access request from being processed when the granule protection information indicates that the selected simulated physical address space is not one of the at least one allowed simulated physical address spaces. (24) A computer-readable storage medium storing the computer program described in clause (23).

[0160] 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.

[0161] 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. a processing circuit for performing processing in one of at least three operating domains, the at least three operating domains including a root domain for managing switching between a plurality of other operating domains; an address translation circuit that translates a virtual address of a memory access executed from a current operating region into a physical address of one of at least three physical address spaces including a root physical address space associated with the root region, the root physical address space being separate from physical address spaces associated with the plurality of other operating regions, and the one of the at least three physical address spaces being selected based at least on the current operating region; at least one pre-Point of Physical Aliasing (PoPA) memory system component located upstream of the PoPA, the at least one pre-PoPA memory system component handling aliased physical addresses from different physical address spaces corresponding to the same memory system resource to correspond to different memory system resources; An apparatus comprising:

2. 2. The apparatus of claim 1, wherein the root physical address space is exclusively accessible from the root region.

3. The apparatus of claim 1 , wherein all of the at least three physical address spaces are accessible from the root region.

4. the plurality of other operating regions includes at least a secure region associated with a secure physical address space and a less secure region associated with a less secure physical address space; the less secure physical address space is accessible from the less secure region, the secure region, and the root region; The apparatus of any one of claims 1 to 3, wherein the secure physical address space is accessible from the secure region and the root region, and is inaccessible from the less secure region.

5. the plurality of other operating regions also includes a further region associated with a further physical address space; the less secure physical address space is also accessible from the further region; 5. The apparatus of claim 4, wherein the further physical address space is accessible from the further region and the root region, and is inaccessible from the less secure region.

6. the additional physical address space is inaccessible from the secure world; The apparatus of claim 5 , wherein the secure physical address space is inaccessible from the further region.

7. The apparatus of any one of claims 4 to 6, wherein the less secure physical address space is accessible from all of the at least three operating domains.

8. the address translation circuitry is configured to translate the virtual address to the physical address based on at least one page table entry; 8. The apparatus of claim 1, wherein, if at least the current operating region is one of a subset of the at least three operating regions, the address translation circuitry is configured to select the one of the at least three physical address spaces based on the current operating region and physical address space selection information specified in the at least one page table entry.

9. 9. The apparatus of claim 8, wherein when the current operating region is the root region, the address translation circuitry is configured to translate the virtual address to the physical address based on a page table entry for the root region of the physical address space selection information, the physical address space selection information including at least two bits for selecting among at least three physical address spaces accessible from the root region.

10. the address translation circuitry is configured to translate the virtual address to the physical address based on at least one page table entry; when the current operating region is the secure region, the address translation circuitry is configured to select whether the one of the at least three physical address spaces is the secure physical address space or the less secure physical address space based on a physical address space selection indicator specified in the at least one page table entry; 7. The apparatus of claim 6, wherein when the current operating region is the further region, the address translation circuitry is configured to select whether the one of the at least three physical address spaces is the further physical address space or the less secure physical address space based on a physical address space selection indicator specified in the at least one page table entry.

11. 11. The apparatus of claim 10, wherein the physical address space selection indicator is encoded in the same position within the at least one page table entry regardless of whether the current operating region is the secure region or the further region.

12. 2. The apparatus of claim 1, wherein the aliased physical addresses comprise physical addresses represented using the same physical address value in the different physical address spaces.

13. 10. The apparatus of claim 1, comprising: a PoPA memory system component configured to unalias the plurality of aliased physical addresses to obtain an unaliased physical address that is provided to at least one downstream memory system component.

14. the at least one pre-PoPA memory system component includes at least one pre-PoPA cache; 14. The apparatus of claim 1, wherein in response to a cache invalidation instruction to a PoPA specifying a target address, the processing circuitry is configured to issue at least one invalidation command to request that the at least one pre-PoPA cache invalidate one or more entries associated with a target physical address value corresponding to the target address.

15. 15. The apparatus of claim 14, wherein when the processing circuit issues the at least one invalidation command, at least one post-PoPA cache located downstream of the PoPA is enabled to hold one or more entries associated with the target physical address value.

16. 16. The apparatus of claim 14, wherein in response to the at least one invalidation command, the at least one pre-PoPA cache is configured to invalidate the one or more entries associated with the target physical address value, regardless of which of the at least three physical address spaces is associated with the one or more entries.

17. 17. The apparatus of claim 1, further comprising: a memory encryption circuit that, in response to a memory access request specifying a selected physical address space and a target physical address within the selected physical address space, encrypts or decrypts data associated with the protected area based on one of a plurality of encryption keys selected in accordance with the selected physical address space, when the target physical address is within a protected address area.

18. A data processing method comprising: a data processor performing processing in one of at least three operating domains, the at least three operating domains including a root domain for managing switching between a plurality of other operating domains; an address translation circuit for translating a virtual address of a memory access executed from a current operating region into a physical address of one of at least three physical address spaces including a root physical address space associated with the root region, the root physical address space being separate from physical address spaces associated with the plurality of other operating regions, one of the at least three physical address spaces being selected based at least on the current operating region; A data processing method in which at least one pre-physical aliasing point (PoPA) memory system component located upstream of a PoPA processes aliased physical addresses from different physical address spaces corresponding to the same memory system resource to correspond to different memory system resources.

Images