Memory access request filtering based on requester group identifier

Abstract

An apparatus comprises address translation circuitry (16, 26), responsive to a memory access request received from a requester hardware device (4, 5) specifying a target virtual address and a requester group identifier (RGID) associated with the requester hardware device, to translate the target virtual address into a target physical address (PA) based on at least one address translation mapping specified in at least one translation table structure. Filtering circuitry (20) performs a granule protection lookup based on the target PA to identify granule protection attributes associated with a target granule of PAs comprising the target PA. The granule protection attributes are derived from granule protection information specified in a granule protection table structure which is orthogonal to the at least one translation table structure. The filtering circuitry determines, based on the granule protection attributes, whether to prohibit the memory access request from being processed by a cache or a memory system interconnect. The filtering circuitry determines, based on the granule protection attributes and the RGID, whether a group of one or more requester hardware devices associated with the RGID is prohibited from accessing the target granule of PAs.

Description

[0001] MEMORY ACCESS REQUEST FILTERING BASED ON REQUESTER GROUP IDENTIFIER

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

[0003] A data processing system may have address translation circuitry to translate a virtual address of memory access request to a physical address corresponding to a location to be accessed in a memory system.

[0004] At least some examples provide an apparatus comprising: address translation circuitry responsive to a memory access request received from a requester hardware device specifying a target virtual address and a requester group identifier associated with the requester hardware device, to translate the target virtual address into a target physical address based on at least one address translation mapping specified in at least one translation table structure; and filtering circuitry to: perform a granule protection lookup based on the target physical address to identify granule protection attributes associated with a target granule of physical addresses comprising the target physical address, where the granule protection attributes are derived from granule protection information specified in a granule protection table structure which is orthogonal to the at least one translation table structure; and determine, based on the granule protection attributes associated with the target granule of physical addresses, whether to prohibit the memory access request from being processed by a cache or a memory system interconnect; wherein: the filtering circuitry is configured to determine, based on the granule protection attributes and the requester group identifier specified by the memory access request, whether the granule protection attributes indicate that a group of one or more requester hardware devices associated with the requester group identifier is prohibited from accessing the target granule of physical addresses comprising the target physical address.

[0005] At least some examples provide computer-readable code for fabrication of the apparatus as described above.

[0006] At least some examples provide a method comprising: in response to a memory access request received from a requester hardware device specifying a target virtual address and a requester group identifier associated with the requester hardware device, translating the target virtual address into a target physical address based on at least one address translation mapping specified in at least one translation table structure; performing a granule protection lookup based on the target physical address to identify granule protection attributes associated with a target granule of physical addresses comprising the target physical address, where the granule protection attributes are derived from granule protection information specified in a granule protection table structure which is orthogonal to the at least one translation table structure; and determining, based on the granule protection attributes associated with the target granule of physical addresses, whether to prohibit the memory access request from being processed by a cache or a memory system interconnect; wherein: the determining comprises, based on the granule protection attributes and the requester group identifier specified by the memory access request, determining whether the granule protection attributes indicate that a group of one or more requester hardware devices associated with the requester group identifier is prohibited from accessing the target granule of physical addresses comprising the target physical address.

[0007] At least some examples provide a computer program for controlling a host data processing apparatus to provide an instruction execution environment for execution of target program code, the computer program comprising: address translation program logic responsive to a memory access request specifying a target virtual address and a requester group identifier associated with a simulated requester hardware device, to translate the target virtual address into a target simulated physical address based on at least one address translation mapping specified in at least one translation table structure; and filtering program logic to: perform a granule protection lookup based on the target simulated physical address to identify granule protection attributes associated with a target granule of simulated physical addresses comprising the target simulated physical address, where the granule protection attributes are derived from granule protection information specified in a granule protection table structure which is orthogonal to the at least one translation table structure; and determine, based on the granule protection attributes associated with the target granule of simulated physical addresses, whether to prohibit the memory access request from being processed; wherein: the filtering program logic is configured to determine, based on the granule protection attributes and the requester group identifier specified by the memory access request, whether the granule protection attributes indicate that a group of one or more simulated requester hardware devices associated with the requester group identifier is prohibited from accessing the target granule of simulated physical addresses comprising the target simulated physical address.

[0008] At least some examples provide a computer-readable storage medium storing the computer-readable code or the computer program described above. The storage medium may be a non-transitory storage medium.

[0009] Further aspects, features and advantages of the present technique will be apparent from the following description of examples, which is to be read in conjunction with the accompanying drawings, in which:

[0010] Figure 1 illustrates an example of a data processing apparatus;

[0011] Figure 2 illustrates processing of a memory access request, including performing a granule protection lookup to obtain granule protection attributes derived from a granule protection table structure;

[0012] Figure 3 illustrates filtering of memory access request based on granule protection attributes determined in the granule protection lookup;

[0013] Figure 4 illustrates an example of multi-level structures used for stage-1 and stage-2 translation table structures and the granule protection table structure;

[0014] Figure 5 illustrates an example of use of an indirection table to provide granule protection attributes; Figure 6 illustrates a more detailed example of an apparatus supporting the granule protection lookup;

[0015] Figure 7 illustrates a number of domains in which processing circuitry of the apparatus can operate;

[0016] Figure 8 illustrates an example of a processing system supporting granule protection lookups;

[0017] Figure 9 schematically illustrates aliasing of a number of physical address spaces onto a system physical address space identifying locations in the memory system;

[0018] Figure 10 illustrates an example of partitioning the effective hardware physical address space so that different architectural physical address spaces have access to respective portions of the system physical address space;

[0019] Figure 1 1 is a flow diagram illustrating a method of determining the current domain of operation of the processing circuitry;

[0020] Figure 12 shows examples of page table entry formats for page table entries used for translating virtual addresses to physical addresses;

[0021] Figure 13 is a flow diagram showing a method of selecting a physical address space to be accessed by a given memory access request;

[0022] Figure 14 illustrates a number of stages of address translation and granule protection information filtering;

[0023] Figure 15 illustrates a method of performing a granule protection check based on granule protection information;

[0024] Figure 16 illustrates filtering checks performed in the granule protection check;

[0025] Figure 17 illustrates use of a requester group identifier to limit which requester hardware devices are able to access a particular physical address space;

[0026] Figure 18 illustrates a particular use case example of using the requester group identifier and read / write granule protection attributes to implement producer / consumer rules for enforcing restrictions on access to protected content being processed in a pipelined manner by multiple requester hardware devices, even if the operating system or hypervisor responsible for controlling translation table permissions cannot be trusted; and

[0027] Figure 19 illustrates a simulation example.

[0028] Data processing systems may support use of virtual memory, where address translation circuitry is provided to translate a target virtual address specified by a memory access request into a physical address associated with a location in a memory system to be accessed. The mappings between virtual addresses and physical addresses may be defined in one or more translation table structures. Translation table entries within the translation table structures could also define access permission information which may control whether a given software process executing on the processing circuitry is allowed to access a particular virtual address. However, for some sensitive processing workloads, there may be a portion of processing (e.g. biometric data processing or processing of content protected by digital rights management) which is desired to be provided with additional security than can be provided with translation table attributes alone. As the translation table structures used to define address mappings and attributes are typically controlled by an operating system or a hypervisor, there is a risk that if an attacker manages to compromise the operating system or hypervisor, the access permission attributes defined by the translation table structures may not be enough to provide sufficient security guarantee for such sensitive workloads.

[0029] Hence, filtering circuitry is provided to perform a granule protection lookup based on the target physical address to identify granule protection attributes associated with a target granule of physical addresses comprising the target physical address, where the granule protection attributes are derived from granule protection information specified in a granule protection table structure which is orthogonal to the at least one translation table structure; and determine, based on the granule protection attributes associated with the target granule of physical addresses, whether to prohibit the memory access request from being processed by a cache or a memory system interconnect. Hence, by defining granule protection attributes in a physically-addressed table (a table looked up based on physical address, and hence independent of the translation table structures used to provide the mapping from virtual address to physical address), an added layer of security can be provided beyond that controlled by the operating system or hypervisor, to reduce risk that an attacker can cause inappropriate access to certain granules of physical address space used by sensitive processing workloads.

[0030] An advantage of performing the granule protection lookup at the requester-side of the interconnect instead of on the completer-side closer to the memory storage is that this can enable more fine-grained control over which physical addresses are accessible from a given physical address space than would be practical at the completer-side. This is because the completer-side may typically have relatively limited ability to access the memory system as a whole. For example, a memory controller for a given memory unit may only have access to the locations within that memory unit and may not have access to other regions of the address space. Providing more fine-grained control may rely on a more complex table of granule protection information which may be stored in the memory system and it may be more practical to access such a table from the requester side where there is more flexibility to issue memory access request to a wider subset of the memory system.

[0031] In one comparative approach to implementing requester-side granule protection checks, all accesses to a particular physical address within a given physical address space may be controlled based on the same granule protection permissions for access, so that regardless of which particular hardware device initiates a request to a particular address within a given physical address space, the outcome of check of the protection attributes may be the same. While this approach may offer high security, it may be relatively inflexible, given that in modern data processing systems, there may be many physical processors, hardware accelerators, and other requester devices with memory access capability, which may have differing security requirements in some usage models. One approach could be to define architectural registers at a given requester device which store state enabling or disabling access to a particular physical address space or portion of a physical address space, but this may offer relatively coarse-grained control.

[0032] Instead, in the examples discussed below, a memory access request received from the requester hardware device specifies a requester group identifier (RGID) associated with that request a hardware device. The filtering circuitry determines, based on the granule protection attributes and the RGID specified by the memory access request, whether the granule protection attributes indicate that a group of one or more requester hardware devices associated with the RGID is prohibited from accessing the target granule of physical addresses comprising the target physical address. With this approach, memory access requests to the same physical address in the same physical address space can be treated differently depending on which hardware device issued the request, without needing to rely on specific permissions defined in the translation table structures. Hence, even if the operating system or hypervisor defining the translation table structures cannot be trusted, it is possible to restrict access to certain regions of physical address space, while enabling one hardware device to gain a view of physical memory which cannot be seen by another hardware device, even if both hardware devices are in principle allowed access to the same physical address space. As the granule protection table structure looked up based on the target physical address is used to define the RG I D-based permissions, a relatively rich set of controls can be provided, enabling fine-grained control of access to each granule of physical addresses, which would be less practical with alternative mechanisms relying on architectural state defined in registers at the hardware device which is looked up independent of the target physical address.

[0033] Hence, this provides a flexible technique for enabling fine-grained control over security of memory access while supporting different views of memory for different requester hardware devices accessing the same physical address in the same physical address space.

[0034] In some cases, information obtained from the granule protection table structure may be cached local to the filtering circuitry. Hence, the granule protection lookup performed by the filtering circuitry could include one or both of: a lookup to the local cache of granule protection information, and / or one or more accesses to memory to access portions of the granule protection table structure stored in the memory system (such memory accesses could be performed in cases where information required from the granule protection table structure cannot be located in a local cache (if provided)). Either way, a lookup based on target physical address is used to identify granule protection attributes derived from the granule protection information specified in the granule protection table structure.

[0035] This technique can be used in systems supporting only a single physical address space

[0036] (PAS). However, the use of RGID-based granule protection checks can be particularly useful in an example supporting multiple PASs, where the granule protection attributes also indicate which PAS is an allowed PAS for the target granule of physical addresses. Use of multiple PASs can be helpful where there is a need for certain processes to execute securely in isolation from other processes. Selection of which PAS is specified for a given memory access may depend on the current domain of operation of the requester hardware device and / or on attributes defined in the translation table structure(s) used to provide address translation mappings. By isolating accesses into distinct PASs, this can provide a stronger security guarantee than is possible in systems supporting only a single PAS. Hence, in a system in which a virtual address of a memory access request can be mapped to a physical address in one of two or more distinct PASs, the granule protection attributes can be used to limit which physical addresses are accessible within a particular PAS, including restricting granule access within a particular PAS based on the RGID of the memory access request.

[0037] Hence, the apparatus may comprise PAS selection circuitry to select a selected PAS for the memory access request from among a plurality of PASs (the PAS selection circuitry could be part of the address translation circuitry itself, part of the filtering circuitry, or circuitry separate from both the address translation circuitry and the filtering circuitry). The filtering circuitry determines, based on the granule protection attributes associated with the target granule of physical addresses, which of the PASs is an allowed PAS, with memory access requests associated with a PAS other than an allowed PAS being prohibited from accessing the target granule of physical addresses. The RGID-based control offers further control over access to each address space so that requester hardware devices specifying different RGIDs can be given differing views of memory within the same PAS, to provide more flexible usage models where a given requester hardware device with sufficient security to justify access to part of a given PAS need not necessarily be granted access to the entire PAS and can be prevented from accessing part of that PAS that is accessible to a different requester hardware device accessing the same PAS. For example, this can be useful for implementing digital rights management processing pipelines, biometric processing, and other sensitive workloads, where the processing as a whole may need to be isolated from other less secure processing which uses an entirely different PAS, but nevertheless it is desirable to not give every requester hardware device access to the entire PAS used for the more secure processing when the address translation attributes defined in the translation tables structures cannot necessarily be trusted to offer that fine-grained control of access within a given PAS. Hence, the use of granule protection attributes defined in the granule protection table structure, which define both rights to access a given granule of physical addresses from a given PAS and provide options for controlling which groups of requester hardware devices can access that granule, can be particularly useful for providing a secure and flexible solution for providing fine-grained control of PAS access based on device type. The apparatus may have a point of physical aliasing (PoPA) memory system component configured to de-alias a plurality of aliasing physical addresses from different PASs which correspond to a same memory system location, to map any of the plurality of aliasing physical addresses to a de-aliased physical address to be 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, where the at least one pre-PoPA memory system component is configured to treat the aliasing physical addresses from different PASs as if the aliasing physical addresses correspond to different memory system locations.

[0038] Hence, for at least some components of the memory system, memory access requests whose virtual addresses are translated into physical addresses in different PASs are treated as if they were accessing completely separate addresses in memory, even if the physical addresses in the respective PASs actually correspond to the same location in memory. For example, the at least one pre-PoPA memory system component could comprise a cache or translation lookaside buffer which may cache data, program code or address translation information for the aliasing physical addresses in separate entries, so that if the same memory system resource is requested to be accessed from different PASs, then the accesses will cause separate cache or TLB entries to be allocated. Also, the pre-PoPA memory system component could comprise coherency control circuitry, such as a coherent interconnect, snoop filter, or other mechanism for maintaining coherency between cached information at respective master devices. The coherency control circuitry could assign separate coherency states to the respective aliasing physical addresses in different PASs. Hence, the aliasing physical addresses are treated as separate addresses for the purpose of maintaining coherency even if they do actually correspond to the same underlying memory system resource. Although on the face of it, tracking coherency separately for the aliasing physical addresses could appear to cause a problem of loss of coherency, in practice this is not a problem because if processes operating in different domains are really intended to share access to a particular memory system resource then they can use a less secure PAS to provide shared access to that resource. Another example of a pre-PoPA memory system component may be a memory protection engine which is provided for protecting data saved to off-chip memory against loss of confidentiality and / or tampering. Such a memory protection engine could, for example, encrypt data associated with a particular memory system resource with different encryption keys depending on which PAS the resource is accessed from, effectively treating the aliasing physical addresses as if they were corresponding to different memory system resources (e.g. an encryption scheme which makes the encryption dependent on the address may be used, and the PAS identifier may be considered to be part of the address for this purpose).

