EP4670051A1

EP4670051A1 - DETERMINE WHETHER A MEMORY ACCESS REQUEST PROVIDED BY A REQUESTER DEVICE REFUSES

Info

Publication number: EP4670051A1
Application number: EP24701270.1A
Authority: EP
Inventors: Jason Parker; Yuval Elad
Original assignee: ARM Ltd; Advanced Risc Machines Ltd
Current assignee: ARM Ltd
Priority date: 2023-02-24
Filing date: 2024-01-11
Publication date: 2025-12-31
Also published as: TW202435076A; WO2024175870A1; IL322294A; CN120752619A; GB202302688D0; GB2627496A; KR20250151484A; GB2627496B; JP2026509719A

Abstract

Apparatus comprising PAS selection circuitry (16) and access control circuitry (23). The PAS selection circuitry is responsive to a memory access request issued by a requester device, the memory access request specifying a memory address identifying a memory location, to select, based on a current domain of operation of the requester device, one of a plurality of physical address spaces, PASs, to be associated with the memory access request. The access control circuitry comprises PAS checking circuitry (20) to reject the memory access request in response to address-space permissions information, defined for the identified memory location, indicating that memory access requests associated with the selected PAS are prohibited from accessing the identified memory location, and device permissions checking circuitry (92) to reject the memory access request in response to device permissions information, defined for the requester device, indicating that memory access requests issued by the requester device are prohibited from accessing the selected PAS.

Description

DETERMINING WHETHER TO REJECT A MEMORY ACCESS REQUEST ISSUED BY A REQUESTER DEVICE

The present technique relates to the field of data processing.

A data processing system may have address translation circuitry to translate an address identified by memory access request (e.g. this could be a virtual address) to a physical address corresponding to a location to be accessed in a memory system.

Viewed from a first example of the present technique, there is provided an apparatus comprising:

PAS selection circuitry responsive to a memory access request issued by a requester device, the memory access request specifying a memory address identifying a memory location, to select, based on a current domain of operation of requester device, one of a plurality of physical address spaces, PASs, to be associated with the memory access request; and access control circuitry responsive to the memory access request to determine, based on the selected PAS, whether to reject the memory access request, wherein the access control circuitry comprises:

PAS checking circuitry to reject the memory access request in response to address-space permissions information, defined for the identified memory location, indicating that memory access requests associated with the selected PAS are prohibited from accessing the identified memory location; and device permissions checking circuitry to reject the memory access request in response to device permissions information, defined for the requester device, indicating that memory access requests issued by the requester device are prohibited from accessing the selected PAS.

Viewed from a second example of the present technique, there is provided a method comprising: in response to a memory access request issued by a requester device, the memory access request specifying a memory address identifying a memory location: selecting, based on a current domain of operation of the requester device, one of a plurality of physical address spaces, PASs, to be associated with the memory access request; determining, based on the selected PAS, whether to reject the memory access request, wherein the determining comprises: rejecting the memory access request in response to address-space permissions information, defined for the identified memory location, indicating that memory access requests associated with the selected PAS are prohibited from accessing the identified memory location; and rejecting the memory access request in response to device permissions information, defined for the requester device, indicating that memory access requests issued by the requester device are prohibited from accessing the selected PAS.

Viewed from a third example of the present technique, there is provided 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:

PAS selection program logic responsive to a memory access request issued by a requester, the memory access request specifying a memory address identifying a memory location, to select, based on a current domain of operation of the requester, one of a plurality of physical address spaces, PASs, to be associated with the memory access request; and access control program logic responsive to the memory access request to determine, based on the selected PAS, whether to reject the memory access request, wherein the access control program logic comprises:

PAS checking program logic to reject the memory access request in response to address-space permissions information, defined for the identified memory location, indicating that memory access requests associated with the selected PAS are prohibited from accessing the identified memory location; and device permissions checking program logic to reject the memory access request in response to device permissions information, defined for the requester, indicating that memory access requests issued by the requester are prohibited from accessing the selected PAS.

Viewed from a third example of the present technique, there is provided a computer- readable storage medium to store the computer program described above. The computer- readable storage medium may be transitory of non-transitory.

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:

Figure 1 illustrates an example of a data processing apparatus;

Figure 2 illustrates a number of domains in which processing circuitry can operate;

Figure 3 illustrates an example of a processing system supporting granule protection lookups;

Figure 4 schematically illustrates aliasing of a number of physical address spaces onto a system physical address space identifying locations in the memory system;

Figure 5 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; Figure 6 is a flow diagram illustrating a method of determining the current domain of operation of the processing circuitry;

Figure 7 shows examples of page table entry formats for page table entries used for translating virtual addresses to physical addresses;

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

Figure 9 illustrates an example of access control circuitry;

Figure 10 illustrates an example of system registers;

Figure 11 illustrates another example of a data processing apparatus;

Figure 12 illustrates a further example of a data processing apparatus;

Figure 13 is a flow diagram illustrating an example method for checking whether to reject a memory access request; and

Figure 14 shows a simulator example that may be used.

Before discussing example implementations with reference to the accompanying figures, the following description of example implementations and associated advantages is provided.

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 physical address associated with a location in a memory system to be accessed. The mappings between virtual addresses and physical addresses may be defined in one or more page 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, all virtual addresses may be mapped by the address translation circuitry onto a single physical address space which is used by the memory system to identify locations in memory to be accessed. In such a system, control over whether a particular software process can access a particular address is provided solely based on the page table structures used to provide the virtual-to-physical address translation mappings. However, such page table structures may typically be defined by an operating system and/or a hypervisor. 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.

Therefore, for some systems where there is a need for certain processes to execute securely in isolation from other processes, the system may support operation in a number of domains and a number of distinct physical address spaces may be supported, where 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. By isolating accesses from different domains of operation of the processing circuitry into respective distinct physical address spaces as viewed for some memory system components, this can provide a stronger security guarantee which does not rely on the page table permission information set by an operating system or hypervisor.

