Attribute information

Abstract

An apparatus comprises address translation circuitry (18) to translate a target virtual address of a memory access request into a target physical address. The apparatus also has attribute determination circuitry (17) to use the translated target physical address to determine attribute information associated with the target physical address. The attribute determination circuitry is configured to identify a corresponding entry of a physically addressed table structure using the target physical address, and determine the attribute information from an attribute storage location identified by an index indicated by the corresponding entry of the physically addressed table structure.

Description

[0001] ATTRIBUTE INFORMATION

[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 to translate a target virtual address of a memory access request into a target physical address; and attribute determination circuitry to use the translated target physical address to determine attribute information associated with the target physical address; wherein the attribute determination circuitry is configured to: identify a corresponding entry of a physically addressed table structure using the target physical address, and determine the attribute information from a given attribute storage location among a set of attribute storage locations, the given attribute storage location identified by an index indicated by the corresponding entry of the physically addressed table structure.

[0005] At least some examples provide a method comprising: translating a target virtual address of a memory access request into a target physical address; and using the translated target physical address to determine attribute information associated with the target physical address; wherein determining the attribute information comprises: identifying a corresponding entry of a physically addressed table structure using the target physical address; and determining the attribute information from a given attribute storage location among a set of attribute storage locations, the given attribute storage location identified by an index indicated by the corresponding entry of the physically addressed table structure.

[0006] At least some examples provide a computer-readable medium to store computer-readable code for fabrication of the apparatus as described above.

[0007] At least some examples provide a computer program comprising instructions which, when executed by a host data processing apparatus, control the host data processing apparatus to provide an instruction execution environment for executing target program code, the computer program comprising: address translation program logic to translate a target virtual address of a memory access request into a target simulated physical address; and attribute determination program logic to use the translated target simulated physical address to determine attribute information associated with the target simulated physical address; wherein the attribute determination program logic is configured to: identify a corresponding entry of a physically addressed table structure using the target simulated physical address, and determine the attribute information from a given attribute storage location among a set of attribute storage locations, the given attribute storage location identified by an index indicated by the corresponding entry of the physically addressed table structure.

[0008] A storage medium may store the computer program mentioned 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 use of a set of attribute storage locations to determine attribute information associated with a target physical address;

[0012] Figure 3 illustrates a more detailed example of a data processing apparatus;

[0013] Figure 4 illustrates an example data processing apparatus comprising a system memory management unit;

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

[0015] Figure 6 illustrates an example of a processing system supporting granule protection lookups;

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

[0017] Figure 8 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;

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

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

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

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

[0022] Figure 13 illustrates a method of performing a granule protection check based on granule protection information;

[0023] Figure 14 illustrates a number of stages of address translation tables and a physically addressed table structure; Figure 15 shows an example of a tag check comprising checking whether an address tag matches a guard tag;

[0024] Figure 16 is a flow diagram illustrating a method of determining attribute information;

[0025] Figure 17 is a flow diagram illustrating a method of handling a memory access request;

[0026] Figure 18 is a flow diagram illustrating a method of detecting errors in a physically addressed table structure;

[0027] Figure 19 is a flow diagram illustrating a method of handling a memory access request in a system supporting memory tagging;

[0028] Figure 20 illustrates a simulator example.

[0029] Data processing systems may support use of virtual memory, where address translation circuitry is provided to translate a virtual address specified by a memory access request into a target physical address associated with a location in a memory system to be accessed. The address translation circuitry may, for example, 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.

[0030] The mappings between virtual addresses and physical addresses may be defined in one or more virtually addressed page table (translation table) structures. The page table entries within the page table structures could also define some access permission information which may control whether a given software process executing on the processing circuitry is allowed to access a particular virtual address. In some processing systems, control over whether a particular software process can access a particular address may be provided solely based on the page table structures used to provide the virtual-to-physical address translation mappings.

[0031] However, for some sensitive processing workloads it may be desired to provide additional security than can be provided with the virtually addressed translation tables 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. If the operating system or the hypervisor is compromised then this may cause a security leak where sensitive information may become accessible to an attacker.

[0032] Hence, in some systems it may be desirable for a further set of attribute information to be defined to control whether a memory access request is permitted to access a target physical address, outside the control of the operating system or hypervisor. Therefore, attribute determination circuitry is provided to determine attribute information associated with the target physical address using a physically addressed table structure. By defining attribute information 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 physical addresses used by sensitive processing workloads.

[0033] It will be appreciated that there may be many different examples of attribute information associated with a target physical address which could be relevant during handling of a memory access request. Whilst various options will be discussed in greater detail below, the attribute information may include information identifying a physical address space which may access a particular target physical address, a processing domain from which the target physical address may be accessed, a requestor device from which the physical address can be accessed, an indication of whether the target physical address is within a region protected by memory tags or in a region storing memory tags, and a read / write permission. It will be appreciated that this list is non-exhaustive, and generally the attribute information may define information associated with physical addresses which may be relevant to determining whether an access request is permitted to access that physical address.

[0034] In some systems using a physically addressed table structure to identify attribute information, the attribute determination circuitry could directly read the attribute information from an entry of the physically addressed table structure corresponding to the target physical address. For example, each entry of the physically addressed table structure could correspond to a granule of physical addresses sharing the same attribute information, and the corresponding entry is the one corresponding to a granule of physical addresses comprising the target physical address. The attribute information could then be directly used, or could be cached until it is needed to be used during a memory access.

[0035] However, the inventors have realised that given the potentially large number of distinct pieces of information which may be represented by the attribute information, if the physically addressed table structure were to directly specify the attribute information in each entry then the size of the physically addressed table structure could become undesirably large and storage and use of the table may be associated with a large overhead. Additionally, the inventors realised that in cases where attribute information may be updated, then updating the attribute information separately for each entry may incur a large overhead.

[0036] The inventors have also recognised that despite the potentially large number of options for encodings of the attribute information, in practice some encodings are used much more frequently than others. In practice, only a subset of the different potential encodings of the attribute information may be desired to be associated with granules of physical addresses at a given time.

[0037] Therefore, rather than directly specifying the attribute information in each entry of the physically addressed table structure, the inventors have recognised that a set of encodings of attribute information which are most likely to be used may be stored in a set of attribute storage locations, and entries of the physically addressed table structure may specify an index identifying one of the attribute storage locations to identify a particular encoding of the attribute information. Hence, entries of the physically addressed table structure may incur the much smaller storage cost of indicating an index identifying a corresponding set of attribute information, rather than directly specifying the attribute information itself. The larger storage cost associated with storing the attribute information itself is therefore incurred a reduced number of times, because rather than incurring the cost of storing the same attribute information in several entries of the physically addressed table structure, each of those entries can use a smaller index to refer to the attribute information stored once in the attribute storage location. Further, when it is desired to update attribute information, then the small number of attribute storage locations may be updated and the indices stored in each entry of the physically addressed table structure may remain the same, meaning that much fewer update operations may need to be performed.

[0038] Providing the attribute information in a set of attribute storage locations rather than directly in the physically addressed table structure would appear to be unusual, since it leads to an increase in the number of accesses which are required to determine the attribute information. Rather than directly accessing the attribute information in the physically addressed table structure, a further access is carried out (at least on the first time the attribute information is determined from the set of attribute storage locations) to the attribute storage location based on the access to the physically addressed table structure. However, the inventors have realised that surprisingly this increased number of accesses is worth incurring due to the increase in the number of attributes which may be represented by the attribute information, and the reduced overhead which may be incurred if the attribute information is updated. It is especially surprising that the indirection is worthwhile in a physically addressed table structure, since it is typically the virtually addressed page tables which are relied on to provide a large number of permissions, and physically addressed table structures may be expected to provide a much more limited number of attributes such that storage requirements for the table may be minimal in any case meaning that indirection is not worthwhile. However, the inventors have identified a number of new examples of attribute information which can be associated with physical addresses, and have recognised that these further attributes which may be associated with physical addresses can justify incurring the extra overhead of indirection even in the case of a physically addressed table structure.

[0039] The physically addressed table structure may be provided in memory, although information derived from portions of the physically addressed table structure may be cached locally at the attribute determination circuitry.

[0040] Although some examples may implement a linear structure for the physically addressed 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 entries 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. Therefore, in some examples, the physically addressed table structure comprises a multilevel table structure comprising a plurality of levels of physically addressed table structure, the entry corresponding to the target physical address being 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 a higher-level entry corresponding to the target physical address in a higher-level physically addressed table structure. 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.

[0041] The entries of the physically addressed table structure may correspond to a granule 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 physically addressed table structure has an encoding capable of assigning independent indices to each 4 KB granule of physical addresses within a physical address space managed using the physically addressed 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 physically addressed table structure to define attribute information at a corresponding granularity to the granularity with which an operating system or hypervisor would control access to memory. Although the physically addressed table structure may have an encoding which supports 4 KB granule sizes, it may also support the option of indicating indices for multiple granules in a single entry (e.g. by encoding an index at a higher-level of a multi-level table structure indicating that the indices 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 physically addressed table structure may support 4 KB granules, it is not necessary for all encodings of the table to actually define 4 KB granules, and some encodings could define a coarser granularity for setting the indices.

[0042] The circuitry providing the set of attribute storage locations is not particularly limited. For example, a set of registers accessible by the attribute determination circuitry may provide a set of attribute storage locations. However, as will be discussed below, in some examples the apparatus may be part of a larger system of a plurality of devices having access to shared memory and hence having shared access to the same physical address space. In these examples, it may be desirable to associate the same attributes with a given target physical address regardless of which device the address is being accessed from. Hence, it may be desirable to share the set of attribute storage locations across the plurality of devices having access to the memory. One way that this may be achieved is by providing the set of attribute storage locations in a region of memory, which in examples comprising a plurality of devices is a region accessible by each device.

[0043] To increase the speed at which the attribute information can be accessed, it may be advantageous for a device comprising attribute determination circuitry to locally cache attribute information in examples where the attribute information is stored in a location which is slower to access than the cache, such as when the attribute storage location is in memory. Hence, the attribute determination circuitry may be configured to cache the attribute information determined from the given attribute storage location identified by the index of the corresponding entry of the physically addressed table structure. The attribute determination circuitry may do this at the same time that the attribute information is also retrieved to control a memory access request, or could cache the attribute information in advance in anticipation that the attribute information will be needed in the future.

[0044] As mentioned above, the attribute information may indicate attributes which are relevant when determining whether a particular memory access request should be permitted to access a target physical address. Hence, in some examples, the access to the attribute information by the attribute determination circuitry may be made whilst the attribute determination circuitry is controlling handling of the memory access request. The attribute determination circuitry may control handling of the memory access request and optionally may also cache the attribute information so that it does not need to be retrieved from the attribute storage location in response to a future memory access request.

[0045] The attribute information may be used to filter memory access requests at the requesterside of the interconnect instead of on the completer-side closer to the memory storage, to 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.

[0046] In some systems where there is a need for certain processes to execute securely in isolation from other processes, the system may support a number of distinct physical address spaces. For example, an address in a given physical address space may not be accessible by a memory access request having a target physical address in a different physical address space. Certain physical address spaces may be prohibited from being selected for memory access requests associated with certain domains of processing operations, thereby preventing those domains from accessing certain regions of memory. By isolating accesses into distinct physical address spaces, this can provide a stronger security guarantee which does not rely on the page table permission information set by an operating system or hypervisor. 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 physical address spaces, the attribute information can be used to limit which physical addresses are accessible within a particular physical address space. This can be useful for ensuring that certain physical memory locations implemented in hardware either on-chip or off-chip can be restricted for access within a particular physical address space or a particular subset of physical address spaces if desired.

[0047] Hence, an apparatus may comprise physical address space (PAS) selection circuitry to select a selected PAS for the memory access request from among two or more PASs. In such an apparatus the attribute determination circuitry may be configured to determine, based on the attribute information associated with the target physical address, which of the plurality of physical address spaces is an allowed physical address space, where memory access requests associated with a physical address space other than an allowed physical address space are prohibited from accessing the target physical address.

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

[0049] Hence, for at least some components of the memory system, memory access requests whose virtual addresses are translated into physical addresses in different physical address spaces are treated as if they were accessing completely separate addresses in memory, even if the physical addresses in the respective physical address spaces actually correspond to the same location in memory.

[0050] For example, the at least one pre-PoPA memory system component could include 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 physical address spaces, then the accesses will cause separate cache or TLB entries to be allocated. Also, the pre-PoPA memory system component could include 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 physical address spaces. 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 physical address space accessible to the different domains to provide 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, separately encrypt data associated with a particular memory system resource with different encryption keys depending on which physical address space 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 physical address space identifier may be considered to be part of the address for this purpose).

[0051] 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 physical address spaces 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.

[0052] It may be possible, in some implementations, for the aliasing physical addresses in the different physical address spaces to be represented using different numeric physical address values for the respective different physical address spaces. This approach may require 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 physical address spaces. If this approach is taken then, at the point of physical aliasing, it can be sufficient simply to discard the physical address space identifier which identifies which physical address space is accessed using a memory access, and then to provide the remaining physical address bits downstream as a de-aliased physical address.

[0053] 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 physical address space this was provided from. Alternatively, in some cases the PoPA memory system component may still provide the physical address space 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 physical address space 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 physical address spaces.

[0054] Some systems supporting a plurality of physical address spaces may support operation in a number of domains. In some examples, the domains may include at least a less secure domain and a more secure domain (corresponding to a less secure physical address space and more secure physical address space respectively), and the more secure physical address space may be prohibited from being selected for memory access requests associated with the less secure domain. By prohibiting the less secure domain from selecting the more secure physical address space for memory access requests, then the less secure domain can be prevented from accessing data stored in locations indicated by the attribute information as accessible only from the secure physical address space. Hence, the secure domain can have access to regions of memory which are entirely isolated from the less secure domain, which can be useful for improving security. The more secure domain may be permitted to issue memory access requests in either the more secure or less secure physical address spaces, thereby having access to a greater range of physical addresses than the less secure domain.

[0055] In some examples, further domains of processing may also be supported. For example, an additional more secure domain associated with an additional more secure PAS may be supported. The additional more secure PAS may be prohibited from being selected for memory access requests associated with the less secure domain. The additional more secure PAS may also be prohibited from being selected for memory access requests associated with the more secure domain, and the more secure PAS may be prohibited from being selected for memory access requests associated with the additional more secure domain. By providing two more secure domains each with a corresponding more secure PAS which cannot be accessed from the other more secure domain (while memory access requests associated with the less secure domain cannot access any of those more secure 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. For example, the more secure domain and additional more secure domain may corresponding to the Secure and Realm domains mentioned below (or vice versa).

[0056] In some examples, there may be a most secure domain which is allowed to access any physical address space, and which has access to a physical address space which cannot be accessed by any other domain. For example, the domains may include a root domain for managing switching between other domains of the plurality of domains. The root domain is associated with a root PAS which is prohibited from being selected for memory access requests associated with a domain other than the root domain.

[0057] There may also be some systems which support a plurality of domains of operation but do not necessarily support a plurality of physical address spaces. In such examples, different domains of operation may have access to different sets of resources and may have a hierarchical structure in which certain domains are more trusted than others.

[0058] In systems supporting a plurality of domains, there may be a desire to restrict access to certain physical addresses to memory accesses issued from certain domains. This may be provided in addition to, or instead of, restricting access based on the physical address space in which the memory access request was issued. Hence, in some examples the attribute determination circuitry is configured to determine, based on the attribute information associated with the target physical address, which of the plurality of domains is an allowed domain, where memory access requests associated with a domain other than an allowed domain are prohibited from accessing the target physical address. Restricting access based on a domain in which a memory access request was issued can provide additional security guarantees in systems where there is a desire to prohibit access to a certain physical address from particular domains of operation. Using the set of attribute storage locations to represent the domain attribute information can be particularly useful, because representing this information directly in the entries of the physically addressed table structure may not be justifiable given the associated increase in entry size.

[0059] In some examples supporting both a plurality of domains and a plurality of physical address spaces, the attribute determination circuitry may be configured to determine, based on the attribute information associated with the target physical address, which of the combinations of the plurality of domains and the plurality of physical address spaces is an allowed combination of domain and physical address space, where memory access requests associated with a combination other than an allowed combination are prohibited from accessing the target physical address. Considering both the domain and physical address space of a memory access request can improve security and increase the flexibility of memory access controls.

[0060] For example, in some examples a more secure domain is generally permitted to issue a memory access request to a given target address in the less secure physical address space, and therefore if the attribute information indicates that the target physical address is accessible from the less secure physical address space then there is nothing to prohibit the more secure domain from accessing the given target address. However, there could be situations in which it is desired to prevent the more secure domain from accessing the target physical address accessible in the less secure physical address space. For example, this can improve robustness against confused deputy attacks, which is a form of attack exploiting the greater privileges of more secure software. For example, an attacker can trick software executing in the more secure domain into performing memory accesses which compromise resources associated with the less secure domain. By providing attribute information indicating allowed combinations of physical address space and allowed domains, then certain regions of the less secure PAS can be isolated from access by more secure software operating in the more secure domain, as for those regions the combination of less secure PAS and more secure domain may not be an allowed combination, and therefore memory access requests associated with more secure domain may be unable to access the physical addresses in those regions, even when they specify the less secure PAS associated with the less secure domain. This helps establish an additional layer of protection that can help in a “defence in depth” approach to defending resources used by less-secure software against confused deputy attacks. Considering combinations of allowed PAS and domain may greatly increase the number of possible encodings of the attribute information, and hence this technique may appear to be unusual in examples where attribute information may be specified directly in a physically addressed table structure. However, the use of indirection by specifying the attribute information in a separate attribute storage location may enable the use of arbitrary combinations of PAS and domain when considering whether an access request is allowed to access a particular physical address.

[0061] In some examples, the entries of the physically addressed table structure may specify certain attribute information in addition to specifying the index indicating the given attribute storage location. However, in some examples the size of the entries may be minimised by specifying only the index in each entry of the physically addressed table structure, and all of the attributes in the attribute storage location. Hence, in some examples, the attribute determination circuitry is arranged to determine the index from the whole of the corresponding entry of the physically addressed table structure.

[0062] In some examples, the attribute determination circuitry is configured to treat at least one encoding of an entry of the physically addressed table structure as a reserved encoding which cannot be used to indicate an attribute storage location, and in response to determining that a portion of the physically addressed table structure comprising the corresponding entry comprises an entry having the reserved encoding, the attribute determination circuitry is configured to trigger an error handling response. A reserved encoding may be, for example, an index which does not correspond to a valid entry in the set of attribute storage locations. The identification of the reserved encodings could be hardwired, or could be programmable such that the number of reserved encodings may be variable. Presence of an entry having a reserved encoding (which should not be selected for correctly configured regions of memory) can be a hint that an error has occurred (such as a malicious attempt to corrupt system operation by changing the state of an index identifying an attribute storage location, or an accidental error such as a flip in a bit from 0 to 1 or vice versa due to a particle strike or other randomly occurring physical event). Triggering an error handling response in response to detecting an entry having the reserved encoding can therefore help to reduce vulnerability to errors.

[0063] In some examples, the portion of the physically addressed table structure checked for reserved encodings when accessing the table structure to seek information for a given target physical address may comprise just the corresponding entry which relates to the given target physical address. However, in practice, if a large number of the encodings are used as nonreserved encodings (e.g., if the index has N bits and the set of attribute storage locations comprises almost 2AN attribute storage locations) then there will only be few reserved encodings for a given entry. If an entry is modified randomly, then the chance of accidentally choosing a nonreserved encoding may therefore be relatively high and the chance of identifying an error using the above approach in cases where the portion comprises only the corresponding entry may be relatively low.

[0064] Hence, in some examples the portion of the physically addressed table structure checked for reserved encodings when seeking information relating to a given target physical address may comprise more entries than the corresponding entry relating to that given target physical address, and the attribute determination circuitry may be configured to trigger the error handling response if any of the entries in the portion of the physically addressed table structure has the reserved encoding, even if that entry is not the corresponding entry for the target physical address associated with the current memory access request. In some examples, the portion may comprise a block of memory containing entries of the physically addressed table structure comprising the corresponding entry. However, to increase the chances of identifying an error even further, which may be especially useful in cases where there are an extremely limited number of reserved encodings, in some examples the portion may comprise several blocks of memory containing entries of the physically addressed table structure comprising the corresponding entry.

[0065] For example, in some examples an entry of the physically addressed table structure may comprise 4 bits encoding up to 2A4=16 different indices. If there were 15 valid attribute storage locations, then 1 encoding of the index may be a reserved encoding which cannot be used to indicate an attribute storage location. The physically addressed table structure may comprise segments of 64 bits which are loaded in a single memory access, and therefore there may be 16 entries in each segment of the physically addressed table structure which are loaded together when a given 4-bit entry is loaded. In some examples, the portion may comprise the 64-bit segment of the physically addressed table structure, such that if any of the 16 entries which are loaded when accessing the corresponding entry have the reserved encoding then the error handling response is triggered. This can increase the likelihood of identifying an error without increasing memory access overhead. In other cases where there is a greater desire to identify any errors, further segments of the table may be loaded along with the segment comprising the corresponding entry such that 128-, 256-, or 512-bit (for example) portions of the physically addressed table structure can be checked for the reserved encoding(s) when accessing the corresponding entry.

[0066] In some examples, the size of the attribute storage locations exceeds the size of the entries of the physically addressed table structure, allowing, for a given number of bits per entry of the physically addressed table structure, each entry to be associated with a larger number of attributes than could be achieved by directly indicating the attributes in each entry of the physically addressed table structure. However, in some examples the attribute storage locations may be no larger than the corresponding entry of the physically addressed table structure. In these examples, provision of the attribute storage locations may not reduce storage requirements of the physically addressed table structure, but may still be useful. For example, provision of the attribute storage locations can enable attribute information to be updated with a reduced number of operations. If several granules of physical addresses share the same set of attributes and it is desired to update that set of attributes, then in examples where the attribute information is directly specified in the physically addressed table structure, each entry would need to be updated individually. However, in examples where the entries sharing attributes all provide an index to the same attribute storage location storing the attribute information, then that attribute information can be updated in a single update to the attribute storage location.

[0067] As mentioned above, in some examples several devices may share access to a memory system comprising storage locations corresponding to the physical addresses which have corresponding entries in the physically addressed table structure. In some examples, it may be desirable to associate the same attributes with each physical address, regardless of the device from which the memory access originates. For example, this may enable security to be enforced consistently for each device having access to the memory. Each device accessing the memory may have its own instance of attribute determination circuitry, or several devices may share access to attribute determination circuitry. In either case, to associate the same attributes with physical addresses consistently across the system, in some examples the set of attribute storage locations may be enforced to be consistent across a plurality of instances of attribute determination circuitry. For example, the plurality of instances of attribute determination circuitry may determine attribute information associated with target physical addresses specified by memory access requests from different sources using the same set of attribute storage locations, or different sets of attribute storage locations which are enforced to be consistent with each other.

[0068] This could be achieved in various ways. For example, the sets of attribute storage locations may be stored in registers local to each instance of the attribute determination circuitry, and a mechanism may be provided to enforce consistency between the registers. Alternatively, the set of attribute storage locations could be stored in the memory which is shared between the devices comprising the plurality of instances of attribute determination circuitry. In these examples, by accessing the set of attribute storage locations from memory the plurality of instances of attribute determination circuitry access the same attribute information.

[0069] In some examples where the attribute information is stored in memory, the set of attribute storage locations may be cached locally for different instances of the attribute determination circuitry, and in such systems the cached copies may be enforced to be consistent with each other. For example, in response to any modification of the set of attribute storage locations, cached copies of the attribute storage locations may be invalidated, as discussed below.

[0070] In some examples, all accesses to a particular physical address within a given physical address space may be considered in the same way regardless of which particular hardware device initiates the request. 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.

[0071] Instead, in some examples, a memory access request received from the requester hardware device specifies a requester group identifier (RGID) associated with that request a hardware device. The attribute determination circuitry is configured to determine, based on the attribute information associated with the target physical address, which of the plurality of RGIDs is an allowed RGID, where memory access requests associated with an RGID other than an allowed RGID are prohibited from accessing 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.

[0072] In some examples, there may be regions of the physical address space which are protected by memory tagging in which memory locations are associated with a memory tag and memory requests are issued in association with an address tag. A comparison of the memory tag and address tag may be required for tagged regions of memory to determine whether the memory access is allowed. When processing a memory access request, it can therefore be useful to know whether the accessed region of memory is a tagged region of memory so it is known whether to perform the tag check. It can also be useful to know whether the accessed region of memory stores memory tags, because regions storing memory tags may be subject to separate permissions checks than other regions to prevent incorrect modification of the memory tags. For example, only a subset of tag-modifying access requests or store instruction types may be permitted to modify regions of memory designated for the storage of memory tags.

[0073] Regions protected by memory tagging and regions storing memory tags may be defined in the physical address space. Hence, a physically addressed table structure provides a particularly convenient mechanism for defining memory tagging attributes. Therefore, in some examples, the attribute determination circuitry is configured to determine, based on the attribute information associated with the target physical address, a memory tagging attribute comprising at least one of: an indication of whether the target physical address lies in a region of memory protected by memory tagging, and an indication of whether the target physical address lies in a region of memory storing memory tags.

[0074] The manner in which the attribute information is specified in the attribute storage locations is not particularly limited. In some examples, for each class of attribute a bit field with fewer bits than the total number of distinct values of that class of attribute could be provided. For example, if there were four possible physical address spaces, then a 2-bit field could be used to encode that attribute information. However, in some examples, to provide greater flexibility in specifying the attribute information (e.g., allowing certain attributes to be modified independently of the others), the attribute information may indicate at least one bitmap, where each bit of the at least one bitmap indicates whether a given class of memory access request is an allowed class of memory access request which is not prohibited from accessing the target physical address. For example, there may be a bit provided for each physical address space separately indicating whether a memory access request issued in that physical address space is allowed to access the target physical address. This can allow an arbitrary combination of attributes to be defined for a given target address. A bitmap is typically a much less compact encoding for representing a given amount of information than other encodings, and would appear an unusual choice for specifying attribute information directly in entries of the physically addressed table structure. However, since in the present technique the attribute information is defined in the separate set of attribute storage locations, it becomes possible to use a bitmap to represent attribute information without incurring an unreasonable increase in size for entries of the physically addressed table structure. Use of the set of attribute storage locations therefore enables the more flexible bitmap encoding to be used to represent the attribute information in some examples, enabling greater flexibility in the number of distinct combinations of attributes that can be set. As mentioned above, in some examples to enforce consistency of the attribute information, the attribute determination circuitry may be configured to invalidate any cached attribute information in response to an indication that the attribute storage location from which that attribute information was determined has been updated. For example, the ISA supported by the processing circuitry of a device may support an “invalidate attribute” instruction which, when executed, causes invalidation of locally cached versions of attribute information from the set of attribute storage locations. Whilst in some examples the invalidate attribute instruction may be a global instruction which when executed causes all cached attribute information to be invalidated, in some other examples the invalidate attribute instruction may specify an identifier of a particular attribute storage location (or subset of attribute storage locations - e.g. identified by a range of attribute storage entry identifiers), and only cached information derived from attribute information determined from the specified attribute storage location (or subset of attribute storage locations) may be invalidated in response to the invalidate attribute instruction. The invalidate attribute instruction may be executed at times when software modifies the attributes in an attribute storage location and especially in cases where the attribute storage locations are provided in memory where it can be difficult without the invalidate attribute instruction to determine whether a given store causes the modification of attribute information. By supporting the invalidate attribute instruction, or any other mechanism for invalidating cached copies of attribute information when attribute storage locations are updated, the system can enforce consistency between attribute information associated with target physical addresses.

[0075] Also as discussed above, there are some examples in which the set of attribute storage locations are provided in memory. Hence, so that the attribute determination circuitry can locate the attribute storage locations, the attribute determination circuitry may have access to a pointer storage location storing pointer information indicating one or more locations in a memory system comprising the set of attribute storage locations. The index specified by the corresponding entry of the physically addressed table structure may be added to or concatenated with the pointer information to identify the selected attribute storage location storing the attribute information corresponding to the target physical address.

[0076] In some examples, the attribute information 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. This can help support definition of readonly 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), and can therefore provide an additional layer of security in systems where the software setting the translation tables may not be trusted. Using the attribute storage locations to provide the read / write permissions means that they do not need to be indicated directly in the entries of the physically addressed table structure, and therefore can be provided with reduced overhead.

[0077] In some examples in which the attribute information indicates both the read / write attribute and an allowed RGID, the attribute information 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 producer-consumer 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.

[0078] 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 attribute determination 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 attribute determination program logic which performs, in software, equivalent functions to the address translation circuitry and address translation 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).