[0039] Regardless of the form of the pre-PoPA memory system component, it can be useful for such a PoPA memory system component to treat the aliasing physical addresses as if they correspond to different memory system resources, as this provides hardware-enforced isolation between the accesses issued to different PASs so that information associated with one domain cannot be leaked to another domain by features such as cache timing side channels or side channels involving changes of coherency triggered by the coherency control circuitry.

[0040] It may be possible, in some implementations, for the aliasing physical addresses in the different PASs to be represented using different numeric physical address values for the respective different PASs. This approach may use a mapping table to determine at the PoPA which of the different physical address values correspond to the same memory system resource. However, this overhead of maintaining the mapping table may be considered unnecessary, and so in some implementations it may be simpler if the aliasing physical addresses comprise physical addresses which are represented using the same numeric physical address value in each of the different PASs. If this approach is taken then, at the point of physical aliasing, it can be sufficient simply to discard the PAS identifier which identifies which PAS is accessed using a memory access, and then to provide the remaining physical address bits downstream as a de-aliased physical address.

[0041] Hence, in addition to the pre-PoPA memory system component, the memory system may also include a PoPA memory system component configured to de-alias the plurality of aliasing physical addresses to obtain a de-aliased physical address to be provided to at least one downstream memory system component. The PoPA memory system component could be a device accessing a mapping table to find the dealiased address corresponding to the aliasing address in a particular address space, as described above. However, the PoPA component could also simply be a location within the memory system where the physical address tag associated with a given memory access is discarded so that the physical address provided downstream uniquely identifies a corresponding memory system resource regardless of which PAS this was provided from. Alternatively, in some cases the PoPA memory system component may still provide the PAS tag to the at least one downstream memory system component (e.g. for the purpose of enabling completer-side filtering as discussed further below), but the PoPA may mark the point within the memory system beyond which downstream memory system components no longer treat the aliasing physical addresses as different memory system resources, but consider each of the aliasing physical addresses to map the same memory system resource. For example, if a memory controller or a hardware memory storage device downstream of the PoPA receives the physical address tag and a physical address for a given memory access request, then if that physical address corresponds to the same physical address as a previously seen transaction, then any hazard checking or performance improvements performed for respective transactions accessing the same physical address (such as merging accesses to the same address) may be applied even if the respective transactions specified different PAS tags. In contrast, for a memory system component upstream of the PoPA, such hazard checking or performance improving steps taken for transactions accessing the same physical address may not be invoked if these transactions specify the same physical address in different PASs. In an example supporting multiple PASs, the memory access request may be associated with one of two or more domains of processing, the plurality of domains including at least a less secure domain associated with a less secure PAS and a more secure domain associated with a more secure PAS. The PASs may include at least the less secure PAS and the more secure PAS, where the more secure PAS is prohibited from being selected by the PAS selection circuitry for memory access requests associated with the less secure domain. Hence, software operating in the less secure domain (or processing performed by a hardware device based on configuration data set by software operating in the less secure domain) may be prevented from accessing physical addresses which are indicated by the granule protection attributes as being inaccessible from the less secure PAS, to provide hardware-enforced security guarantees to processes operating in the more secure domain.

[0042] The less secure PAS and more secure PAS may not be the only PASs supported (and similarly there may be at least one further domain in addition to the less secure domain and more secure domain). For example, the plurality of domains of processing may also include a realm domain of processing, with the PASs also including a realm PAS. The realm PAS may be prohibited from being selected by the PAS selection circuitry for memory access requests associated with the more secure domain, while the more secure PAS may be prohibited from being selected by the PAS selection circuitry for memory access requests associated with the realm domain, and both the realm PAS and more secure PAS may be prohibited from being selected for memory access requests associated with the less secure domain. By providing two domains each with greater security than the less secure domain (so the less secure domain is unable to access the PASs associated with the more secure and realm domains), but which cannot access each other’s corresponding PASs, this allows software provided by two mutually untrusted software developers to coexist on the same hardware without having to trust each other, even when both providers require guarantees of isolation from less secure software components.

[0043] The granule protection attributes could be encoded in different ways, to indicate the PAS permissions governing which PASs are allowed PASs for a given granule of physical addresses and the requester group access permissions used for RGID-based control.

[0044] In one example, the granule protection attributes specify requester group access permissions, indicative of which groups of one or more requester hardware devices associated with respective values of the requester group identifier are prohibited from accessing the target granule of physical addresses; and orthogonal to the requester group access permissions, physical address space permissions indicative of which one or more of the plurality of physical address spaces is an allowed physical address space for the target granule of physical addresses. For example, a first subset of bits of the granule protection attributes could specify the requester group access permissions and a second subset of bits of the granule protection attributes (different to the first subset of bits) could specify the PAS permissions. By providing orthogonal controls for PAS access permissions and RGID based permissions, this provides increased flexibility, to support any desired combination between PAS access rules and RGID access rules.

[0045] In other examples, the granule protection attributes may specify combined requester group and physical address space attributes indicative of which combinations of requester group identifier and physical address space are allowed combinations permitted to access the target granule of physical addresses. This approach could offer more efficient encoding and may not support all arbitrary combinations of allowed RGIDs and allowed PASs, but could provide a combined field for which certain values are allocated to represent particular combinations of RGID / PAS allowed to access the corresponding granule of physical addresses.

[0046] The PAS permissions and requester group access permissions may not be the only permissions indicated by the granule protection attributes.

[0047] In some examples, the granule protection attributes may comprise at least one read / write permission attribute indicative of whether read access to the target granule of physical addresses is prohibited, and independently from whether read access is prohibited, whether write access to the target granule of physical addresses is prohibited. The filtering circuitry is configured to: determine that a read memory access request is prohibited from accessing the target granule of physical addresses when the at least one read / write permission attribute indicates that read access is prohibited, and determine that a write memory access request is prohibited from accessing the target granule of physical addresses when the at least one read / write permission attribute indicates that write access is prohibited. This can help support definition of read-only or write-only regions using attributes which are beyond the control of the software setting the attributes in the translation table structure (which would normally be used to control read-only or write-only memory attributes).

[0048] More particularly, the at least one read / write permission attribute may comprise a plurality of read / write permission attributes to independently define, for a plurality of respective values of the requester group identifier, whether read access or write access is prohibited for respective groups of one or more requester hardware devices associated with the respective values of the requester group identifier. This can be useful to allow different hardware devices associated with different RGIDs to be given differing rights as to whether they can read or write to a given memory region, in a manner orthogonal to the translation table permissions controlled by an operating system or hypervisor. For example, it could be useful to give one or more requester hardware devices associated with one RGID value read-only access to a given memory region and one or more requester hardware devices associated with a different RGID value write-only access to the given memory region, when that memory region is used as a buffer for content processed in a pipelined manner by multiple requester devices or processes. This can help define producerconsumer relationships between hardware devices, so that a device which acts as the producer for a given step in the pipeline can be given write-only access and a device which acts as the consumer of the data generated at that given step in the pipeline is given read-only access. By restricting the types of access that are allowed for a given RGID when accessing a given memory region, this can improve security.

[0049] The granule protection attributes could encode the requester group access permissions in different ways. In some examples, a bit field with fewer bits than the total number of distinct values of the RGID supported could be used to indicate which RGIDs (or combinations of RGIDs) are allowed to access the target granule of physical addresses. For example, an N-bit field could provide 2Nencodings, each encoding representing a different combination of zero, one or more of the RGIDs being allowed to access the granule of physical addresses.

[0050] However, in some examples, to offer greater flexibility in specifying which RGIDs are permitted to access the target granule, the granule protection attributes may comprise a requester group bitmap comprising a plurality of permission bits, each permission bit indicative of whether a group of requester hardware devices associated with a corresponding value of the RGID is prohibited from accessing the target granule of physical addresses. This can allow an arbitrary combination of RGIDs to be defined as being allowed access or denied access to a given granule of physical addresses.

[0051] The granule protection attributes could be defined in the granule protection table structure in different ways.

[0052] In some examples, the granule protection attributes associated with the target physical address may be obtained from a corresponding entry of the granule protection table structure corresponding to the target granule of physical addresses. For example, the granule protection attributes may be directly encoded in the corresponding entry of the granule protection table structure.

[0053] However, in other examples, at least a portion of the granule protection attributes may be obtained from a target entry of an indirection table, the target entry identified by an indirection entry identifier specified by the granule protection information in a corresponding entry of the granule protection table structure corresponding to the target granule of physical addresses. Hence, in this case the corresponding entry of the granule protection table structure indirectly defines the granule protection attributes by providing a pointer to the target entry of the indirection table. This approach can provide several advantages, for example allowing software to update the permission type applied to two or more different granules of physical addresses (which are all to share the same attribute values and reference the same entry of the indirection table) using a single write to that indirection table entry, rather than needing to update each separate granule protection table entry corresponding to those granules. Also, in some examples there may be insufficient encoding space in the granule protection entry itself to encode every possible permission type desired to be encoded, and so use of permission indirection can allow a limited number of bits within the entry encoding itself to reference a larger indirection table entry which is able to select from a wider range of permissions than is possible within the entry itself (recognizing that although in general a wide range of combinations of control options may be desired to be supported, at any one time only a subset of these combinations may be in use and so it may be acceptable to restrict the user / software to selecting a maximum of a certain number of combinations at a time, corresponding to the number of pointer encodings supported in the granule protection entry itself).

[0054] Nevertheless, other approaches may specify the granule protection attributes directly within the encoding of the granule protection entry. Therefore, it will be appreciated that reference to granule protection attributes being “specified by” or “indicated by” a granule protection table entry may include those attributes either being directly specified in the encoding of the granule protection table entry or specified indirectly via an entry of an indirection table (or using a mixture of both direct and indirect specification of the information).

[0055] Where indirection is used, it is possible to cache a portion of the indirection table local to filtering circuitry, so that it is not necessary to access the indirection table every time a memory access needs to be checked based on granule protection attributes. For example, a cache of granule protection attributes associated with particular physical addresses may specify the attributes obtained from the indirection table, rather than the pointer to the indirection table entry, so that the indirection table itself might be accessed (based on a pointer obtained from a corresponding granule protection table entry) only when there is a miss in the cache of granule protection attributes for a particular physical address.

[0056] The RGID could be defined in different ways. In some examples, the RGID associated with a given requester hardware device may be static at runtime. For example, the RGID for a given requester hardware device may be hardwired, or could be set by boot code at boot time and then remain static thereafter. This could provide for certain predefined groupings of requester hardware devices, to be assigned different views of the physical address space(s).

[0057] In other examples, the RGID associated with a given requester hardware device may be variable at runtime. For example, secure software operating in a most secure domain (e.g. the root domain mentioned below) may be able to modify the RGID assigned to a particular requester hardware device.

[0058] In some examples, the requester group identifier associated with the requester hardware device may be independent of an execution context associated with processing performed by the requester hardware device which caused the memory access request to be issued. For example, a given hardware accelerator could always specify the same RGID for a memory access request regardless of which software execution context is associated with the processing performed on that hardware accelerator which caused the memory access request to be issued.

[0059] In other examples, the RGID is variable depending on an execution context associated with processing performed by the requester hardware device which caused the memory access request to be issued. For example, the requester hardware device could have a table or other structure which defines different RGIDs per execution context. This could allow a particular requester device, such as a processor (e.g. central processing unit or graphics processing unit) or hardware accelerator, to issue requests with different RGIDs depending on which software execution context is associated with the processing that caused that device to issue the memory access request. The structure defining the association between RGIDs and execution contexts could be configurable based on software executing in the most secure domain of processing (e.g. the root domain mentioned below).

[0060] Some examples may support RGIDs with two or more bits, to define at least four distinct RGIDs. This can provide added flexibility to define different access rights to at least four distinct classes of hardware device.

[0061] However, other examples may support a one-bit RGID, which divides the requester hardware devices into two classes (e.g. protected and non-protected requester hardware devices, where the GPT can be defined to provide protected requester hardware devices can with access to some regions within a physical address space that are not accessible to non-protected requester hardware devices). Use of a 1 -bit RGID can offer a considerable enhancement to the security model compared to an approach not supporting RGIDs at all, but at relatively little additional cost in terms of encoding space for the granule protection attributes offering the RGID- based control and the memory access request parameters which accompany the memory access request when issued to the filtering circuitry.

[0062] The requester hardware device which issues the memory access request could be of various types. For example, the requester hardware device could be one of: a processor; a hardware accelerator; and an input / output device (e.g. modem, network controller, display controller, external storage controller, etc.).

[0063] The granule protection table structure may be a memory-based table structure, rather than a structure defined solely using architectural registers at the requester. Portions of the memorybased table structure may be cached local to the filtering circuitry for faster access.

[0064] Although some examples may implement a linear structure for the granule protection table structure (represented using a contiguous block of address space indexed with a single lookup relative to a base address), this may limit the granularity with which distinct granule protection attributes can be defined for respective granules of address space, as it may be difficult for a sufficiently large contiguous block of address space to be allocated for a single level of granule protection table covering a large address space.

[0065] Therefore, in some approaches, it can be useful to implement the granule protection table structure as a multi-level table structure comprising two or more levels of granule protection table, with the granule protection information corresponding to the target granule of physical addresses being obtained from an entry of a subsequent-level granule protection table stored at a memory system location associated with a physical address derived from a portion of the target physical address and a table pointer obtained from an entry corresponding to the target physical address in a higher-level granule protection table. This enables fine-grained control of distinct attributes for smaller granules of physical addresses, without imposing the limitation that the whole table has to be located in a contiguous block of memory of size corresponding to the size of the whole physical address space to be protected using the table as would be the case for a single linear structure.

[0066] The filtering circuitry may access the granule protection table structure based on a granule protection table base address, and the granule protection table base address may be prohibited from being updated by a software context processed in at least one execution state for which updates to a base address of the at least one translation table structure are allowed. For example, the granule protection table base address may be restricted to being set by software operating in a particular security domain (e.g. the root domain mentioned below) or execution state (e.g. EL3 mentioned below). For example, the least privileged state allowed to set the base address for the granule protection table structure may be more privileged than the least privileged state allowed to set the base address for any of the one or more translation table structures.

[0067] The granule protection table may define attributes for regions of memory at granularity of certain “granules” of physical addresses, where a given granule is a contiguous block of addresses of some defined size. The particular size of a granule can vary depending on the particular implementation. However, in one example the granule protection table structure has an encoding capable of assigning independent granule protection attributes to each 4 KB granule of physical addresses within a physical address space managed using the granule protection table structure. Use of 4 KB granules is particularly useful as 4 KB is a typical page size for defining translation table attributes in the translation table structures, so this approach allows the granule protection attributes to be defined at a corresponding granularity to the granularity with which an operating system or hypervisor would control access to memory. Although the granule protection table may have an encoding which supports 4 KB granule sizes, it may also support the option of indicating attributes for multiple granules in a single entry (e.g. by encoding information at a higher-level of a multi-level table structure indicating that the granule protection attributes are the same for a corresponding block of memory of size larger than the minimum granule size, so that it is not necessary to access a further level of the table structure which would have been accessed had separately defined attributes been desired for smaller granules within that block). Hence, while the encoding of the granule protection table may support 4 KB granules, it is not necessary for all encodings of the granule protection table to actually define 4 KB granules, and some encodings could define a coarser granularity for setting the granule protection attributes. Some examples may support granules having a size other than 4 KB. For example, 16 KB and 64 KB granules may be supported. Larger granules may correspond to a page size or may be a multiple of a page size, for example, and the use of larger granules can reduce the number of entries which may be provided in the granule protection table and therefore reduce the storage overhead of the granule protection table.