Note that, in the present technique, it is not essential to provide virtual-to-physical address translation. However, it should be noted that where this is provided, the multiple different physical address spaces are different from the multiple virtual address spaces which may be provided.

In accordance with the present technique, an apparatus is provided with PAS selection circuitry responsive to a memory access request issued by a requester device, the memory access request specifying a memory address identifying a memory location, to select, based on a current domain of operation of the requester device, one of a plurality of physical address spaces, PASs, to be associated with the memory access request.

For example, the memory address specified by the memory access request could be a memory address in an input address space (e.g. a virtual address in a virtual address space, or an intermediate address representing an intermediate stage in the translation of a virtual address into a physical address), and hence the memory location may be identified by translating the memory address into a physical address. Alternatively, the memory address could be a physical address in a system physical address space (e.g. the apparatus may provide a single “system” physical address space in which each memory location maps to a single memory system resource - this system PAS is then mapped onto the plurality of PASs described above).

The apparatus of the present technique supports the use of multiple PASs - for example, a requester device may operate (e.g. execute instructions and/or perform data processing) in any of a number of domains of operation, and a separate PAS could be defined for each of the domains of operation. Memory access requests issued by the requester device (which could be an internal processing element that forms part of the apparatus, or an external/peripheral device) can thus be assigned to a particular PASs depending on the current domain of operation of the requester device (e.g. the domain of operation of the requester device at the time the memory access request was issued). The PAS selection circuitry is responsible for selecting the PAS to be associated with a given memory access request. As discussed above, providing multiple distinct PASs can provide isolation between memory accesses from different domains of operation.

The apparatus of the present technique also includes access control circuitry responsive to the memory access request to determine, based on the selected PAS, whether to reject the memory access request. The access control circuitry may perform any number of checks to determine whether the memory access request should be rejected (as opposed to, for example, being passed on to another component downstream (e.g. logically closer to the memory system) of the access control circuitry). In the present technique, the access control circuitry performs at least a PAS check based on the identified memory location and the selected PAS, and a device check based on the requester device and the PAS. However, it will be appreciated that further checks might also be performed, and hence a memory access request that passes both of these checks might still be rejected by the access control circuitry if it fails another check.

In the present technique, the access control circuitry comprises PAS checking circuitry to perform the check based on the selected PAS and the identified memory location, and device permissions checking circuitry to perform the check based on the selected PAS and the requester device. In particular, the PAS checking circuitry rejects the memory access request in response to address-space permissions information, defined for the identified memory location, indicating that memory access requests associated with the selected PAS are prohibited from accessing the identified memory location. Hence, the PAS checking circuitry (which may also be referred to as a “PAS filter”) enforces address-space permissions information that determines which PASs are permitted to access which memory resources. Note that the address-space permissions information may, in some examples, comprise “granule protection information” (GPI).

The device permissions checking circuitry rejects the memory access request in response to device permissions information, defined for the requester device, indicating that memory access requests issued by the requester device are prohibited from accessing the selected PAS. Hence, the device permissions checking circuitry is responsible for enforcing device permissions information that determines which devices are permitted to access which PASs. The check performed by the device permissions checking circuitry may, therefore, be dependent on the identity of the device as well as being dependent on the selected PAS. The identity of the device can be determined in any of a number of ways, which may be dependent on the type of the requester device and/or on how the device permissions checking circuitry is configured. For example, if the device permissions checking circuitry is associated with a particular requester device (e.g. if the requester devices is separated from a memory system by an interconnect, the device permissions checking circuitry could be provided on the requester-side of the interconnect (e.g. memory access requests could be filtered, by the device permissions checking circuitry, before being passed to the interconnect)), the identity of the requester device may be implicit. On the other hand, if the device permissions checking circuitry is associated with multiple requester devices, it may determine the identity of the requester device based on a device identifier associated with the memory access request (e.g. if the requester device is an external device), or based on requester identifying information held in a register or other storage circuitry.

The device permissions checking circuitry, therefore, provides an additional layer of security on top of that provided by the PAS checking circuitry, and makes it possible to isolate regions of memory from particular devices. This can be particularly useful in, for example, a system comprising a secure processing element or secure device that is responsible for performing particularly high-security processes - e.g. this could include face-unlock or biometrics authentication processes. The device permissions checking circuitry of the present technique improves the security of the apparatus, by making it possible to isolate data associated with such processes from other devices, even if those devices are able to generate requests having the same selected PAS.

As suggested above, the PAS checking circuitry and the device permissions checking circuitry need not necessarily be provided in the same physical location. Moreover, the checks performed by the PAS checking circuitry and the device permissions checking circuitry could either be performed one after the other (optionally with some time between the two checks, during which time other operations (such as other checks) may be performed), or they may be performed in parallel. In addition, if the memory access request is rejected as a result of one check, the other check may not be performed (e.g. the memory access request may be rejected in response to failing either one of the checks, which may mean that the other check is not performed).

In some examples, the device permissions checking circuitry is permitted, in response to a first memory access request issued by the requester device and a second memory access request issued by a further requester device, wherein the first memory access request and the second memory access request are associated with the same selected PAS and identify the same memory location, to reject the first memory access request without rejecting the second memory access request, in dependence on the device permissions information.

If a memory access request passes the check performed by the PAS checking circuitry, this does not mean that it will necessarily pass the check performed by the device permissions checking circuitry. Indeed - as in this example - even if two memory access requests identify the same memory location and are associated with the same PAS, it is possible for the device permissions checking circuitry to reject one of the memory access requests and not reject the other memory access request (e.g. even if both passed the check performed by the PAS checking circuitry). For example, the first and second memory access requests may have been issued by first and second requester devices (respectively) which are different from one another, where the first requester device is permitted to access the selected PAS while the second requester device is prohibited from accessing the selected PAS.

In some examples, the device permissions checking circuitry is configured to identify the device permissions information in dependence on the contents of at least one data structure accessible to the device permissions checking circuitry.