[0079] Particular examples will now be described with reference to the Figures.

[0080] Figure 1 schematically illustrates an example of an apparatus having processing circuitry 10 for performing data processing in response to instructions. The processing circuitry 10 may be capable of issuing memory access requests specifying a target virtual address (VA) identifying the addressable location to be accessed. 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.

[0081] The page table data specified in the virtually addressed page table structures may, in addition to providing the address translation, specify some permissions for controlling whether the memory access to a particular target virtual address is allowed. The page table structures used to define these permissions are typically controlled by an operating system or a hypervisor, and there is a risk that if an attacker manages to compromise the operating system or hypervisor, then the access permission attributes defined by the translation table structures may not be enough to provide sufficient security guarantee for certain sensitive workloads.

[0082] Hence, the apparatus also comprises attribute determination circuitry 17 configured to access a physically addressed table structure stored in a memory system 6, 7 to determine attribute information associated with the target physical address of the memory access request. By defining attribute information 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 attack can cause inappropriate access to certain physical addresses used by sensitive processing workloads.

[0083] The attribute information can be useful for controlling access to memory. However, the attribute determination circuitry does not need to access the attribute information only when handling a memory access request, and in some examples could pre-load and cache certain attribute information in anticipation that the attribute information will be relevant for the handling of a future access request.