[0068] The address translation circuitry may comprise one of: a memory management unit associated with a processor; and a system memory management unit associated with at least one device, the at least one device comprising at least one hardware accelerator and / or at least one input / output device. Similarly, the filtering circuitry (and PAS selection circuitry mentioned earlier if provided) could also be associated with the processor itself, or with the system memory management unit.

[0069] The techniques discussed above can be implemented in a hardware apparatus which has hardware circuitry logic for implementing the functions as discussed above. Hence, the address translation circuitry and filtering circuitry may comprise hardware circuit logic. However, in other examples a computer program for controlling a host data processing apparatus to provide an instruction execution environment for execution of target code may be provided with address translation program logic and filtering program logic which performs, in software, equivalent functions to the address translation circuitry and filtering circuitry discussed above. This can be useful, for example, for enabling target code written for a particular instruction set architecture to be executed on a host computer which may not support that instruction set architecture. Functionality expected by the instruction set architecture which is not provided by the host computer could be emulated instead by simulation software providing an equivalent instruction execution environment for the target code as would be expected if the target code had been executed on the hardware device which actually supports the instruction set architecture. Providing such a simulation can be useful for a range of purposes, for example for enabling legacy code written for one instruction set architecture to be executed on a different platform which supports a different instruction set architecture, or for assisting with software development of new software to be executed for a new version of an instruction set architecture when hardware devices supporting that new version of the instruction set architecture are not available yet (this can enable the software for the new version of the architecture to start to be developed in parallel with development of the hardware devices supporting the new version of the architecture). In the case of the simulated embodiment, the RGIDs compared against the granule protection attributes may represent simulated groups of requester hardware devices, not real requester hardware devices, and may be assigned to access requests by the simulation software based on the type of memory access being issued, to simulate requests being issued from various simulated hardware devices.

[0070] Specific examples are now described with reference to the drawings.

[0071] Figure 1 schematically illustrates an example of an apparatus (e.g. a data processing system, integrated circuit or system on chip) 2 having at least one processor 4. In this example the processor is a CPU (Central Processing Unit), but other examples of processors include a GPU (Graphics Processing Unit) or NPU (Neural Processing Unit - a type of processor with specialized hardware for accelerating vector and / or matrix operations or other operations used in Neural Network and other machine learning processing). The processor 4 has an instruction decoder 11 for decoding program instructions and processing circuitry 10 which is controlled to perform processing operations in response to the instructions decoded by the instruction decoder 11 . The processor 4 has a cache 24 for caching data from memory for faster access by the processor and has a memory management unit (MMU) 16 which functions as address translation circuitry for translating virtual addresses specified by instructions executed by the processor 4 into physical addresses identifying locations within the memory system. The MMU may have at least one TLB 18 for storing translation entries which depend on page table data from page table structures stored in the memory system. The page table structures define the address mappings between virtual and physical addresses and may also define memory access permissions which may define whether certain software processes executing on the processor 4 are allowed to access certain addresses. The MMU 12 may support 2-stage address translation where the mapping of a virtual address to a physical address depends on both stage 1 address translation data which maps the virtual address (VA) to an intermediate physical address (IPA) and stage 2 translation data which maps the IPA to a physical address (PA). The stage 1 address translation data may be set by an operating system or virtual machine. The stage 2 translation data may be set by a hypervisor.

[0072] The processor 4 is an example of a requester device which is capable of executing program instructions. While Figure 1 only shows one such requester device 4, it will be appreciated that system 2 could have two or more such devices, which may include further CPUs or could include other types of instruction execution devices such as a graphics processing unit (GPU).

[0073] In addition to the processor 4 or other devices capable of instruction execution which have their own internal MMU 16, the system may also include requester devices 5 which may not have an internal MMU, and so for accessing memory and providing address translation functionality, such devices may communicate with the rest of the system via a system memory management unit (SMMU) 26 which includes address translation circuitry which controls address translation and memory permissions based on translation data defined in page table structures in memory. Again, the SMMU 26 may have one or more TLBs 28 which have a similar functionality to the TLBs 18 associated with the MMU 16 of the processor 4. The devices 5 which access memory via the SMMU 26 can include cached devices which include an internal cache 7 and uncached devices which do not have any cache. For example, a device 5 could include a display controller for controlling display of image frames on display, a network controller for controlling input or output of data via a network, a hardware accelerator for performing certain dedicated processing functions in a more efficient manner than can be achieved using software executing on a generic processor such as the processor 4, and so on.

[0074] All of the requester devices 4, 5 communicate with each other via an interconnect 8 which is responsible for routing transactions between the requester devices and memory 6. Interconnect 8 may also be responsible for managing coherency between data cached in respective caches 24, 7 of the apparatus. It will be appreciated that Figure 1 is a simplified diagram and the apparatus 2 may have many other components not shown in Figure 1 for conciseness. As shown in Figure 1 , the processor 4 and SMMU 26 each comprise filtering circuitry 20 comprising a granule protection cache 22. The filtering circuitry 20 implements further permission checks on memory accesses issued by the processor 4 or SMMU 26 to the cache 24 or interconnect 8, to determine whether a given memory access satisfy security requirements defined in a granule protection table structure stored in the memory system 6. The granule protection table structure is orthogonal to the at least one translation table structure (e.g. stage 1 and stage 2 translation table structures) used to define address translation mappings and corresponding permissions for pages of memory address space. The granule protection table structure defines, for a number of granules of physical addresses of a given size (e.g. 4 KB or larger), granule protection information indicating a set of granule protection attributes for determining whether a given memory access request is prohibited from being processed by the cache 24 or interconnect 8. The granule protection table structure is looked up based on the target physical address of the memory access determined by the MMU 16 or SMMU 26 based on the address translation mappings for mapping the target virtual address into the target physical address. This contrasts with translation table structures which would be looked up based on a virtual address (for a stage 1 translation table structure) or an intermediate address (for a stage 2 translation table structure). The granule protection cache 22 can cache information derived from the granule protection table structure (or from an indirection table referenced by entries of the granule protection table structure), for faster access by the filtering circuitry 20, so that the filtering circuitry 20 does not need to access the granule protection table structure stored in memory if the required information for checking whether an access to a given physical address is already available in the granule protection cache 22.

[0075] Hence, in general the filtering circuitry 20 may perform a granule protection lookup based on the target physical address obtained by the translation circuitry 16, 26 for a given memory access request, to identify granule protection attributes associated with the target granule physical addresses comprising the target physical address. That granule protection lookup could comprise a lookup in the granule protection cache 22 and / or one or more accesses to portions of the granule protection table structure stored in memory 6 (e.g. a walk of a multi-level table structure, as discussed in more detail below with respect to Figure 4).

[0076] The contents of the granule protection table structure may be controlled by a software process executing at a more privileged execution state than software which controls the translation table structures used by the MMU 16 or SMMU 26 for controlling address translation. For example, where the processor 4 implements a number of exception levels EL0, EL1 , EL2, EL3 with successively increasing levels of privilege, exception level EL1 may be the least privileged exception level at which software is allowed to set a stage 1 translation table base address used by the MMU 16 or SMMU 26 to access the stage 1 translation tables, exception level EL2 may be the least privileged exception level at which software is allowed to set a stage 2 translation table base address used by the MMU 16 or SMMU 26 to access the stage 2 translation tables, and exception level EL3 may be the least privileged exception level at which software is allowed to set granule protection table base address used by the filtering circuitry 20 to access the granule protection table. Hence, the least privileged state allowed to set the base address for the granule protection table structure may be more privileged than the least privileged state allowed to set the base address for any of the translation table structures. The granule protection table base address is prohibited from being updated by a software context processed in at least one execution state for which updates to a base address of the at least one translation table structure are allowed.

[0077] Hence, this means that the granule protection table structure can be used to set additional permissions that are beyond the control of the operating system or hypervisor which typically is allowed to control address translation mappings and permissions in the translation table structures. This can provide added security for workloads which require a guarantee against attack based on a compromised operating system or hypervisor.

[0078] In the examples discussed below, each requester hardware device (e.g. processor 4 or other device 5) is associated with a requester group identifier (RGID) used to group hardware devices capable of initiating accesses to memory into two or more groups. The granule protection attributes associated with a given granule of physical addresses include one or more attributes used by the filtering circuitry 20 to determine which groups of requester hardware devices (as identified by the requester group identifier) are allowed to access (or prohibited from accessing) the given granule physical addresses. This means that it is possible to define permissions which result in two hardware devices having differing rights to access the same granule of physical addresses in the same physical address space, providing greater control over security than would be possible in an example where the RGID based control is not provided.

[0079] Figure 2 is a flow diagram illustrating steps for controlling access to memory using the address translation circuitry (e.g. MMU 16 or SMMU 26) and filtering circuitry 20. At step 400, the address translation circuitry 16, 26 receives a memory access request specifying a target virtual address and a requester group identifier (RGID) associated with the requester hardware device which issue the request. The RGID for the requester hardware device could be a hardwired identifier permanently assigned to the requester hardware device in non-configurable storage, or could be statically programmed by boot code when the apparatus 2 boots up, and then not changed at runtime. Alternatively, the RGID could be stored in configurable storage which is updatable at runtime (e.g. based on instructions executing at the most privileged execution state EL3 that is allowed to set the granule protection table base address). Also, in some cases a given requester hardware device, such as a hardware accelerator or GPU, may have a table identifying RGIDs associated with two or more different execution contexts, and the RGID specified for a given memory access is selected based on which execution context caused that access to be issued. At step 402, the address translation circuitry 16, 26 translates the target virtual address into a target physical address, based on any known address translation technique. The mapping from target virtual address to target physical address may depend on one stage of translation tables, or two stages of translation tables (where the first stage maps the target virtual address to a target intermediate address and the second stage maps the target intermediate address to the target physical address). TLBs 18, 28 may be used to speed up the address translation by caching information derived from lookups of the translation tables, to avoid needing to repeat the lookup if the cached information obtained for one access can be reused for another access.

[0080] At step 404, the address translation circuitry 16, 26 determines whether the memory access request violates any access permissions defined in at least one translation table structure used to define the address translation mapping(s) used to map the target virtual address to the target physical address. If so, then at step 406, the address translation circuitry 16, 26 blocks the memory access request from being issued to a cache 24 or the interconnect 8, and signals a fault.

[0081] If the memory access request passes the checks based on access permissions defined in one or more translation table structures, then at step 408 the filtering circuitry 20 performs the granule protection lookup based on the target physical address generated in the translation at step 402. This lookup could be performed in a granule protection cache 22 (which could be a separate structure from the TLB 18, 28 or could be a combined hardware structure implementing both the TLB 18, 28 and granule protection cache 22 functionality), or the lookup could cause memory access requests to be issued to access portions of a granule protection table stored in memory (the addresses of those memory access requests being identified based on the target physical address, a granule protection table base address and / or one or more pointers obtained from granule protection tables). The granule protection lookup identifies granule protection attributes associated with a target granule physical addresses comprising the target physical address.

[0082] At step 410, based on the granule protection attributes associated with the target granule of physical addresses, the filtering circuitry 20 determines whether the memory access request is prohibited from being processed by cache 24 or memory system interconnect 8. Examples of the checks performed at step 410 are set out in Figures 3 and 16 discussed further below. If the memory access request is not prohibited from being processed by the cache 24 or interconnect 8, at step 412 the filtering circuitry 20 allows the memory access request to be processed by the cache 24 or interconnect 8. If the memory access request is determined to be prohibited from accessing the target granule of physical addresses, the filtering circuitry 20 blocks the memory access request and signals a fault.

[0083] Figure 3 shows in more detail an example of checks performed at step 410. At step 420, the filtering circuitry determines, based on the granule protection attributes associated with the target granule physical addresses and on the RGID specified by the memory access request, whether the granule protection attributes indicates that a group of one or more requester hardware devices associated with the RGID is prohibited from accessing the target granule of physical addresses. If so, then at step 422 the memory access request is determined to be prohibited from being processed by the cache 24 or interconnect 8. If the RGID based check is passed (the requester hardware device associated with the specified RGID can be allowed to access the target granule of physical addresses, depending on results of any other checks), then at step 424 the filtering circuitry 20 determines whether the memory access request violates any other access permission indicated by the growing protection attributes for the target granule. Further examples of other access permissions are discussed in more detail with respect to Figure 16 below. It will be appreciated that the particular permissions implemented in a given apparatus may vary, and where a number of distinct types of checks are required, those checks could be performed in any order or could be performed at least partially in parallel.

[0084] If another type of access permission (other than the RGID-based permission) is not satisfied by the memory access request, then at step 422 the filtering circuitry 20 again determines that the memory access request should be prohibited from being processed by the cache 24 or the interconnect 8. If the memory access request passes any other checks at step 424, then at step 426 the filtering circuitry determines that the memory access request can be allowed to be processed by the cache 24 or memory system interconnect 8.

[0085] Figure 4 illustrates multi-level table structures used for the translation table structures and granule protection table structure (GPT).

[0086] The MMU 16 or SMMU 26 translates virtual addresses to physical addresses based on address mappings. The mappings between virtual addresses and physical addresses are stored in translation tables (sometimes referred to as page tables). Translation tables are stored in memory and are managed by software, typically an OS or hypervisor. The translations tables are not static, and the tables can be updated as the needs of software change. This changes the mapping between virtual and physical addresses. The translation tables can also specify access control attributes such as information on whether a memory region can be accessed by read accesses, write accesses and instruction fetch accesses (for fetching an executable instruction) respectively.

[0087] For memory accesses performed when the processing circuitry 4 is in a certain subset of execution states (in particular, when the processing circuitry 4 is at ELO or EL1 in the exception model discussed further in Figure 7 below), two-stage address translation is used (for other execution states one stage of address translation using the stage- 1 page tables can be sufficient). Hence, the virtual addresses from ELO and EL1 are translated using two sets of tables. These tables support virtualization and allow a hypervisor to virtualize the view of physical memory that is seen by a given virtual machine (VM) (the virtual machine corresponding to a guest operating system and the applications controlled by that guest operating system). We call the set of translations that are controlled by the OS, Stage 1 . The Stage 1 tables translate virtual addresses (VAs) to intermediate physical addresses (IPAs). In Stage 1 , the OS thinks that the IPAs are physical addresses. However, the hypervisor controls a second set of translation mappings, which is called Stage 2. This second set of translation mappings translates IPAs to physical addresses (PAs).

[0088] The stage-1 and stage-2 translation tables are implemented as hierarchical multi-level table structures comprising a number of levels of translation tables as shown in Figure 4. In this example, both the stage-1 and stage-2 tables can have up to 4 levels of page tables, namely level 0 (L0), level 1 (L1 ), level 2 (L2) and level 3 (L3).

[0089] To locate the physical address mapping for a given address, a translation table walk is performed comprising one or more translation table lookups. The translation table walk is the set of lookups (memory accesses) that are required to translate the virtual address to the physical address. For the EL1 &0 translation regime, this set includes lookups for both the stage 1 translation and the stage 2 translation. The information returned by a successful translation table walk using stage-1 and stage-2 lookups is:

[0090] • The required physical address (translated based on the stage-1 mapping to the intermediate address and the stage-2 mapping to the physical address).

[0091] • Access permissions and / or memory attributes for the target memory region, which provide information about how to control access to that memory region. These may include stage- 1 access permissions and / or attributes defined in the stage-1 table structure and stage-2 access permissions and / or attributes defined in the stage-2 table structure.