For example, the device permissions checking circuitry may read, in response to the memory access request, the contents of the at least one data structure (e.g. there could be at least one data structure for each requester device, or a single data structure with at least one entry or field corresponding to each of a plurality of requester devices) to determine the device permissions information.

In some examples, the at least one data structure is configured to hold, for a given PAS, a value indicating whether the requester device is prohibited from accessing the given PAS.

In this way, a single value held in the at least one data structure can be set to prevent the requester device from being able to access a given PAS; the value thus effectively disables the PAS from the perspective of the requester device - hence, the value may be revered to as a “PAS disable” (PASD) value. For example, the at least one data structure may hold a value corresponding to each available PAS - for example a separate field or entry could be provided for each PAS. However, note that there may not necessarily be a value held for every available PASs - e.g. in particular examples where the available PASs include a root PAS (e.g. a PAS accessible to code responsible for managing switching between different domains of operation), there may not be any value held in the at least one data structure that corresponds to the root PAS. This may be because the root PAS is already typically only accessible to the most trusted processes, so the additional protection provided by the PASD value may not be necessary.

In some examples, the apparatus is prohibited from writing data to the at least one data structure in response to instructions executed at an exception level less privileged than a threshold exception level.

This can ensure that the device permissions information recorded in the at least one data structure cannot be modified by untrusted software (e.g. software operating at less privileged exception levels than the threshold exception level). This further improves the security of the system.

In some examples, the threshold exception level comprises a most privileged exception level.

Hence, in this example, only the most trusted processes (e.g. those which are permitted to operate at the most privileged exception level) are allowed to modify the device permissions information held in the at least one data structure. This even further improves the security of the system.

The at least one data structure can, in some examples, include at least one system register, but it can also (or instead) include another type of data structure. As a particular example, if the requester device is an external device and the device permissions checking circuitry is located in a system memory management unit (SMMLI), the device permissions information state for each device may come from a Stream Table Entry (STE). For example, each data flow through the SMMLI may be called a stream, and a single stream may be shared by more than one device, and/or, a single device may have multiple streams. Hence, the device permissions information could be expressed within a STE.

Moreover, the Stream Table may not be the only table that describes the device configuration or access permissions (including the device permissions information described herein) for each device. Other data structures - such as a Device Permission Table (DPT) - can also hold information that should be the same as the SMMLI, which can be used by devices in different configurations. Hence, these other data structures may also act as the at least one data structure.

In some examples, the at least one data structure comprises a system register, and the apparatus is prohibited, in response to a register lockdown value being held in at least one control register, from writing data to at least a portion of the system register in response to the register lockdown value being set.

The inventors of the present technique realised that, in some cases, it can be beneficial to prevent even the most trusted processes from modifying the device permissions information held in the at least one system register. Hence, in this example, a register lockdown value (also referred to herein as a “write ignore” value) is defined which, when set to a given value, indicates that any write requests targeting the system register - or to an identified portion of the system register - should be ignored. For example, the value may comprise a single bit that is set to a “1” to indicate that the writes to the system register should be ignored, or to a “0” to indicate that writes to the system register are permitted (subject to any other restrictions that might be in place - e.g. dependent on the current exception level). It will be appreciated, however, that the allocation of a “1” or a “0” to indicating that writes should or should not be ignored is arbitrary, and it could instead be a value of “0” that indicates that the writes should be ignored. Moreover, there could, in some particular examples, be a separate lockdown value (e.g. in a separate field of the control register) defined for each of the at least one system register. Also, while the control register holding the register lockdown value may, in some examples, be separate from the system register, in other examples the at least one control register may be the same as the system register. In such examples, the register lockdown value could, in fact, be a value held in a given field of system register itself.

Moreover, the register lockdown value described herein can also be used to protect other registers (e.g. not just the system register responsible for storing the device permissions information) in the apparatus. For example, the control register may hold register lockdown values corresponding to any specified register in the system.

In some examples, the apparatus is prevented from clearing the register lockdown value after it has been set, unless the requester device is reset.

Hence, the register lockdown value may be “sticky”. This improves security by making it more difficult to clear the register lockdown value, and hence re-enable the corresponding PAS for the requester device. Note that the apparatus is permitted to set the register lockdown value (e.g. the value is not “sticky” unless it is set); it will be appreciated the level of security associated with setting the register lockdown value need not necessarily be as high as the level of security associated with clearing the register lockdown value, since setting the value only increases the level of protection provided for the at least one system register.

In some examples, the apparatus comprises address translation circuitry responsive to the memory access request to translate the memory address specified by the memory access request into a physical address in the selected PAS associated with the memory access request.

In this example, the memory address is in an input address space that is different to the selected physical address space, and so address translation circuitry is provided to translate the memory address into a physical address in the selected PAS. As a particular example, the memory address could be a virtual address. Virtualising a physical address space into one or more input address spaces that are exposed to processes can improve security, by providing a further level of isolation between the processes.

In some examples, the address translation circuitry comprises the PAS selection circuitry.

Hence, in this example, the selection of a PAS is performed when translating the memory address into a physical address. In particular examples, this could involve associating a PAS identifier to the memory access request.

In some examples, the PAS selection circuitry is responsive to the memory access request to select, based on information defined in a page table entry for the memory address specified by the memory access request, the selected PAS to be associated with the memory access request.

In this example, the address translation circuitry translates the memory address into a physical address using address translation information defined in page tables (which may be stored in memory, with some of the information from the page tables optionally being cached in a translation lookaside buffer, for example). A page table entry corresponding to the memory address provides the translated PAS and, in this example, also provides information for use in selecting the PAS to be associated with the memory access request. Any such information defined in the page table entry is used in combination with an identifier of the current domain of operation to select the PAS.

In some examples, the address translation circuitry comprises at least one of: a memory management unit (MMU) associated with at least one processing element; and a system MMU (SMMU) associated with at least one external device.