[0084] The physically addressed table structure comprises entries corresponding to granules of physical addresses. To identify attribute information associated with the target physical address, the attribute determination circuitry looks up the physically addressed table structure to identify an entry corresponding to a granule of physical addresses containing the target physical address. The attribute determination circuitry uses an index specified by the corresponding entry of the physically addressed table structure to identify one of a set of attribute storage locations 19. The attribute storage locations 19 may be provided in registers or in memory 6, and could be cached from memory in the cache 7. The attribute information corresponding to the target physical address is specified by the selected attribute storage locations. Hence, the physically addressed table structure does not directly specify the (entirety of the) attribute information, but instead specifies an index which can be used to retrieve at least a portion of the attribute information from a separate attribute storage location.

[0085] The use of an index enables a much greater number of independent permissions to be associated with a given physical address than if the attribute information were directly specified in the physically addressed table structure, because the storage cost can be incurred in the attribute storage location rather than the physically addressed table structure itself. The number of index encodings available is typically less than the number of possible combinations of attributes (to allow the index to be smaller than the attribute information). For example, an N bit index can specify up to 2Nattribute storage locations. However, if there are more than 2Nencodings of the attribute information (which is likely to be the case) then this means that the number of attribute storage locations may be less than the number of possible combinations of attributes, so that it is not possible to represent every combination of attributes in the set of attribute storage locations. However, the inventors have recognised that only a subset of the possible encodings of the attribute information may be used at one time, so rather than assigning each unique combination of attributes its own attribute storage location, the commonly used subset of attribute information encodings may be provided in the attribute storage locations. Using fewer bits to encode the index than the attribute information means that the entries of the physically addressed table structure can be made smaller than if they were to directly specify the attribute information (or specify an index which can identify one of a full set of attribute storage locations which can identify each possible encoding), which can be very important for power and area overhead in modern systems with large physical address spaces when a large number of granules of physical addresses are associated with an entry and therefore where many entries are provided.