[0092] For traversing a given one of the stage-1 and stage-2 structures, the walk starts with a read of a top-level (L0) translation table for the initial lookup, based on an address specified in a translation table base address register (e.g. TTBR for stage 1 , VTTBR EL2 for stage 2). Each translation table lookup returns a descriptor, that indicates one of the following:

[0093] • The entry is the final entry of the traversal of the stage-1 or stage-2 structure, which provides the address mapping and memory region permissions / attributes being sought. If the entry is in the final level table L3, this entry is called a Page descriptor (D Page), while if the entry providing the final entry of the walk is at one of the higher levels it is called a Block descriptor (D BIock). The final entry of the traversal contains the output address (i.e. IPA for stage 1 or PA for stage 2), and the permissions and attributes for the access. If a Block descriptor is found at a higher level of the translation table structure, this means that the Block descriptor represents a memory region of greater size than a 4kB memory page represented by a single entry at L3 (the particular sizes represented by Block descriptors at L1 and L2 being dependent on the number of index bits used to index into the L1 or L2 tables - for example L1 and L2 Block descriptors could represent 1 GB and 2MB regions respectively).

[0094] • An additional level of lookup is required. In this case, the entry is called a Table descriptor (D Table), since it provides a pointer indicating the translation table base address for that lookup in a further level of table. The Table descriptor can optionally also provide other hierarchical attributes that can be applied to the final translation. An encoding of translation table entries at levels 1 and 2 distinguishes a Block descriptor from a Table descriptor.

[0095] • The descriptor is invalid. In this case, the memory access generates a Translation fault.

[0096] Figure 4 illustrates indexing of the stage-1 and stage-2 translation tables using index values derived as a function of bits of the VA (for stage-1 ) or IPA (for stage-2). The particular entry to select within a given level of stage-1 translation table is determined based on an index value which corresponds to, or is derived from, a certain subset of bits of the VA or IPA provided as input address for the lookup. Each level is indexed based on a different subset of bits of the VA or IPA, with a given level being indexed based on a more significant portion of bits of the VA / IPA than the next level in the structure (e.g. L2 is indexed using a less significant portion of bits than L1 ). The address of the relevant entry in a given table is obtained by adding a multiple of the index bits to the base address of that given table as determined based on TTBR or the address specified in a Table descriptor at the previous level (the multiplier applied to the index value corresponding to the size of one translation table entry).

[0097] In practice when the full translation table walk including both stage-1 and stage-2 translation is performed, then each stage- 1 table base address obtained from the TTBR and the Table descriptors accessed in the stage-1 L0, L1 , L2 translation tables will be an intermediate address which itself needs translating using the stage-2 transition tables. Hence, in cases when the translation table walk does not encounter any Block descriptors, but proceeds all the way to L3 where a Page descriptor is found, then the full page table walk process may include 24 memory accesses (4 lookups for stage-1 , and 5*4 lookups for stage-2, where the translation of each of the 4 stage-1 table base addresses (L0-L3) and the final IPA returned by the stage-1 L3 address mapping causes a separate set of 4 lookups to the stage-2 L0-L3 tables for each of those 5 addresses).

[0098] Hence, without any caching, performing the entire page table walk process can be very slow as it may require a large number of accesses to memory to step through each of the levels of page tables for each of the stages of address translation. This is why it is often desirable to cache information derived from translation table walks in the TLB 18, 28 of the MMU 16 or SMMU 28. The cached information can include any of:

[0099] - a final stage- 1 address mapping from VA to IPA,

[0100] - a final stage-2 mapping from IPA to PA

[0101] - a combined stage-1 and stage-2 mapping from VA direct to PA (derived from previous lookups of the stage 1 and stage 2 structures),

[0102] - access permissions and attributes obtained from the stage-1 and stage-2 structures; and

[0103] - translation table pointers derived from entries from higher level page tables of the stage 1 and the stage 2 tables. This can allow at least some steps of the full page table walk to be bypassed even if the final level address mapping for a given target address is not currently in the address translation cache.

[0104] As shown in Figure 4, the GPT may have a similar multi-level structure to the translation tables, although the maximum number of levels may differ from the maximum number of levels for the translation table structures. The GPT is accessed based on a granule protection table base address obtained from a register of the processor 4 or SMMU 28 that is writable by software operating at the supervisory execution state EL3 and is not writable in less privileged execution states EL1 and EL2 which are allowed to update the registers storing the base addresses for the stage- 1 and stage-2 tables respectively (software operating at EL2 may also be allowed to set the stage-1 base address). Hence, the least privileged state allowed to set the stage-1 base address is EL1 , the least privileged state allowed to set the stage-2 base address is EL2, and the least privileged state allowed to set the GPT base address is EL3.

[0105] Unlike the translation tables, the GPT is a physically-addressed table, where the traversal is based on the PA generated in the translation performed by the MMU 16 or SMMU 28 based on the mappings from the translation tables.

[0106] The GPT associates a set of “granule protection information” (GPI) with each region of physical addresses. Each GPI may be associated with a granule of physical addresses of a certain size, e.g. 4KB if the GPI is defined in the final-level table of the GPT structure. As the GPI does not need to specify an address translation mapping, the GPI for a given 4KB region can be much smaller than the translation table entry providing the address mapping for the region, and so multiple GPIs for respective 4KB regions can be packed into a single cache line, so that the GPT structure can be more compact than the translation tables and so a structure involving fewer table levels can be practical. For example, Figure 4 shows an example of a GPT with a two-level structure, with the L1 GPT being accessed based on a table pointer provided by an entry of the L0 GPT corresponding to the target PA. The index used for each level of GPT is selected based on a respective subset of bits of the target PA, with the L1 table being indexed using a less significant portion of bits of the target PA than the portion of bits used for indexing the L0 table. It will be appreciated that a 2-level GPT structure is just one example, and other examples could have a different number of GPT levels depending on the granularity (region size) for which the GPI is defined and the size of the GPI for a given region. Each GPI can specify at least the RGID- based permissions mentioned above, but can also describe other pieces of protection information as explained in further examples below.

[0107] Although in some examples, the GPI may directly indicate any attributes associated with the corresponding granule of PAs, it is also possible to use indirection to define the attributes associated with the granule of Pas. As shown in Figure 5, the GPI may specify a pointer (indirection entry identifier) identifying a corresponding entry of an indirection table 427. The indirection table 427 is a further memory-based structure (information from which could be cached in a cache). In some examples, the entire set of bits of the GPI indicates the indirection pointer, so the GPI does not directly encode any other attributes other than the indirection pointer. In other examples, the GPI directly encoded in the GPT could also specify at least one directly- encoded attribute, as well as the pointer to the indirection table. Similar to the addresses used for the GPT itself, software may ensure that the indirection table is protected against unauthorized updates by setting the GPI entries of the GPT corresponding to the physical addresses corresponding to the indirection table to indicate that the indirection table addresses are accessible only to software executing in the most privileged exception level EL3 (e.g. by setting the GPI to restrict access to the Root PAS mentioned below), and any base address associated with the indirection table may also be restricted to be updated in the most privileged exception level EL3 and may not be updatable from EL0-EL2.

[0108] Each entry of the indirection table 427 may have a size less than, equal to, or greater than the size of a given GPI entry. The use of indirection can be particularly useful when the indirection table entries each comprise a greater number of bits than the number of bits in the GPI, as this allows a wider range of permissions / attributes to be supported than would fit in the available encoding space of the GPI. However, even if the size of an entry of the indirection table 427 is less than or equal to the size of a given GPI entry, use of indirection can still be beneficial to allow a single update to an indirection table entry to effectively change the attributes associated with multiple granules of address space (as writing to a single indirection table entry can be faster than writing to many different GPI entries pointing to that indirection entry).

[0109] The principles discussed above are now applied in a further example. Hence, the features discussed earlier are still relevant to the subsequent examples. However, further detail is provided in the particular examples discussed below.