An MMU is a particular example of address translation circuitry, and may also be responsible for enforcing at least some memory access permissions (e.g. access permissions defined in the page tables, which may or may not include the address-space permissions information). A particular example of an MMU is an SMMU, which provides the functions of an MMU for memory access requests received from one or more external devices. In this example of the present technique, the apparatus may comprise one or both of an MMU and an SMMU, each of which can provide the functions of the PAS selection circuitry described above.

In some examples, the requester device comprises a processing element or an external device.

Hence, the requester device can be a processing element (PE) such as a central processing unit (CPU), a graphics processing unit (GPU) or a neural processing unit (NPU), or it could be some external (e.g. peripheral or I/O) device. Note that the apparatus may be adapted to receive memory access requests from multiple requester devices (e.g. the requester device could be one of a plurality of requester devices), which could include both PEs and external devices. In some examples, the PAS checking circuitry is configured to identify the address-space permissions information in dependence on permissions information defined in a table entry of a table in memory, wherein the permissions information defines which of the plurality of PASs is an allowed PAS for the identified memory location.

For example, this may be a different table to the page tables discussed above, and may be referred to as a “Granule Protection Table” (GPT). The GPT may hold information (referred to as “Granule Protection Information” (GPI)) which indicates, for a given memory location, which PASs are permitted to access that memory location. Hence, the PAS checking circuitry in this example uses the GPI to determine whether to reject the memory access request (e.g. because the GPI does not identify the selected PAS as an allowed PAS for the memory location).

In some examples, the apparatus comprises at least one pre-PoPA memory system component provided upstream of a point of physical aliasing, PoPA, to treat aliasing physical addresses from different PASs which correspond to the same memory system resource as if the aliasing physical addresses correspond to different memory system resources.

The memory system may include a point of physical aliasing (PoPA), which is a point at which aliasing physical addresses from different physical address spaces which correspond to the same memory system resource are mapped to a single physical address uniquely identifying that memory system resource. The memory system may include at least one pre-PoPA memory system component which is provided upstream of the PoPA, which treats the aliasing physical addresses as if they correspond to different memory system resources.

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 the less secure physical address space to access that resource (or use the restrictive sharing feature described below to access the resource using one of the other physical address spaces). Another example of a pre-PoPA memory system component 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).

Regardless of the form of the pre-PoPA memory system component, it can be useful for such a pre-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.

In some examples, the apparatus comprises 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.

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.

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.

The techniques discussed above can be implemented in a hardware apparatus which has circuit hardware implementing the PAS selection circuitry and access control circuitry described above.

However, in another example the same techniques may be implemented in a computer program (e.g. an architecture simulator or model) which may be provided for controlling a host data processing apparatus to provide an instruction execution environment for execution of instructions from target code. The computer program may include PAS selection program logic for selecting a PAS to be associated with a memory access request - the PAS selection program logic thus emulates the functionality of the PAS selection circuitry. The computer program may also include PAS checking program logic and device permissions checking program logic to emulate the functionality of the PAS checking circuitry and the device permissions checking circuitry respectively. The PAS checking program logic and the device permissions checking program logic may together be considered to be part of access control program logic.

In particular examples, the program may also include register maintenance program logic which maintains a data structure (within the memory or architectural registers of the host apparatus) which represents (emulates) the architectural registers of the instruction set architecture being simulated by the program. The emulated registers may include the at least one system register and/or the at least one control register described in some examples above. Hence, such a simulator computer program may present, to target code executing on the simulator computer program, a similar instruction execution environment to that which would be provided by an actual hardware apparatus capable of directly executing the target instruction set, even though there may not be any actual hardware providing these features in the host computer which is executing the simulator program. This can be useful for executing code written for one instruction set architecture on a host platform which does not actually support that architecture. Also, the simulator can be useful during development of software for a new version of an instruction set architecture while software development is being performed in parallel with development of hardware devices supporting the new architecture. This can allow software to be developed and tested on the simulator so that software development can start before the hardware devices supporting the new architecture are available.

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.

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 be 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.

Additionally or alternatively, the computer-readable code may embody computer-readable representations of one or more netlists. The one or more netlists may be generated by applying one or more logic synthesis processes to an RTL representation. 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.

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.

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.

Particular embodiments will now be described with reference to the figures.

Controlling Access by Software to Physical Address Spaces

Figure 1 schematically illustrates an example of a data processing system 2 having at least one requester device 4 and at least one completer device 6. An interconnect 8 provides communication between the requester 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 1 , 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, external devices (also referred to as “peripheral” or “input/output” (I/O) devices), etc. The completer devices may include memory controllers responsible for controlling access to corresponding memory storage units, peripheral controllers for controlling access to a peripheral device, etc. Figure 1 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 1.

The requester device 4 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. The registers may also include further system registers 13, to be discussed in more detail below.

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. Hence, the address translation circuitry 16 in this example acts as PAS selection circuitry. Selection of the PAS will be discussed in more detail below; note that in some other examples the PAS selection circuitry may be separate from the address translation circuitry 16.

A PAS filter 20 acts as requester-side filtering 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 stored in a granule protection table structure stored within the memory system. The granule protection information may be cached within a granule protection information cache 22, similar to a 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 1 , 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.

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

While Figure 1 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. Alternatively, the PAS selection may be separate from both the address translation circuitry 16 and the PAS filter 20. 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.

Figure 2 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).

The processing circuitry 10 is operable at a number of different exception levels 80, in this example four exception levels labelled EL0, EL1 , EL2 and EL3, where in this example EL3 refers to the exception level with the greatest level of privilege while EL0 refers to the exception level with the least privilege. It will be appreciated that other architectures could choose the opposite numbering so that the exception level with the highest number could be considered to have the lowest privilege. In this example the least privileged exception level EL0 is for application-level code, the next most privileged exception level EL1 is used for operating system-level code, the next most privileged exception level EL2 is used for hypervisor-level code which manages switching between a number of virtualised operating systems, while the most privileged exception level EL3 is used for monitor code which manages switches between respective domains and allocation of physical addresses to physical address spaces, as described later.

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.

