TW202435076A - Determining whether to reject a memory access request issued by a requester device - Google Patents

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

Determines whether to deny a memory access request issued by the requester device

This technology is related to the field of data processing.

A data processing system may have address translation circuitry to translate an address identified by a memory access request (which may be a virtual address, for example) into a physical address corresponding to a location to be accessed in the memory system.

In view of the first example of the present technology, a device is provided, comprising: A PAS selection circuit system, which responds to a memory access request issued by a requester device and selects one of a plurality of physical address spaces (PAS) to be associated with the memory access request based on a current operating domain of the requester device, the memory access request specifying a memory address identifying a memory location; and An access control circuit system, which responds to the memory access request and determines whether to deny the memory access request based on the selected PAS, wherein the access control circuit system comprises: A PAS checking circuit system, which responds to the address space permission information defined for the identified memory location indicating that the memory access request associated with the selected PAS is prohibited from accessing the identified memory location and denies the memory access request; and A device permission checking circuit system, which responds to the device permission information defined for the requester device indicating that the memory access request issued by the requester device is prohibited from accessing the selected PAS and denies the memory access request.

In view of a second example of the present technology, a method is provided, comprising: In response to a memory access request issued by a requestor device, the memory access request specifying a memory address identifying a memory location: Selecting one of a plurality of physical address spaces (PAS) to be associated with the memory access request based on a current operating domain of the requestor device; Determining whether to deny the memory access request based on the selected PAS, wherein the determination comprises: In response to address space permission information defined for the identified memory location indicating that the memory access request associated with the selected PAS is prohibited from accessing the identified memory location, denying the memory access request; and In response to device permission information defined for the requester device indicating that a memory access request issued by the requester device is prohibited from accessing the selected PAS, the memory access request is denied.

In view of the third example of the present technology, a computer program including instructions is provided, which, when executed by a host data processing device, controls the host data processing device to provide an instruction execution environment for executing a target program code, the computer program including: PAS selection program logic, which responds to a memory access request issued by a requester and selects one of a plurality of physical address spaces (PAS) to be associated with the memory access request based on a current operating domain of the requester, the memory access request specifies a memory address identifying a memory location; and Access control program logic, which responds to the memory access request and determines whether to deny the memory access request based on the selected PAS, wherein the access control program logic includes: PAS check program logic, which responds to the address space permission information defined for the identified memory location indicating that the memory access request associated with the selected PAS is prohibited from accessing the identified memory location and denies the memory access request; and Device permission checker logic that denies a memory access request issued by the requester in response to device permission information defined by the requester indicating that access to the selected PAS is prohibited.

In view of the third embodiment of the present technology, a computer-readable storage medium is provided for storing the above-mentioned computer program. The computer-readable storage medium can be non-temporary and temporary.

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

A data processing system may support the use of virtual memory, wherein address translation circuitry is provided to translate a virtual address specified by a memory access request into a physical address associated with a location in the memory system to be accessed. The mapping between virtual addresses and physical addresses may be defined in one or more page table structures. Page table entries within the page table structures may also define some access permission information that controls whether a given software program executing on the processing circuitry is allowed to access a particular virtual address.

In some processing systems, all virtual addresses may be mapped by address translation circuitry to a single physical address space used by the memory system to identify locations in memory to be accessed. In such a system, control over whether a particular software program can access a particular address is based solely on page table structures that provide virtual-to-physical address translation mappings. However, such page table structures may generally be defined by the operating system and/or hypervisor. If the operating system or hypervisor is compromised, this may result in security vulnerabilities that may make sensitive information accessible to an attacker.

Thus, for some systems that have a requirement that certain programs be isolated from other programs for secure execution, the system may support operation in several domains and may support several different physical address spaces, wherein memory access requests whose virtual addresses are translated into physical addresses in different physical address spaces are treated by at least some components of the memory system as if they were accessing completely separate addresses in memory, even though the physical addresses in the respective physical address spaces actually correspond to the same location in memory. By isolating accesses from different operating domains of the processing circuitry into separate distinct physical address spaces as seen by some memory system components, this provides stronger security that is independent of page table permission information set by the operating system or hypervisor.

It should be noted that in the present technology, it is not necessary to provide virtual to physical address translation. However, it should be noted that in the case of providing such virtual to physical address translation, the multiple different physical address spaces are different from the multiple virtual address spaces that can be provided.

According to the present technology, an apparatus is provided in which PAS selection circuitry selects one of a plurality of physical address spaces (PAS) to be associated with a memory access request issued by a requestor device based on a current operating domain of the requestor device, the memory access request specifying a memory address identifying a memory location.

For example, a memory address specified by a memory access request may 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 translating a virtual address into a physical address), and thus the memory location may be identified by translating the memory address into a physical address. Alternatively, the memory address may be a physical address in a system physical address space (e.g., a device may provide a single "system" physical address space, in which each memory location is mapped to a single memory system resource - this system PAS is then mapped onto the plurality of PASs described above).

Apparatus of the present technology supports the use of multiple PASs - for example, a requestor device may operate in any of a number of operating domains (e.g., executing instructions and/or performing data processing), and a separate PAS may be defined for each of the operating domains. Memory access requests issued by a requestor device (which may be an internal processing element forming part of the apparatus, or an external/peripheral device) may therefore be assigned to a particular PAS depending on the current operating domain of the requestor device (e.g., the operating domain of the requestor device at the time the memory access request was issued). 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 may provide isolation between memory accesses from different operating domains.

The apparatus of the present technology also includes access control circuitry that determines, in response to the memory access request, whether to deny the memory access request based on the selected PAS. The access control circuitry may perform any number of checks to determine whether the memory access request should be denied (e.g., as opposed to being passed to another component downstream of the access control circuitry (e.g., logically closer to the memory system)). In the present technology, 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 should be understood that further checks may also be performed, and thus a memory access request that passes both of these checks may still be rejected by the access control circuitry if it fails the other check.

In the present technology, the access control circuit system includes: a PAS check circuit system, which is used to perform a check based on a selected PAS and an identified memory location; and a device permission check circuit system, which is used to perform a check based on the selected PAS and a requester device. Specifically, the PAS check circuit system responds to the address space permission information defined for the identified memory location indicating that a memory access request associated with the selected PAS is prohibited from accessing the identified memory location and rejects the memory access request. Therefore, the PAS check circuit system (which may also be referred to as a "PAS filter") enforces the address space permission information that determines which PASs are allowed to access which memory resources. It should be noted that in some instances, the address space permission information may include granule protection information (GPI).

The device permission checking circuitry denies a memory access request issued by the requestor device in response to device permission information defined for the requestor device indicating that access to the selected PAS is prohibited. Thus, the device permission checking circuitry is responsible for enforcing the device permission information that determines which devices are allowed to access which PAS. Thus, the checks performed by the device permission checking circuitry may depend on the identity of the device and on the selected PAS. The identity of the device may be determined in any of a number of ways, which may depend on the type of requestor device and/or on how the device permission checking circuitry is configured. For example, if the device permission checking circuitry is associated with a particular requestor device (e.g., if the requestor device is separated from the memory system by an interconnect, the device permission checking circuitry may be provided on the requestor side of the interconnect (e.g., memory access requests may be filtered by the device permission checking circuitry before being passed to the interconnect)), the identity of the requestor device may be implicit. On the other hand, if the device permission checking circuitry is associated with multiple requestor devices, the identity of the requestor device may be determined based on a device identifier associated with the memory access request (e.g., if the requestor device is an external device) or based on requestor identification information maintained in a register or other storage circuitry.

Thus, the device permission check circuitry provides an additional layer of security over and above that provided by the PAS check circuitry and makes it possible to isolate areas of memory from specific devices. This may be particularly useful, for example, in systems that include secure processing elements or secure devices responsible for executing specific high-security programs—for example, this may include facial unlocking or biometric authentication programs. The device permission check circuitry of the present technology improves the security of the device by making it possible to isolate data associated with such programs from other devices, even if such devices are capable of generating requests with the same selected PAS.

As suggested above, the PAS check circuitry and the device permission check circuitry do not necessarily need to be provided in the same physical location. Furthermore, the checks performed by the PAS check circuitry and the device permission check circuitry may be performed sequentially (optionally with some time between the two checks during which other operations (such as other checks) may be performed), or they may be performed in parallel. Additionally, if a memory access request is denied due to one check, the other check may not be performed (e.g., a memory access request may be denied in response to failing any of the checks, which may mean that the other check is not performed).

In some examples, in response to a first memory access request issued by the requestor device and a second memory access request issued by another requestor device, the device permission checking circuitry is allowed to deny the first memory access request without denying the second memory access request depending on the device permission information, 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.

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 permission checking circuitry. In fact—as in this example—even if two memory access requests both identify the same memory location and are associated with the same PAS, it is possible for the device permission checking circuitry to deny one of the memory access requests without denying the other memory access request (e.g., even if both pass the check performed by the PAS checking circuitry). For example, a first and second memory access request may have been issued (respectively) by first and second requestor devices (which are different from each other), with the first requestor device being allowed to access a selected PAS while the second requestor device being prohibited from accessing the selected PAS.

In some examples, the device permission check circuitry is configured to identify the device permission information based on the contents of at least one data structure accessible to the device permission check circuitry.

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

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

In this way, a single value maintained in at least one data structure may be set to prevent a requestor device from being able to access a given PAS; from the requestor device's perspective, the value thus effectively disables the PAS - hence, the value may be referred to as a "PAS disable" (PASD) value. For example, at least one data structure may maintain a value corresponding to each available PAS - e.g., there may be a separate field or entry provided for each PAS. However, it should be noted that there may not necessarily be a value maintained for each available PAS - e.g., in a particular instance where the available PASs include a root PAS (e.g., a code-accessible PAS responsible for managing switching between different operating domains), there may not be any value maintained in the at least one data structure corresponding to the root PAS. This may be because the root PAS is generally already accessible only by the most trusted programs, so the additional protection provided by the PASD value may not be necessary.

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