[0110] Figure 6 schematically illustrates an example of an apparatus (e.g. 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 devices 4 and completer devices 6. A requester device is capable of issuing memory access requests requesting a memory access to a particular addressable memory system location. A completer device 6 is a device that has responsibility for servicing memory access requests directed to it. Although not shown in Figure 6, some devices may be capable of acting both as a requester device and as a completer device. The requester devices 4 may for example include processing elements such as a central processing unit (CPU) or graphics processing unit (GPU) or other master devices such as bus master devices, network interface controllers, display controllers, hardware accelerators, I / O devices, etc. The completer devices may include memory controllers responsible for controlling access to corresponding memory storage units, peripheral controllers for controlling access to a peripheral device, etc. Figure 6 shows an example configuration of one of the requester devices 4 in more detail but it will be appreciated that the other requester devices 4 could have a similar configuration. Alternatively, the other requester devices may have a different configuration to the requester device 4 shown on the left of Figure 6 (e.g. in some cases one of the requester devices 4 may not have the address translation circuitry 16 and PAS filter 20 itself, but may instead rely on these functions being provided within a system memory management unit (SMMU) 26 as shown for devices 5 in the example of Figure 1 ).

[0111] The requester device 4 shown in Figure 6 has processing circuitry 10 for performing data processing in response to instructions, with reference to data stored in registers 12. The 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 domain of operation is the current domain, and a current exception level indication 15 indicating which exception level is the current exception level in which the processing circuitry 10 is operating.

[0112] The processing circuitry 10 may be capable of issuing memory access requests specifying a virtual address (VA) identifying the addressable location to be accessed and a domain identifier (Domain ID or ‘security state’) identifying the current domain. Address translation circuitry 16 (e.g. a memory management unit (MMU)) translates the virtual address into a physical address (PA) through one of more stages of address translation based on page table data defined in page table structures stored in the memory system. A translation lookaside buffer (TLB) 18 acts as a lookup cache for caching some of that page table information for faster access than if the page table information had to be fetched from memory each time an address translation is required. In this example, as well as generating the physical address, the address translation circuitry 16 also selects one of a number of physical address spaces associated with the physical address and outputs a physical address space (PAS) identifier identifying the selected physical address space. Selection of the PAS will be discussed in more detail below.

[0113] A PAS filter 20 acts as the filtering circuitry mentioned in the earlier example, and is for checking, based on the translated physical address and the PAS identifier, whether that physical address is allowed 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. The granule protection information may be cached within a granule protection information cache 22, similar to caching of page table data in the TLB 18. While the granule protection information cache 22 is shown as a separate structure from the TLB 18 in the example of Figure 6, in other examples these types of lookup caches could be combined into a single lookup cache structure so that a single lookup of an entry of the combined structure provides both the page table information and the granule protection information. The granule protection information defines information restricting the physical address spaces from which a given physical address can be accessed, and based on this lookup the PAS filter 20 determines whether to allow the memory access request to proceed to be issued to one or more caches 24 and / or the interconnect 8. If the specified PAS for the memory access request is not allowed to access the specified physical address then the PAS filter 20 blocks the transaction and may signal a fault.

[0114] While Figure 6 shows an example with a system having multiple requester devices 4, the features shown for the one requester device on the left hand side of Figure 6 could also be included in a system where there is only one requester device, such as a single-core processor.

[0115] While Figure 6 shows an example where selection of the PAS for a given request is performed by the address translation circuitry 16, in other examples information for determining which PAS to select can be output by the address translation circuitry 16 to the PAS filter 20 along with the PA, and the PAS filter 20 may select the PAS and check whether the PA is allowed to be accessed within the selected PAS. Hence, PAS selection circuitry could be provided by either the address translation circuitry 16, or the PAS filter 20, or both working together.

[0116] The provision of the PAS filter 20 helps to support a system which can operate in a number of domains of operation each associated with its own isolated physical address space where, for at least part of the memory system (e.g. for some caches or coherency enforcing mechanisms such as a snoop filter), the separate physical address spaces are treated as if they refer to completely separate sets of addresses identifying separate memory system locations, even if addresses within those address spaces actually refer to the same physical location in the memory system. This can be useful for security purposes.

[0117] Figure 7 shows an example of different operating states and domains in which the processing circuitry 10 can operate, and an example of types of software which could be executed in the different exception levels and domains (of course, it will be appreciated that the particular software installed on a system is chosen by the parties managing that system and so is not an essential feature of the hardware architecture).

[0118] The processing circuitry 10 is operable at a number of different exception levels (also referred to as “execution states” above) 80, in this example four exception levels labelled EL0, EL1 , EL2 and EL3, where in this example EL3 refers to the exception level with the greatest level of privilege while EL0 refers to the exception level with the least privilege. It will be appreciated that other architectures could choose the opposite numbering so that the exception level with the highest number could be considered to have the lowest privilege. 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 which manages switching between a number of virtualised operating systems, while the most privileged exception level EL3 is used for monitor code which manages switches between respective domains and allocation of physical addresses to physical address spaces, as described later.

[0119] When an exception occurs while processing software in a particular exception level, for some types of exceptions, the exception is taken to a higher (more privileged) exception level, with the particular exception level in which the exception is to be taken being selected based on attributes of the particular exception which occurred. However, it may be possible for other types of exceptions to be taken at the same exception level as the exception level associated with the code being processed at the time an exception was taken, in some situations. When an exception is taken, information characterising the state of the processor at the time the exception was taken may be saved, including for example the current exception level at the time the exception was taken, and so once an exception handler has been processed to deal with the exception, processing may then return to the previous processing and the saved information can be used to identify the exception level to which processing should return.

[0120] In addition to the different exception levels, the processing circuitry also supports a number of domains of operation (also known as “security states”), the domains including a root domain 82, a secure (S) domain 84, a less secure domain 86 and a realm domain 88. For ease of reference, the less secure domain will be described below as the “non-secure” (NS) domain, but it will be appreciated that this is not intended to imply any particular level of (or lack of) security. Instead, “non-secure” merely indicates that the non-secure domain is intended for code which is less secure than code operating in the secure domain. The root domain 82 is selected when the processing circuitry 10 is in the highest exception level EL3. When the processing circuitry is in one of the other exception levels ELO to EL2, the current domain is selected based on the current domain indicator 14, which indicates which of the other domains 84, 86, 88 is active. For each of the other domains 84, 86, 88 the processing circuitry could be in any of the exception levels ELO, EL1 or EL2.

[0121] At boot time, a number of pieces of boot code (e.g. BL1 , BL2, OEM Boot) may be executed, e.g. within the more privileged exception levels EL3 or EL2. The boot code BL1 , BL2 may be associated with the root domain for example and the OEM boot code may operate in the Secure domain. However, once the system is booted, at runtime the processing circuitry 10 may be considered to operate in one of the domains 82, 84, 86 and 88 at a time. Each of the domains 82 to 88 is associated with its own associated physical address space (PAS) which enables isolation of data from the different domains within at least part of the memory system. This will be described in more detail below.

[0122] The non-secure domain 86 can be used for regular application-level processing, and for the operating system and hypervisor activity for managing such applications. Hence, within the non-secure domain 86, there may be application code 30 operating at ELO, operating system (OS) code 32 operating at EL1 and hypervisor code 34 operating at EL2.

[0123] The secure domain 84 enables certain system-on-chip security, media or system services to be isolated into a separate physical address space from the physical address space used for non-secure processing. The secure and non-secure domains are not equal, in the sense that the non-secure domain code cannot access resources associated with the secure domain 84, while the secure domain can access both secure and non-secure resources (at least for regions of memory for which the predetermined less-secure memory property described further below is not defined). An example of a system supporting such partitioning of secure and non-secure domains 84, 86 is a system based on the TrustZone® architecture provided by Arm® Limited. The secure domain can run trusted applications 36 at ELO, a trusted operating system 38 at EL1 , as well as optionally a secure partition manager 40 at EL2 which may, if secure partitioning is supported, use stage 2 page tables to support isolation between different trusted operating systems 38 executing in the secure domain 84 in a similar way to the way that the hypervisor 34 may manage isolation between virtual machines or guest operating systems 32 executing in the non-secure domain 86.

[0124] Extending the system to support a secure domain 84 has become popular in recent years because it enables a single hardware processor to support isolated secure processing, avoiding the need for the processing to be performed on a separate hardware processor. However, with the increasing popularity of use of the secure domain, many practical systems having such a secure domain now support, within the secure domain, a relatively sophisticated mixed environment of services which are provided by a wide range of different software providers. For example the code operating in the secure domain 84 may include different pieces of software provided by (among others): the silicon provider who manufactured the integrated circuit, an original equipment manufacturer (OEM) who assembles the integrated circuit provided by the silicon provider into an electronic device such as a mobile telephone, an operating system vendor (OSV) who provides the operating system 32 for the device; and / or a cloud platform provider who manages a cloud server supporting services for a number of different clients through the cloud.

[0125] However, increasingly there is a desire for parties providing user-level code (which might normally be expected to execute as applications 30 within the non-secure domain 86) to be provided with secure computing environments which can be trusted not to leak information to other parties operating code on the same physical platform. It may be desirable for such secure computing environments to be dynamically allocatable at runtime, and to be certified and attestable so that the user is able to verify whether sufficient security guarantee is provided on the physical platform, before trusting the device to process potentially sensitive code or data. A user of such software may not wish to trust the party providing a rich operating system 32 or hypervisor 34 which might normally operate in the non-secure domain 86 (or even if those providers themselves can be trusted, the user may wish to protect themselves against the operating system 32 or hypervisor 34 being compromised by an attacker). Also, while the secure domain 84 could be used for such user-provided applications needing secure processing, in practice this causes problems both for the user providing the code requiring the secure computing environment and for the providers of existing code operating within the secure domain 84. For the providers of existing code operating within the secure domain 84, the addition of arbitrary user-provided code within the secure domain would increase the attack surface for potential attacks against their code, which may be undesirable, and so allowing users to add code into the secure domain 84 may be strongly discouraged. On the other hand, the user providing the code requiring the secure computing environment may not be willing to trust all of the providers of the different pieces of code operating in the secure domain 84 to have access to its data or code, if certification or attestation of the code operating in a particular domain is needed as a prerequisite for the user-provided code to perform its processing, it may be difficult to audit and certify all of the distinct pieces of code operating in the secure domain 84 provided by the different software providers, which may limit the opportunities for third parties to provide more secure services.

[0126] Therefore, as shown in Figure 7, an additional more secure domain 88, called the realm domain, is provided which can be used by such user-introduced code to provide a secure computing environment orthogonal to any secure computing environment associated with components operating in the secure domain 24. In the realm domain, the software executed can include a number of realms, where each realm can be isolated from other realms by a realm management module (RMM) 46 operating at exception level EL2. The RMM 46 may control isolation between the respective realms 42, 44 executing the realm domain 88, for example by defining access permissions and address mappings in page table structures similar to the way in which hypervisor 34 manages isolation between different components operating in the nonsecure domain 86. In this example, the realms include an application-level realm 42 which executes at ELO and an encapsulated application / operating system realm 44 which executes across exception levels ELO and EL1 . It will be appreciated that it is not essential to support both ELO and EL0 / EL1 types of realms, and that multiple realms of the same type could be established by the RMM 46.

[0127] The realm domain 88 has its own physical address space allocated to it, similar to the secure domain 84, but the realm domain is orthogonal to the secure domain 84 in the sense that while the realm and secure domains 88, 84 can each access the non-secure PAS associated with the non-secure domain 86, the realm and secure domains 88, 84 cannot access each other’s physical address spaces. This means that code executing in the realm domain 88 and secure domains 84 have no dependencies on each other. Code in the realm domain only needs to trust the hardware, the RMM 46 and the code operating in the root domain 82 which manages switching between domains, which means attestation and certification becomes more feasible. Attestation enables a given piece of software to request verification that code installed on the device matches certain anticipated properties. This could be implemented by checking whether a hash of the program code installed on the device matches an expected value that is signed by a trusted party using a cryptographic protocol. The RMM 46 and monitor code 29 could for example be attested by checking whether a hash of this software matches an expected value signed by a trusted party, such as the silicon provider who manufactured the integrated circuit comprising the processing system 2 or an architecture provider who designed the processor architecture which supports the domain-based memory access control. This can allow user- provided code 42, 44 to verify whether the integrity of the domain-based architecture can be trusted prior to executing any secure or sensitive functions. Hence, it can be seen that the code associated with realms 42, 44, which would previously have executed in the non-secure domain 86 as shown by the dotted lines showing the gap in the non-secure domain where these processes would previously have executed, can now be moved to the realm domain where they may have stronger security guarantees because their data and code is not accessible by other code operating in a non-secure domain 86. However, due to the fact that the realm domain 88 and secure domain 84 are orthogonal and so cannot see each other’s physical address spaces, this means that the providers of code in the realm domain do not need to trust the providers of code in the secure domain and vice versa. The code in the realm domain can simply trust the trusted firmware providing the monitor code 29 for the root domain 82 and the RMM 46, which may be provided by the silicon provider or the provider of the instruction set architecture supported by the processor, who may already inherently need to be trusted when the code is executing on their device, so that no further trust relationships with other operating system vendors, OEMs or cloud hosts are needed for the user to be able to be provided with a secure computing environment.

[0128] This can be useful for a range of applications and use cases, including for example mobile wallet and payment applications, gaming anti-cheating and piracy mechanisms, operating system platform security enhancements, secure virtual machine hosting, confidential computing, networking, or gateway processing for Internet of Things devices. It will be appreciated that users may find many other applications where the realm support is useful.

[0129] To support the security guarantees provided to a realm, the processing system may support an attestation report function, where at boot time or at run time measurements are made of firmware images and configuration, e.g. monitor code images and configuration or RMM code images and configuration and at runtime realm contents and configuration are measured, so that the realm owner can trace the relevant attestation report back to known implementations and certifications to make a trust decision on whether to operate on that system.

[0130] As shown in Figure 7, a separate root domain 82 is provided which manages domain switching, and that root domain has its own isolated root physical address space. The creation of the root domain and the isolation of its resources from the secure domain allows for a more robust implementation even for systems which only have the non-secure and secure domains 86, 84 but do not have the realm domain 88, but can also be used for implementations which do support the realm domain 88. The root domain 82 can be implemented using monitor software 29 provided by (or certified by) the silicon provider or the architecture designer, and can be used to provide secure boot functionality, trusted boot measurements, system-on-chip configuration, debug control and management of firmware updates of firmware components provided by other parties such as the OEM. The root domain code can be developed, certified and deployed by the silicon provider or architecture designer without dependencies on the final device. In contrast the secure domain 84 can be managed by the OEM for implementing certain platform and security services. The management of the non-secure domain 86 may be controlled by an operating system 32 to provide operating system services, while the realm domain 88 allows the development of new forms of trusted execution environments which can be dedicated to user or third party applications while being mutually isolated from existing secure software environments in the secure domain 84.

[0131] Figure 8 schematically illustrates another example of a processing system 2 for supporting these techniques. Elements which are the same as in Figure 6 are illustrated with the same reference numeral. Figure 8 shows more detail in the address translation circuitry 16, which comprises stage 1 and stage 2 memory management units 50, 52. The stage 1 MMU 50 may be responsible for translating virtual addresses to either physical addresses (when the translation is triggered by EL2 or EL3 code) or to intermediate addresses (when the translation is triggered by ELO or EL1 code in an operating state where a further stage 2 translation by the stage 2 MMU 52 is required). The stage 2 MMU may translate intermediate addresses into physical addresses. The stage 1 MMU may be based on page tables controlled by an operating system for translations initiated from ELO or EL1 , page tables controlled by a hypervisor for translations from EL2, or page tables controlled by monitor code 29 for translations from EL3. On the other hand, the stage 2 MMU 52 may be based on page table structures defined by a hypervisor 34, RMM 46 or secure partition manager 14 depending on which domain is being used. Separating the translations into two stages in this way allows operating systems to manage address translation for themselves and applications under the assumption that they are the only operating system running on the system, while the RMM 46, hypervisor 34 or SPM40 may manage isolation between different operating systems running in the same domain.

[0132] As shown in Figure 8, the address translation process using the address translation circuitry 16 may return security attributes 54 which, in combination with the current exception level 15 and the current domain 14 (or security state), allow section of a particular physical address space (identified by a PAS identifier or “PAS TAG”) to be accessed in response to a given memory access request. The physical address and PAS identifier may be looked up in a granule protection table 56 which provides the granule protection information described earlier. In this example the PAS filter 20 is shown as a granular memory protection unit (GMPU) which verifies whether the selected PAS is allowed to access the requested physical address and if so allows the transaction to be passed to any caches 24 or interconnect 8 which are part of the system fabric of the memory system.

[0133] The GMPU 20 allows assigning memory to separate address spaces while providing a strong, hardware-based, isolation guarantee and providing spatial and temporal flexibility in the assignment methods of physical memory into these address spaces, as well as efficient sharing schemes. As described earlier, the execution units in the system are logically partitioned to virtual execution states (domains or “Worlds”) where there is one execution state (Root world) located at the highest exception level (EL3), referred to as the “Root World” that manages physical memory assignment to these worlds. 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 to a single “Logical” Physical Address Space by extending it with a PAS tag.

[0134] A given World is allowed access to a subset of Logical Physical Address Spaces. This is enforced by a hardware filter 20 that can be attached to the output of the Memory Management Unit 16.

[0135] A World defines the security attributes (the PAS tag) of the access using fields in the Translation Table Descriptor of the page tables used for address translation. The hardware filter 20 has access to a table (Granule Protection Table 56, or GPT) that defines for each page in the system physical address space granule protection information (GPI) indicating the PAS TAG it is associated with and (optionally) other Granule Protection attributes.

[0136] The hardware filter 20 checks the World ID and the Security Attributes against the Granule’s GPI and decides if access can be granted or not, thus forming a Granular Memory Protection Unit (GMPU).

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

[0138] Locating the GMPU 20 on the requester-side of the system (e.g. on the MMU output) rather than on the completer-side allows allocating access permissions in page granularity while permitting the interconnect 8 to continue hashing / striping the page across multiple DRAM ports.

[0139] Transactions remain tagged with the PAS TAG as they propagate throughout the system fabric 24, 8 until reaching a location defined as the Point of Physical Aliasing 60. This allows to locate the filter on the Master-side without diminishing the security guarantees comparing to Slave-side filtering. As the transaction propagates throughout the system, the PAS TAG can be used as an in-depth security mechanism for address isolation: e.g. caches can add the PAS TAG to the address tag in the cache, preventing accesses made to the same PA using the wrong PAS TAG from hitting in the cache and therefore improving side-channel resistance. The PAS TAG can also be used as context selector for a Protection Engine attached to the memory controller that encrypts data before it is written to external DRAM.

[0140] The Point of Physical Aliasing (PoPA) is a location in the system where the PAS TAG is stripped and the address changes back from a Logical Physical Address to a System Physical Address. The PoPA can be located below the caches, at the completer-side of the system where access to the physical DRAM is made (using encryption context resolved through the PAS TAG). Alternatively, it may be located above the caches to simplify system implementation at the cost of reduced security.

[0141] At any point in time, a world can request to transition a page from one PAS to another. The request is made to the monitor code 29 at EL3 which inspects the current state of the GPI. EL3 may only allow a specific set of transitions to occur (e.g. from Non-secure PAS to Secure PAS but not from Realm PAS to Secure PAS - another supported transition may be between Non-Secure PAS with the predetermined less secure memory property and Non-Secure PAS with the second less secure memory property). To provide a clean transition, a new instruction is supported by the System - “Data Clean and Invalidate to the Point of Physical Aliasing” which EL3 can submit before transitioning a page to the new PAS - this guarantees that any residual state associated with the previous PAS is flushed from any caches upstream of (closer to the requester-side than) the PoPA 60.

[0142] 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 grant a subset of N worlds with shared access to a physical granule while preventing other worlds from accessing it. This can be achieved by adding a “restrictive shared” semantic to the Granule Protection Information, while forcing it to use a specific PAS TAG. As an example, the GPI can indicate that a physical Granule is can accessed only by “Realm World” 88 and “Secure World” 84 while being tagged with the PAS TAG of the Secure PAS 84.

[0143] An example of the above property is making fast changes in the visibility properties of a specific physical granule. Consider a case where each world is assigned with a private PAS that is only accessible to that World. For specific granules, the World can request to make them visible to the Non-Secure world at any point in time by changing their GPI from “exclusive” to “restrictive shared with Non-Secure world”, and without changing the PAS association. This way, the visibility of that granule can be increased without requiring costly cache-maintenance or data copy operations.

[0144] Figure 9 illustrates the concept of aliasing of the respective physical address spaces onto physical memory provided in hardware. As described earlier, each of the domains 82, 84, 86, 88 has its own respective physical address space 61 .

[0145] At the point when a physical address is generated by address translation circuitry 16, the physical address has a value within a certain numeric range 62 supported by the system, which is the same regardless of which physical address space is selected. However, in addition to the generation of the physical address, the address translation circuitry 16 may also select a particular physical address space (PAS) based on the current domain 14 and / or information in the page table entry used to derive the physical address. Alternatively, instead of the address translation circuitry 16 performing the selection of the PAS, the address translation circuitry (e.g. MMU) could output the physical address and the information derived from the page table entry (PTE) which is used for selection of the PAS, and then this information could be used by the PAS filter or GMPU 20 to select the PAS.

[0146] The selection of PAS for a given memory access request may be restricted depending on the current domain in which the processing circuitry 10 is operating when issuing the memory access request, according to rules defined in the following table:

[0147] For those domains for which there are multiple physical address spaces available for selection, the information from the accessed page table entry used to provide the physical address is used to select between the available PAS options. For the entries in the table marked * regarding access to the Non-Secure PAS, whether the Secure and Realm domains are able to access the Non-Secure PAS also depends on whether the predetermined less-secure memory property defined earlier has been specified in the granule protection information (GPI) for the PA being accessed (at least in some modes of operation - it is possible to provide a mode where use of this property is disabled for backwards compatibility reasons).

[0148] Hence, at the point when the PAS filter 20 outputs a memory access request to the system fabric 24, 8 (assuming it passed any filtering checks), the memory access request is associated with a physical address (PA) and a selected physical address space (PAS).

[0149] From the point of view of memory system components (such as caches, interconnects, snoop filters etc.) which operate before the point of physical aliasing (PoPA) 60, the respective physical address spaces 61 are viewed as entirely separate ranges of addresses which correspond to different system locations within memory. This means that, from the point of view of the pre-PoPA memory system components, the range of addresses identified by the memory access request is actually four times the size of the range 62 which could be output in the address translation, as effectively the PAS identifier is treated as additional address bits alongside the physical address itself, so that depending on which PAS is selected the same physical address PAx can be mapped to a number of aliasing physical addresses 63 in the distinct physical address spaces 61. These aliasing physical addresses 63, all actually correspond to the same memory system location implemented in physical hardware, but the pre-PoPA memory system components treat aliasing addresses 63 as separate addresses. Hence, if there are any pre- PoPA caches or snoop filters allocating entries for such addresses, the aliasing addresses 63 would be mapped into different entries with separate cache hit / miss decisions and separate coherency management. This reduces likelihood or effectiveness of attackers using cache or coherency side channels as a mechanism to probe the operation of other domains.

[0150] The system may include more than one PoPA 60 (e.g. memory access requests specifying different physical addresses may be routed via different paths through the memory system and may be handled by different PoPAs 60). At each PoPA 60, the aliasing physical addresses are collapsed into a single de-aliased address 65 in the system physical address space 64. The dealiased address 65 is provided downstream to any post-PoPA components, so that the system physical address space 64 which actually identifies memory system locations is once more of the same size as the range of physical addresses that could be output in the address translation performed on the requester side. For example, at the PoPA 60 the PAS identifier may be stripped out from the addresses, and for the downstream components the addresses may simply be identified using the physical address value, without specifying the PAS. Alternatively, for some cases where some completer-side filtering of memory access request is desired, the PAS identifier could still be provided downstream of the PoPA 60, but may not be interpreted as part of the address so that the same physical addresses appearing in different physical address spaces 60 would be interpreted downstream of the PoPA as referring to the same memory system location, but the supplied PAS identifier can still be used for performing any completer-side security checks.

[0151] Figure 10 illustrates how the system physical address space 64 can be divided, using the granule protection table 56, into chunks allocated for access within a particular architectural physical address space 61 . The granule protection table (GPT) 56 defines which portions of the system physical address space 65 are allowed to be accessed from each architectural physical address space 61. For example the GPT 56 may comprise a number of entries each defining granule protection information (GPI) corresponding to a granule of physical addresses of a certain size (e.g. a 4K page). The GPI may assign a particular PAS for that granule, or may indicate that more than one PAS can be used to access the granule. In some examples, for at least one setting of the GPI, the GPI may also impose a further requirement regarding which domain is the input domain that triggered generation of the memory access request. If a particular granule or set of granules of physical memory address space is defined in the GPT as being accessible from only one PAS, then it can only be accessed within that PAS and cannot be accessed within the PASs of the other domains. However, note that while a granule allocated to the secure PAS (for instance) cannot be accessed from within the root PAS, the root domain 82 is nevertheless able to access that granule of physical addresses by specifying in its page tables the PAS selection information for ensuring that virtual addresses associated with pages which map to that region of physical addressed memory are translated into a physical address in the secure PAS instead of the root PAS. Hence, the sharing of data across domains (to the extent permitted by the accessibility / inaccessibility rules defined in the table described earlier) may be controlled at the point of selecting the PAS for a given memory access request.

[0152] However, in some implementations, in addition to allowing a granule of physical addresses to be accessed within a single assigned PAS defined by the GPT, the GPT could use other GPT attributes to mark certain regions of the address space as shared with another address space (e.g. an address space associated with a domain of lower or orthogonal privilege which would not normally be allowed to select the assigned PAS for that domain’s access requests). This can facilitate temporary sharing of data without needing to change the assigned PAS for a given granule. For example, in Figure 10 the region 70 of the realm PAS is defined in the GPT as being assigned to the realm domain, so normally it would be inaccessible from the non-secure domain 86 because the non-secure domain 86 cannot select the realm PAS for its access requests. As the non-secure domain 26 cannot access the realm PAS, then normally non-secure code could not see the data in region 70. However, if the realm temporarily wishes to share some of its data in its assigned regions of memory with the non-secure domain then it could request that the monitor code 29 operating in the root domain 82 updates the GPT 56 to indicate that region 70 is to be shared with the non-secure domain 86, and this may make region 70 also be accessible from the non-secure PAS as shown on the left hand side of Figure 5, without needing to change which domain is the assigned domain for region 70. If the realm domain has designated a region of its address space as shared with the non-secure domain, then although the memory access requests targeting that region which are issued from the non-secure domain may initially specify the non-secure PAS, the PAS filter 20 may remap the PAS identifier of the request to specify the realm PAS instead, so that downstream memory system components treat the request as if it was issued from the realm domain all along. This sharing can improve performance because the operations for assigning a different domain to a particular memory region may be more performance intensive involving a greater degree of cache / TLB invalidation and / or data zeroing in memory or copying of data between memory regions, which may be unjustified if the sharing is only expected to be temporary.

[0153] Other implementations may not support such sharing options and so the GPT may restrict each physical address to being accessible through one PAS only.

[0154] Figure 11 is a flow diagram showing how to determine the current domain of operation, which could be performed by the processing circuitry 10 or by address translation circuitry 16 or the PAS filter 20. At step 100 it is determined whether the current exception level 15 is EL3 and if so then at step 102 the current domain is determined to be the root domain 82. If the current exception level is not EL3, then at step 104 the current domain is determined to be one of the non-secure, secure and realm domains 86, 84, 88 as indicated by at least two domain indicating bits 14 within an EL3 control register of the processor (as the root domain is indicated by the current exception level being EL3, it may not be essential to have an encoding of the domain indicating bits 14 corresponding to the root domain, so at least one encoding of the domain indicating bits could be reserved for other purposes). The EL3 control register is writable when operating at EL3 and cannot be written from other exception levels EL2-EL0.

[0155] Figure 12 shows an example of page table entry (PTE) formats which can be used for page table entries in the page table structures (also referred to as translation table structures earlier) used by the address translation circuitry 16 for mapping virtual addresses to physical addresses, mapping virtual addresses to intermediate addresses or mapping intermediate addresses to physical addresses (depending on whether translation is being performed in an operating state where a stage 2 translation is required at all, and if stage 2 translation is required, whether the translation is a stage 1 translation or a stage 2 translation). In general, as shown in Figure 4 discussed earlier, a given page table structure may be defined as a multi-level table structure which is implemented as a tree of page tables where a 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 an index selecting a particular level 1 page table entry within the page table is derived from a subset of bits of the input address for which the translation lookup is being performed (the input address could be a virtual address for stage 1 translations of an intermediate address for stage 2 translations). The level 1 page table entry may be a “table descriptor” 110 which provides a pointer 1 12 to a next level page table, from which a further page table entry can then be selected based on a further subset of bits of the input address. Eventually, after one or more lookups to successive levels of page tables, a block or page descriptor PTE 1 14, 1 16, 118 may be identified which provides an output address 120 corresponding to the input address. The output address could be an intermediate address (for stage 1 translations performed in an operating state where further stage 2 translation is also performed) or a physical address (for stage 2 translations, or stage 1 translations when stage 2 is not needed).

[0156] To support the distinct physical address spaces described above, the page table entry formats may, in addition to the next level page table pointer 1 12 or output address 120, and any attributes 122 for controlling access to the corresponding block of memory, also specify some additional state for use in physical address space selection.

[0157] For a table descriptor 110, the PTEs used by any domain other than the non-secure domain 86 includes a non-secure table indicator 124 which indicates whether the next level page table is to be accessed from the non-secure physical address space or from the current domain’s physical address space. This helps to facilitate more efficient management of page tables. Often the page table structures used by the root, realm or secure domains 24 may only need to define special page table entries for a portion of the virtual address space, and for other portions the same page table entries as used by the non-secure domain 26 could be used, so by providing the non-secure table indicator 124 this can allow higher levels of the page table structure to provide dedicated realm / secure table descriptors, while at a certain point of the page table tree, the root realm or secure domains could switch to using page table entries from the non-secure domain for those portions of the address space where higher security is not needed. Other page table descriptors in other parts of the tree of page tables could still be fetched from the relevant physical address space associated with the root, realm or the secure domain.

[0158] On the other hand, the block / page descriptors 114, 116, 118 may, depending on which domain they are associated with, include physical address space selection information 126. The non-secure block / page descriptors 118 used in the non-secure domain 86 do not include any PAS selection information because the non-secure domain is only able to access the non-secure PAS. However for the other domains the block / page descriptor 114, 1 16 includes PAS selection information 126 which is used to select which PAS to translate the input address into. For the root domain 22, EL3 page table entries may have PAS selection information 126 which includes at least 2 bits to indicate the PAS associated with any of the 4 domains 82, 84, 86, 88 as the selected PAS into which the corresponding physical address is to be translated. In contrast, for the realm and secure domains, the corresponding block / page descriptor 116 need only include one bit of PAS selection information 126 which, for the realm domain, selects between the realm and nonsecure PASs, and for the secure domain selects between the secure and non-secure PASs. To improve efficiency of circuit implementation and avoid increasing the size of page table entries, for the realm and secure domains the block / page descriptor 1 16 may encode the PAS selection information 126 at the same positon within the PTE, regardless of whether the current domain is realm or secure, so that the PAS selection bit 126 can be shared.

[0159] Hence, Figure 13 is a flow diagram showing a method of selecting the PAS based on the current domain and the information 124, 126 from the block / page PTE used in generating the physical address for a given memory access request. The PAS selection could be performed by the address translation circuitry 16, or if the address translation circuitry forwards the PAS selection information 126 to the PAS filter 20, performed by a combination of address translation circuitry 16 and the PAS filter 20.

[0160] At step 130 in Figure 13, the processing circuitry 10 issues a memory access request specifying a given virtual address (VA) as a target VA. At step 132 the address translation circuitry 16 looks up any page table entries (or cached information derived from such page table entries) in its TLB 18. If any required page table information is not available, address translation circuitry 16 initiates a page table walk to memory to fetch the required PTEs (potentially requiring a series of memory accesses to step through respective levels of the page table structure and / or multiple stages of address translation for obtaining mappings from a VA to an intermediate address (IPA) and then from an IPA to a PA). Note that any memory access requests issued by the address translation circuitry 16 in the page table walk operations may themselves be subject to address translation and PAS filtering, so the request received at step 130 could be a memory access request issued to request a page table entry from memory. Once the relevant page table information has been identified, the virtual address is translated into a physical address (possibly in two stages via an IPA). At step 134 the address translation circuitry 16 or the PAS filter 20 determines which domain is the current domain, using the approach shown in Figure 11 .

[0161] If the current domain is the non-secure domain then at step 136 the output PAS selected for this memory access request is the non-secure PAS.

[0162] If the current domain is the secure domain, then at step 138 the output PAS is selected based on the PAS selection information 126 which was included in the block / page descriptor PTE which provided the physical address, where the output PAS will be selected as either secure PAS or non-secure PAS.

[0163] If the current domain is the realm domain, then at step 140 the output PAS is selected based on the PAS selection information 126 included in the block / page descriptor PTE from which the physical address was derived, and in this case the output PAS is selected as either the realm PAS or the non-secure PAS. If at step 134 the current domain is determined to be the root domain, then at step 142 the output PAS is selected 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 any of the physical address spaces associated with the root, realm, secure and nonsecure domains.

[0164] Figure 14 summarises the operation of the address translation circuitry 16 and PAS filter 20. The PAS filtering 20 (granule protection lookup) can be regarded as an additional stage 3 check performed after the stage 1 (and optionally stage 2) address translations performed by the address translation circuitry. Note also that the EL3 translations are based on page table entries which provide two bits of address based selection information (labelled NS,NSE in the example of Figure 14), while a single bit of selection information “NS” is used to select the PAS in the other states. The security state indicated in Figure 14 as input to the granule protection check refers to the Domain ID identifying the input domain of the processing element 4 which caused the memory access to be issued, which may be relevant if any granule protection attributes indicate permissions which depend on the input domain.

[0165] Figure 15 is a flow diagram illustrating a method for the PAS filter 20 (checking circuitry) to perform the protection check at stage 3 shown in Figure 14. At step 200, the PAS filter 20 obtains protection information, GPT[PA], corresponding to the target physical address (PA) obtained for the memory access request by the address translation circuitry 16. For example, the PAS filter 20 looks up the target PA in the granule protection information cache 22, and if there is a hit for the target PA, determines the protection information associated with the target PA based on cached information specified in a hit entry of the granule protection information cache 22. If the target PA misses in the granule protection information cache 22, then at least one memory access request is sent to the memory system to request that the granule protection entry corresponding to the target PA is returned from memory.

[0166] For example, the PAS filter 20 may have a register storing a base address of the granule protection table used to define the granule protection information, and may generate the address(es) of the memory access request(s) issued to request the relevant granule protection entry as a function of the base address and the target PA. The right to update the register storing the GPT base address may be restricted to software executing in the root domain (at exception level EL3).

[0167] Although some implementations may use a linear table structure which can access the required granule protection entry in a single access, other approaches may use a hierarchical table structure similar to multi-level page tables used by the address translation circuitry 16 for accessing address translation mappings, so that it may be required to issue more than one memory access request to step through multiple levels of granule protection table, with each level of granule protection table being indexed based on a respective portion of the target PA, and a pointer provided in an entry in one level of granule protection table providing a base address which can be used to derive the address at which the next level granule protection table is to be accessed. See for example the multi-level GPT structure shown in Figure 4 discussed above. Once the relevant granule protection entry corresponding to the target PA of the original memory access has been returned from memory, information derived from this granule protection entry may be cached in the granule protection information cache (it is not necessary for the cached information to be encoded in exactly the same way as the granule protection entry stored in memory - e.g. a compression scheme could be used to reduce the volume of cached data compared to the encoding stored in memory).

[0168] Hence, at step 200 information allowing the PAS filter 20 to determine the encoding of the granule protection information corresponding to the target PA is identified by the PAS filter 20. This could be identified either based on cached information in cache 22, or based on information stored in memory.

[0169] At step 202 the PAS filter 20 determines, based on the information identifying the granule protection information corresponding to the target PA, whether the memory access request is permitted. If the memory access request is not permitted, at step 204 the memory access request is rejected, and a fault is signalled. If the memory access request is determined to be permitted, then at step 206 the memory access request is permitted to proceed.

[0170] The granule protection information may be specified at granularity of blocks of memory of a certain size (e.g. 4KB pages, or blocks of a larger or smaller size), so that all physical addresses in the same block share the same granule protection information entry.

[0171] In general, the granule protection information entry that corresponds to a given PA provides information identifies granule protection attributes for controlling access to the corresponding granule of physical addresses, based on memory access request properties of the memory access request. The properties of the memory access request that can be compared with the granule protection information can include various information. For example, the memory access request may specify:

[0172] • read / write type information indicating whether the memory access request is a read access request or a write access request;

[0173] • the input domain (security state) from which the memory access request was issued (i.e. the current domain determined according to Figure 11 , irrespective of which PAS was selected for the memory access request based on the combination of input domain and any PAS selection bits in the translation tables as shown in Figure 13)

[0174] • the selected PAS selected by PAS selection circuitry 16, 20 for the memory access request (e.g. based on the selection rules shown in Figure 13); and

[0175] • the requester group ID (RGID) associated with the requester hardware device which issued the memory access request.

[0176] The granule protection attributes, which are specified directly or indirectly by the GPI for a given granule of physical addresses, can include various types of attributes including: • PAS permissions indicating, for each PAS, whether that PAS is an allowable PAS from which the given granule is allowed to be accessed (depending on the encoding used for this information, it may be possible to identify multiple PASs as allowable PASs, or it may be restricted to a single PAS being an allowable PAS);

[0177] • requester group access permissions (e.g. allowable RGID identifying attribute information) indicating, for each RGID, whether that RGID is an allowable RGID for which requests specifying that RGID are allowed to access the given granule (in some cases, this information could separately define allowable RGIDs for read requests and write requests respectively so that it is possible to define read-only or write-only access for a given RGID, or allow that RGID to perform both read and write accesses);

[0178] • input domain permissions indicating one or more allowable input domains from which the granule is allowed to be accessed; and

[0179] • read / write attributes, which restrict which of read / write accesses are allowed to access the granule (as mentioned above, in some cases this read / write permission attribute may be defined specific to particular RGIDs).

[0180] There could be a wide variety of techniques by which this information could be encoded. The granule protection attributes could be encoded either directly in the GPI stored in the GPT, or indirectly in an indirection table referenced by the GPI, or using a mixture of directly encoded bits of the GPI and indirectly encoded bits stored in the indirection table entry identified by the pointer stored in the GPI. One particular example of a possible encoding is shown below, but it will be appreciated that other approaches are possible. The meaning of particular encodings shown below can be swapped to change which encoded value represents each option, and the relative positions of bits within the granule protection attributes could be swapped. It would also be possible to combine multiple pieces of information (allowed output PAS, allowed input domain, and / or allowed RGID) into a single combined field indicating allowable combinations of two or more of output PAS, allowed input domain and RGID).