In addition to the different exception levels, the processing circuitry also supports a number of domains of operation 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.

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.

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.

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. 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.

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.

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.

Therefore, as shown in Figure 2, an additional 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 non-secure 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.

The realm domain 88 has its own physical address space allocated to it, similar to the secure domain 84, but the realm domain is orthogonal to the secure domain 84 in the sense that while the realm and secure domains 88, 84 can each access the non-secure PAS associated with the non-secure domain 86, the realm and secure domains 88, 84 cannot access each other’s physical address spaces. This means that code executing in the realm domain 88 and secure domains 84 have no dependencies on each other. Code in the realm domain only needs to trust the hardware, the RMM 46 and the code operating in the root domain 82 which manages switching between domains, which means attestation and certification becomes more feasible. Attestation enables a given piece of software to request verification that code installed on the device matches certain anticipated properties. This could be implemented by checking whether a hash of the program code installed on the device matches an expected value that is signed by a trusted party using a cryptographic protocol. The RMM 46 and monitor code 29 could for example be attested by checking whether a hash of this software matches an expected value signed by a trusted party, such as the silicon provider who manufactured the integrated circuit comprising the processing system 2 or an architecture provider who designed the processor architecture which supports the domain-based memory access control. This can allow user-provided code 42, 44 to verify whether the integrity of the domain-based architecture can be trusted prior to executing any secure or sensitive functions.

Hence, it can be seen that the code associated with realms 42, 44, which would previously have executed in the non-secure domain 86 as shown by the dotted lines showing the gap in the non-secure domain where these processes would previously have executed, can now be moved to the realm domain where they may have stronger security guarantees because their data and code is not accessible by other code operating in a non-secure domain 86. However, due to the fact that the realm domain 88 and secure domain 84 are orthogonal and so cannot see each other’s physical address spaces, this means that the providers of code in the realm domain do not need to trust the providers of code in the secure domain and vice versa. The code in the realm domain can simply trust the trusted firmware providing the monitor code 29 for the root domain 82 and the RMM 46, which may be provided by the silicon provider or the provider of the instruction set architecture supported by the processor, who may already inherently need to be trusted when the code is executing on their device, so that no further trust relationships with other operating system vendors, OEMs or cloud hosts are needed for the user to be able to be provided with a secure computing environment.

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.

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.

As shown in Figure 2, 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.

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

As shown in Figure 3, 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 selection of a particular physical address space (identified by a PAS identifier or “PAS TAG”) to be accessed in response to a given memory access request. The physical address and PAS identifier may be looked up in a granule protection table 56 which provides the granule protection information described earlier. In this example the PAS filter 20 is shown as a granular memory protection unit (GMPLI) 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.

The GMPLI 20 allows assigning memory to separate address spaces while providing a strong, hardware-based, isolation guarantee and providing spatial and temporal flexibility in the assignment methods of physical memory into these address spaces, as well as efficient sharing schemes. As described earlier, the execution units in the system are logically partitioned to virtual execution states (domains or “Worlds”) where there is one execution state (Root world) located at the highest exception level (EL3), referred to as the “Root World” that manages physical memory assignment to these worlds.

A single System physical address space is virtualized into multiple “Logical” or “Architectural” Physical Address Spaces (PAS) where each such PAS is an orthogonal address space with independent coherency attributes. A System Physical Address is mapped to a single “Logical” Physical Address Space by extending it with a PAS tag.

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.

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

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). 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.

Locating the GMPLI 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.

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.

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.

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). To provide a clean transition, an 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.

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.

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.

The GMPLI (20) includes the PAS checking circuitry and may also include the device permissions checking circuitry.

Figure 4 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 .

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.

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:

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.

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).

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.

The system may include more than one PoPA 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 de-aliased 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.

Figure 5 illustrates how the system physical address space 64 can be divided, using the granule protection table 56, into chunks allocated for access within a particular architectural physical address space 61 . The granule protection table (GPT) 56 defines which portions of the system physical address space 65 are allowed to be accessed from each architectural physical address space 61. For example the GPT 56 may comprise a number of entries each corresponding to a granule of physical addresses of a certain size (e.g. a 4K page) and may define an assigned PAS for that granule, which may be selected from among the non-secure, secure, realm and root domains. By design, if a particular granule or set of granules is assigned to the PAS associated with one of the domains, then it can only be accessed within the PAS associated with that domain 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.

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

Figure 6 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.

Figure 7 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).

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.

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.

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.

Hence, Figure 8 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.

At step 130 in Figure 8, 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 in Figure 6.

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.

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.

If the current domain is the realm domain, then at step 140 the output PAS is selected based on the PAS selection information 126 included in the block/page descriptor PTE from which the physical address was derived, and in this case the output PAS is selected as either the realm PAS or the non-secure PAS.

If at step 134 the current domain is determined to be the root domain, then at step 142 the output PAS is selected based on the PAS selection information 126 in the root block/page descriptor PTE 114 from which the physical address was derived. In this case the output PAS is selected as any of the physical address spaces associated with the root, realm, secure and non- secure domains.

Controlling Access by Hardware Devices to Physical Address Spaces

Figure 9 shows an example of access control circuitry 23. The access control circuitry 23 comprises PAS checking circuitry 20 (e.g. the PAS filter discussed above) and device permissions checking circuitry 92. The device permissions checking circuitry 92 is not explicitly shown in Figure 1 , but may be provided alongside the PAS filter 20 shown in Figure 1 (e.g. it may be at a logical position along the path taken by memory access requests between the address translation circuitry and the interconnect). Alternatively, the device permissions checking circuitry may be provided at a different location. The PAS checking circuitry 20 is responsible for controlling access to a given memory location based on granule protection information (GPI) defined for the given physical address. The GPI for the given physical address indicates which PASs are permitted to access the given physical address (e.g. as shown in Figure 5). As discussed above, this allows data stored in certain regions of memory to be protected from being accessed by software executing in certain other domains - for example, software executing in the “non-secure” domain cannot usually access data stored in a region of memory designated as “secure”, “realm” or “root”.