This ensures that the device permission information recorded in the at least one data structure cannot be modified by untrusted software (e.g., software operating at an exception level with lower privileges than the critical exception level). This further improves the security of the system.

In some examples, the threshold exception level includes a maximum privilege exception level.

Thus, in this example, only the most trusted programs (e.g., those allowed to operate at the highest privilege exception level) are allowed to modify the device permission information maintained in the at least one data structure. This even further improves the security of the system.

In some examples, the at least one data structure may include at least one system register, but it may also (or alternatively) include another type of data structure. As a specific example, if the requestor device is an external device and the device permission checking circuitry is located in a system memory management unit (SMMU), the device permission information state of each device may come from a stream table entry (STE). For example, each data flow through the SMMU may be referred to as a stream, and a single stream may be shared by more than one device and/or a single device may have multiple streams. Therefore, the device permission information may be expressed in the STE.

Additionally, the stream table may not be the only table that describes the device configuration or access permissions (including the device permission information described herein) of each device. Other data structures—such as the Device Permission Table (DPT)—may also hold information that should be the same as the SMMU, which can be used by devices in different configurations. Therefore, these other data structures may also serve as the at least one data structure.

In some examples, the at least one data structure includes a system register, and in response to a register lock value being maintained in at least one control register, the device is prohibited from writing data to at least a portion of the system register in response to the register lock value being set.

The inventors of the present technology understand that in some cases, it may be beneficial to prevent even the most trusted programs from modifying the device permission information maintained in the at least one system register. Therefore, in this example, a register lock value (also referred to herein as a "write ignore" value) is defined as when set to a given value, indicating that any write request to a designated system register - or to an identified portion of a system register - should be ignored. For example, the value may include a single bit that is set to "1" to indicate that writes to the system register should be ignored, or set to "0" to indicate that writes to the system register are allowed (subject to any other restrictions that may be appropriate - for example, depending on the current exception level). However, it should be understood that the assignment of "1" or "0" to indicate that a write should or should not be ignored is arbitrary, and a value of "0" may alternatively indicate that a write should be ignored. Additionally, in some specific examples, there may be a separate lock value defined for each of the at least one system register (e.g., in a separate field of the control register). Furthermore, while in some examples the control register that holds the register lock value may 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 lock value may actually be the value held in a given field of the system register itself.

In addition, the register lock values described herein may also be used to protect other registers in the device (e.g., not just system registers responsible for storing device permission information). For example, a control register may hold a register lock value corresponding to any specified register in the system.

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

Thus, the register lock value may be "sticky." This improves security by making it more difficult to clear the register lock value (and thereby re-enable the corresponding PAS of the requestor device). It should be noted that a device is permitted to set the register lock value (e.g., unless the value is set, it is not "sticky"); it should be understood that the security level associated with setting the register lock value does not necessarily need to be as high as the security level associated with clearing the register lock value, as setting the value merely increases the level of protection provided to the at least one system register.

In some examples, the device includes address translation circuitry that, in response to the memory access request, translates 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 from the selected physical address space, and therefore address translation circuitry is provided to translate the memory address into a physical address in the selected PAS. As a specific example, the memory address may be a virtual address. Virtualizing the physical address space into one or more input address spaces exposed to the program may improve security by providing a further level of isolation between programs.

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

Thus, in this example, the selection of a PAS is performed when translating a memory address into a physical address. In a specific example, this may involve associating a PAS identifier with a memory access request.

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

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

In some embodiments, the address translation circuitry includes 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 specific instance of address translation circuitry and may also be responsible for enforcing at least some memory access permissions (e.g., access permissions defined in page tables that may or may not include address space permission information). A specific instance of an MMU is an SMMU, which provides the functionality of the MMU for memory access requests received from one or more external devices. In this example of the present technology, an apparatus may include one or both of an MMU and an SMMU, each of which may provide the functionality of the PAS selection circuitry described above.

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

Thus, the requestor device may 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 may be some external (e.g., peripheral or I/O) device. It should be noted that the apparatus may be adapted to receive memory access requests from multiple requestor devices (e.g., the requestor device may be one of a plurality of requestor devices), which may include both PEs and external devices.

In some examples, the PAS checking circuitry is configured to identify the address space permission information based on permission information in an entry in a table defined in memory, wherein the permission 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 than the page table discussed above, and may be referred to as a "Granule Protection Table" (GPT). The GPT may maintain information indicating, for a given memory location, which PASs are allowed to access that memory location (referred to as "granule protection information" (GPI)). Thus, in this example, the PAS checking circuitry uses the GPI to determine whether to deny a memory access request (e.g., because the GPI does not identify the selected PAS as an allowed PAS for that memory location).

In some examples, the apparatus includes at least one pre-PoPA memory system component provided upstream of a physical point of alias (PoPA) to treat aliased physical addresses from different PASs corresponding to the same memory system resources as if the aliased physical addresses correspond to different memory system resources.

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

For example, at least one pre-PoPA memory system component may include a cache or translation lookaside buffer that can cache data, code, or address translation information for aliased physical addresses in separate entries, so that if the same memory system resource is requested to be accessed from different physical address spaces, the access will result in the allocation of separate cache or TLB entries. Furthermore, the pre-PoPA memory system component may include consistency control circuitry, such as a consistency interconnect, a snoop filter, or other mechanism for maintaining consistency between cached information at separate masters. The consistency control circuitry can assign separate consistency states to separate aliased physical addresses in different physical address spaces. Therefore, for the purpose of maintaining consistency, alias physical addresses are treated as separate addresses even though they actually correspond to the same underlying memory system resource. Although on the surface, separately tracking the consistency of alias physical addresses may appear to cause consistency loss problems, in reality this is because if programs operating in different domains do intend to share access to a particular memory system resource, they can use the less secure physical address space to access that resource (or use the restricted sharing feature described below to access the resource using one of the other physical address spaces) without being a problem. Another example of a pre-PoPA memory system component may be a memory protection engine, which is provided for protecting data stored to off-chip memory from confidentiality loss and/or tampering. For example, such a memory protection engine may separately encrypt data associated with particular memory system resources using different encryption keys depending on which physical address space the resource is accessed from, effectively treating the aliased physical addresses as if they corresponded to different memory system resources (e.g., an encryption scheme may be used that makes encryption address-dependent, and the physical address space identifier may be treated as part of the address for this purpose).

Regardless of the form of the pre-PoPA memory system component, it may be useful for such a pre-PoPA memory system component to treat aliased physical addresses as if they correspond to different memory system resources, since this provides hardware-enforced isolation between accesses issued to different physical address spaces so that information associated with one domain cannot be leaked to another domain through characteristics such as cache timing side channels or side channels involving changes in coherence triggered by coherence control circuitry.

In some examples, the apparatus includes a PoPA memory system component configured to de-alias the plurality of aliased physical addresses to obtain a de-aliased physical address to be provided to at least one downstream memory system component.

In some implementations, it may be feasible for aliased physical addresses in different physical address spaces to be represented using different numerical physical address values for respectively different physical address spaces. This approach may require a mapping table to determine which of the different physical address values correspond to the same memory system resources at the PoPA. However, this burden of maintaining a mapping table may be considered unnecessary, and therefore in some implementations, it may be simpler if the aliased physical addresses include physical addresses represented using the same numerical physical address value in each of the different physical address spaces. If this approach is adopted, then at the physical alias point, it may be simple enough to discard the physical address space identifier that identifies which physical address space is accessed using a memory access, and then provide the remaining physical address bits downstream as a de-aliased physical address.

Thus, 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 aliased physical addresses to obtain a de-aliased physical address to be provided to at least one downstream memory system component. As described above, the PoPA memory system component may be a device that accesses a mapping table to locate a de-aliased address corresponding to an aliased address in a particular address space. However, the PoPA component may 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 the corresponding memory system resource, regardless of which physical address space it is provided from. Alternatively, in some cases, a PoPA memory system component may still provide physical address space labels to at least one downstream memory system component (e.g., as discussed further below, for the purpose of enabling completer-side filtering), but the PoPA may mark a point within the memory system beyond which its downstream memory system components no longer treat the aliased physical addresses as different memory system resources, but instead treat each of the aliased physical addresses as mapping the same memory system resource. For example, if a memory controller or hardware memory storage device downstream of PoPA receives a physical address tag and the physical address of a given memory access request, then if the physical address corresponds to the same physical address as a previously seen transaction, any risk checks or performance improvements that are performed for separate transactions accessing the same physical address (such as merging accesses to the same address) may be applied, even if the separate transactions specify different physical address space tags. In contrast, for a memory system component upstream of PoPA, if such transactions specify the same physical address in different physical address spaces, such risk checks or performance improvement steps that are taken for transactions accessing the same physical address may not be invoked.

The techniques discussed above may be implemented in a hardware device having circuit hardware that implements the PAS selection circuitry and access control circuitry described above.

However, in another example, the same technology may be implemented in a computer program (e.g., an architecture simulator or model) that may provide an instruction execution environment for controlling a host data processing device to provide for the execution of instructions from target code. The computer program may include PAS selector logic for selecting a PAS to be associated with a memory access request—the PAS selector logic thus emulating the functionality of a PAS selection circuit system. The computer program may also include PAS checker logic and device permission checker logic to respectively emulate the functionality of a PAS checker circuit system and a device permission checker circuit system. The PAS checker logic and the device permission checker logic may be considered together as part of the access control program logic.