[0181] Example Granule protection attribute encoding:

[0182] An alternative approach would be to combine the allowed PAS and allowed input domain into a single field indicating allowable combinations of PAS and input domain, for example: Another attribute that could be encoded could be a read / write control attribute specifying whether read and write access is allowed, for example:

[0183] In the above example, the requester group access permissions indicate allowed RGIDs for the purpose of both read and write accesses, so that a hardware device associated with an allowed RGID can perform both read and write accesses to the corresponding region, assuming that any other read / write control attribute (independent of RGID, such as attributes in translation tables) is set to permit both read and write access.

[0184] However, another approach could be to define “allowed RGID” attributes for read and write access respectively, for example a set of 2-bit fields per RGID encoded as in the previous read / write control attribute example, to indicate separately for each RGID whether read access is allowed and / or whether write access is allowed:

[0185] ... and so on for other RGID values.

[0186] Another approach could be that the “allowed RGID” field [23:16] shown above indicates whether each RGID is an allowed RGID for read accesses, and then a second instance of an “allowed RGID” field could be provided to indicate whether each RGID is an allowed RGID for write accesses:

[0187] Regardless of the particular encoding used, specifying allowed RGIDs separately for reads and writes can allow a given RGID to be an allowed RGID for read accesses but not write accesses, or vice versa. The example above uses a 3-bit RGID with 8 possible RGID values 0-7, but it will be appreciated that other examples could use a RGID with more or fewer bits than 3. For example, a 1 -bit RGID could be enough to distinguish “protected” and “non-protected” devices (e.g. with biometric processing hardware being “protected” and a general purpose CPU for application processing being “unprotected”), where the “allowed RGID” field could be used to designate certain memory granules as being reserved for access by “protected” devices. Alternatively, a multi-bit RGID could allow more flexible groupings of devices, e.g. with a general purpose CPU, a modem, and two or more other classes of device each being treated as a different device group (RGID value), with associated differences in the access rights granted within a single PAS for each RGID class. This can be particularly useful for the Realm PAS which may be used for sensitive processing and which may benefit from one device which needs access to a portion of the Realm PAS being denied access to another portion of the Realm PAS reserved for access by a different hardware device. Clearly, the particular allocation of RGIDs to devices may be a matter of design choice for a system operator.