It can be useful, however, to also provide mechanisms for isolating regions of memory from particular hardware elements (e.g. requester devices), in addition to isolating regions from software processes. For example, there may be circumstances in which it can be useful to be able to isolate certain data or code from a particular processing element (PE), regardless of the current domain in which the PE is executing. Similarly, one may wish to make a certain region of memory visible to only a particular requester device, without it being accessible to any other devices. For example, this could allow multiple requester devices in a data processing system (e.g. a system-on-chip (SoC)) to effectively be partitioned into sub-sets of the PASs described above. An example of where this might be useful is where a dedicated secure processing unit is provided to perform high-security processing (e.g. this could be processing involved in managing biometrics or facial-recognition features) - allowing such processes to be isolated from other processing elements can be particularly useful, since it limits the number of other processes/devices that need to be trusted.

One might assume that such high-security processes could be protected by executing them within the secure domain or the realm domain, and storing any data or code associated with the processes in the corresponding secure or realm PAS. However, while this would provide some protection by isolating the high-security processes from processes associated with other PASs, other processes operating in the same PAS might still be able to access the code. Hence, providing an additional level of isolation can provide a greater level of security, which might be warranted in certain cases.

One might also consider executing such high-security processes within the root domain. However, it is preferable to minimise the number of processes which are permitted to operate within the root domain, in order to preserve the root domain for those processes involved in managing switching between the other domains of operation.

Therefore, the present technique isolates these high-security processes using device permissions checking circuitry 92. The device permissions checking circuitry 92 checks whether the requester device which issued the access request is permitted to access the selected PAS (the PAS selected by the PAS selection circuitry). The identity of the requester device may be determined based on a device identifier provided with the request (e.g. this might be the case if the requester is an external device - either as part of an SMMLI (discussed below) or as part of the interconnect 8). Alternatively, the device identifier may be determined based on the contents of a register or other storage structure (e.g. if the device permissions checking circuitry 92 is shared between multiple PEs - e.g. it could be on the interconnect 8), or may be implicit (e.g. if the device permissions checking circuitry 92 is provided within the requester device itself - e.g. as shown in Figure 1). The device permissions checking circuitry then rejects the request if it determines that requests from the identified device are not permitted to access the selected PAS.

Note that, while some of the figures illustrate the access control circuitry 20 as a single unit, it is possible for the device permissions checking circuitry 92 and the PAS checking circuitry 20 to be provided in different locations. For example, since the physical address is not needed for the check performed by the device permissions checking circuitry 92, this circuitry could be provided before the address translation circuitry 16 (assuming that some alternative PAS selection circuitry is provided before the device permissions checking circuitry 92). Alternatively, the address translation circuitry 16 may, in some examples, be able to obtain the PAS partway through the address translation (e.g. in an earlier stage of address translation, if multi-stage address translation is implemented). Hence, in some examples, the address translation circuitry 16 might pass the PAS to the device permissions checking circuitry 92 part-way through the address translation, and the device permissions checking circuitry 92 may perform its checks in parallel with the address translation circuitry 16 performing the final stages of the translation.

The device permissions checking circuitry 92 determines whether to reject an access request from a particular device in dependence on access permissions defined for the particular device and the selected PAS. An example of how these access permissions could be defined is shown in Figure 10.

Figure 10 shows an example of a system register 96, associated with a particular device and accessible to the device permissions checking circuitry, which defines the additional advicebased permissions described above. In some particular examples, this register 96 could be one of the registers 12 provided within a requester device 4, although the register could also be provided outside of the requester device. The register 96 is referred to in Figure 7 as a “GPC Control Register” or “GPCCR” and, in this example, its contents can only be modified by processes executing at the highest exception level (e.g. EL3 in this example).

The GPPCR comprises a number of fields, each corresponding to one of the PASs discussed earlier, and each of these fields holds information that can be used to indicate whether the associated device is permitted to access the corresponding PAS. In particular, the “SPASD” field 95 defines permissions information relating to the secure (S) PAS; the “NSPASD” field 97 defines permissions information relating to the less-secure (NS) PAS; and the “RLPASD” field 99 defines permissions information relating to the realm (RL) PAS. There is no field provided for the root PAS.

In a particular example, each of the fields (referred to as “PASD” fields) holds a “PAS Disable” (PASD) bit. This is a single bit (either a “1” or a “0”) which indicates whether the device is prohibited from accessing the corresponding PAS - the PASD bit therefore defines an additional set of permissions for the associated device, on top of the permissions enforced by the PAS checking circuitry 20 (e.g. those defined in the GPT). For example, a value of “0” may indicate that no additional permissions are defined, while a value of “1” may indicate that access to the corresponding PAS from the associated device are prohibited. For example, the values held in each of the PASD bits may be interpreted as follows:

RLPASD bit: if RLPASD = 0, allow access to realm PAS when selected as selected PAS and granule protection check based on GPT indicates that access to Realm PAS is permitted for the target physical address. if RLPASD = 1 , any access to the realm physical address space when granule protection checks are enabled results in a GPF (Granule Protection Fault).

SPASD bit: if SPASD = 0, allow access to secure PAS when selected as selected PAS and granule protection check based on GPT indicates that access to secure PAS is permitted for the target physical address if SPASD = 1 , any access to the secure physical address space when granule protection checks are enabled results in a GPF.

NSPASD bit: if NSPASD = 0, allow access to non-secure (less-secure) PAS when selected as selected PAS and granule protection check based on GPT indicates that access to non-secure PAS is permitted for the target physical address if NSPASD = 1, any access to the non-secure (less-secure) physical address space when granule protection checks are enabled results in a GPF.

This is also illustrated in the following table: be flipped, such that the value of 0b1 indicates that the permissions are dependent on the GPI.