In certain examples, the program may also include register-maintained program logic that maintains a data structure (in a memory or architecture register of a host device) of an architecture register representing (simulating) an instruction set architecture emulated 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. Thus, such an emulator computer program can present to target code executed on the emulator computer program an instruction execution environment similar to that which would be provided by actual hardware devices capable of directly executing the target instruction set, even though there may not be any actual hardware providing such features on the host computer on which the emulator program is being executed. This can be useful for executing code written for an instruction set architecture on a host platform that does not actually support that architecture. Furthermore, an emulator can be useful during the development of software for a new version of an instruction set architecture, while the software development is performed in parallel with the development of hardware devices supporting the new architecture. This allows software to be developed and tested on the emulator, allowing software development to begin before hardware devices supporting the new architecture are available.

The concepts described herein may be embodied in computer readable code for use in fabricating devices embodying the described concepts. For example, the computer readable code may be used in one or more stages of a semiconductor design and fabrication process, including an electronic design automation (EDA) stage, to fabricate an integrated circuit comprising a device implementing the concepts. The computer readable code may additionally or alternatively facilitate the definition, modeling, simulation, verification and/or testing of devices implementing the concepts described herein.

For example, computer-readable code for making devices that implement the concepts described herein may define a code implementation of a hardware description language (HDL) that represents the concepts. For example, the code may define a register-transfer-level (RTL) abstract concept that is used to define one or more logic circuits of a device that implements the concept. The code may define an HDL that represents one or more logic circuits that implement the device in Verilog, System Verilog, Chisel, or VHDL (Very High Speed Integrated Circuit Hardware Description Language), as well as intermediate representations such as FIRRTL. The computer-readable code may provide definitions of the implementation concepts using a system-level modeling language such as System C and System Verilog or other behavioral representations of the concepts that can be interpreted by a computer to facilitate simulation, functional and/or formal verification and testing of the concepts.

Additionally or alternatively, the computer readable code may implement a computer readable representation of one or more wiring lookup tables. The one or more wiring lookup tables may be generated by applying one or more logic synthesis programs to the RTL representation. Alternatively or additionally, the one or more logic synthesis programs may generate a bit stream from the computer readable code that is loaded into a field programmable gate array (FPGA) to configure the FPGA to implement the described concepts. The FPGA may be deployed for the purpose of validating and testing concepts prior to fabrication in an integrated circuit, or the FPGA may be deployed directly in a product.

The computer readable code may include a mixture of code representations used to manufacture a device, such as a mixture of one or more of an RTL representation, a wiring lookup table representation, or another computer readable definition used in a semiconductor design and manufacturing process to manufacture a device that implements the present invention. Alternatively or additionally, a concept may define a combination of a computer readable definition used in a semiconductor design and manufacturing process to manufacture a device and computer readable code definition instructions executed by the defined device once manufactured.

Such computer readable code may be placed in any known transient computer readable medium (e.g., wired or wireless transmission code over a network) or non-transient computer readable medium (e.g., semiconductor, disk, or optical disk). An integrated circuit fabricated using computer readable code may include components such as a central processing unit, a graphics processing unit, a neural processing unit, a digital signal processor, or one or more of the other components that implement the concept alone or together.

A specific embodiment will now be described with reference to the drawings. Access to physical address space controlled by software

FIG. 1 schematically illustrates an example of a data processing system 2 having at least one requestor device 4 and at least one completer device 6. An interconnect 8 provides communication between the requestor device 4 and the completer device 6. The requestor device is capable of issuing memory access requests requesting memory access to a specific addressable memory system location. The completer device 6 is a device that has the responsibility of servicing memory access requests directed to it. Although not shown in FIG. 1 , some devices may be capable of acting as both a requestor device and as a completer device. Requester device 4 may, for example, include a processing element such as a central processing unit (CPU) or a graphics processing unit (GPU) or other host devices such as a bus host device, a network interface controller, a display controller, an external device (also referred to as a "peripheral" or "input/output" (I/O) device) and the like. A completer device may include a memory controller responsible for controlling access to a corresponding memory storage unit, a peripheral controller for controlling access to a peripheral device, and the like. FIG. 1 shows an example configuration of one of requester devices 4 in more detail, but it should be understood that other requester devices 4 may have similar configurations. Alternatively, other requester devices may have a different configuration than the requester device 4 shown on the left side of FIG. 1 .

The requester device 4 has a processing circuit system 10 for performing data processing in response to an instruction with reference to data stored in a register 12. The register 12 may include general registers for storing operands and results of processed instructions, and control registers for storing control data for configuring how processing is performed by the processing circuit system. For example, the control data may include a current domain indication 14 for selecting which operating domain is the current domain, and a current exception level indication 15 indicating which exception level is the current exception level at which the processing circuit system 10 is operating. The registers may also further include a system register 13 to be discussed in more detail below.

Processing circuitry 10 may be capable of issuing a memory access request specifying a virtual address (VA) identifying an addressable location to be accessed and a domain identifier (domain ID or "security state") identifying a 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 multiple levels of address translation based on page table data defined in a page table structure stored in the memory system. Translation lookaside buffer (TLB) 18 acts as a lookup cache for caching some page table information for faster access than if the page table information had to be fetched from memory each time an address translation is needed. In this example, in addition to generating a physical address, address translation circuitry 16 also selects one of several physical address spaces associated with the physical address and outputs a physical address space (PAS) identifier that identifies the selected physical address space. Thus, address translation circuitry 16 in this example acts as PAS selection circuitry. The selection of a PAS will be discussed in more detail below; it should be noted that in some other examples, the PAS selection circuitry may be separate from the address translation circuitry 16.

The PAS filter 20 acts as a requester-side filtering circuit system for checking whether the physical address is allowed to access the specified physical address space identified by the PAS identifier based on the translated physical address and the PAS identifier. This search is based on the grain protection information stored in the grain protection table structure stored in the memory system. The grain protection information can be cached in the grain protection information cache 22, similar to caching the page table data in the TLB 18. 1 is shown as a separate structure from the TLB 18, in other examples, these types of lookup caches may be combined into a single lookup cache structure so that a single lookup of the entries of the combined structure provides both page table information and granule protection information. The granule protection information defines information that restricts the physical address space from which a given physical address can be accessed, and based on this lookup, the PAS filter 20 determines whether to allow a memory access request to proceed to be issued to one or more caches 24 and/or the interconnect 8. If the PAS-specified physical address of the memory access request is not allowed, the PAS filter 20 blocks the transaction and may signal a fault.

Although FIG. 1 shows an example of a system having multiple requester devices 4, the features shown for one requester device on the left side of FIG. 1 may also be included in a system having only one requester device (e.g., a single core processor).

Although FIG. 1 shows an example in which the selection of a PAS for a given request is performed by the address translation circuit system 16, in other examples, information used to determine which PAS to select may be output by the address translation circuit system 16 along with the PA to the PAS filter 20, and the PAS filter 20 may select the PAS and check whether the PA is allowed to access within the selected PAS. Alternatively, the PAS selection may be separate from both the address translation circuit system 16 and the PAS filter 20.

The provision of PAS filter 20 helps support systems that can operate in several operating domains, each associated with its own isolated physical address space, where to at least part of the memory system (e.g., to some cache or consistency enforcement mechanisms such as monitoring filters), the separate physical address spaces are treated as if they refer to completely separate sets of addresses that identify separate memory system locations, even though 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 examples of different operating states and domains in which the processing circuit system 10 can operate, and examples of the types of software that can execute in different exception levels and domains (of course, it should be understood that the specific software installed on the system is selected by the administrator who manages the system and is therefore not an essential feature of the hardware architecture).

The processing circuit system 10 can operate at a number of different exception levels 80, in this example, four exception levels labeled EL0, EL1, EL2, and EL3, where in this example, EL3 refers to the exception level with the most privileged level and EL0 refers to the exception level with the least privileged level. It should be understood that other architectures may choose the opposite numbering, so that the exception level with the highest number can be considered to have the least privilege. In this example, the least privileged exception level EL0 is used for application-level code, the next most privileged exception level EL1 is used for operating system-level code, the next most privileged exception level EL2 is used for hypervisor-level code that manages switching between several virtualized operating systems, and the most privileged exception level EL3 is used for monitoring code that manages switching between individual domains and allocation of physical addresses to physical address space, as described later.

When an exception occurs while processing software at a particular exception level, for some types of exceptions, the exception is taken to a higher (more privileged) exception level, where the particular exception level to which the exception is taken is selected based on the attributes of the particular exception that occurred. However, in some cases, 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 when the exception was taken. When an exception is taken, information describing characteristics of the state of the processor at the time the exception was taken may be stored, including, for example, the current exception level at the time the exception was taken, and thus once the exception handler has processed to handle the exception, processing may then return to the previous processing and the stored information may be used to identify the exception level to which processing should return.

In addition to the different exception levels, the processing circuit system also supports several operating domains including a root domain 82, a secure (S) domain 84, a less secure domain 86, and a domain domain 88. For ease of reference, the less secure domain will be described below as a "non-secure" (NS) domain, but it should be understood that this is not intended to imply any particular level of security (or lack of security). Instead, "non-secure" simply indicates that the non-secure domain is intended for code that is less secure than code operating in the secure domain. When the processing circuit system 10 is at the highest exception level EL3, the root domain 82 is selected. When the processing circuit system is in one of the other exception levels EL0 to EL2, the current domain is selected based on the current domain indicator 14 indicating which of the other domains 84, 86, 88 is in use. For each of the other domains 84, 86, 88, the processing circuitry may be in any of the exception levels EL0, EL1, or EL2.

At boot time, several boot code segments (e.g., BL1, BL2, OEM boot) may be executed, for example, within a higher privilege exception level EL3 or EL2. For example, boot code BL1, BL2 may be associated with a root domain and OEM boot code may operate in a secure domain. However, once the system is booted, at run time, processing circuit system 10 may be considered to operate in one of domains 82, 84, 86, and 88 at a time. Each of domains 82 to 88 is associated with its own associated physical address space (PAS), which enables data to be isolated from different domains within at least a portion of the memory system. This will be described in more detail below.