[0188] Also, for an RGID with a given number of bits, it is not essential for all possible RGID values to be in use. For example, while the GPT architecture may support use of a 3-bit RGID, a given system implementation might only use 1 or 2 of those bits with the remaining bits being fixed to 0, so as to restrict how many distinct device classes are in use. For example, there may be no requester hardware devices which have been assigned RGID values in the range 4-7, so that effectively one bit of the RGID is not in use.

[0189] It is not essential to use a bitmask to indicate the allowable RGIDs, and other examples could limit the number of allowable RGIDs to a certain number (e.g. 1 or 2) and identify those allowable RGIDs using a corresponding number of RGID fields specifying the particular RGID value for each allowable RGID. However, a bitmask can be a particularly efficient encoding supporting maximum flexibility in identifying any combination of RGID values as the allowable RGIDs for a particular granule of physical addresses.

[0190] The association between a RGID value and a requester hardware device can be defined in a number of ways. In some cases, the particular RGID value assigned to a particular hardware device is static at runtime. For example, a given requester hardware device may have a hardwired register which defines the RGID value for that device, so that the RGID mapping for that device is defined by the system manufacturer who designs the system. Alternatively, the boot code executed at boot time (see Figure 7) may include a portion of code executing in exception level EL3 which sets the RGID value for each hardware device by writing to a register or other configurable storage associated with that device, but it may then not be possible to overwrite the RGID value for a given hardware device at runtime.

[0191] In other examples, the association between an RGID value and a requester hardware device may be variable at runtime. For example, a certain CPU instruction type may be defined to support setting of RGID values for particular devices (e.g. a system register updating instruction which specifies a system register storing the RGID value). Such an instruction may be restricted to be executed only at exception level EL3 (so an attempt to execute the instruction at EL0-EL2 may cause a fault). Alternatively, the storage location storing the RGID value for a given requester hardware device may be a memory-mapped storage location which can be written to with a general purpose store instruction triggering a write access to memory specifying an address mapped to the RGID storage location. A restriction on the ability to update the RGID value may be implemented using the GPT by defining the memory region comprising the address mapped to the RGID storage location as a region accessible only in the Root PAS.

[0192] In some cases, a given requester hardware device may be associated with a single RGID value which is used for all memory access requests issued by that device.

[0193] However, it is also possible to provide a given device with the ability to select between different RGID values depending on the execution context associated with a memory access request being issued. For example, a table of RGID-execution context mappings could be provided (either statically set at boot time or dynamically variable based on a CPU instruction or memory-mapped register write as mentioned above). Alternatively, the association between an RGID value and device may be updated for a current execution context by updating the value specified in a single RGID storage location each time there is a switch of execution context. Hence, it is possible for the RGID value specified by memory access requests from a single requester hardware device to vary based on the execution context being processed. For a CPU or other processor, the execution context may indicate which thread of processing is being carried out. For a hardware accelerator or other system device, the current execution context may be indicated by a register specifying an execution context identifier which may be configured by a software workload executing on a processor at the time when the accelerator / device is configured by the CPU to carry out processing on behalf of that software workload.

[0194] Hence, there are a wide variety of ways in which one or more RGIDs for a particular requester hardware device can be defined, but in general the RGIDs allow different hardware devices to be assigned different views of memory within the same PAS, enabling greater security by restricting access to a given device only to the regions of the PAS that the device really needs to access. This can reduce an attack surface available for attackers to exploit, improving robustness against attack.

[0195] Figure 16 is a flow diagram showing another example of checking granule protection attributes at step 410 of Figure 2. While Figure 16 shows a number of checks being performed in a particular order, it will be appreciated that this order is just one example, and other examples could perform the checks in a different order or at least partially in parallel.

[0196] Steps 420 and 422 are the same as in Figure 3, to check, based on the granule protection attributes associated with the target granule physical addresses and the RGID specified by the memory access request being checked, whether the granule protection attributes indicate that a group of one or more requester hardware devices associated with the RGID is prohibited from accessing the target granule physical addresses. If the group of requester hardware devices associated with the RGID is prohibited from accessing the target granule, the memory access request is blocked at step 422, to prevent it from being processed by a cache 24 or memory system interconnect 8, and a fault is signalled.

[0197] At step 434, the filtering circuitry 20 determines whether the granule protection attributes indicate that the selected PAS selected for the memory access request (the selected PAS being selected based on the steps in Figure 13) is not an allowed PAS for the target granule, and if so then again at step 422 the memory access is prohibited from being processed by the cache 24 or interconnect 8 and a fault is signalled.

[0198] At step 436, the filtering circuitry 20 determines whether the granule protection attributes indicate that the input domain (Secure, Non-Secure, Realm or Root) from which the memory access request was issued is not an allowed domain for the target granule, and if so then again at step 422 the memory access is prohibited from being processed by the cache 24 or interconnect 8 and a fault is signalled. Here, for a CPU or other processor the input domain would be the current domain as determined in Figure 1 1 (regardless of which PAS is subsequently selected based on that input domain using the process of Figure 13). For a device other than a processor, which does not explicitly execute software but can be configured to carry out functions on behalf of software executing on a processor, the device may have similar “current domain” registers to those of the processor indicating which domain is the current domain, with those “current domain” registers being configured by the software executing on the processor at the time of configuring the device to carry out its functions. For example, processing executing on a processor 4 in the Realm domain may cause a corresponding device 5 to set its “current domain” registers to indicate the Realm domain as the current domain.

[0199] At step 438, the filtering circuitry identifies whether the type of memory access request being processed is a read access request or a write access request. If the request is a read access request, then at step 440 the filtering circuitry 20 determines whether any read / write granule protection attributes specify that a read access is prohibited. As noted above, in some cases these read / write granule protection attributes may be specific to the particular RGID specified by the request, so that at step 440 the filtering circuitry 20 checks whether the RGID specified by the request is allowed to carry out a read access (which might yield a different result to the same check carried out based on read permission attributes set for a different RGID). If the filtering circuitry 20 determines that read access is prohibited (at least for the current RGID), then at step 422 the memory access is prohibited from being processed by the cache 24 or interconnect 8 and a fault is signalled. Similarly, if the memory access request being processed is a write access request, then at step 442 the filtering circuitry 20 determines whether any read / write granule protection attributes specify that a write access is prohibited (in some cases, based on an attribute specific to the RGID of the memory access request). If write access is prohibited (at least for the current RGID), then again at step 422 the memory access is prohibited from being processed by the cache 24 or interconnect 8 and a fault is signalled.

[0200] If all of the checks performed at steps 420, 434, 436 and one of 440 and 442 are passed (so that they all determine that the access is not prohibited by the associated type of granule protection attribute information being checked), then at step 426 the memory access request is allowed to be processed by the cache 24 or interconnect 8, without signalling a fault.

[0201] Figure 17 shows a particular example of a use case for the RGID-based permissions, which for ease of explanation in this example assume a one-bit RGID which distinguishes “protected” and “non-protected” devices. In this example, the general purpose CPU, any other processors 4 and one or more system devices 5 are considered “non-protected”, but a particular system device 480 is designated as “protected”. For example, the protected device 480 could be a biometric data processing engine, or an encryption / decryption engine. As shown in the lower part of Figure 17, the system memory address space can be partitioned between the respective PASs using the GPT, with distinct memory granules assigned to the Secure, Non-Secure, Realm and Root PASs as shown (the granule marked “GPT” is assigned to the Root PAS, and the granules marked as “NS”, “S”, “RL” respectively are assigned to the Non-Secure, Secure and Realm PASs respectively). Among the granules assigned to the Realm PAS, those granules indicated with bold outline are assigned requester group permissions which indicate that the “protected” device group (e.g. RGID = 1 ) is allowed to access those granules but the “nonprotected” device group (e.g. RGID = 0) is not allowed to access those granules. The other granules within the Realm PAS which are not shown with bold outline may be accessible to devices with both RGID = 0 and RGID = 1. With this approach, the critical regions of memory used by devices performing sensitive processing such as decryption or biometric data processing can be locked down to be accessible only by those devices and cannot be accessed by general purpose CPUs, which can reduce vulnerability to attack since even if an attacker manages to compromise software running on the general purpose CPU to cause a memory access request to specify an address in one of the protected Realm granules, and that software has been granted access to other parts of the Realm PAS, the filtering circuitry 20 can detect that the non-protected device cannot access those granules and will signal a fault.

[0202] Another use case could be that the management of the GPT, which is extremely sensitive as it governs the security model used for all other accesses, can be restricted to a “protected” security processor distinct from the general purpose processors used for user application processing, by designating some granules of the Root PAS as being accessible only to “protected” devices.

[0203] Figure 18 illustrates another use case where the RGID based controls can be used to support a video processing pipeline where each requester hardware device in the pipeline is restricted in terms of its read and write access permissions to access only the portions of the Realm PAS that are relevant to its particular function within the pipeline. This can be useful for processing of content protected by digital rights management. The GPT can be used to define producer / consumer relationships between the respective hardware devices to restrict the access to the minimum required at each step in the pipeline.