[0086] An additional benefit of representing the attribute information in the set of attribute storage locations, instead of the entries of the physically addressed table structure themselves, is that updating the attribute information can be made simpler. For example, if several entries share the same attribute information then if the attribute information were specified directly in the entries, each of the several entries would need to be updated. In comparison, only one update would be required to the attribute storage location when the entries instead specify the same index pointing to that attribute storage location.

[0087] Figure 2 illustrates an example of the physically addressed table structure and set of attribute storage locations in more detail. The physically addressed table structure of Figure 2 is illustrated as a single linear structure, although as discussed in further detail later can also be provided as a multi-level table structure. The target physical address which has been translated from a target virtual address specified by a memory access request is used to look up the physically addressed table structure. An entry is identified which corresponds to a granule of physical addresses comprising the target physical address, where the corresponding entry specifies an index.

[0088] The index specified by the corresponding entry of the physically addressed table structure is used to select a given attribute storage location among a set of attribute storage locations. The attribute determination circuitry is configured to determine the attribute information corresponding to the target physical address from the given attribute storage location.

[0089] Both of the physically addressed table structure and the set of attribute storage locations may be provided in memory. Alternatively, the set of attribute storage locations may be stored in registers. When stored in memory, the set of attribute storage locations may be cached locally to the attribute determination circuitry for faster access.

[0090] Although Figure 2 shows each entry of the physically addressed table structure specifying only an index, in other examples the entries could still specify further attributes in addition to those specified in the corresponding attribute storage location. However, in contrast to entries of the virtually addressed page table structure, entries of the physically addressed structure do not need to include an address translation corresponding to the entry. This means that in some examples the entries could comprise only the index, which would not be possible if indirection were applied to the page table structures.

[0091] Figure 3 schematically illustrates an example of a data processing system 2 having at least one requester device 4 and at least one completer device 6. An interconnect 8 provides communication between the requester 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 3, 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, 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 3 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 3 (e.g. as shown in Figure 4 discussed in more detail below, in some cases another requester device 4 may be a system memory management unit (SMMLI) which has address translation circuitry 16 and a PAS filter 20 but does not have the processing circuitry 10 shown in Figure 3).

[0092] The requester device 4 shown in Figure 3 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.

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

[0094] A PAS filter 20 acts as checking circuitry 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 (which is an example of attribute information discussed above) which is accessed using a granule protection table structure (which is a physically addressed table structure) stored within the memory system. As discussed above, an entry of the granule protection table corresponding to the target PA specifies an index, and the granule protection information is retrieved from an attribute storage location (not shown, although this may be a location within the registers 12 or within memory, for example at a completer device 6). The granule protection information, once retrieved from the attribute storage location using the physically addressed granule protection table, 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 3, 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.

[0095] While Figure 3 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 3 could also be included in a system where there is only one requester device, such as a single-core processor.

[0096] While Figure 3 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.

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

[0098] The above example of Figure 3 shows the address translation circuitry 16 and PAS filter 20 (checking circuitry), and the PAS selection circuitry represented by one or both of the address translation circuitry 16 and PAS filter 20, within a requester device 4 which may, for example, be a processor such as a CPU, GPU or other processing unit capable of execution of program instructions from an instruction set architecture.