The non-secure domain 86 may be used for conventional application level processing, and for managing operating system and hypervisor activities of such applications. Thus, within the non-secure domain 86, there may be application code 30 operating at EL0, operating system (OS) code 32 operating at EL1, and hypervisor code 34 operating at EL2.

The secure domain 84 enables certain SoC security, media, or system services to be isolated into a physical address space separate from the physical address space used for non-secure processing. The secure and non-secure domains are not equal in the sense that 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 that supports such a partitioning of the secure domain 84 and the non-secure domain 86 is a system based on the ^TrustZone® architecture provided by ^Arm® Limited. The secure domain can run trusted applications 36 at EL0, a trusted operating system 38 at EL1, and optionally a secure partitioning manager 40 at EL2. If secure partitioning is supported, the secure partitioning manager can use a two-level page table to support isolation between different trusted operating systems 38 running in the secure domain 84 in a manner similar to the way the hypervisor 34 can manage isolation between virtual machines or guest operating systems 32 running in the non-secure domain 86.

Extending systems to support security domains 84 has become popular in recent years because it enables a single hardware processor to support isolated secure processing, avoiding the need to execute that processing on a separate hardware processor. However, as the use of security domains has become more common, many actual systems with such a security domain now support relatively complex mixed service environments within the security domain provided by a wide range of different software providers. For example, code operating in security domain 84 may include different software segments provided by (among others): a silicon supplier that manufactures integrated circuits, an original equipment manufacturer (OEM) that assembles the integrated circuits provided by the silicon supplier into an electronic device (such as a mobile phone), an operating system vendor (OSV) that provides an operating system 32 for the device; and/or a cloud platform provider that manages a cloud server that supports services for a number of different clients via the cloud.

However, there is an increasing desire among vendors of user-level code (which is typically expected to be executed as an application 30 in a non-secure domain 86) to have a secure computing environment that can be trusted not to leak information to other parties' operating code on the same physical platform. Such secure computing environments can be dynamically allocated, authenticated, and certifiable at run time, so that users can verify that sufficient security assurances are desirable on the physical platform before trusting the device to process potentially sensitive code or data. Users of such software may not want to trust vendors that provide rich operating systems 32 or hypervisors 34 that may typically operate in non-secure domains 86 (or even if their vendors themselves can be trusted, users may want to protect themselves from having their operating systems 32 or hypervisors 34 compromised by attackers). Furthermore, while security domain 84 may be used for such user-provided applications that require secure processing, in practice this causes problems for both users who provide code that requires a secure computing environment and for vendors of existing code that operates within security domain 84. For vendors of existing code that operates within security domain 84, adding arbitrary user-provided code within the security domain increases the potential attack surface for attacking their code, which may be undesirable, and therefore there may be strong disincentives to allow users to add code into security domain 84. On the other hand, users who provide code that requires a secure computing environment may not be willing to trust all suppliers of different code segments operating in security domain 84 to have access to their data or code. If authentication or proof of code operating in a specific domain is required as a prerequisite for user-provided code to perform its processing, it may be difficult to review and authenticate all different code segments operating in security domain 84 provided by different software vendors, which may limit the opportunity for third parties to provide more secure services.

2, an additional domain 88, referred to as a realm domain, is provided that may be used by such user-introduced code to provide a secure computing environment that is orthogonal to any secure computing environment associated with components operating in the secure domain 24. In the realm domain, the software executed may include a number of realms, each of which may be isolated from other realms by a realm management module (RMM) 46 operating at exception level EL2. The RMM 46 may control isolation between the respective realms 42, 44 executing the realm domain 88, for example, by defining access permissions and address mappings in a page table structure in a manner similar to how the hypervisor 34 manages isolation between different components operating in the non-secure domain 86. In this example, the domains include an application level domain 42 that executes at EL0, and a packaged application/operating system domain 44 that executes across exception levels EL0 and EL1. It should be understood that supporting both EL0 and EL0/EL1 type domains is not necessary, and multiple domains of the same type may be created by RMM 46.

Domain domain 88 has its own physical address space allocated to it similar to security domain 84, but is orthogonal to security domain 84 in the sense that while domain domain 88 and security domain 84 can each access the non-secure PAS associated with non-secure domain 86, domain domain 88 and security domain 84 cannot access each other's physical address space. This means that the code executing in domain domain 88 and security domain 84 has no dependencies on each other. Code in the domain domain only needs to trust the hardware, RMM 46, and the code switching between management domains operating in root domain 82, which means that certification and authentication become more feasible. Certification enables a given piece of software to request verification that the code installed on a device matches certain expected properties. This can be implemented by checking whether the hash of the code installed on the device matches the expected value signed by a trusted party using a cryptographic protocol. For example, the RMM 46 and monitoring code 29 can be verified by checking whether the hash of this software matches the expected value signed by a trusted party (such as a silicon vendor that manufactures the integrated circuits that include the processing system 2, or an architecture vendor that designs the processor architecture that supports domain-based memory access control). This allows the user-provided code 42, 44 to verify that the integrity of the domain-based architecture can be trusted before performing any secure or sensitive functions.

Thus, it can be seen that code associated with domains 42, 44 (which would have previously been executed in non-secure domain 86, as indicated by the dashed lines showing gaps in the non-secure domain where such programs would have previously been executed) can now be moved into domains where they can have stronger security assurances because their data and code are not accessible by other code operating in non-secure domain 86. However, because domain 88 is orthogonal to secure domain 84 and therefore cannot see each other's physical address space, this means that suppliers of code in the domains do not need to trust suppliers of code in the secure domain, and vice versa. Code in the domain domain may simply trust trusted firmware that provides monitoring code 29 and RMM 46 for the root domain 82, which may be provided by vendors that may already be inherently trusted when the code is executed on devices from silicon vendors or vendors of instruction set architectures supported by the processor, enabling users to have a secure computing environment without the need for further trust relationships with other operating system vendors, OEMs, or cloud hosts.

This can be useful for a range of applications and use cases, including, for example, mobile e-wallets and payment applications, gaming anti-cheat and piracy mechanisms, OS platform security enhancements, secure virtual machine hosting, confidential computing, networking, or gateway processing for IoT devices. It will be appreciated that there are many other applications where users may find domain support useful.

To support security assurance provided to a domain, the processing system may support attestation reporting capabilities, where firmware images and configurations are measured at boot time or at run time, such as monitoring code images and configurations or RMM code images and configurations, and at run time, domain content and configurations are measured so that the domain owner can trace the attestation reports back to known implementations and certifications to make a trust decision whether to operate on the system.

As shown in Figure 2, a separate root domain 82 is provided to manage domain switching, and the root domain has its own isolated root physical address space. The establishment of the root domain and the isolation of its resources from the secure domain allows for a more robust implementation even for systems that only have a non-secure domain 86 and a secure domain 84 but no domain domain 88, but can also be used for implementations that do support the domain domain 88. The root domain 82 can be implemented using monitoring software 29 provided (or certified) by a silicon vendor or architecture designer, and can be used to provide secure boot functionality, trusted boot measurements, system on chip configuration, debugging control, and management of firmware updates for firmware components provided by other parties (such as OEMs). The root domain code can be developed, certified, and deployed by silicon vendors or architects without dependency on the end device. In contrast, the secure domain 84 can be managed by the OEM for implementation of certain platform and security services. The management of the non-secure domain 86 can be controlled by the operating system 32 to provide operating system services, while the domain domain 88 allows the development of new forms of trusted execution environments that can be dedicated to users or third-party applications while being isolated from the existing secure software environment in the secure domain 84.

FIG3 schematically illustrates another example of a processing system 2 for supporting these techniques. Components identical to those of FIG1 are illustrated using the same component numbers. FIG3 shows in greater detail the address translation circuitry 16, which includes a level 1 memory management unit 50 and a level 2 memory management unit 52. The level 1 MMU 50 may be responsible for translating a virtual address into a physical address (when the translation is triggered by an EL2 or EL3 code) or an intermediate address (when the translation is triggered by an EL0 or EL1 code in an operating state that requires an additional level 2 translation by the level 2 MMU 52). The level 2 MMU may translate an intermediate address into a physical address. The level 1 MMU may be based on page tables controlled by the operating system for translations originating from EL0 or EL1, by the hypervisor for translations from EL2, or by monitor code 29 for translations from EL3. Level 2 MMU 52, on the other hand, may be based on a page table structure defined by the hypervisor 34, RMM 46, or secure partition manager 14, depending on which domain is being used. Separating translations into two stages in this manner allows the operating system to manage address translations for itself and applications under the assumption that they are the only operating system running on the system, while RMM 46, hypervisor 34, or SPM 40 can manage isolation between different operating systems running in the same domain.

3, the address translation process using the address translation circuitry 16 may return security attributes 54 which, in conjunction 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 granule protection information as described earlier. In this example, the PAS filter 20 is shown as a granular memory protection unit (GMPU) that verifies whether access to the requested physical address is allowed through the selected PAS, and if so, allows the transaction to pass to any cache 24 or interconnect 8 that is part of the system mesh fabric of the memory system.

The GMPU 20 allows memory to be assigned to separate address spaces, providing strong hardware-based isolation guarantees and providing spatial and temporal flexibility in the method of assigning physical memory to these address spaces, as well as allowing efficient sharing schemes. As described earlier, the execution units in the system are logically divided into virtual execution states (domains or "worlds"), of which there is an execution state (root world) at the highest exception level (EL3) called the "root world" that manages the assignment of physical memory to these worlds.

Virtualizes a single system physical address space into multiple "logical" or "architectural" physical address spaces (PAS), where each such PAS is an orthogonal address space with independent consistency properties. System physical addresses are mapped to the single "logical" physical address space using PAS tag extensions.