[0204] For example, the general purpose processors used for user application processing (such as execution of a content player) can be considered “non-protected”, while each of the respective hardware devices processing subsequent parts of the pipeline (such as decryption engine (dev A), video decode engine (dev B), scaling / compositing engine (dev C) and display controller (dev D) may be assigned distinct RGIDs indicating various protected device groups, to give each device a different view of memory within the Realm PAS. The player application and input file storing the encrypted content may be accessible to all in non-protected granules of the PAS, but the regions used for respective content buffers for storing decrypted content, decoded content and output content for display output may all be designated by the granule protection attributes as inaccessible to the RGID associated with the non-protected processors.

[0205] Meanwhile, different read / write permissions may be defined by the granule protection attributes for the respective protected devices Dev A to Dev D. Dev A (a decryption engine) may be allowed to write to the granules used for decrypted content buffer, but not read the decrypted content buffer, as Dev A is only a producer of content for the decrypted content buffer and does not need to consume content from the decrypted content buffer. Similarly, Dev B (a decode engine) may be allowed to read (but not write) the granules of physical addresses used for the decrypted content buffer, and may be allowed to write (but not read) the granules allocated for the decoded content buffer, reflecting Dev B’s status as a consumer of the decrypted content and a producer of the decoded content. Dev C (a scaling / compositing engine) may be allowed to read (but not write) the granules of physical addresses used for the decoded content buffer, and may be allowed to write (but not read) the granules allocated for the display output buffer, reflecting Dev C’s status as a consumer of the decoded content and a producer of the display content. Finally, Dev D (the display controller) may be allowed to read (but not write) the granules allocated for the display output buffer, as the display controller consumes content from the display output buffer, but cannot write to the display output buffer. The granules corresponding to the Decrypted content buffer are set in the granule protection attributes as being completely inaccessible (to both read and write access) for the RGIDs associated with devices C and D. The granules corresponding to the Decoded content buffer are set in the granule protection attributes as being completely inaccessible (to both read and write access) for the RGIDs associated with devices A and D. The granules corresponding to the Output content buffer are set in the granule protection attributes as being completely inaccessible (to both read and write access) for the RGIDs associated with devices A and B.

[0206] With this approach, the GPT can be used to partition up rights to access within the Realm PAS, so that each device can only access those buffers it needs to access and only for the expected type of access (read or write), and is not given access to other buffers associated with other steps in the pipeline, depending on the producer / consumer relationship within the pipeline. The attributes used to define these permissions are in the GPT, not the translation tables, so there is no need to trust the operating system / hypervisor which sets the translation tables (which could be vulnerable to being compromised by an attacker). Meanwhile, the memory accesses made for the entire content processing pipeline can be isolated by hardware from the Non-Secure and Secure domains, by processing the entire pipeline in the Realm domain, but nevertheless differing views of Realm PAS for different devices are possible due to the use of the RGID based controls.

[0207] Hence, this provides an extremely flexible security control model which can benefit a wide range of use cases. It will be appreciated that the example in Figure 18 is just one possible use case.

[0208] Concepts described herein may be embodied in computer-readable code for fabrication of an apparatus that embodies the described concepts. For example, the computer-readable code can be used at one or more stages of a semiconductor design and fabrication process, including an electronic design automation (EDA) stage, to fabricate an integrated circuit comprising the apparatus embodying the concepts. The above computer-readable code may additionally or alternatively enable the definition, modelling, simulation, verification and / or testing of an apparatus embodying the concepts described herein.

[0209] For example, the computer-readable code for fabrication of an apparatus embodying the concepts described herein can be embodied in code defining a hardware description language (HDL) representation of the concepts. For example, the code may define a register-transfer-level (RTL) abstraction of one or more logic circuits for defining an apparatus embodying the concepts. The code may define a HDL representation of the one or more logic circuits embodying the apparatus in Verilog, SystemVerilog, Chisel, or VHDL (Very High-Speed Integrated Circuit Hardware Description Language) as well as intermediate representations such as FIRRTL. Computer-readable code may provide definitions embodying the concept using system-level modelling languages such as SystemC and SystemVerilog or other behavioural representations of the concepts that can be interpreted by a computer to enable simulation, functional and / or formal verification, and testing of the concepts.

[0210] Additionally or alternatively, the computer-readable code may define a low-level description of integrated circuit components that embody concepts described herein, such as one or more netlists or integrated circuit layout definitions, including representations such as GDSIL The one or more netlists or other computer-readable representation of integrated circuit components may be generated by applying one or more logic synthesis processes to an RTL representation to generate definitions for use in fabrication of an apparatus embodying the invention. Alternatively or additionally, the one or more logic synthesis processes can generate from the computer-readable code a bitstream to be loaded into a field programmable gate array (FPGA) to configure the FPGA to embody the described concepts. The FPGA may be deployed for the purposes of verification and test of the concepts prior to fabrication in an integrated circuit or the FPGA may be deployed in a product directly.

[0211] The computer-readable code may comprise a mix of code representations for fabrication of an apparatus, for example including a mix of one or more of an RTL representation, a netlist representation, or another computer-readable definition to be used in a semiconductor design and fabrication process to fabricate an apparatus embodying the invention. Alternatively or additionally, the concept may be defined in a combination of a computer-readable definition to be used in a semiconductor design and fabrication process to fabricate an apparatus and computer- readable code defining instructions which are to be executed by the defined apparatus once fabricated.

[0212] Such computer-readable code can be disposed in any known transitory computer- readable medium (such as wired or wireless transmission of code over a network) or non- transitory computer-readable medium such as semiconductor, magnetic disk, or optical disc. An integrated circuit fabricated using the computer-readable code may comprise components such as one or more of a central processing unit, graphics processing unit, neural processing unit, digital signal processor or other components that individually or collectively embody the concept.

[0213] Figure 19 illustrates a simulator implementation that may be used. Whilst the earlier described embodiments implement the present invention in terms of apparatus and methods for operating specific processing hardware supporting the techniques concerned, it is also possible to provide an instruction execution environment in accordance with the embodiments described herein which is implemented through the use of a computer program. Such computer programs are often referred to as simulators, insofar as they provide a software based implementation of a hardware architecture. Varieties of simulator computer programs include emulators, virtual machines, models, and binary translators, including dynamic binary translators. Typically, a simulator implementation may run on a host processor 530, optionally running a host operating system 520, supporting the simulator program 510. In some arrangements, there may be multiple layers of simulation between the hardware and the provided instruction execution environment, and / or multiple distinct instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations which execute at a reasonable speed, but such an approach may be justified in certain circumstances, such as when there is a desire to run code native to another processor for compatibility or re-use reasons. For example, the simulator implementation may provide an instruction execution environment with additional functionality which is not supported by the host processor hardware, or 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, Pages 53 - 63.

[0214] To the extent that embodiments have previously been described with reference to particular hardware constructs or features, in a simulated embodiment, equivalent functionality may be provided by suitable software constructs or features. For example, particular circuitry may be implemented in a simulated embodiment as computer program logic. Similarly, memory hardware, such as a register or cache, may be implemented in a simulated embodiment as a software data structure. In arrangements where one or more of the hardware elements referenced in the previously described embodiments are present on the host hardware (for example, host processor 530), some simulated embodiments may make use of the host hardware, where suitable.

[0215] The simulator program 510 may be stored on a computer-readable storage medium (which may be a non-transitory medium), and provides a program interface (instruction execution environment) to the target code 500 (which may include applications, operating systems and a hypervisor) which is the same as the interface of the hardware architecture being modelled by the simulator program 510. Thus, the program instructions of the target code 500 may be executed from within the instruction execution environment using the simulator program 510, so that a host computer 530 which does not actually have the hardware features of the apparatus 2 discussed above can emulate these features. This can be useful, for example, for allowing testing of target code 500 being developed for a new version of a processor architecture before hardware devices actually supporting that architecture are yet available, as the target code can be tested by running within the simulator executing on a host device which does not support that architecture.

[0216] The simulator code includes processing program logic 512 which emulates the behaviour of the processing circuitry 10, e.g. including instruction decoding program logic which decodes instructions of the target code 500 and maps the instructions to corresponding sequences of instructions in the native instruction set supported by the host hardware 530 to execute functions equivalent to the decoded instructions. The processing program logic 512 also simulates processing of code in different exception levels and domains as described above. Register emulating program logic 513 maintains a data structure in a host address space of the host processor, which emulates architectural register state defined according to the target instruction set architecture associated with the target code 500. Hence, instead of such architectural state being stored in hardware registers 12 as in the example of Figure 6, it is instead stored in the memory of the host processor 530, with the register emulating program logic 513 mapping register references of instructions of the target code 500 to corresponding addresses for obtaining the simulated architectural state data from the host memory. This architectural state may include the current domain indication 14 and current exception level indication 15 described earlier.

[0217] The simulation code includes address translation program logic 514 and filtering program logic 516 which emulate the functionality of the address translation circuitry 16 and PAS filter 20 respectively, with reference to the same page table structures and GPT 56 as described earlier. One or both of the address translation program logic 514 and filtering program logic 516 also acts as PAS selection program logic for selecting the selected PAS associated with a given memory access request, based on the current domain of the processing program logic 512 and PAS selection information defined using the page tables. Hence, the address translation program logic 514 translates virtual addresses specified by the target code 500 into simulated physical addresses in one of the PASs (which from the point of view of the target code refer to physical locations in memory, but actually these simulated physical addresses are mapped onto the (virtual) address space of the host processor by address space mapping program logic 515). The filtering program logic 516 performs a lookup of granule protection information to determine whether to allow memory accesses triggered by the target code to proceed, in the same way as the PAS filter 20 described above. The granule protection attributes indicated using the granule protection table include RGID based attributes as described earlier. For the simulated example, the RGIDs indicate groups of simulated requester hardware devices and the RGIDs are assigned by the simulator code 510 to represent simulated hardware devices which would be present in a real processing apparatus 2, but those simulated hardware devices may not actually exist in the host hardware 530. For example, when the target code requests a function such as biometric processing or decryption that might be done on a specialized hardware device in the real apparatus 2, the simulation program may allocate a different RGID for the memory access requests issued for that biometric processing or decryption, compared to the RGID used for other more generic tasks triggered by the target code 500.

[0218] In the present application, the words “configured to...” are used to mean that an element of an apparatus has a configuration able to carry out the defined operation. In this context, a “configuration” means an arrangement or manner of interconnection of hardware or software. For example, the apparatus may have dedicated hardware which 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 element needs to be changed in any way in order to provide the defined operation.

[0219] In the present application, lists of features preceded with the phrase “at least one of” mean that any one or more of those features can be provided either individually or in combination. For example, “at least one of: [A], [B] and [C]” encompasses any of the following options: A alone (without B or C), B alone (without A or C), C alone (without A or B), A and B in combination (without C), A and C in combination (without B), B and C in combination (without A), or A, B and C in combination.

[0220] Although illustrative embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various changes and modifications can be effected therein by one skilled in the art without departing from the scope of the invention as defined by the appended claims.

Claims

CLAIMS1 . An apparatus comprising: address translation circuitry responsive to a memory access request received from a requester hardware device specifying a target virtual address and a requester group identifier associated with the requester hardware device, to translate the target virtual address into a target physical address based on at least one address translation mapping specified in at least one translation table structure; and filtering circuitry to: perform a granule protection lookup based on the target physical address to identify granule protection attributes associated with a target granule of physical addresses comprising the target physical address, where the granule protection attributes are derived from granule protection information specified in a granule protection table structure which is orthogonal to the at least one translation table structure; and determine, based on the granule protection attributes associated with the target granule of physical addresses, whether to prohibit the memory access request from being processed by a cache or a memory system interconnect; wherein: the filtering circuitry is configured to determine, based on the granule protection attributes and the requester group identifier specified by the memory access request, whether the granule protection attributes indicate that a group of one or more requester hardware devices associated with the requester group identifier is prohibited from accessing the target granule of physical addresses comprising the target physical address.

2. The apparatus according to claim 1 , comprising physical address space selection circuitry to select a selected physical address space for the memory access request from among a plurality of physical address spaces; wherein the filtering circuitry is configured to determine, based on the granule protection attributes associated with the target granule of physical addresses, which of the plurality of physical address spaces is an allowed physical address space, memory access requests associated with a physical address space other than an allowed physical address space being prohibited from accessing the target granule of physical addresses.

3. The apparatus according to claim 2, comprising: a point of physical aliasing (PoPA) memory system component configured to de-alias a plurality of aliasing physical addresses from different physical address spaces which correspond to a same memory system location, to map any of the plurality of aliasing physical addresses toa de-aliased physical address to be 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, where the at least one pre-PoPA memory system component is configured to treat the aliasing physical addresses from different physical address spaces as if the aliasing physical addresses correspond to different memory system locations.

4. The apparatus according to any of claims 2 and 3, wherein the memory access request is associated with one of a plurality of domains of processing, the plurality of domains including at least a less secure domain associated with a less secure physical address space and a more secure domain associated with a more secure physical address space; and the plurality of physical address spaces includes at least the less secure physical address space and the more secure physical address space, wherein the more secure physical address space is prohibited from being selected by the physical address space selection circuitry for memory access requests associated with the less secure domain.

5. The apparatus according to claim 4, wherein: the plurality of domains of processing also include a realm domain of processing; the plurality of physical address spaces also include a realm physical address space; the realm physical address space is prohibited from being selected by the physical address space selection circuitry for memory access requests associated with the more secure domain; the more secure physical address space is prohibited from being selected by the physical address space selection circuitry for memory access requests associated with the realm domain; and the realm physical address space and the more secure physical address space are prohibited from being selected by the physical address space selection circuitry for memory access requests associated with the less secure domain.

6. The apparatus according to any preceding claim, wherein the granule protection attributes comprise at least one read / write permission attribute indicative of whether read access to the target granule of physical addresses is prohibited, and independently from whether read access is prohibited, whether write access to the target granule of physical addresses is prohibited; and the filtering circuitry is configured to: determine that a read memory access request is prohibited from accessing the target granule of physical addresses when the at least one read / write permission attribute indicates that read access is prohibited, anddetermine that a write memory access request is prohibited from accessing the target granule of physical addresses when the at least one read / write permission attribute indicates that write access is prohibited.

7. The apparatus according to claim 6, wherein the at least one read / write permission attribute comprises a plurality of read / write permission attributes to independently define, for a plurality of respective values of the requester group identifier, whether read access or write access is prohibited for respective groups of one or more requester hardware devices associated with the respective values of the requester group identifier.

8. The apparatus according to any preceding claim, wherein the granule protection attributes comprise a requester group bitmap comprising a plurality of permission bits, each permission bit indicative of whether a group of requester hardware devices associated with a corresponding value of the requester group identifier is prohibited from accessing the target granule of physical addresses.

9. The apparatus according to any preceding claim, wherein the filtering circuitry is configured to obtain at least a portion of the granule protection attributes from a target entry of an indirection table, the target entry identified by an indirection entry identifier specified by the granule protection information in an entry of the granule protection table structure corresponding to the target granule of physical addresses.

10. The apparatus according to any preceding claim, wherein the requester group identifier associated with the requester hardware device is static at runtime.11 . The apparatus according to any of claims 1 to 9, wherein the requester group identifier associated with the requester hardware device is variable at runtime.

12. The apparatus according to any preceding claim, wherein the requester group identifier associated with the requester hardware device is independent of an execution context associated with processing performed by the requester hardware device which caused the memory access request to be issued.

13. The apparatus according to any of claims 1 to 1 1 , wherein the requester group identifier is variable depending on an execution context associated with processing performed by the requester hardware device which caused the memory access request to be issued.

14. The apparatus according to any preceding claim, wherein the requester group identifier is a one-bit identifier for distinguishing between two groups of requester hardware devices.

15. The apparatus according to any preceding claim, wherein the requester group identifier is a multi-bit identifier for distinguishing between at least four groups of requester hardware devices.

16. The apparatus according to any preceding claim, wherein the requester hardware device is one of: a processor; a hardware accelerator; and an input / output device.

17. The apparatus according to any preceding claim, wherein the granule protection table structure is a memory-based table structure.

18. The apparatus according to any preceding claim, wherein the granule protection table structure comprises a multi-level table structure comprising a plurality of levels of granule protection table, the granule protection information corresponding to the target granule of physical addresses being obtained from an entry of a subsequent-level granule protection table stored at a memory system location associated with a physical address derived from a portion of the target physical address and a table pointer obtained from an entry corresponding to the target physical address in a higher-level granule protection table.

19. The apparatus according to any preceding claim, wherein the filtering circuitry is configured to access the granule protection table structure based on a granule protection table base address; and the granule protection table base address is prohibited from being updated by a software context processed in at least one execution state for which updates to a base address of the at least one translation table structure are allowed.

20. The apparatus according to any preceding claim, wherein the granule protection table structure has an encoding capable of assigning independent granule protection attributes to each 4 KB granule of physical addresses within a physical address space managed using the granule protection table structure.21 . The apparatus according to any preceding claim, wherein the address translation circuitry comprises one of:a memory management unit associated with a processor; and a system memory management unit associated with at least one device, the at least one device comprising at least one hardware accelerator and / or at least one input / output device.

22. Computer-readable code for fabrication of the apparatus according to any of claims 1 to 21.

23. A method comprising: in response to a memory access request received from a requester hardware device specifying a target virtual address and a requester group identifier associated with the requester hardware device, translating the target virtual address into a target physical address based on at least one address translation mapping specified in at least one translation table structure; performing a granule protection lookup based on the target physical address to identify granule protection attributes associated with a target granule of physical addresses comprising the target physical address, where the granule protection attributes are derived from granule protection information specified in a granule protection table structure which is orthogonal to the at least one translation table structure; and determining, based on the granule protection attributes associated with the target granule of physical addresses, whether to prohibit the memory access request from being processed by a cache or a memory system interconnect; wherein: the determining comprises, based on the granule protection attributes and the requester group identifier specified by the memory access request, determining whether the granule protection attributes indicate that a group of one or more requester hardware devices associated with the requester group identifier is prohibited from accessing the target granule of physical addresses comprising the target physical address.

24. A computer program for controlling a host data processing apparatus to provide an instruction execution environment for execution of target program code, the computer program comprising: address translation program logic responsive to a memory access request specifying a target virtual address and a requester group identifier associated with a simulated requester hardware device, to translate the target virtual address into a target simulated physical address based on at least one address translation mapping specified in at least one translation table structure; and filtering program logic to: perform a granule protection lookup based on the target simulated physical address to identify granule protection attributes associated with a target granule of simulated physical addresses comprising the target simulated physical address, wherethe granule protection attributes are derived from granule protection information specified in a granule protection table structure which is orthogonal to the at least one translation table structure; and determine, based on the granule protection attributes associated with the target granule of simulated physical addresses, whether to prohibit the memory access request from being processed; wherein: the filtering program logic is configured to determine, based on the granule protection attributes and the requester group identifier specified by the memory access request, whether the granule protection attributes indicate that a group of one or more simulated requester hardware devices associated with the requester group identifier is prohibited from accessing the target granule of simulated physical addresses comprising the target simulated physical address.

25. A computer-readable storage medium storing the computer-readable code of claim 20 or the computer program of claim 24.

Images