[0099] However, as shown in Figure 4, the memory system accessed by such a requester device 4 (e.g. a CPU in the example of Figure 4) may be shared to also be accessible to one or more other devices 252 which may access memory via a system memory management unit (SMMU, also known as an input / output memory management unit or IOMMU) 250. The SMMU 250 may be an example of the other requester device 4 shown in Figure 3.

[0100] The devices 252 may, for example, include peripheral devices or I / O devices which provide an interface between the CPU 4 and the outside world (e.g. the devices could include display controllers, network controllers, user interface controllers, memory controllers for accessing external off-ship storage, etc.). Also, the devices 252 may include hardware accelerators which are provided to accelerate bespoke processing tasks using specialised hardware which can carry out this task more efficiently than general purpose processor hardware provided by the CPU 4. For example, hardware accelerators can be provided for accelerating functions such as cryptographic operations and machine learning tasks such as neural network processing. Use of a hardware accelerator can also be helpful to offload certain memory-intensive tasks to take place in the background of ongoing processing at the CPU 4.

[0101] As the devices 252 may not have their own address translation circuitry capable of translating virtual addresses to physical addresses based on the rich memory mappings defined by the page tables used by the CPU 4, the SMMU 250 may be provided as a system component to receive requests from the devices 252 specifying a virtual address, and to perform the required address translations on behalf of the devices.

[0102] Hence, in some systems, the SMMU 250 may be provided with address translation circuitry 16 and a PAS filter 20 similar to that shown in Figure 3, with the PAS filter 20 acting as checking circuitry for checking the permissions defined by the granule protection information, and one or both of the address translation circuitry 16 and PAS filter 20 of the SMMU 250 providing the PAS selection circuitry described earlier. Hence, the SMMU 250 can also support access to multiple physical address spaces and a third stage of checks based on the granule protection information as shown in Figure 9. The address translation circuitry 16 and PAS filter 20 may therefore operate in the same way as discussed above. The SMMU 250 may have a TLB 18 and / or GPI cache 22 similar to the corresponding cache structures in the requester 4 shown in Figure 3.

[0103] In some examples to be discussed where access requests may be filtered based on the domain issuing the memory access request, the PAS filter 20 of the SMMU 250 needs information on which domain (security state) is associated with a memory access request received from a device 252. The SMMU 250 will not have access to the system registers 12 of the CPU which define the register state 14 defining the current domain of operation, and in any case the requests sent by a given device 252 may be related to processing in a domain other than the current domain that is active at the CPU 4. Therefore, in the approach shown in Figure 4, the memory access requests sent to the SMMU 250 by a device 252 may specify a domain identifier which identifies the domain associated with the memory access request. For example, each device 252 may maintain a data structure identifying, for each workload assigned to the device, a corresponding domain identifier (which may be set, for example, at the time of assigning work to the device, based on the current domain 14 associated with the software that caused the work to be assigned to that device). This data structure can be used by the device 252 to select which domain to specify in the domain identifier provided to the SMMU 250 when a memory access request is issued to the SMMU 250. The particular mechanism by which memory access requests from devices are associated with particular domain identifier values may depend on the specific purpose of the device and the mechanism chosen by software developers for assigning workloads to the device 252, so may not be a required feature of the system hardware. However, in general the hardware support for providing signal paths allowing a domain identifier to be provided by the device 252 to the SMMU 250 along with a memory access request means that the PAS filter 20 within the SMMLI 250 can implement the protection checking using the domain associated with the memory access request, not just the selected PAS.

[0104] As shown in the example of Figure 4, the interconnect 8 may include a system cache 300 which can be an example of a pre-PoPA memory system component which treats aliasing physical addresses from different PASs as if they correspond to different memory system resources.

[0105] Figure 5 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).

[0106] The processing circuitry 10 is operable at a number of different exception levels 80, in this example four exception levels labelled ELO, EL1 , EL2 and EL3, where in this example EL3 refers to the exception level with the greatest level of privilege while ELO 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 ELO 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.

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

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

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

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

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

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

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

[0114] Therefore, as shown in Figure 5, 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.

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

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

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

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

[0119] As shown in Figure 5, 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.

[0120] Figure 6 schematically illustrates another example of a processing system 2 for supporting these techniques. Elements which are the same as in Figure 3 are illustrated with the same reference numeral. Figure 6 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.

[0121] As shown in Figure 6, 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 an index to identify an attribute storage location providing 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.

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

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

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

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

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

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

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

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

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

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

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

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

[0134] Figure 7 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 .

[0135] 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 GMPLI 20 to select the PAS.

[0136] 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:

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

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

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

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

[0141] Figure 8 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 attribute information corresponding to each granule of physical addresses 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 corresponding to a granule of physical addresses of a certain size (e.g. a 4K page). The GPT entry corresponding to a particular target physical address may specify an index for identifying an attribute storage location corresponding to that physical address, the attribute storage location specifying the granule protection information (GPI). 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. The GPI may also impose a further requirement regarding which domain is associated with 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.

[0142] However, in some implementations, in addition to allowing a granule of physical addresses to be accessed within a single assigned PAS defined by the GPI, the GPI could 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 8 the region 70 of the realm PAS is defined in the GPI identified by the attribute storage location indicated by the GPT as corresponding to that region 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 GPI 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 8, 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.

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

[0144] Figure 9 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.

[0145] Figure 10 shows an example of page table entry (PTE) formats which can be used for page table entries in the page table structures 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, 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 112 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 114, 116, 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).

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

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

[0148] 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, 116 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 non- secure 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 116 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.

[0149] Hence, Figure 11 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.

[0150] At step 130 in Figure 11 , 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 (I PA) and then from an I PA 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 I PA). At step 134 the address translation circuitry 16 or the PAS filter 20 determines which domain is the current domain, using the approach shown earlier.

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

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

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

[0154] 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 non- secure domains. Figure 12 summarises the operation of the address translation circuitry 16 and PAS filter 20. The PAS filtering 20 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 12), while a single bit of selection information “NS” is used to select the PAS in the other states. The security state indicated in Figure 12 as input to the granule protection check refers to the Domain ID identifying the current domain of the processing element 4.

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

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

[0157] 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. Once the relevant granule protection entry corresponding to the target PA of the original memory access has been returned from memory, then an index specified by the entry can be used to identify one of a set of attribute storage locations. The attribute storage locations may, for example, be provided as locations in a memory system (which may optionally be cached for faster access), or could be provided in a set of registers. The granule protection information corresponding to the target PA can be retrieved from the attribute storage location corresponding to the index specified by the relevant granule protection entry.

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

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

[0160] Figure 14 illustrates multi-level table structures which may be used for the translation table structures and physically addressed table structure (e.g., the GPT).

[0161] The MMU 16 or SMMLI 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.

[0162] 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 EL0 or EL1 in the exception model shown in Figure 5), 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 EL0 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). Despite their name, the intermediate physical addresses are not physical addresses because they do not correspond to a location in memory, and the name derives from the fact that the OS thinks that the IPAs are PAs. 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 14. 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).

[0163] 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:

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

[0165] • 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.

[0166] 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:

[0167] • 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_Block). The final entry of the traversal contains the output address (i.e. I PA 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 1GB and 2MB regions respectively).

[0168] • 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.

[0169] • The descriptor is invalid. In this case, the memory access generates a Translation fault. Figure 14 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).

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

[0171] 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 SMMLI 28. The cached information can include any of: a final stage-1 address mapping from VA to IPA, a final stage-2 mapping from IPA to PA 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), access permissions and attributes obtained from the stage-1 and stage-2 structures; and 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.

[0172] As shown in Figure 14, the physically addressed table structure may have a similar multilevel 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 physically addressed table structure is accessed based on a physically addressed table structure base address obtained from a register of the processor 4 or SMMLI 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 physically addressed table structure base address is EL3.

[0173] Unlike the translation tables, the physically addressed table structure is addressed using physical addresses, 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.

[0174] The physically addressed table structure associates a set of attribute information with each region of physical addresses by identifying an index which points to an attribute storage location storing the attribute information. The attribute information may be associated with a granule of physical addresses of a certain size, e.g. 4KB if the index is defined in the final-level table of the physically addressed table structure. As the corresponding entry of the physically addressed table structure does not need to specify an address translation mapping, the entry for a given 4KB region can be much smaller than the translation table entry providing the address mapping for the region, and so multiple entries for respective 4KB regions can be packed into a single cache line, so that the physically addressed table structure can be more compact than the translation tables and so a structure involving fewer table levels can be practical. For example, Figure 14 shows an example of a physically addressed table structure with a two-level structure, with the L1 physically addressed table structure being accessed based on a table pointer provided by an entry of the L0 physically addressed table structure corresponding to the target PA. The index used for each level of physically addressed table structure 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 physically addressed table structure is just one example, and other examples could have a different number of physically addressed table structure levels depending on the granularity (region size) for which the index is defined. Each set of attribute information identified by the index specified in a given entry of the physically addressed table structure can specify at least the PAS- based permissions mentioned above, but can also describe other pieces of attribute information as explained in further examples below.