A separate GPCCR 96 may be provided for each of a plurality of requester devices, although it should be noted that there need not necessarily be a GPCCR 96 provided for every requester device in the data processing system.

In another example, there may be more than one GPCCR 96 provided for a given requester device - for example, the permissions defined in each of the PASD fields 95, 97, 99 could instead be defined in a separate register.

Moreover, in some examples, the PASD permissions could be defined in a different data structure. In particular, an SMMLI may access a stream table entry to determine the device permissions information for an external device - Since an SMMLI may manage hundreds of devices, defining the permissions in a table in memory may be more feasible than using the GPCCR. It can be useful to provide a mechanism for preventing the permissions defined in any of the PASD fields from being modified. Preventing modification of the register 96 by programs executed in exception levels other than the highest exception level (EL3 in this case) provides some protection, but further protection can be provided by implementing a “write ignore” feature. For example, a “write ignore control register” 98 could be provided to identify one or more registers (which may include the GPCCR), and/or one or more specific parts of registers, to which write requests should, under some circumstances, be ignored.

The write ignore control register 98 shown in Figure 10 can only be edited by processes operating at the highest (most-privileged) exception level (EL3), and comprises a field 101 holding a register lockdown value indicating whether direct writes to the GPPCR should be ignored. For example, this field could store a single bit which, when set, indicates that write requests targeting the GPCCR 96 should be ignored. Further fields 103 are also provided, to indicate whether writes to other named registers should also be ignored. For example, the bits held in these fields could be interpreted as follows:

“Named Register” bit 101 , 103:

ObO : Direct writes to “Named Register” (e.g. for the GPCCR field 101 , the “Named Register” is the GPCCR) are not affected by this mechanism

0b1 : Direct writes to “Named Register” are ignored and the “Named Register” is not updated.

It will be appreciated that, again, the interpretations applied to values of ObO and 0b1 could also be flipped, such that the value of ObO indicates that writes should be ignored. Moreover, while the example above demonstrates how an entire “Named Register” can be locked down, in some examples the write ignore control register may identify specific bits/fields of a given register to which write requests should be ignored.

In a particular example, these “Named Register” bits (also referred to herein as “register lockdown values” or “write ignore values”) are “sticky”, such that any request to write a value of ObO (e.g. a request to clear the value) is ignored, while writes of 0b1 are not ignored. The “Named Register” bits 101 , 103 may then be reset to 0 on a reset of the data processing apparatus.

Note that, in an alternative implementation, the register lockdown value for the GPCCR could be provided as a field 105 of the GPCCR itself, rather than being a field of a separate register.

It can be useful to provide a mechanism for disabling the features described above (e.g. to disable the PASD and/or write-ignore features). For example, this may help to provide backwards compatibility. Hence, Figure 10 also shows a feature register 94, which comprises a PASD enable field 91 indicating whether the PASD features are enabled, and a FGWIE field 93 indicating whether the write-ignore features are enabled. For example, a value of 1 in either of these fields could indicate that the corresponding features are enabled, while a value of 0 may indicate that they are disabled (or vice versa). Figure 11 schematically illustrates another example arrangement of the data processing apparatus 2. The apparatus 2 includes a number of requester devices 4 which in this example include two central processing units (CPUs) 5 and an input/output unit 7 for controlling input or output of data from/to a peripheral device. At least some of the requester devices may have internal data or instruction caches 21 for caching instructions or data local to the device. Other masters such as the input/output interface 7 may be uncached masters. Coherency between data in the respective caches and accessed by the respective masters may be managed by a coherent interconnect 9 (which is an example of an interconnect 8 as shown in Figure 1) which tracks requests for accesses to data from a given address and controls snooping of data in other masters’ caches when required for maintaining coherency. It will be appreciated that in other embodiments such coherency operations could be managed in software, but a benefit of providing a hardware interconnect 9 for tracking such coherency is that the programmers of the software executed by the system do not need to consider coherency.

As shown in Figure 11 , some requesters may include a memory management unit (MMU) 17 which may include at least one address translation cache for caching address translation data used for translating addresses specified by the software into physical addresses referring to specific locations in memory 11. It is also possible to provide a system memory management unit (SMMU) 19 which is not provided within a given requester device, but is provided as an additional component between a particular requester 7 and the coherent interconnect 9, for allowing simpler master devices which are not designed with a built-in MMU to use address translation functionality. In other examples the SMMU 17 could be considered part of the interconnect 9. The MMUs 17 and SMMU 19 are examples of address translation circuitry and, in some examples, may also provide the functionality of PAS selection circuitry.

Figure 12 illustrates another example of a data processing system 2 in which the present technique is implemented. In this example, a memory - specifically dynamic random access memory (DRAM) 146 - is logically partitioned into multiple PASs: a root PAS, a realm (RL) PAS, a secure (S) PAS and a less-secure (NS) PAS. Multiple requester devices are provided, including multiple PEs 5 and multiple external devices 7. In this example, the PEs 5 are each permitted to execute software in either the secure domain 84, the less secure domain 86 or the root domain 82 (the root domain being reserved for certain processes, as shown in Figure 2 for example). Meanwhile, the external devices 7 are each permitted to execute software in either the less secure domain 86 or the realm domain 88. Hence, in this particular example, the realm domain 88 is used exclusively by the external devices 7, and the secure domain 84 is used exclusively by the PEs 5.

As in the examples described above, the root PAS 82 is isolated from all other PASs, while the realm and secure PASs 88, 84 are isolated from each other and from the less-secure PAS 86. The isolation between the different PASs is enforced by a system realm controller (SRC) 144 which owns (controls) the GPT and operates in the root domain 82. The SRC 144 may also, optionally, be responsible for programming realm SMMLI contexts.

A hardware enforced security (HES) mechanism is also implemented in Figure 9, for example to protect so-called “root of trust” (RoT) services, which may include the processes performed by the SRC 144.