A given world is allowed to access a subset of the logical physical address space. This is enforced by a hardware filter 20 which may be attached to the output of the memory management unit 16.

The world defines the security attributes of accesses (PAS tags) using fields in the translation table descriptors of the page tables used for address translation. Hardware filter 20 has access to a table (granule protection table 56, or GPT) that defines, for each page in the system's physical address space, granule protection information (GPI) indicating the PAS TAG associated therewith and (optionally) other granule protection attributes.

The hardware filter 20 checks the world ID and security attributes against the GPI of the particle and determines whether access is authorized, thus forming a particle memory protection unit (GMPU).

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

Locating the GMPU 20 on the requester side of the system (e.g., on the MMU output) rather than on the completer side allows access permissions to be allocated at a page granularity while allowing the interconnect 8 to continue to hash/strip pages across multiple DRAM ports.

Transactions remain tagged with PAS TAGs as they propagate throughout the system mesh fabric 24, 8 until they reach a location defined as a physical alias point 60. This allows filters to be located on the master side without sacrificing security compared to slave-side filtering. PAS TAGs can be used as a deep security mechanism for address isolation as transactions propagate throughout the system: for example, a cache can add PAS TAGs to address tags in the cache, preventing accesses to the same PA with the wrong PAS TAG from hitting in the cache, and thus improving side channel resistance. PAS TAGs can also be used as context selectors for a protection engine attached to a memory controller that encrypts data before writing it to external DRAM.

The physical point of alias (PoPA) is the location in the system where the PAS TAG is stripped and the address is changed from a logical physical address back to a system physical address. The PoPA can be located below the cache on the completer side of the system that accesses the physical DRAM (using the encryption context resolved through the PAS TAG). Alternatively, it can be located above the cache to simplify the system implementation at the cost of reduced security.

At any point in time, the world may request to transfer a page from one PAS to another. The request is made to monitor code 29 at EL3 which detects the current state of the GPI. EL3 may only allow certain sets of transfers to occur (e.g., from a non-secure PAS to a secure PAS, but not from a domain PAS to a secure PAS). To provide a clean transfer, a system supported command - "data cleanup and invalidation of entity alias points" - is submitted by EL3 before transferring the page to the new PAS - this ensures that any residual state associated with the previous PAS is cleared from any cache memory upstream of the PoPA 60 (closer to the requester side than that PoPA).

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 authorize shared access to a physical particle to a subset of N worlds while preventing other worlds from accessing it. This can be achieved by adding "restricted sharing" semantics to the particle protection information while forcing it to use a specific PAS TAG. As an example, a GPI while being tagged with a PAS TAG of secure PAS 84 can indicate that a physical particle can only be accessed by "domain world" 88 and "secure world" 84.

Examples of the above properties allow the visibility properties of a particular physical particle to be changed quickly. Consider a situation where each world is assigned a private PAS that is only accessible to that world. For a particular particle, a world can request to make it visible to the non-secure world at any point in time by changing its GPI from "exclusive" to "restricted sharing with non-secure world" without changing the PAS association. In this way, the visibility of the particle can be increased without the need for expensive cache maintenance or data replication operations.

The GMPU (20) includes a PAS check circuit system and may also include a device authority check circuit system.

Figure 4 illustrates the concept of aliasing individual physical address spaces to physical memory provided in hardware. As described earlier, each of the domains 82, 84, 86, 88 has its own individual physical address space 61.

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

The selection of a PAS for a given memory access request may depend on the current domain in which the processing circuitry 10 is operating when the memory access request is issued and may be constrained according to the rules defined in the following table: Current domain Non-Security PAS SafePAS Field PAS Root PAS Non-security Accessible Not accessible Not accessible Not accessible Safety Accessible Accessible Not accessible Not accessible Field Accessible Not accessible Accessible Not accessible root Accessible Accessible Accessible Accessible

For those domains where there are multiple physical address spaces available for selection, information from the accessed page table entry used to provide the physical address is used to select between the available PAS options.

Therefore, when the PAS filter 20 outputs a memory access request (assuming it passes any filtering checks) to the system mesh fabric 24, 8, the memory access request is associated with a physical address (PA) and a selected physical address space (PAS).

From the perspective of memory system components (such as caches, interconnects, snoop filters, etc.) operating before a physical point of alias (PoPA) 60, the individual physical address spaces 61 are viewed as being completely separate address ranges corresponding to different system locations within memory. This means that from the perspective of the pre-PoPA memory system components, the range of addresses identified by a memory access request is actually four times the size of the range 62 that can be output in an address translation, since the PAS identifier is effectively viewed as an additional address bit next to the physical address itself, such that the same physical address PAx can be mapped to a number of individual alias physical addresses 63 in different physical address spaces 61, depending on which PAS is selected. These alias physical addresses 63 actually all correspond to the same memory system location implemented in physical hardware, but the pre-PoPA memory system components treat the alias addresses 63 as separate addresses. Therefore, if there are any pre-PoPA caches or snoop filters that allocate entries for such addresses, the alias addresses 63 will be mapped to different entries with separate cache hit/miss decisions and separate coherency management. This reduces the likelihood or effectiveness of an attacker using cache or coherency side channels as a mechanism to probe the operations of other domains.

The system may include more than one PoPA 60. At each PoPA 60, the aliased 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 to any post-PoPA components downstream so that the system physical address space 64 that actually identifies the memory system location is again the same size as the range of physical addresses that can be output in the address translation performed on the requester side. For example, the PAS identifier can be stripped from the address at the PoPA 60, and for downstream components, the address can simply be identified using the physical address value without specifying the PAS. Alternatively, for some situations where some completer-side memory access request filtering is desired, the PAS identifier may still be provided downstream of the PoPA 60, but may not be interpreted as part of an address, such that the same physical address appearing in different physical address spaces 60 will be interpreted downstream of the PoPA as referring to the same memory system location, but the supplied PAS identifier may still be used to perform any completer-side security checks.

FIG5 illustrates how a granule protection table 56 may be used to divide the system physical address space 64 into blocks allocated for access within a particular architectural physical address space 61. A 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 include a number of entries, each corresponding to a granule of physical addresses of a particular size (e.g., a 4K page) and may define an assigned PAS for the granule, which may be selected from a non-secure, secure, domain, and root domain. By design, if a particular granule or group of granules is assigned to a PAS associated with one of the domains, it may only be accessed within the PAS associated with that domain and cannot be accessed within the PASs of other domains. However, it should be noted that although a granule assigned to a secure PAS (for example) cannot be accessed from within the root PAS, the root domain 82 is able to access the granule of the physical address by specifying in its page table PAS selection information for ensuring that the virtual address associated with the page mapped to the region of physically addressed memory is translated into a physical address in the secure PAS rather than in the root PAS. Thus, data sharing across domains (where permitted by the accessibility/inaccessibility rules defined in the table described earlier) can be controlled when selecting the PAS for a given memory access request.

However, in some implementations, in addition to allowing physically addressed particles to be accessed within the assigned PAS defined by the GPT, the GPT may use other GPT attributes to mark certain areas of the address space as being shared with another address space (e.g., an address space associated with a domain of lower privilege or orthogonal privilege that would not normally be allowed to select the assigned PAS for access requests to that domain). This can facilitate temporary sharing of data without requiring changes to the assigned PAS for a given particle. For example, in FIG. 5 , area 70 of the domain PAS is defined in the GPT as being assigned to the domain domain, and is generally not accessible from the non-secure domain 86 because the non-secure domain 86 cannot select the domain PAS for its access requests. Since the non-secure domain 26 cannot access the domain PAS, the non-secure code generally cannot see the data in area 70. However, if the domain temporarily wishes to share some of its data in its assigned memory region with the non-secure domain, it may request the monitor code 29 operating in the root domain 82 to update the GPT 56 to indicate that region 70 is to be shared with the non-secure domain 86, and as shown on the left side of Figure 5, this may make region 70 also accessible from the non-secure PAS without changing which domain is the assigned domain for region 70. If the domain domain has designated a region of its address space as being shared with the non-secure domain, then although a memory access request issued from the non-secure domain targeting that region may initially specify the non-secure PAS, the PAS filter 20 may remap the PAS identifier of the request to instead specify the domain PAS so that downstream memory system components treat the request as if it had always been issued from the domain domain. Since the operation of assigning different domains to a particular memory region may be more performance intensive involving greater cache/TLB invalidation and/or zeroing of data in memory or copying of data between memory regions, such operations may be unnecessary if the intended sharing is only temporary, and such sharing may improve performance.

6 is a flow chart showing how to determine the current operating domain, which may be performed by the processing circuitry 10 or by the address translation circuitry 16 or 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 domain 86, the secure domain 84, and the domain domain 88 as indicated by at least two domain indication bits 14 in the EL3 control register of the processor (since the root domain is indicated by the current exception level being EL3, the domain indication bits 14 may not necessarily have a coding corresponding to the root domain, so at least one coding of the domain indication bits may be reserved for other purposes). The EL3 control registers are writable when operating at EL3 and cannot be written from other exception levels EL2 to EL0.

FIG. 7 shows an example of a page table entry (PTE) format that may be used by the address translation circuitry 16 for a page table entry in a page table structure for mapping a virtual address to a physical address, mapping a virtual address to an intermediate address, or mapping an intermediate address to a physical address (depending on whether the translation is being performed in an operating state that fully requires a 2nd-level translation, and if a 2nd-level translation is required, depending on whether the translation is a 1st-level translation or a 2nd-level translation). In general, a given page table structure may be defined as a multi-level table structure implemented as a tree of page tables, where a first level page table is identified based on a base address stored in a processor's translation table base address register, and the index that selects a particular level 1 table entry within the page table is derived from a bit subset of the input address for which the translation lookup is being performed (the input address may be a virtual address of a level 1 translation of an intermediate address for a level 2 translation). The level 1 page table entry may be a "table descriptor" 110 that provides a pointer 112 to a next level page table, from which additional page table entries may then be selected based on additional bit subsets of the input address. Finally, after one or more lookups of consecutive levels of page tables, a block or page descriptor PTE 114, 116, 118 may be identified that provides an output address 120 corresponding to the input address. The output address may be an intermediate address (for level 1 translation performed in an operating state that also performs further level 2 translation) or a physical address (for level 2 translation, or for level 1 translation when level 2 translation is not required).