[0175] In the system described with reference to Figures 4-13, the attribute information has been described to include an indication of the PAS from which the target physical address is available, and in some examples an allowed domain from which a memory access request to the target physical address is allowed to be in for the request to be granted. It will be appreciated that these are merely examples, and other attributes may be indicated by the attribute information.

[0176] For example, Figure 15 schematically illustrates a concept of tag-guarded memory accesses. The physical address space used to refer to memory locations within the memory system may be logically partitioned into a number of blocks 150 each comprising a certain number of addressable locations. For conciseness, in the example of Figure 15, each block 150 comprises four memory locations, but other block sizes could be used as well. Each block 150 is associated with a corresponding guard tag 152 (also referred to as a memory tag). The guard tags associated with a certain number of blocks 150 can be gathered together and stored either within a different architecturally accessible memory location 154 within the physical address space, or within additional storage locations provided in main memory which are not architecturally accessible (not mapped to the same physical address space). The use of separate non-architecturally accessible storage may in some cases be preferred to avoid using up space in the data caches for caching guard tag values, which could impact on the performance of the regular code and could make coherency management more complex. An additional tag cache could be provided in the micro architecture for caching tag values from the non-architecturally accessible storage, for faster access than if the tags had to be accessed from main memory. The particular mapping of which tag storage locations 154 correspond to each block 150 may be controlled by the load / store unit and could be hardwired or could be programmable.

[0177] Hence, when a tag-guarded memory access is required, an address tag 160 is compared against the guard tag 152. The address tag 160 is associated with the target address 162 identifying the addressed location 164 to be accessed, and the guard tag 152 is associated with the block of memory locations 150 which includes the addressed location 164. For example, in Figure 15 the target address 162 points to a certain location B1 in memory, marked 164 in the address space of Figure 15. Therefore the guard tag B which is associated with the block of locations B including location B1 is compared against the address tag 160 associated with a target address 164.

[0178] As shown in the top of Figure 15, the address tag 160 may be indicated within selected bits of the target address itself, such that it can be determined as a function of selected bits of the target address. In particular, the address tag may be determined from bits within a portion of the target address which is unused for indicating the specific memory location which is to be selected as the addressed location 164. For example, in some architectures the top portion of bits of the target address may always have a certain fixed value such as a sign extension (all 0s or all 1s) which are not used to select an addressed location, and therefore could be re-used to store the address tag, and so an address can be tagged with the address tag 160 by overwriting these unused bits with an arbitrary tag value. The particular address tag value can be selected by a programmer or compiler for example. The address tag and guard tag 152 can be a relatively small number of bits, e.g. 4 bits, and so need not occupy much space within the memory and within the target address. Providing 4 bits of tag space, i.e. 16 possible values of the tags, can often be enough to detect many common types of memory access errors.

[0179] Hence, when a tag-guarded memory access is performed, the load / store unit compares the address tag 160 and the guard tag 152 (associated with a block 150 including the addressed location 164), and determines whether they match. The load / store unit generates a match indication indicating whether the address tag 160 and the guard tag 152 matched. For example, this match indication could be a fault signal which is generated if there is a mismatch between the address tag 160 and the guard tag 152. Alternatively, the match indication may be an indication placed in a status register indicating whether there was a match. Further, the match indication may be an entry added to an error report to indicate the address for which the error was detected and / or the instruction address of the instruction which triggered the error. Memory access requests could be prevented if there is a mismatch between the address tag and guard tag. Alternatively, memory access requests could be allowed to proceed and the error reported for later analysis.

[0180] Memory tagging can be useful to identify errors which cause an address to be calculated incorrectly. A memory access request specifying the incorrectly calculated address will be associated with an address tag corresponding to the correct address, since the address tag is associated with the address pointer rather than the calculated address value. The incorrect address will point to a location having a guard tag which is unlikely to match the address tag associated with the request, because the address tag was not intended to match the guard tag associated with the incorrect location in memory.

[0181] In examples which use a portion of the target address to determine the address tag, note that this address tag is different to a tag portion of the target address which may be used by caches to determine whether the information from the addressed location identified by the target address is stored within the cache. Many caching schemes may store a tag portion of the address of a cached piece of data alongside that data within the cache, so that on searching the cache for a given address, part of the address can be compared with the tags stored alongside the cached data in order to determine whether the cached data actually corresponds to the required address. However, in this case the tag portion of the address, which is compared with the tag in the cache, would be part of the portion of the address which actually identifies the particular addressed location for which the data is required, i.e. changing the cache tag portion of an address would by definition result in the address pointing to a different addressed location within the memory system. In contrast, with the address tag used for the tag-guarded memory access, the memory access circuitry may select the addressed location for which data is required independent of the address tag. That is, even if the address tag has different values, the addressed location referenced by the target address may still be the same, since the selection of the addressed location depends only on other portions of the target address. This gives the freedom for compilers to set the address tags associated with particular addresses to any value to match the corresponding guard tag values which have been allocated to the relevant blocks of data in the memory system.

[0182] In some examples, memory tagging may only be enabled for a subset of memory locations, such as locations with higher security requirements. This may be the case because memory tagging may incur some latency on memory accesses, and it may be undesirable to incur the storage required to store the guard tags for every memory location. Hence, it would be desirable to provide an indication of which regions of memory are regions for which a tag check is required, and which are regions for which memory tagging is disabled, so that it is known how to handle a memory access request. The inventors have realised that the physically addressed table structure provides a particularly convenient mechanism for providing this information, since it already associates some attributes with each memory location and is looked up on memory accesses. Hence, there would be use in using the physically addressed table structure to indicate whether the target physical address lies in a region for which memory tagging is enabled. This would appear to be unusual, because if the physically addressed table structure were to directly specify attribute information in its entries, then incurring the cost of representing an indication of whether tag checks are required for the target physical address may be harder to justify. However, the inventors have realised that as a result of the attribute information being specified indirectly in a set of attribute storage locations, then this removes a barrier to representing in the attribute information an indication of whether the target address lies within a region of memory for which a tag check is required.

[0183] In addition to an indication of whether the target physical address lies in a region protected by memory tagging, the attribute information may provide an indication of whether the target physical address lies in a region storing memory tags (guard tags), such as location 154 in Figure 15. Access to guard tags may be restricted to prevent incorrect modification of the guard tags. For example, some systems may only allow certain types of memory access request to modify guard tags, and therefore when handling a memory access request it may be relevant whether the target physical address lies in a region storing guard tags. The physically addressed table structure provides a particularly convenient mechanism to track these permissions, and the use of indirection by storing the attributes in an attribute storage location enables this to be done with a much lower overhead than directly specifying the permissions in each entry of the table.

[0184] In some systems comprising a plurality of requester devices (e.g., processor 4 or other device 252 in Figure 4), each requester device may be associated with a requester group identifier (RGID) used to group hardware devices capable of initiating accesses to memory into two or more groups. 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.

[0185] The attribute information corresponding to a target physical address may include one or more attributes used during a memory access request 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 target physical address. This means that it is possible to define permissions which result in two hardware devices having differing rights to access the same physical address 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. As the RGID permissions are associated with particular physical addresses, the physically addressed table structure provides a particularly convenient mechanism to represent these attributes. It may not be justifiable to represent RGID permissions in each individual entry of the physically addressed table structure, but providing the set of attribute storage locations allows a much greater amount of attribute information to be specified, and hence by providing the attribute information in an attribute storage location rather than directly in the physically addressed table structure entries, it becomes more justifiable to use the physically addressed table structure to associate RGID permissions with granules of physical addresses.

[0186] Having regard to the discussion above, one example encoding of the attribute information may have bits allocated as follows: bit[O] Valid - indicates whether the entry is valid. If this bit has a value of 0, then this could indicate a reserved encoding. bit[1 -4] PAS Mask - Indicating an allowed physical address space of the memory access request, in which:

[0187] 0001 == Secure

[0188] 0010 == Non-secure

[0189] 0100 == Realm

[0190] 1000 == Root

[0191] Such that combinations of the PAS mask bits can indicate different combinations of allowed PASs. For example, 1010 may indicate that the location is accessible from Root and Nonsecure PASs only. bit[5-8] Allowed input Security State mask - Indicating which domains the physical address is accessible from, in which:

[0192] 0001 == Secure

[0193] 0010 == Non-secure

[0194] 0100 == Realm

[0195] 1000 == Root The security state mask indicates allowed domains which may access the physical address. In the same way as the PAS mask, the Security State mask can indicate various combinations of bits, e.g., 1100 indicates that the target physical address is accessible to memory access requests issued from processing circuitry operating in the root and realm domains only. Even if issued in the correct PAS (as indicated by the PAS mask), a request may be refused if it is issued by a domain which has been prohibited from accessing the target physical address. bit[9-16] RGID Mask - Indicating which requester groups are permitted to access the target physical address, in which:

[0196] 00000001 == RGID 0

[0197] 00000010 == RGID 1

[0198] 00000100 == RGID 2