Figure 13 is a flow diagram illustrating an example method according to the present technique. In this example method, a memory access request specifying a memory address (e.g. this could be a virtual address) is received, in step 106, from a device labelled “device X”. In step 108, a PAS is selected to be associated with the memory address - this selection is made in dependence on the current domain of execution. In step 148, it is determined whether device X is permitted to access the selected PAS. If it is determined that the device is prohibited from accessing the selected PAS, the request is rejected (step 156). On the other hand, if it is not determined that the device is prohibited from accessing the selected PAS, the GPI for the specified memory address is obtained in step 150. In step 152 it is determined whether the selected PAS is permitted to access the PAS assigned, according to the GPI, to the memory address. If access is not permitted, the access is rejected in step 156. On the other hand, if access is not prohibited by the GPI, the access is allowed (step 154) to progress.

Simulator Implementation

Figure 14 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. 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.

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.

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 as in the example of Figure 1 , 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, the current exception level indication 15 and the other system registers 13 described earlier.

The simulation code includes address translation program logic 414 and filtering program logic 416 which emulate the functionality of the address translation circuitry 16 and PAS filter 20 respectively, with reference to the same page table structures and GPT 56 as described earlier. 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 filtering program logic 416 performs a lookup of granule protection information to determine whether to allow memory accesses triggered by the target code to proceed, in the same way as the PAS filter described above.

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.

Further, the words “comprising at least one of...” in the present application are used to mean that any one of the following options or any combination of the following options is included. For example, “at least one of: A; B and C” is intended to mean A or B or C or any combination of A, B and C (e.g. A and B or A and C or B and C).

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

1. An apparatus comprising:

PAS selection circuitry responsive to a memory access request issued by a requester device, the memory access request specifying a memory address identifying a memory location, to select, based on a current domain of operation of the requester device, one of a plurality of physical address spaces, PASs, to be associated with the memory access request; and access control circuitry responsive to the memory access request to determine, based on the selected PAS, whether to reject the memory access request, wherein the access control circuitry comprises:

2. The apparatus of claim 1 , wherein the device permissions checking circuitry is permitted, in response to a first memory access request issued by the requester device and a second memory access request issued by a further requester device, wherein the first memory access request and the second memory access request are associated with the same selected PAS and identify the same memory location, to reject the first memory access request without rejecting the second memory access request, in dependence on the device permissions information.

3. The apparatus of claim 1 or claim 2, wherein the device permissions checking circuitry is configured to identify the device permissions information in dependence on the contents of at one least data structure accessible to the device permissions checking circuitry.

4. The apparatus of claim 3, wherein the at least one data structure is configured to hold, for a given PAS, a value indicating whether the requester device is prohibited from accessing the given PAS.

5. The apparatus of claim 3 or claim 4, wherein the apparatus is prohibited from writing data to the at least one data structure in response to instructions executed at an exception level less privileged than a threshold exception level.

6. The apparatus of claim 5, wherein the threshold exception level comprises a most privileged exception level.

7. The apparatus of any of claims 3 to 6, wherein the at least one data structure comprises a system register; and the apparatus is prohibited, in response to a register lockdown value being held in at least one control register, from writing data to at least a portion of the system register in response to the register lockdown value being set.

8. The apparatus of claim 7, wherein the apparatus is prevented from clearing the register lockdown value after it has been set, unless the requester device is reset.

9. The apparatus of any preceding claim, comprising address translation circuitry responsive to the memory access request to translate the memory address specified by the memory access request into a physical address in the selected PAS associated with the memory access request.

10. The apparatus of claim 9, wherein the address translation circuitry comprises the PAS selection circuitry.

11. The apparatus of claim 10, wherein the PAS selection circuitry is responsive to the memory access request to select, based on information defined in a page table entry for the memory address specified by the memory access request, the selected PAS to be associated with the memory access request.

12. The apparatus of any of claims 9 to 11 , wherein: the address translation circuitry comprises at least one of: a memory management unit, MMU, associated with at least one processing element; and a system MMU, SMMU, associated with at least one external device.

13. The apparatus of any preceding claim, wherein the requester device comprises a processing element or an external device.

14. The apparatus of any preceding claim, wherein the PAS checking circuitry is configured to identify the address-space permissions information in dependence on permissions information defined in a table entry of a table in memory, wherein the permissions information defines which of the plurality of PASs is an allowed PAS for the identified memory location.

15. The apparatus of any preceding claim, comprising: at least one pre-PoPA memory system component provided upstream of a point of physical aliasing, PoPA, to treat aliasing physical addresses from different PASs which correspond to the same memory system resource as if the aliasing physical addresses correspond to different memory system resources.

16. The apparatus of claim 15, comprising: 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.

17. A method comprising: in response to a memory access request issued by a requester device, the memory access request specifying a memory address identifying a memory location: selecting, based on a current domain of operation of the requester device, one of a plurality of physical address spaces, PASs, to be associated with the memory access request; determining, based on the selected PAS, whether to reject the memory access request, wherein the determining comprises: rejecting the memory access request in response to address-space permissions information, defined for the identified memory location, indicating that memory access requests associated with the selected PAS are prohibited from accessing the identified memory location; and rejecting the memory access request in response to device permissions information, defined for the requester device, indicating that memory access requests issued by the requester device are prohibited from accessing the selected PAS.

18. 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: PAS selection program logic responsive to a memory access request issued by a requester, the memory access request specifying a memory address identifying a memory location, to select, based on a current domain of operation of the requester, one of a plurality of physical address spaces, PASs, to be associated with the memory access request; and access control program logic responsive to the memory access request to determine, based on the selected PAS, whether to reject the memory access request, wherein the access control program logic comprises:

PAS checking program logic to reject the memory access request in response to addressspace permissions information, defined for the identified memory location, indicating that memory access requests associated with the selected PAS are prohibited from accessing the identified memory location; and device permissions checking program logic to reject the memory access request in response to device permissions information, defined for the requester, indicating that memory access requests issued by the requester are prohibited from accessing the selected PAS.

19. A computer-readable storage medium to store the computer program of claim 18.

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