To support the different physical address spaces described above, in addition to the next level page table pointer 112 or output address 120 and any attributes 122 used to control access to the corresponding memory block, the page table entry format may also specify some additional state for use in physical address space selection.

For table descriptors 110, PTEs used by any domain other than non-secure domain 86 include a non-secure table indicator 124 indicating that the next level page table will be accessed from the non-secure physical address space or from the physical address space of the current domain. This helps promote more efficient page table management. Typically, a page table structure used by a root domain, a domain domain, or a secure domain 24 may only need to define special page table entries for a portion of the virtual address space, and the same page table entries can be used for other portions when used by a non-secure domain 26, so by providing a non-secure table indicator 124, this allows higher-level page table structures to provide dedicated domain/security table descriptors, while at specific points in the page table tree, the root domain, the domain domain, or the secure domain can switch to use page table entries from the non-secure domain for those portions of the address space that do not require higher security. Other page table descriptors in other parts of the page table tree may still be fetched from the relevant physical address space associated with the root domain, domain domain, or security domain.

On the other hand, depending on which domain the block/page descriptor 114, 116, 118 is associated with, it may include physical address space selection information 126. Since the non-secure domain can only access the non-secure PAS, the non-secure block/page descriptor 118 used in the non-secure domain 86 does not include any PAS selection information. However, for other domains, the block/page descriptor 114, 116 includes PAS selection information 126 for selecting which PAS the input address is translated into. For the root domain 22, the EL3 page table entry may have PAS selection information 126 including at least 2 bits to indicate the PAS associated with any of the 4 domains 82, 84, 86, 88 as the selected PAS to which the corresponding physical address is translated. In contrast, for the domain domain and the security domain, the corresponding block/page descriptor 116 only needs to include one bit of PAS selection information 126, which is used to select between the domain PAS and the non-secure PAS when used for the domain domain, and to select between the secure PAS and the non-secure PAS when used for the security domain. To improve the efficiency of the circuit implementation and avoid increasing the size of the page table entry, for the domain domain and the security domain, the block/page descriptor 116 can encode the PAS selection information 126 at the same position within the PTE, regardless of whether the current domain is the domain domain or the security domain, so that the PAS selection bit 126 can be shared.

8 is a flow chart showing a method of selecting a PAS based on the current domain and information 124, 126 from the block/page PTE used when generating the physical address of a given memory access request. The PAS selection may 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, by a combination of the address translation circuitry 16 and the PAS filter 20.

At step 130 in FIG. 8 , processing circuitry 10 issues a memory access request specifying a given virtual address (VA) as the target VA. At step 132 , 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 accesses the memory origin page table to retrieve the required PTE (a series of memory accesses may be required to step through the various layers of the page table structure and/or multiple stages of address translation to obtain a mapping from VA to an intermediate address (IPA) and then from IPA to PA). It should be noted that any memory access request issued by the address translation circuit system 16 during a page table walk operation may itself be subject to address translation and PAS filtering, so the request received in step 130 may 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 via IPA in two stages). In step 134, the address translation circuit system 16 or PAS filter 20 determines which domain is the current domain using the method shown in Figure 6.

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

If the current domain is a secure domain, then in step 138, the output PAS is selected based on the PAS selection information 126 included in the block/page descriptor PTE providing the physical address, wherein the output PAS is selected as either a secure PAS or a non-secure PAS.

If the current domain is the domain domain, then in 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 is derived, and in this case, the output PAS is selected as either the domain 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 is derived. In this case, the output PAS is selected to be any one of the physical address spaces associated with the root domain, the domain domain, the secure domain, and the non-secure domain. Controlling access to the physical address space by a hardware device

FIG9 shows an example of an access control circuit system 23. The access control circuit system 23 includes the PAS check circuit system 20 (e.g., the PAS filter discussed above) and the device permission check circuit system 92. The device permission check circuit system 92 is not explicitly shown in FIG1, but may be provided next to the PAS filter 20 shown in FIG1 (e.g., it may be at a logical location along the path taken by the memory access request between the address translation circuit system and the interconnect). Alternatively, the device permission check circuit system may be provided at a different location. The PAS check circuit system 20 is responsible for controlling access to a given memory location based on the granular protection information (GPI) defined for the given physical address. The GPI for a given physical address indicates which PASs are allowed to access the given physical address (e.g., as shown in FIG. 5 ). As discussed above, this allows data stored in certain areas of memory to be protected from access by software executing in certain other domains—for example, software executing in a “non-secure” domain generally cannot access data stored in areas of memory designated as “secure,” “domain,” or “root.”

However, in addition to isolating regions from software programs, it may be useful to also provide a mechanism for isolating regions of memory from specific hardware elements (e.g., requestor devices). For example, there may be situations where it may be useful to be able to isolate certain data or code from a specific processing element (PE), regardless of the current domain in which the PE is executing. Similarly, it may be desirable to make a certain region of memory visible only to a specific requestor device without requiring it to be accessible to any other device. For example, this may allow multiple requestor devices (e.g., a system-on-chip (SoC)) in a data processing system to be effectively partitioned into subsets of the PAS described above. An example where this might be useful is to provide a dedicated secure processing unit to perform high security processing (for example, this might be the processing involved in managing biometric or facial recognition features) – allowing such processes to be isolated from other processing elements can be particularly useful as it limits the number of other processes/devices that need to be trusted.

It may be assumed that such high security programs may be protected by executing them within a secure or domain domain and storing any data or code associated with such programs in the corresponding secure or domain PAS. However, while this will provide some protection by isolating the high security programs from programs associated with other PASs, other programs operating in the same PAS may still be able to access the code. Therefore, providing an additional level of isolation may provide a greater degree of security, which may be warranted in certain circumstances.

It may also be considered to run such high-security programs in the root domain. However, it is better to minimize the number of programs allowed to operate in the root domain, reserving the root domain for those programs involved in managing handoffs between other operating domains.