[0199] 00001000 == RGID 3

[0200] 00010000 == RGID 4

[0201] 00100000 == RGID 5

[0202] 01000000 == RGID 6

[0203] 10000000 == RGID 7

[0204] The requestor group IDs may be allocated to different classes of requesters in various different ways. For example, RGID 0 may be the indicator associated with CPUs, such that memory access requests issued by all CPUs are associated with an RGID 0 indicator. In other examples, particular processing elements may be associated different RGIDs. In any case, the RGID Mask indicates which RGIDs may be specified by an allowable memory access request. If the RGID mask indicates that the requester issuing a memory access request is not permitted to access the target physical address, then an error may be raised and the request may be refused. bits[17-18] R / W permission bits - each bit indicating whether data is permitted to be read from or written to the target physical address respectively. Although these may be provided as standalone bits, in some other encodings the R / W permissions may be combined with the RGID permissions such that two bits are provided per requester group indicating R / W permissions specific to the corresponding requester group.

[0205] Figure 16 is a flow diagram illustrating a method according to the present technique. At step 1600 a memory access request specifying a target virtual address is received by address translation circuitry. The target virtual address is translated into a target physical address, for example using the S1 and S2 translation tables illustrated in Figure 14. At this stage, permissions associated with the target virtual address (and / or intermediate physical address) may be identified for controlling handling of the memory access request. In some examples, the target physical address may be associated with a physical address space by the translation tables.

[0206] Having obtained the target physical address, attribute determination circuitry may perform a lookup in an attribute cache using the target physical address to check whether attribute information associated with the target physical address has previously been determined and cached. If this lookup results in a miss (or if caching of the attribute information is not supported at all), then at step 1602, the target physical address determined by the address translation circuitry is used to identify a corresponding entry in a physically addressed table structure, such as the one indicated in Figure 14. The corresponding entry may be identified from one or more levels of table using portions of the target physical address. The corresponding entry does not need to be unique to the target physical address, and in some examples corresponds to a granule of addresses (e.g., contiguous addresses, such as a 4KB page in memory) which include the target physical address. The physically addressed table structure may be set by software having a greater privilege level than the software responsible for setting the translation tables (e.g., in some examples, access to the region of memory storing the physically addressed table structure may be limited to the Root PAS (EL3) - note it may be the responsibility of the software setting the physically addressed table structure to set the permissions such that this limitation in access to Root PAS is enforced for the addresses corresponding to the physically addressed table structure, and there may be no hardware feature of the apparatus which ensures that the relevant permissions have been set to guarantee that this limitation in access is enforced). Hence, the physically addressed table structure can be used to associate permissions with physical addresses which are less susceptible to bypass by compromised OSs / hypervisors, therefore increasing overall system security.

[0207] The corresponding entry may in some examples directly specify certain attributes associated with the target physical address. However, the corresponding entry at least specifies an index. At step 1604, the index specified by the corresponding entry is used to identify an attribute storage location out of a set of attribute storage locations. For example, the index may be added to a base address to identify a location in memory, and the location in memory may be the attribute storage location. Alternatively, the index may identify a register acting as the attribute storage location.

[0208] At step 1606, attribute information is determined from the given attribute storage location. Determining attribute information from the attribute storage location rather than directly from the corresponding entry of the physically addressed table structure means that entries of the physically addressed table structure need only specify an index, rather than a full set of attributes. Hence, entries of the physically addressed table structure can be made smaller. Given the large number of entries that would be provided in modern systems having large physical address spaces, this can lead to a significant reduction in size of the physically addressed table structure. As several entries may specify the same index, and therefore may access the same attribute storage location to determine the attribute information, overall storage requirements can also be decreased by sharing the attribute information between entries.

[0209] Use of the attribute storage locations to specify the attribute information means that a larger amount of attribute information may be associated with each physical address without necessarily increasing the size of the physically addressed table structure (the entries could be made larger to specify a larger index to identify one of a larger set of attribute storage locations if a greater range of distinct encodings of the attribute information was desired, but the size of the index is not directly coupled to the size of the attribute information). This opens the door to associating attributes with physical addresses which would otherwise be much harder to justify, and therefore allows device security to be increased in new ways.

[0210] Similar to the physically addressed table itself, if the attribute storage locations are a memory-based structure, access to the region of memory storing the physically addressed table structure may be limited to the Root PAS (EL3), again based on reliance on the software that manages the attribute storage locations setting the GPT or other attributes associated with the physical address storing the attributes appropriately.

[0211] At step 1608 the attribute information associated with the target physical address may be used to control handling of the memory access request. The attribute information may also be cached (e.g., in the attribute cache mentioned earlier), so that it may be quicker to identify in the future the attributes used to control memory accesses to the same target physical address or another address in the same granule. In some examples, the attribute information may be cached without handling the memory access itself, for example if the memory access request was merely an indication that a memory access may be requested to the target virtual address in the future, acting as a prompt to prefetch the attribute information.

[0212] Figure 17 is a flow diagram illustrating a method of handling a memory access request in dependence on attribute information. At step 1700 the attribute information determined as indicated in Figure 16 is used to determine allowed classes of memory access request. This may include allowed combinations of several features of the access request, such as whether the access request is a read or a write, the physical address space in which the target physical address lies, the domain of operation from which the memory access request was issued, the type of requester device from which the memory access request was issued, and so on. The attribute information may for example specify attribute information using a bitmap as indicated above, from which the allowed classes of access requests can be determined.

[0213] At step 1702, the properties of the memory access request are compared with the attribute information to determine whether the memory access request is an allowed memory access request.

[0214] If not, then at step 1706 an error handling response is triggered. This may involve rejecting the memory access request and / or signalling a fault. An error log could also be maintained to track the occurrence of the error.

[0215] If the attribute information indicates that the memory access request is an allowed memory access request, then at step 1704 handling of the request is allowed subject to any further checks which may need to be carried out, such as checks based on the permissions specified by the translation tables. Figure 18 is a flow diagram illustrating a method of error detection for the physically addressed table structure. To reduce storage costs, entries of the physically addressed table structure may be provided without error correcting bits. Hence, on retrieving an entry of the physically addressed table structure (e.g., from memory) it can be difficult to identify if the entry has been modified maliciously or accidentally (e.g., by a random bit-flip). Whilst the entries may be encrypted in memory such that they may not be maliciously modified to have a particular encoding, there may still be a chance that the entries could be modified randomly to cause the system to behave incorrectly.

[0216] One way that errors may be identified is by reserving a number of encodings of the entries of the physically addressed table structure, such that they cannot be used to indicate an attribute storage location. For example, if there were 4 bits in each entry having 16 possible encodings, then there may be (for example only) 14 encodings which indicate one of the attribute storage locations and 2 reserved encodings incapable of indicating an attribute storage location. If the corresponding entry has a reserved encoding then it can be identified that an error has occurred (because that encoding should not be used).

[0217] Identifying a random error using a single entry can have a relatively low probability of success, as the probability of the error causing the entry to take a reserved encoding may be relatively low (e.g., 1 / 8 in the example given above). However, as the entries of the physically addressed table structure may be so small (e.g., 4 bits), then due to the nature of typical processing systems, several entries may be loaded at the same time whenever one entry is loaded. For example, systems may load a minimum of 64 bits of memory each time, therefore loading 16 entries at once. In these cases, an error in any one of the loaded entries may be indicative of errors more generally in the physically addressed table structure, and therefore may indicate that the corresponding entry may not be trusted (even if the corresponding entry does not have a reserved encoding). Hence, the entire loaded portion may be checked for reserved encodings when determining whether to trust the corresponding entry.

[0218] To increase the chance of identifying an error yet further, which may be particularly relevant when the number of reserved encodings is low (e.g., 1 encoding), greater portions of memory may be loaded and checked for reserved encodings when checking for errors in one reserved encoding. That is, even if the minimum amount to be loaded from memory is 64 bits, a greater amount such as 128 bits or 256 bits may be loaded when accessing the corresponding entry, even if a smaller amount of data could be loaded. The entries stored in the whole loaded portion may then be checked for reserved encodings to determine whether to trust the one corresponding entry.

[0219] Hence, at step 1800 a portion of the physically addressed table structure comprising the corresponding entry is retrieved by error detecting circuitry, where the portion may include just the corresponding entry, a cache line comprising the corresponding entry, or a larger portion of memory. At step 1802, the error detecting circuitry may determine whether any entries in the portion have a reserved encoding.

[0220] If, at step 1802 it is determined that any entries have a reserved encoding, even if the corresponding entry does not have a reserved encoding, then at step 1806 an error handling response is triggered. The error handling response may vary depending on implementation, but could involve generating an indication that an error has been detected and may in some examples involve preventing the corresponding entry from being used to determine the attribute information. If there are no entries with the reserved encoding, then at step 1804 no error handling response is triggered.

[0221] A similar technique could also be applied to the attribute information stored in the attribute storage locations, where the attribute information could be provided with a number of reserved encodings for error detection. However, given that storage is less of a concern in the attribute storage locations, the attribute storage locations could alternatively specify some error detection / correction bits (e.g., parity bits, ECCs) within the attribute information which can be used to detect and optionally correct errors.

[0222] Figure 19 is a flow diagram illustrating a method of handling a memory access request in a system supporting memory tagging. At step 1900, the attribute information (determined as indicated in Figure 16) is used to determine memory tagging attributes associated with the target physical address.

[0223] At step 1902, the memory tagging attributes are used to determine whether the target physical address lies within a region of memory protected by memory tagging. If so, then at step 1904 a tag check can be triggered so that a memory tag is retrieved and compared with an address tag associated with the memory access request.

[0224] At step 1906, the memory tagging attributes are used to determine whether the target physical address lies within a region of memory designated for the storage of memory tags. If so, then at step 1908 the memory access is controlled to prevent incorrect modification of the memory tags. For example, the memory access request may only be permitted if it is a predetermined type of memory access designated for modifying memory tags (e.g. a memory access triggered by a dedicated class of one or more types of tag modifying instruction, separate from a more general class of load / store instructions). The predetermined type of memory access request may not directly specify the address lying in the region for storing memory tags, but may specify another address associated with the address storing the memory tags.

[0225] If the target physical address does not lie in a region protected by memory tagging or storing memory tags, then the memory tagging attribute may not be relevant for the handling of the memory access request, and handling of the memory access request may be handled based on other attribute information.

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

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

[0228] 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 GDSII. 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.

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

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

[0231] Figure 20 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 430, optionally running a host operating system 420, supporting the simulator program 410. 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 IISENIX Conference, Pages 53 - 63.

[0232] 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 430), some simulated embodiments may make use of the host hardware, where suitable.

[0233] The simulator program 410 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 400 (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 410. Thus, the program instructions of the target code 400 may be executed from within the instruction execution environment using the simulator program 410, so that a host computer 430 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 400 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.

[0234] The simulator code includes processing program logic 412 which emulates the behaviour of the processing circuitry 10, e.g. including instruction decoding program logic which decodes instructions of the target code 400 and maps the instructions to corresponding sequences of instructions in the native instruction set supported by the host hardware 430 to execute functions equivalent to the decoded instructions. The processing program logic 412 also simulates processing of code in different exception levels and domains as described above. Register emulating program logic 413 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 400. Hence, instead of such architectural state being stored in hardware registers 12, it is instead stored in the memory of the host processor 430, with the register emulating program logic 413 mapping register references of instructions of the target code 400 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.

[0235] The simulation code includes address translation program logic 414 which emulates the functionality of the address translation circuitry 16. Although not shown, the simulation code may also comprise filtering program logic which emulates the functionality of the PAS filter 20. The simulation code also comprises attribute determination program logic 416 which uses a physically addressed table structure and set of attribute storage locations to determine attribute information associated with the target physical address translated by the address translation program logic 414. One or both of the address translation program logic 414 and filtering program logic 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 412 and PAS selection information defined using the page tables. Hence, the address translation program logic 414 translates virtual addresses specified by the target code 400 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 415). The attribute information may include RGID information as discussed earlier. For the simulated example, the RGIDs indicate groups of simulated requester hardware devices and the RGIDs are assigned by the simulator code 410 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 430. 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.

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

[0237] 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 to translate a target virtual address of a memory access request into a target physical address; and attribute determination circuitry to use the translated target physical address to determine attribute information associated with the target physical address; wherein the attribute determination circuitry is configured to: identify a corresponding entry of a physically addressed table structure using the target physical address, and determine the attribute information from a given attribute storage location among a set of attribute storage locations, the given attribute storage location identified by an index indicated by the corresponding entry of the physically addressed table structure.

2. The apparatus according to claim 1 , wherein the attribute determination circuitry is configured to cache the attribute information from the attribute storage location in a cache location associated with the target physical address.

3. The apparatus according to any of claims 1 and 2, wherein the attribute determination circuitry is configured to control handling of the memory access request based on the attribute information.

4. The apparatus according to any preceding claim, 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 attribute determination circuitry is configured to determine, based on the attribute information associated with the target physical address, which of the plurality of physical address spaces is an allowed physical address space, where memory access requests associated with a physical address space other than an allowed physical address space are prohibited from accessing the target physical address.

5. The apparatus according to claim 4, 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 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 isconfigured to treat the aliasing physical addresses from different physical address spaces as if the aliasing physical addresses correspond to different memory system locations.

6. The apparatus according to any of claims 4 and 5, wherein the address translation circuitry is configured to translate a memory access request 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.

7. The apparatus according to any preceding claim, wherein the address translation circuitry is arranged to translate a memory access request associated with one of a plurality of domains of processing.

8. The apparatus according to claim 7, wherein the attribute determination circuitry is configured to determine, based on the attribute information associated with the target physical address, which of the plurality of domains is an allowed domain, where memory access requests associated with a domain other than an allowed domain are prohibited from accessing the target physical address.

9. The apparatus according to any of claims 7 and 8, 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 attribute determination circuitry is configured to determine, based on the attribute information associated with the target physical address, which of the combinations of the plurality of domains and the plurality of physical address spaces is an allowed combination of domain and physical address space, where memory access requests associated with a combination other than an allowed combination are prohibited from accessing the target physical address.

10. The apparatus according to any preceding claim, in which the attribute determination circuitry is arranged to determine the index from the whole of the corresponding entry of the physically addressed table structure.

11. The apparatus according to any preceding claim, in which the attribute determination circuitry is configured to treat at least one encoding of an entry of the physically addressed table structure as a reserved encoding which cannot be used to indicate an attribute storage location; and in response to determining that a portion of the physically addressed table structure comprising the corresponding entry comprises an entry having the reserved encoding, the attribute determination circuitry is configured to trigger an error handling response.

12. The apparatus according to any preceding claim, in which the size of the given attribute storage location exceeds the size of the corresponding entry of the physically addressed table structure.

13. The apparatus according to any preceding claim, in which the set of attribute storage locations is enforced to be consistent across a plurality of instances of attribute determination circuitry.

14. The apparatus according to any preceding claim, wherein the address translation circuitry is configured to translate a memory access request associated with one of a plurality of requester group identifiers (RGIDs) associated with a requester device which issued the memory access request; and the attribute determination circuitry is configured to determine, based on the attribute information associated with the target physical address, which of the plurality of RGIDs is an allowed RGID, where memory access requests associated with an RGID other than an allowed RGID are prohibited from accessing the target physical address.

15. The apparatus according to any preceding claim, wherein the attribute determination circuitry is configured to determine, based on the attribute information associated with the target physical address, a memory tagging attribute; wherein the memory tagging attribute comprises at least one of: an indication of whether the target physical address lies in a region of memory protected by memory tagging; and an indication of whether the target physical address lies in a region of memory storing memory tags.

16. The apparatus according to any preceding claim, wherein the attribute determination circuitry is configured to determine the attribute information from at least one bitmap indicated by the given attribute storage element, where each bit of the at least one bitmap indicateswhether a given class of memory access request is an allowed class of memory access request which is not prohibited from accessing the target physical address.

17. The apparatus according to any preceding claim, in which the attribute determination circuitry is configured to invalidate, in response to an indication that an attribute storage location has been updated, cached attribute information determined from the set of attribute storage locations.

18. The apparatus according to any preceding claim, wherein the attribute determination circuitry has access to a pointer storage location storing pointer information indicating one or more locations in a memory system comprising the set of attribute storage locations.

19. The apparatus according to any preceding claim, wherein the attribute determination circuitry is configured to determine, based on the attribute information associated with the target physical address, at least one read / write permission attribute indicative of whether read access to the target physical address is permitted and separately whether write access to the target physical address is permitted.

20. A computer-readable medium to store computer-readable code for fabrication of the apparatus according to any of claims 1 to 19.

21. A method comprising: translating a target virtual address of a memory access request into a target physical address; and using the translated target physical address to determine attribute information associated with the target physical address; wherein determining the attribute information comprises: identifying a corresponding entry of a physically addressed table structure using the target physical address; and determining the attribute information from a given attribute storage location among a set of attribute storage locations, the given attribute storage location identified by an index indicated by the corresponding entry of the physically addressed table structure.

22. A computer program comprising instructions which, when executed by a host data processing apparatus, control the host data processing apparatus to provide an instruction execution environment for executing target program code, the computer program comprising:address translation program logic to translate a target virtual address of a memory access request into a target simulated physical address; and attribute determination program logic to use the translated target simulated physical address to determine attribute information associated with the target simulated physical address; wherein the attribute determination program logic is configured to: identify a corresponding entry of a physically addressed table structure using the target simulated physical address, and determine the attribute information from a given attribute storage location among a set of attribute storage locations, the given attribute storage location identified by an index indicated by the corresponding entry of the physically addressed table structure.

23. A computer-readable medium to store the computer program according to claim 22.

Images