Therefore, the present technology isolates these high security processes using device permission checking circuitry 92. Device permission checking circuitry 92 checks whether the requestor device issuing the access request is allowed to access the selected PAS (the PAS selected by the PAS selection circuitry). The identity of the requestor device can be determined based on the device identifier provided with the request (for example, this may be the case if the requestor is an external device - as part of the SMMU (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 device permission checking circuitry 92 is shared among multiple PEs - e.g., it may be on interconnect 8), or may be implicit (e.g., if device permission checking circuitry 92 is provided in the requestor device itself - e.g., as shown in FIG. 1). If the device permission checking circuitry determines that the request from the identified device is not allowed to access the selected PAS, it denies the request.

It should be noted that although some of the figures illustrate access control circuitry 20 as a single unit, it is feasible to provide device authorization check circuitry 92 and PAS check circuitry 20 at different locations. For example, because the checks performed by device authorization check circuitry 92 do not require a physical address, this circuitry may be provided before address translation circuitry 16 (assuming that some alternative PAS selection circuitry is provided before device authorization check circuitry 92). Alternatively, address translation circuitry 16 may in some instances be able to obtain the PAS midway through address translation (e.g., in an earlier stage of address translation if multi-stage address translation is implemented). Therefore, in some examples, the address translation circuitry 16 may pass the PAS to the device permission check circuitry 92 midway through the address translation, and the device permission check circuitry 92 may perform its check in parallel with the address translation circuitry 16 performing the final translation.

Device permission checking circuitry 92 determines whether to deny an access request from a particular device based on the access permissions defined for the particular device and the selected PAS. An example of how these access permissions may be defined is shown in FIG. 10 .

FIG10 shows an example of a system register 96 associated with a particular device and accessible by the device permission checking circuitry, which defines the additional advisory-based permissions described above. In some specific examples, this register 96 may be one of the registers 12 provided within the requestor device 4, although the register may also be provided external to the requestor device. Register 96 is referred to as the "GPC Control Register" or "GPCCR" in FIG7, and in this example, its contents may only be modified by a program executing at the highest exception level (e.g., EL3 in this example).

The GPPCR includes several fields that each correspond 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 allowed to access the corresponding PAS. Specifically, the "SPASD" field 95 defines permission information related to the secure (S) PAS; the "NSPASD" field 97 defines permission information related to the less secure (NS) PAS; and the "RLPASD" field 99 defines permission information related to the domain (RL) PAS. There are no fields provided for the root PAS.

In one particular example, each of the fields (referred to as "PASD" fields) holds a "PAS Disable" (PASD) bit. This is a single bit (one of "1" or "0") that indicates whether a device is prohibited from accessing the corresponding PAS - the PASD bit thus defines an additional set of permissions for the associated device over and above those enforced by the PAS checking circuitry 20 (e.g., those permissions 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 is prohibited. For example, the value held in each of the PASD bits may be interpreted as follows: RLPASD Bits: -      If RLPASD = 0, access to the domain PAS is allowed when the domain PAS is selected as the selected PAS and the GPT-based granular protection check indicates that access to the domain PAS is allowed for the target physical address. -      If RLPASD = 1, when granular protection checking is enabled, any access to the domain physical address space results in a GPF (granular protection fault). SPASD bit: -      If SPASD = 0, access to the secure PAS is allowed when the secure PAS is selected as the selected PAS and the GPT-based granular protection check indicates that access to the secure PAS is allowed for the target physical address. -      If SPASD = 1, when granular protection checking is enabled, any access to the secure physical address space causes a GPF. NSPASD bit: -      If NSPASD = 0, access to the non-secure (less secure) PAS is allowed when the non-secure (less secure) PAS is selected as the selected PAS and the GPT-based granular protection check indicates that access to the non-secure PAS is allowed for the target physical address. -      If NSPASD = 1, when granular protection checking is enabled, any access to the non-secure (less secure) physical address space causes a GPF.

This is also illustrated in the table below: Less safe PAS SafePAS Field PAS Root PAS NSPASD 0b0: Permission depends on GPI 0b1: Error Any value: permissions depend on GPI Any value: permissions depend on GPI Any value: permissions depend on GPI SPASD Any value: permissions depend on GPI 0b0: Permission depends on GPI 0b1: Error Any value: permissions depend on GPI Any value: permissions depend on GPI RLPASD Any value: permissions depend on GPI Any value: permissions depend on GPI 0b0: Permission depends on GPI 0b1: Error Any value: permissions depend on GPI

It should be understood that the interpretation applied to the values of 0b0 and 0b1 may also be reversed, such that the value of 0b1 indicates that the authority depends 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 requestor device - for example, the permissions defined in each of PASD fields 95, 97, 99 may alternatively be defined in a separate register.

Additionally, in some examples, PASD permissions may be defined in different data structures. Specifically, the SMMU may access stream table entries to determine device permission information for external devices - since the SMMU may manage hundreds of devices, defining permissions in a table in memory may be more feasible than using GPCCR.

It can be used to provide a mechanism for preventing the permissions defined in any of the PASD fields from being modified. Preventing registers 96 from being modified by programs executing 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 can be provided to identify one or more registers (which may include the GPCCR) and/or one or more specific portions of registers to which write requests should be ignored in some circumstances.

The write ignore control register 98 shown in FIG10 can be edited only by a program operating at the highest (most privileged) exception level (EL3), and includes a field 101 that holds a register lock value indicating whether direct writes to the GPPCR should be ignored. For example, this field may store a single bit that, when set, indicates that write requests to the designated GPCCR 96 should be ignored. Additional 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 may be interpreted as follows: "Named register" bits 101, 103: -      0b0: Direct writes to the "named register" (e.g., for GPCCR field 101, the "named register" is the GPCCR) are not affected by this mechanism -      0b1: Direct writes to the "named register" are ignored and the "named register" is not updated.

It should again be understood that the interpretation of the values applied to 0b0 and 0b1 can also be flipped so that a value of 0b0 indicates that a write should be ignored. Furthermore, while the above example shows how an entire "named register" can be locked, in some examples, a write ignore control register can identify specific bits/fields of a given register for which write requests should be ignored.

In a particular example, these "named register" bits (also referred to herein as "register lock values" or "write ignore values") are "sticky" such that any request to write a value of 0b0 (e.g., a request to clear the value) is ignored, while a write of 0b1 is not ignored. The "named register" bits 101, 103 may then be reset to 0 when the data processing device is reset.

It should be noted that in alternative embodiments, the register lock value of the GPCCR may be provided as field 105 of the GPCCR itself rather than as a field of a separate register.

It can be used to provide a mechanism for disabling the above-mentioned features (e.g., disabling PASD and/or write-ignore features). For example, this can help provide retroactive compatibility. Therefore, Figure 10 also shows a feature register 94 including a PASD enable field 91 indicating whether the PASD feature is enabled and a FGWIE field 93 indicating whether the write-ignore feature is enabled. For example, a value of 1 in either of these fields can indicate that the corresponding feature is enabled, while a value of 0 can indicate that it is disabled (or vice versa).

FIG11 schematically shows another example configuration of a 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 the input or output of data from/to peripheral devices. At least some of the requester devices may have an internal data or instruction cache 21 for caching local instructions or data to the device. Other master devices (such as the input/output interface 7) may be cacheless master devices. The consistency between the data in the respective caches and the data accessed by the respective masters may be managed by a consistency interconnect 9 (which is an example of interconnect 8 shown in FIG. 1 ) which tracks requests to access data from a given address and controls the monitoring of data in caches of other masters when necessary to maintain consistency. It should be understood that in other embodiments, such consistency operations may be managed by software, but the benefit of providing a hardware interconnect 9 for tracking such consistency is that programmers of software executed by the system do not need to be concerned with consistency.

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

FIG. 12 illustrates another example of a data processing system 2 in which the present technology may be implemented. In this example, memory—specifically, dynamic random access memory (DRAM) 146—is logically partitioned into multiple PASs: a root PAS, a domain (RL) PAS, a secure (S) PAS, and a less secure (NS) PAS. A plurality of requestor devices including a plurality of PEs 5 and a plurality of external devices 7 are provided. In this example, each PE 5 is allowed to execute software in one of a secure domain 84, a less secure domain 86, or a root domain 82 (e.g., as shown in FIG. 2, the root domain is reserved for use by certain programs). At the same time, each external device 7 is allowed to execute software in one of the less secure domain 86 or the domain domain 88. Thus, in this particular example, domain domain 88 is used exclusively by external device 7 and security domain 84 is used exclusively by PE 5.

As in the example described above, the root PAS 82 is isolated from all other PASs, while the domain PAS 88 and the secure PAS 84 are isolated from each other and from the less secure PAS 86. The isolation between the different PASs is enforced by the system range 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 the domain SMMU context.

Hardware enforced security (HES) mechanisms are also implemented in FIG. 9 , for example, to protect so-called “root of trust (RoT)” services that may include programs executed by SRC 144 .

FIG. 13 is a flow chart illustrating an example method according to the present technology. In this example method, in step 106, a memory access request is received from a device labeled "Device X" specifying a memory address (e.g., this may be a virtual address). In step 108, a PAS is selected to be associated with the memory address - this selection is made depending on the current execution domain. In step 148, a determination is made whether device X is allowed to access the selected PAS. If it is determined that the device is prohibited from accessing the selected PAS, the request is denied (step 156). On the other hand, if it is not determined that the device is prohibited from accessing the selected PAS, then in step 150, a GPI for the specified memory address is obtained. In step 152, it is determined whether access to the PAS assigned to the memory address according to the GPI is allowed via the selected PAS. If access is not allowed, access is denied in step 156. On the other hand, if access is not prohibited by the GPI, access is allowed (step 154) to proceed. Simulator Implementation Scheme

FIG. 14 illustrates a simulator implementation that may be used. Although the embodiments described earlier implement the present invention with apparatus and methods for operating specific processing hardware supporting the technology of interest, it is also possible to provide an instruction execution environment according to the embodiments described herein that is implemented using a computer program. Such computer programs are often referred to as simulators because they provide software-based implementations of the hardware architecture. Types of simulator computer programs include emulators, virtual machines, models, and binary translators (including dynamic binary translators). Generally speaking, the simulator implementation can be run on a host processor 430 that optionally runs a host operating system 420 and supports the simulator program 410. In some configurations, there may be multiple layers of emulation between the hardware and the instruction execution environment provided and/or multiple different instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide an emulator implementation that executes at reasonable speeds, but this approach may be justified in certain circumstances, such as when it is necessary to execute code that is native to another processor for compatibility or reuse reasons. For example, an emulator implementation may provide an instruction execution environment with additional functionality not supported by the host processor hardware, or provide an instruction execution environment that is generally associated with a different hardware architecture. An overview of simulation is given in "Some Efficient Architecture Simulation Techniques", Robert Bedichek, Winter 1990 USENIX Conference, pages 53-63.

Where an embodiment has been previously described with reference to a particular hardware architecture or feature, in an analog embodiment, equivalent functionality may be provided by an appropriate software architecture or feature. For example, a particular circuit system may be implemented as computer program logic in an analog embodiment. Similarly, memory hardware (such as registers or caches) may be implemented as software data structures in an analog embodiment. In configurations where one or more of the hardware elements mentioned in the previously described embodiments reside on host hardware (e.g., host processor 430), some analog embodiments may utilize host hardware when appropriate.

The emulator program 410 may be stored on a computer-readable storage medium (which may be a non-transitory medium) and provides a programming interface (instruction execution environment) to the object code 400 (which may include applications, operating systems, and hypervisors), which is the same as the interface of the hardware architecture modeled by the emulator program 410. Therefore, program instructions of the object code 400 can be executed from within the instruction execution environment using the emulator program 410, so that a host computer 430 that does not actually have the hardware features of the device 2 discussed above can emulate these features. For example, since the object code can be tested by running within an emulator executing on a host device that does not support the architecture, this can be useful to allow object code 400 developed for a new version of a processor architecture to be tested before actual hardware devices supporting the architecture are available.

The emulator code includes handler logic 412 that emulates the behavior of the processing circuit system 10, for example, including instruction decoder logic that decodes instructions of the target code 400 and maps the instructions to corresponding instruction sequences in the native instruction set supported by the host hardware 430 to perform functions equivalent to the decoded instructions. The handler logic 412 also emulates the processing of the code in different exception levels and domains as described above. The register emulator logic 413 maintains data structures in the host address space of the host processor that emulate the architecture register states defined according to the target instruction set architecture associated with the target code 400. Therefore, instead of storing such architectural state in hardware registers 12 as in the example of Figure 1, it is instead stored in the memory of the host processor 430, where the register emulation program logic 413 maps the register references of the 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 other system registers 13 described earlier.

The emulation code includes address translation logic 414 and filter logic 416 which respectively emulate the functionality of the address translation circuitry 16 and the PAS filter 20 with reference to the same page table structure and GPT 56 as described earlier. Thus, the address translation logic 414 translates virtual addresses specified by the object code 400 into emulated physical addresses in one of the PASs (which, from the object code's point of view, refer to physical locations in memory), but in reality these emulated physical addresses are mapped onto the (virtual) address space of the host processor by the address space mapper logic 415. Filter logic 416 performs a lookup of the particle protection information to determine whether the memory access triggered by the target code is allowed to proceed in the same manner as the PAS filter described above.

In this application, the phrase "configured to..." is used to mean that a component of a device has a configuration that enables it to perform the defined operation. In this context, "configuration" means the arrangement or manner in which hardware or software is interconnected. For example, the device may have dedicated hardware that provides the defined operation, or a processor or other processing device may be programmed to perform the function. "Configured to" does not mean that the device component needs to be changed in any way to provide the defined operation.

Furthermore, the term "comprising at least one of..." is used in this application to mean including any one of the following options or any combination of the following options. For example, "at least one of the following: 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 present invention have been described in detail with reference to the accompanying drawings, it should be understood that the present invention is not limited to those precise embodiments and that a person skilled in the art may implement various changes and modifications therein without departing from the scope of the present invention as defined by the appended claims.

2: data processing system; processing system; data processing equipment; equipment 4: requester device 5: central processing unit (CPU); PE 6: completer device 7: input/output unit; input/output interface; requester; external device 8: interconnect; system mesh architecture 9: coherent interconnect; hardware interconnect; interconnect 10: processing circuit system 11: memory 12: register 13: system register 14: current domain indicator; current domain indicator; current domain; domain indicator bit 15: current exception level indicator; current exception level 16: address translation circuit system; PAS selection circuit system 17: memory management unit (MMU) 18: Translation lookaside buffer (TLB) 19: System memory management unit (SMMU) 20: PAS filter; GMPU; hardware filter; PAS check circuit system 21: Internal data or instruction cache 22: Granular protection information cache 23: Access control circuit system 24: Cache memory; System mesh architecture; Security domain 26: Non-secure domain 29: Monitoring code; Monitoring software 30: Application code; Application 32: Operating system (OS) code; Guest operating system; Rich operating system; Operating system 34: Hypervisor code; Hypervisor 36: Trusted application 38: Trusted Operating System 40: Secure Partition Manager; SPM 42: Domain; User-Provided Code 44: Domain; User-Provided Code 46: Domain Management Module (RMM) 50: Level 1 Memory Management Unit; Level 1 MMU 52: Level 2 Memory Management Unit; Level 2 MMU 54: Security Attributes 56: Granular Protection Table (GPT) 60: Physical Point of Alias (PoPA) 61: Physical Address Space 62: Numeric Range; Range 63: Alias Physical Address; Alias Address 64: System Physical Address Space 65: De-Aliased Address; System Physical Address Space 70: Zone 80: Exception Level 82: Root Domain; Domain; Root PAS 84: secure (S) domain; domain; secure PAS; secure world 86: less secure domain; domain; less secure PAS; non-secure domain 88: domain domain; domain; domain PAS; domain world 91: PASD enable field 92: device permission check circuitry 93: FGWIE field 94: feature registers 95: SPASD field; PASD field 96: system registers; GPCCR; registers 97: NSPASD field; PASD field 98: write ignore control register 99: RLPASD field; PASD field 100: step 101: field; named register bits 102: step 103: field; named register bit 104: step 105: field 106: step 108: step 110: table descriptor 112: pointer 114: block or page descriptor PTE; block/page descriptor 116: block or page descriptor PTE; block/page descriptor 118: block or page descriptor PTE; block/page descriptor 120: output address 122: attribute 124: non-secure table indicator; information 126: physical address space selection information; PAS selection information; information; PAS selection bit 130: step 132: step 134: step 136: step 138: step 140: step 142: step 144: system domain controller (SRC) 146: dynamic random access memory (DRAM) 148: step 150: step 152: step 154: step 156: step 400: target code 410: simulator program 412: processing program logic 413: register emulation program logic 414: address translation program logic 415: address space mapping program logic 416: Filter logic 420: Host operating system 430: Host processor; Host computer; Host hardware

Further aspects, features, and advantages of the present technology will become apparent from the following example descriptions read in conjunction with the accompanying drawings, in which: [FIG. 1] illustrates an example of a data processing device; [FIG. 2] illustrates a number of domains in which a processing circuit system can operate; [FIG. 3] illustrates an example of a processing system that supports granular protection lookup; [FIG. 4] schematically illustrates aliasing a number of physical address spaces to a system physical address space that identifies locations in a memory system; [FIG. 5] illustrates an example of partitioning an effective hardware physical address space so that physical address spaces of different architectures have access to separate portions of the system physical address space; [FIG. 6] is a flow chart illustrating a method for determining the current operating domain of a processing circuit system; [FIG. 7] shows an example of a page table entry format for a page table entry used to translate a virtual address into a physical address; [FIG. 8] is a flow chart showing a method for selecting a physical address space to be accessed by a given memory access request; [FIG. 9] shows an example of an access control circuit system; [FIG. 10] shows an example of a system register; [FIG. 11] shows another example of a data processing device; [FIG. 12] shows a further example of a data processing device; [FIG. 13] is a flow chart showing an example method for checking whether to deny a memory access request; and [FIG. 14] shows an example of a simulator that can be used.

20:PAS filter; GMPU; hardware filter; PAS inspection circuit system

23: Access control circuit system

92: Device permission check circuit system

Claims (20)

A device comprising: PAS selection circuitry, responsive to a memory access request issued by a requestor device, selecting one of a plurality of physical address spaces (PAS) to be associated with the memory access request based on a current operating domain of the requestor device, the memory access request specifying a memory address identifying a memory location; and access control circuitry, responsive to the memory access request, determining whether to deny the memory access request based on the selected PAS, wherein the access control circuitry comprises: A PAS checking circuit system, which responds to the address space permission information defined for the identified memory location indicating that the memory access request associated with the selected PAS is prohibited from accessing the identified memory location and denies the memory access request; and A device permission checking circuit system, which responds to the device permission information defined for the requester device indicating that the memory access request issued by the requester device is prohibited from accessing the selected PAS and denies the memory access request. The device of claim 1, wherein in response to a first memory access request issued by the requestor device and a second memory access request issued by another requestor device, the device permission checking circuitry is allowed to deny the first memory access request without denying the second memory access request depending on the device permission information, 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. A device as claimed in claim 1 or claim 2, wherein the device permission check circuitry is configured to identify the device permission information based on the contents of at least one data structure accessible to the device permission check circuitry. The apparatus of claim 3, wherein the at least one data structure is configured to maintain, for a given PAS, a value indicating whether the requester device is prohibited from accessing the given PAS. A device as claimed in claim 3 or claim 4, wherein the device is prohibited from writing data to the at least one data structure in response to an instruction executed at an exception level with a lower privilege than a threshold exception level. The device of claim 5, wherein the limited exception level includes a maximum privilege exception level. A device as claimed in any one of claims 3 to 6, wherein the at least one data structure comprises a system register; and in response to a register lock value being maintained in at least one control register, the device is prohibited from writing data to at least a portion of the system register in response to the register lock value being set. A device as claimed in claim 7, wherein the device is prevented from clearing the register lock value after it has been set unless the requester device is reset. A device as in any of the preceding request items, comprising an address translation circuit system that, in response to the memory access request, translates the memory address specified by the memory access request into a physical address in the selected PAS associated with the memory access request. The device of claim 9, wherein the address translation circuit system includes the PAS selection circuit system. The apparatus of claim 10, wherein the PAS selection circuitry selects the selected PAS to be associated with the memory access request based on information defined in a page table entry for the memory address specified by the memory access request in response to the memory access request. A device as claimed in any one of claims 9 to 11, wherein: the address translation circuit system includes at least one of the following: 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 apparatus as in any of the preceding claims, wherein the requester device comprises a processing element or an external device. The apparatus of any of the preceding claims, wherein the PAS checking circuitry is configured to identify the address space permission information based on permission information in an entry of a table defined in memory, wherein the permission information defines which of the plurality of PASs is an allowed PAS for the identified memory location. An apparatus as claimed in any of the preceding claims, comprising: At least one pre-PoPA memory system component provided upstream of a physical point of alias (PoPA) to treat alias physical addresses corresponding to the same memory system resource from different PASs as if the alias physical addresses correspond to different memory system resources. The device of claim 15, comprising: A PoPA memory system component configured to de-alias the plurality of aliased physical addresses to obtain a de-aliased physical address to be provided to at least one downstream memory system component. A method comprising: In response to a memory access request issued by a requestor device, the memory access request specifying a memory address identifying a memory location: Selecting one of a plurality of physical address spaces (PAS) to be associated with the memory access request based on a current operating domain of the requestor device; Determining whether to deny the memory access request based on the selected PAS, wherein the determination comprises: Denying the memory access request in response to address space permission information defined for the identified memory location indicating that the memory access request associated with the selected PAS is prohibited from accessing the identified memory location; and In response to device permission information defined for the requester device indicating that a memory access request issued by the requester device is prohibited from accessing the selected PAS, the memory access request is denied. A computer program comprising instructions that, when executed by a host data processing device, controls the host data processing device to provide an instruction execution environment for executing a target program code, the computer program comprising: PAS selection program logic, which responds to a memory access request issued by a requester and selects one of a plurality of physical address spaces (PAS) to be associated with the memory access request based on a current operating domain of the requester, the memory access request specifying a memory address identifying a memory location; and Access control program logic, which responds to the memory access request and determines whether to deny the memory access request based on the selected PAS, The access control program logic includes: PAS check program logic, which responds to the address space permission information defined for the identified memory location indicating that the memory access request associated with the selected PAS is prohibited from accessing the identified memory location and rejecting the memory access request; and device permission check program logic, which responds to the device permission information defined for the requester indicating that the memory access request issued by the requester is prohibited from accessing the selected PAS and rejecting the memory access request. A computer-readable storage medium for storing a computer program as claimed in claim 18. A computer-readable medium for storing computer-readable code for manufacturing a device as claimed in any one of claims 1 to 16.