Determining whether to deny memory access request issued by requester device

Abstract

The apparatus comprises a PAS selection circuit (16) and an access control circuit (23). The PAS selection circuitry is responsive to a memory access request issued by a requester device to select one of a plurality of physical address space PASs 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. The access control circuitry comprises: PAS check circuitry (20) for denying a memory access request in response to address space permission information defined for the identified memory location, the address space permission information indicating that a memory access request associated with the selected PAS is prohibited from accessing the identified memory location; and device permission check circuitry (92) for denying the memory access request in response to device permission information defined for the requester device, the device permission information indicating that the memory access request issued by the requester device is prohibited from accessing the selected PAS.

Description

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

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

[0003] According to a first example of the present technology, there is provided an apparatus comprising:

[0004] a PAS selection circuit responsive to a memory access request issued by a requestor device to select one of a plurality of physical address spaces (PASs) 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

[0005] access control circuitry responsive to a memory access request to determine whether to deny the memory access request based on the selected PAS,

[0006] The access control circuit includes:

[0007] PAS checking circuitry to deny a memory access request in response to address space permission information defined for the identified memory location, the address space permission information indicating that the memory access request associated with the selected PAS is prohibited from accessing the identified memory location; and

[0008] A device permission checking circuit is configured to deny the memory access request in response to device permission information defined for the requester device, the device permission information indicating that the memory access request issued by the requester device is prohibited from accessing the selected PAS.

[0009] According to a second example of the present technology, a method is provided, the method comprising:

[0010] In response to a memory access request issued by a requestor device, the memory access request specifying a memory address identifying a memory location:

[0011] selecting, based on a current operating domain of the requestor device, a physical address space PAS of a plurality of physical address spaces PAS to be associated with the memory access request;

[0012] Determine whether to deny the memory access request based on the selected PAS,

[0013] These include:

[0014] denying the memory access request in response to address space permission information defined for the identified memory location, the address space permission information indicating that the memory access request associated with the selected PAS is prohibited from accessing the identified memory location; and

[0015] The memory access request is denied in response to device permission information defined for the requestor device, the device permission information indicating that the memory access request issued by the requestor device is prohibited from accessing the selected PAS.

[0016] According to a third example of the present technology, there is provided a computer program, the computer program including instructions that, when executed by a host data processing device, control the host data processing device to provide an instruction execution environment for executing target program code, the computer program including:

[0017] PAS selector logic responsive to a memory access request issued by a requestor to select one of a plurality of physical address spaces (PASs) to be associated with the memory access request based on a current operating domain of the requestor, the memory access request specifying a memory address identifying a memory location; and

[0018] access control program logic that responds to a memory access request to determine whether to deny the memory access request based on the selected PAS,

[0019] The access control program logic includes:

[0020] PAS checker logic to deny a memory access request in response to address space permission information defined for the identified memory location, the address space permission information indicating that the memory access request associated with the selected PAS is prohibited from accessing the identified memory location; and

[0021] Device permission checker logic is configured to deny the memory access request in response to device permission information defined for the requester, the device permission information indicating that the memory access request issued by the requester is prohibited from accessing the selected PAS.

[0022] According to a third example of the present technology, there is provided a computer-readable storage medium for storing the above-mentioned computer program. The computer-readable storage medium may be transient or non-transitory.

[0023] Additional aspects, features, and advantages of the present technology will be apparent from the following description of examples read in conjunction with the accompanying drawings, in which:

[0024] Figure 1An example of a data processing apparatus is illustrated;

[0025] Figure 2 illustrates a plurality of domains in which processing circuitry may operate;

[0026] Figure 3 An example of a processing system that supports particle protection lookup is illustrated;

[0027] Figure 4 schematically illustrates aliasing of multiple physical address spaces onto a system physical address space identifying locations in a memory system;

[0028] Figure 5 An example of partitioning the effective hardware physical address space so that different architectural physical address spaces have access to corresponding portions of the system physical address space is illustrated;

[0029] Figure 6 is a flow chart illustrating a method of determining a current operating domain of a processing circuit;

[0030] Figure 7 An example of a page table entry format for a page table entry used to translate a virtual address into a physical address is shown;

[0031] Figure 8 is a flow chart illustrating a method of selecting a physical address space to be accessed by a given memory access request;

[0032] Figure 9 An example of an access control circuit is illustrated;

[0033] Figure 10 An example of a system register is illustrated;

[0034] Figure 11 Another example of a data processing apparatus is illustrated;

[0035] Figure 12 Another example of a data processing apparatus is illustrated;

[0036] Figure 13 is a flow chart illustrating an example method for checking whether a memory access request is denied; and

[0037] Figure 14 An example of a simulator that can be used is shown.

[0038] The following description of example implementations and associated advantages is provided before discussing example implementations with reference to the accompanying drawings.

[0039] 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 access permission information that controls whether a given software process executing on the processing circuitry is permitted to access a particular virtual address.

[0040] In some processing systems, address translation circuitry can map all virtual addresses to a single physical address space, which the memory system uses to identify locations in memory to be accessed. In such systems, control over whether a particular software process can access a particular address is provided solely based on a page table structure that provides a virtual-to-physical address translation mapping. However, such page table structures are typically defined by an operating system and / or a hypervisor. If the operating system or hypervisor is compromised, this can lead to security vulnerabilities, in which case sensitive information can be accessed by an attacker.

[0041] Therefore, for some systems that require certain processes to be securely executed in isolation from other processes, the system may support operations in multiple domains and may support multiple different physical address spaces, wherein, for at least some components of the memory system, memory access requests whose virtual addresses are translated into physical addresses in different physical address spaces are treated as if they were accessing completely separate addresses in memory, even if the physical addresses in the respective physical address spaces actually correspond to the same location in memory. By isolating accesses from different operating domains of processing circuitry into respective different physical address spaces viewed by some memory system components, this may provide stronger security guarantees that are independent of page table permission information set by an operating system or hypervisor.

[0042] Note that in the present technology, it is not necessary to provide virtual to physical address translation. However, it should be noted that where this is provided, a plurality of different physical address spaces is different from the plurality of virtual address spaces that can be provided.

[0043] According to the present technology, an apparatus is provided with a PAS selection circuit that is responsive to a memory access request issued by a requestor device to select one of a plurality of physical address spaces (PASs) 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.

[0044] For example, the memory address specified by the memory access request may be a memory address in the input address space (e.g., a virtual address in a virtual address space, or an intermediate address representing an intermediate stage in the conversion of a virtual address to a physical address), and thus the memory location may be identified by converting the memory address to 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, and the system PAS is then mapped to the aforementioned multiple PASs).

[0045] The apparatus of the present technology supports the use of multiple PASs, for example, a requester device can operate in any of a plurality of operating domains (e.g., execute instructions and / or perform data processing), and a separate PAS can be defined for each operating domain. Thus, a memory access request issued by a requester device (which can be an internal processing element forming part of the apparatus, or an external / peripheral device) can be assigned to a particular PAS based on the current operating domain of the requester device (e.g., the operating domain of the requester device when the memory access request is issued). The PAS selection circuit is responsible for selecting the PAS to be associated with a given memory access request. As discussed above, providing multiple different PASs can provide isolation between memory accesses from different operating domains.

[0046] The apparatus of the present technology also includes an access control circuit that responds to the memory access request to determine whether to deny the memory access request based on the selected PAS. The access control circuit can perform any number of checks to determine whether the memory access request should be denied (as opposed to, for example, passing the memory access request to another component downstream of the access control circuit (e.g., logically closer to the memory system)). In the present technology, the access control circuit performs at least a PAS check based on the identified memory location and the selected PAS, and performs a device check based on the requester device and the PAS. However, it should be understood that further checks may also be performed, and therefore a memory access request that passes both checks may still be denied by the access control circuit if it fails another check.

[0047] In the present technology, the access control circuit includes: a PAS check circuit, which is used to perform a check based on the selected PAS and the identified memory location; and a device permission check circuit, which is used to perform a check based on the selected PAS and the requester device. Specifically, the PAS check circuit rejects the memory access request in response to the address space permission information defined for the identified memory location, which indicates that the memory access request associated with the selected PAS is prohibited from accessing the identified memory location. Therefore, the PAS check circuit (which may also be referred to as a "PAS filter") enforces the address space permission information, which determines which PAS is permitted to access which memory resources. It should be noted that in some examples, the address space permission information may include "granular protection information" (GPI).

[0048] The device permission check circuit rejects the memory access request in response to the device permission information defined for the requester device, which device permission information indicates that the memory access request issued by the requester device is prohibited from accessing the selected PAS. Therefore, the device permission check circuit is responsible for enforcing the device permission information that determines which devices are permitted to access which PAS. Therefore, the check performed by the device permission check circuit can depend on the identity of the device and on the selected PAS. The identity of the device can be determined in any of a variety of ways, which can depend on the type of requester device and / or how the device permission check circuit is configured. For example, if the device permission check circuit is associated with a specific requester device (for example, if the requester device is separated from the memory system by an interconnect, the device permission check circuit can be set on the requester side of the interconnect (for example, the memory access request can be filtered by the device permission check circuit before being passed to the interconnect)), the identity of the requester device can be implicit. On the other hand, if the device permission checking circuit is associated with multiple requestor devices, it may determine the identity of the requestor device 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 circuit.

[0049] Thus, the device permission check circuitry provides an additional layer of security on top of the security layer provided by the PAS check circuitry and enables the isolation of memory regions from specific devices. This can be particularly useful, for example, in systems that include a secure processing element or secure device responsible for executing particularly high-security processes, such as face unlock or biometric authentication processes. The device permission check circuitry of the present technology improves the security of the apparatus by enabling the isolation of data associated with such processes from other devices, even if those devices are capable of generating requests with the same selected PAS.

[0050] As suggested above, the PAS check circuitry and the device permission check circuitry do not necessarily need to be located in the same physical location. Furthermore, the checks performed by the PAS check circuitry and the device permission check circuitry can be performed one after the other (optionally with a period of time between checks during which other operations (such as other checks) can be performed), or they can be performed in parallel. Furthermore, 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 failure of either check, which may mean that the other check is not performed).

[0051] In some examples, in response to a first memory access request issued by a requestor device and a second memory access request issued by another requestor device, the device permission checking circuit is permitted to deny the first memory access request without denying the second memory access request based 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.

[0052] If a memory access request passes the check performed by the PAS check circuitry, this does not mean that it will necessarily pass the check performed by the device permission check circuitry. Indeed, as in this example, even if the two memory access requests identify the same memory location and are associated with the same PAS, the device permission check circuitry may deny one of the memory access requests without denying the other memory access request (e.g., even if both memory access requests pass the check performed by the PAS check circuitry). For example, the first memory access request and the second memory access request may have been issued (respectively) by first and second requester devices that are different from each other, where the first requester device is permitted to access a selected PAS, while the second requester device is prohibited from accessing the selected PAS.

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

[0054] 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 having 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.

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

[0056] 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; thus, from the perspective of the requestor device, the value effectively disables the PAS—thus, the value may be considered a "PAS disabled" (PASD) value. For example, at least one data structure may maintain a value corresponding to each available PAS, e.g., a separate field or entry may be provided for each PAS. However, it is noted that there may not necessarily be a value maintained for each available PAS, e.g., in the particular example where the available PASs include a root PAS (e.g., a PAS accessible to code responsible for managing switching between different operating domains), there may not be any values ​​maintained in the at least one data structure corresponding to the root PAS. This may be because the root PAS is typically already accessible only to the most trusted processes, so the additional protection provided by the PASD value may not be necessary.

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

[0058] This can ensure that the device permission information recorded in the at least one data structure cannot be modified by untrusted software (eg, software operating at an exception level with lower privileges than a threshold exception level), which further improves the security of the system.

[0059] In some examples, the threshold exception level comprises a highest privilege exception level.

[0060] Thus, in this example, only the most trusted processes (eg, those processes permitted to operate at the highest privileged exception level) are allowed to modify the device permission information maintained in the at least one data structure. This even further increases the security of the system.

[0061] 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 requester device is an external device and the device permission check circuit is located in the 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 within the STE.

[0062] Furthermore, the flow table may not be the only table that describes the device configuration or access permissions (including the device permission information described herein) for 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 at least one data structure.

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

[0064] The inventors of the present technology recognized that, in some cases, it may be beneficial to prevent even the most trusted processes from modifying device permission information maintained in at least one system register. Accordingly, in this example, a register lock value (also referred to herein as a "write ignore" value) is defined that, when set to a given value, indicates that any write request targeting a system register, or when set 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 permitted (subject to any other restrictions that may exist, for example, depending on the current exception level). However, it will be understood that the assignment of "1" or "0" to indicate that a write should be ignored or should not be ignored is arbitrary, and may alternatively be a value of "0" indicating that a write should be ignored. Furthermore, in some specific examples, there may be a separate lock value defined for each of the at least one system registers (e.g., in a separate field of a control register). Additionally, while in some examples, the control register that holds the register lock value may be separate from the system register, in other examples, at least one control register may be the same as the system register. In such examples, the register lock value may actually be a value held in a given field of the system register itself.

[0065] In addition, the register lock values ​​described herein can 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 can hold a register lock value corresponding to any specified register in the system.

[0066] In some examples, the apparatus is prevented from clearing the register lock value after the register lock value is set unless the requestor device is reset.

[0067] Thus, the register lock value can be "sticky". This increases security by making it more difficult to clear the register lock value and, therefore, re-enable the corresponding PAS of the requester device. Note that the apparatus is permitted to set the register lock value (e.g., the value is not "sticky" unless it is set); 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 for at least one system register.

[0068] In some examples, the apparatus includes address translation circuitry that is responsive to a memory access request to translate a memory address specified by the memory access request into a physical address in a selected PAS associated with the memory access request.

[0069] 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 process can improve security by providing a further level of isolation between processes.

[0070] In some examples, the address translation circuitry includes a PAS selection circuitry.

[0071] Thus, in this example, selection of a PAS is performed when converting a memory address to a physical address. In a specific example, this may involve associating a PAS identifier with a memory access request.

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

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

[0074] In some examples, the address translation circuitry includes at least one of:

[0075] - a memory management unit (MMU) associated with at least one processing element; and

[0076] - A system MMU (SMMU) associated with at least one external device.

[0077] An MMU is a specific example of an address translation circuit and may also be responsible for enforcing at least some memory access permissions (e.g., access permissions defined in a page table, which may or may not include address space permission information). A specific example of an MMU is an SMMU, which provides the functionality of an MMU for memory access requests received from one or more external devices. In this example of the present technology, the device may include one or both of an MMU and an SMMU, each of which may provide the functionality of the PAS selection circuit described above.

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

[0079] 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. Note that the apparatus may be adapted to receive memory access requests from a plurality of requestor devices (e.g., the requestor device may be one of a plurality of requestor devices), which may include both PEs and external devices.

[0080] In some examples, the PAS checking circuit is configured to identify the address space permission information based on permission information defined in a table entry of a table in the memory, wherein the permission information defines which of the plurality of PASs is an allowed PAS for the identified memory location.

[0081] For example, this can be a different table than the page table discussed above and can be referred to as a "granular protection table" (GPT). The GPT can hold information (referred to as "granular protection information" (GPI)) that indicates, for a given memory location, which PASs are permitted to access the memory location. 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 the memory location).

[0082] In some examples, the apparatus includes at least one pre-PoPA memory system component disposed upstream of a physical point of alias (PoPA) to treat alias physical addresses corresponding to the same memory system resource from different PASs as corresponding to different memory system resources.

[0083] A memory system may include a point of physical alias (PoPA), which is a point that maps alias physical addresses corresponding to the same memory system resource from different physical address spaces 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 that treats the alias physical addresses as if they correspond to different memory system resources.

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

[0085] Regardless of the form factor of pre-PoPA memory system components, it is useful for such pre-PoPA memory system components to treat aliased physical addresses as if they correspond to different memory system resources because this provides hardware-enforced separation between accesses issued to different physical address spaces so that information associated with one domain cannot leak into another domain through features such as cache timing side channels or side channels involving coherency changes triggered by coherency control circuitry.

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

[0087] In some implementations, aliased physical addresses in different physical address spaces may be represented using different digital physical address values ​​for each different physical address space. This approach may require a mapping table to determine at the PoPA which of the different physical address values ​​corresponds to the same memory system resource. However, the overhead of maintaining such a mapping table may be deemed unnecessary, and therefore in some implementations it may be simpler if the aliased physical address comprises a physical address represented using the same digital physical address value in each of the different physical address spaces. If this approach is adopted, then at the physical aliasing point, it is sufficient to simply discard the physical address space identifier that identifies which physical address space is being accessed using the memory access, and then provide the remaining physical address bits downstream as the de-aliased physical address.

[0088] 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 a plurality of alias physical addresses to obtain a de-aliased physical address to be provided to at least one downstream memory system component. The PoPA memory system component may be a device that accesses a mapping table to locate a de-aliased address corresponding to an alias address in a particular address space, as described above. However, the PoPA component may simply be a location in the memory system where the physical address tag associated with a given memory access is discarded, such that a physical address provided downstream uniquely identifies the corresponding memory system resource, regardless of which physical address space it is provided from. Alternatively, in some cases, the PoPA memory system component may still provide the physical address space tag to at least one downstream memory system component (e.g., to implement completer-side filtering as discussed further below), but the PoPA may mark a point within the memory system beyond which the downstream memory system component no longer considers the aliased physical addresses as distinct memory system resources, but instead considers each of the aliased physical addresses to map to the same memory system resource. For example, if a memory controller or hardware memory storage device downstream of the PoPA receives a physical address tag and physical address for a given memory access request, then if the physical address corresponds to the same physical address as a previously seen transaction, then any hazard checking or performance improvement performed on transactions accessing the same physical address (such as coalescing accesses to the same address) may be applied even if the transactions specify different physical address space tags. In contrast, for memory system components upstream of the PoPA, such hazard checking or performance improvement steps may not be invoked for transactions accessing the same physical address if they specify the same physical address in different physical address spaces.

[0089] The techniques discussed above may be implemented in a hardware device having circuit hardware implementing the PAS selection circuitry and access control circuitry described above.

[0090] However, in another example, the same technique can be implemented in a computer program (e.g., an architecture simulator or model) that can be provided to control a host data processing device to provide an instruction execution environment for executing instructions from the target code. The computer program can include PAS selector logic for selecting a PAS to be associated with a memory access request, whereby the PAS selector logic emulates the functionality of a PAS selector circuit. The computer program can also include PAS checker logic and device permission checker logic to emulate the functionality of a PAS checker circuit and a device permission checker circuit, respectively. The PAS checker logic and the device permission checker logic can be considered together as part of the access control program logic.

[0091] In a specific example, the program may also include register maintenance program logic that maintains a data structure (in the memory or architecture registers of the host device) representing the architecture registers of the instruction set architecture simulated by the (simulation) program. The simulated registers may include at least one system register and / or at least one control register described in some examples above. Therefore, such a simulator computer program can present an instruction execution environment similar to the instruction environment provided by an actual hardware device that can directly execute the target instruction set for the target code executed on the simulator computer program, even if there may not be any actual hardware that provides these features in the host computer that executes the simulator program. This may be useful for executing code written for an instruction set architecture on a host platform that does not actually support the architecture. During the development of software for a new version of an instruction set architecture, when software development is performed in parallel with the development of hardware devices that support the new architecture, the simulator can also be useful. This can allow software to be developed and tested on the simulator so that software development can begin before hardware devices that support the new architecture are available.

[0092] The concepts described herein may be embodied in computer-readable code for fabricating devices embodying the described concepts. For example, the computer-readable code may be used at one or more stages of the semiconductor design and fabrication process, including the electronic design automation (EDA) stage, to fabricate integrated circuits that include devices embodying these concepts. The computer-readable code may additionally or alternatively enable the definition, modeling, simulation, verification, and / or testing of devices embodying the concepts described herein.

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

[0094] Additionally or alternatively, the computer-readable code may embody a computer-readable representation of one or more netlists. The one or more netlists may be generated by applying one or more logic synthesis processes to the RTL representation. Alternatively or additionally, the one or more logic synthesis processes may generate a bitstream from the computer-readable code to be loaded into a field programmable gate array (FPGA) to configure the FPGA to embody the described concepts. The FPGA may be deployed for the purpose of validating and testing concepts prior to manufacturing integrated circuits, or the FPGA may be deployed directly in a product.

[0095] The computer-readable code may include a mixture of code representations for fabricating a device, including, for example, a mixture of one or more of an RTL representation, a netlist representation, or another computer-readable definition for fabricating a device embodying the invention during semiconductor design and fabrication. Alternatively or additionally, concepts may be defined in a combination of a computer-readable definition for fabricating a device during semiconductor design and fabrication and computer-readable code defining instructions to be executed by the defined device once fabricated.

[0096] Such computer readable code may be provided in any known transient computer readable medium (such as wired or wireless transmission of the code over a network) or non-transitory computer readable medium such as a semiconductor, magnetic disk, or optical disk. An integrated circuit fabricated using the computer readable code may include components such as one or more of the following: a central processing unit, a graphics processing unit, a neural processing unit, a digital signal processor, or other components embodying the concepts herein, either individually or collectively.

[0097] Specific embodiments will now be described with reference to the accompanying drawings.

[0098] Control software access to physical address space

[0099] Figure 1Schematically illustrates an example of a data processing system 2 having at least one requester device 4 and at least one completer device 6. An interconnect 8 provides communication between the requester device 4 and the completer device 6. The requester device is capable of issuing memory access requests requesting memory access to a specific addressable memory system location. The completer device 6 is the device responsible for servicing the memory access requests directed to it. Although Figure 1 Requester device 4 may include, for example, a processing element such as a central processing unit (CPU) or a graphics processing unit (GPU), or other master devices such as a bus master, a network interface controller, a display controller, an external device (also known as a "peripheral" or "input / output" (I / O) device), etc. The completer device may include a memory controller responsible for controlling access to corresponding memory storage units, a peripheral controller for controlling access to peripheral devices, etc. Figure 1 An exemplary configuration of one of the requester devices 4 is shown in greater detail, but it should be understood that the other requester devices 4 may have similar configurations. Alternatively, the other requester devices may have the same configurations. Figure 1 The requester device 4 shown on the left is in a different configuration.

[0100] The requester device 4 has processing circuitry 10 for performing data processing in response to instructions with reference to data stored in registers 12. Registers 12 may include general registers for storing operands and results of processed instructions, as well as control registers for storing control data to configure how the processing circuitry performs processing. 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 circuitry 10 is operating. The registers may also include additional system registers 13, which will be discussed in more detail below.

[0101] Processing circuitry 10 may be capable of issuing a memory access request that specifies a virtual address (VA) identifying an addressable location to be accessed and a domain identifier (domain ID or "security state") identifying the current domain. Address translation circuitry 16 (e.g., a memory management unit (MMU)) converts the virtual address into a physical address (PA) through one or more stages 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 to cache some of this page table information, thereby providing faster access than if the page table information had to be retrieved from memory each time an address translation was required. In this example, in addition to generating a physical address, address translation circuitry 16 also selects one of a plurality of physical address spaces associated with the physical address and outputs a physical address space (PAS) identifier identifying the selected physical address space. Thus, in this example, address translation circuitry 16 acts as a PAS selection circuit. PAS selection will be discussed in more detail below; it should be noted that in some other examples, the PAS selection circuitry may be separate from address translation circuitry 16.

[0102] The PAS filter 20 acts as a requester-side filtering circuit to check whether the physical address is allowed to be accessed within the specified physical address space identified by the PAS identifier based on the translated physical address and the PAS identifier. This lookup is based on the granular protection information stored in the granular protection table structure stored within the memory system. Similar to the caching of page table data in the TLB 18, granular protection information can be cached in the granular protection information cache 22. Although the granular protection information cache 22 is Figure 1 In the example of , PAS filter 20 is shown as a separate structure from TLB 18, but in other examples, these types of lookup caches can be combined into a single lookup cache structure so that a single lookup of an entry of the combined structure provides both page table information and granular protection information. The granular protection information defines information that limits the physical address space from which a given physical address can be accessed, and based on this lookup, PAS filter 20 determines whether to allow a memory access request to proceed to one or more caches 24 and / or interconnect 8. If the specified PAS of the memory access request is not allowed to access the specified physical address, PAS filter 20 blocks the transaction and may signal a fault.

[0103] Although Figure 1 An example of a system including multiple requester devices 4 is shown, but Figure 1 The features shown with one requestor device on the left-hand side of may also be included in systems where only one requestor device is present (such as a single-core processor).

[0104] Although Figure 1In the example shown, the address translation circuit 16 performs the selection of the PAS for a given request. However, in other examples, the address translation circuit 16 may output information for determining which PAS to select together with the PA to the PAS filter 20, and the PAS filter 20 may select the PAS and check whether access to the PA is permitted within the selected PAS. Alternatively, the PAS selection may be separated from both the address translation circuit 16 and the PAS filter 20.

[0105] The provision of the PAS filter 20 helps support systems that can operate in multiple operating domains, each operating domain being associated with its own isolated physical address space, wherein to at least a portion of the memory system (e.g., to some caches or coherency enforcement mechanisms such as snoop filters), the separate physical address spaces are treated as if they relate to completely separate sets of addresses identifying separate memory system locations, even if addresses within those address spaces actually refer to the same physical location in the memory system. This may be useful for security purposes.

[0106] Figure 2 Examples of different operating states and domains in which processing circuitry 10 may operate are shown, as well as examples of the types of software that may be executed in different exception levels and domains (it will be understood, of course, that the particular software installed on a system is selected by the parties managing the system and is not an essential feature of the hardware architecture).

[0107] The processing circuit 10 can operate at multiple 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 highest privilege level and EL0 refers to the exception level with the lowest privilege. 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 lowest 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 multiple virtualized operating systems, and the most privileged exception level EL3 is used for monitoring code that manages switching between corresponding domains and allocation of physical addresses to physical address spaces, as described later.

[0108] When exception occurs when processing software is in a specific exception level, for some types of exception, the exception to the exception level of higher (higher authority) is generated, wherein the specific exception level that will generate this exception is selected based on the attribute of the specific exception that occurs. Yet, in some cases, it is possible to generate other types of exceptions at the exception level identical with the exception level associated with the code that is processed when generating an exception. When generating an exception, the information of the state of the processor when generating this exception can be preserved, including the current exception level when for example generating this exception, so that once exception handler has been processed to process this exception, processing can just return to the previous processing and the information preserved can be used for identifying the exception level that processing should return to.

[0109] In addition to the different exception levels, the processing circuitry also supports multiple 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 will be understood that this is not intended to imply any particular level of security (or lack thereof). Instead, "non-secure" simply indicates that the non-secure domain is intended for code that is not as secure as code operating in the secure domain. The root domain 82 is selected when the processing circuitry 10 is in the highest exception level EL3. When the processing circuitry is in one of the other exception levels EL0 to EL2, the current domain is selected based on a current domain indicator 14 that indicates which of the other domains 84, 86, 88 is active. For each of the other domains 84, 86, 88, the processing circuitry may be in any of the exception levels EL0, EL1, or EL2.

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

[0111] The non-secure domain 86 may be used for conventional application-level processing and for operating system and hypervisor activities to manage 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.

[0112] The secure domain 84 enables certain system-on-chip security, media, or system services to be isolated into a physical address space separate from the physical address space used for non-secure processing. 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. In this sense, the secure domain and the non-secure domain are not equivalent. An example of a system that supports such partitioning of the secure domain 84 and the non-secure domain 86 is based on the ARM ( Limited) The secure domain may run trusted applications 36 at EL0, a trusted operating system 38 at EL1, and optionally a secure partition manager 40 at EL2, if secure partitioning is supported, which uses stage 2 page tables to support isolation between different trusted operating systems 38 executing in the secure domain 84, in a manner similar to how the hypervisor 34 may manage isolation between virtual machines or guest operating systems 32 executing in the non-secure domain 86.

[0113] Extending the system to support security domains 84 has become common in recent years because it enables a single hardware processor to support isolated secure processing, thereby avoiding the need to perform that processing on a separate hardware processor. However, as the use of security domains has become increasingly prevalent, many actual systems with such security domains now support a relatively complex hybrid service environment provided by a wide variety of different software providers within the security domain. For example, the code operating in the security domain 84 may include different pieces of software provided by (among other things): a silicon provider that manufactures integrated circuits, an original equipment manufacturer (OEM) that assembles the integrated circuits provided by the silicon provider 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 multiple different clients via the cloud.

[0114] However, it is increasingly desirable to provide a secure computing environment for parties providing user-level code (which might typically be expected to execute as an application 30 within a non-secure domain 86) that can be trusted not to leak information to other parties operating the code on the same physical platform. It may be desirable that such a secure computing environment be dynamically allocated at runtime and be authenticated and provable so that users can verify that adequate security guarantees are provided on the physical platform before trusting the device to process potentially sensitive code or data. Users of such software may not want to trust a party providing a rich operating system 32 or hypervisor 34 that might typically operate in a non-secure domain 86 (or even if such providers themselves can be trusted, users may want to protect themselves from having the operating system 32 or hypervisor 34 compromised by attackers). Additionally, while a secure domain 84 can be used for such user-provided applications that require secure processing, in practice this can create problems for users providing code that requires a secure computing environment and for providers of existing code that operates within a secure domain 84. For providers of existing code operating within security domain 84, adding arbitrary user-provided code within the security domain will increase the attack surface for potential attacks on their code, which may be undesirable, and therefore it may be strongly recommended not to allow users to add code to security domain 84. On the other hand, users providing code that requires a secure computing environment may be reluctant to trust all providers of different pieces of code operating in security domain 84 with access to their data or code, and if authentication or certification of code operating in a particular domain is required as a prerequisite for the user-provided code to perform its processing, it may be difficult to audit and certify all the different pieces of code operating in security domain 84 provided by different software providers, which may limit the opportunities for third parties to provide more secure services.

[0115] Therefore, if Figure 2 As shown, an additional domain 88 (referred to as a realm domain) is provided that can 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. Within the realm domain, the software executed may include multiple realms, each of which may be isolated from the other realms by a realm management module (RMM) 46 operating at exception level EL2. The RMM 46 may control the isolation between the respective realms 42, 44 executing the realm domain 88, for example, by defining access permissions and address mappings in page table structures, 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 realms include an application-level realm 42 executing at EL0 and an encapsulated application / operating system realm 44 executing across exception levels EL0 and EL1. It should be understood that it is not necessary to support both EL0 and EL0 / EL1 types of realms, and multiple realms of the same type may be established by the RMM 46.

[0116] Similar to the security domain 84, the domain domain 88 has its own physical address space assigned to it, but the domain domain 88 and the security domain 84 can each access the non-secure PAS associated with the non-secure domain 86, while the domain domain 88 and the security domain 84 cannot access each other's physical address space. In this sense, the domain domain is orthogonal to the security domain 84. This means that the code executing in the domain domain 88 and the security domain 84 has no dependencies on each other. The code in the domain domain only needs to trust the hardware RMM 46 and the code that switches between the management domains operating in the root domain 82, which means that attestation and authentication become more feasible. Attestation enables a given piece of software to request verification that the code installed on the device matches certain expected characteristics. This can be achieved by checking whether the hash of the program code installed on the device matches an expected value signed by a trusted party using a cryptographic protocol. The RMM 46 and monitoring code 29 can be authenticated, for example, by checking that a hash of the software matches an 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 a processor architecture that supports domain-based memory access control. This allows user-provided code 42, 44 to verify that the integrity of the domain-based architecture can be trusted before executing any secure or sensitive functions.

[0117] Thus, it can be seen that code associated with the realms 42, 44 (which was previously executed in the non-secure domain 86, as shown by the dashed lines that illustrate the gaps in the non-secure domain where these processes were previously executed) can now be moved to the realm domain, where they can have stronger security guarantees because their data and code cannot be accessed by other code operating in the non-secure domain 86. However, due to the fact that the realm domain 88 and the secure domain 84 are orthogonal and therefore cannot see each other's physical address spaces, this means that the provider of code in the realm domain does not need to trust the provider of code in the secure domain, and vice versa. The code in the realm domain can simply trust the trusted firmware that provides the monitoring code 29 for the root domain 82, as well as the RMM 46 that may be provided by the silicon provider or the provider of the instruction set architecture supported by the processor (which provider may already be inherently trusted when the code is executed on its device), so that a secure computing environment can be provided to users without the need for further trust relationships with other operating system vendors, OEMs, or cloud hosts.

[0118] This can be used for a range of applications and use cases, including, for example, mobile wallets and payment applications, anti-cheating and piracy mechanisms for games, operating system platform security enhancements, secure virtual machine hosting, confidential computing, gateway processing for connected or IoT devices. It will be appreciated that there are many other applications where users may find domain support useful.

[0119] To support the security assurances provided to the domain, the processing system may support attestation reporting capabilities where firmware images and configurations (e.g., monitoring code images and configurations or RMM code images and configurations) are measured at boot time or at runtime, and domain content and configurations are measured at runtime so that domain owners can trace relevant attestation reports back to known implementations and certifications to make trust decisions about whether to operate on the system.

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

[0121] Figure 3 Another example of a processing system 2 for supporting these techniques is schematically illustrated. Figure 1 The same components in Figure 3The address translation circuitry 16 is shown in greater detail and includes a stage 1 memory management unit 50 and a stage 2 memory management unit 52. The stage 1 MMU 50 may be responsible for translating virtual addresses into physical addresses (when the translation is triggered by EL2 or EL3 code) or into intermediate addresses (when the translation is triggered by EL0 or EL1 code in an operating state where further stage 2 translation by the stage 2 MMU 52 is required). The stage 2 MMU may translate the intermediate addresses into physical addresses. The stage 1 MMU may be based on page tables controlled by the operating system for translations initiated from EL0 or EL1, page tables controlled by the hypervisor for translations from EL2, or page tables controlled by the monitoring code 29 for translations from EL3. On the other hand, the stage 2 MMU 52 may be based on a page table structure defined by the hypervisor 34, the RMM 46, or the secure partition manager 14, depending on which domain is to be used. Splitting these translations into two stages in this way allows the operating system to manage address translations for itself and applications (assuming they are the only operating system running on the system), while the RMM 46, hypervisor 34 or SPM 40 can manage isolation between different operating systems running in the same domain.

[0122] like Figure 3 As shown, the address translation process using the address translation circuitry 16 may return a security attribute 54 that, in combination with the current exception level 15 and the current domain 14 (or security state), allows a particular physical address space (identified by a PAS identifier or "PAS TAG") to be selected in response to a given memory access request. The physical address and PAS identifier may be looked up in a granular protection table 56 that provides the granular protection information previously described. In this example, the PAS filter 20 is shown as a granular memory protection unit (GMPU), which verifies whether the physical address of the selected PAS access request is allowed and, if so, allows the transaction to pass to any cache 24 or interconnect 8 that is part of the system fabric of the memory system.

[0123] The GMPU 20 allows memory to be allocated into separate address spaces while providing strong hardware-based isolation guarantees and spatial and temporal flexibility and efficient sharing schemes in the way physical memory is allocated into these address spaces. As previously described, the execution units in this system are logically partitioned into virtual execution states (domains or "worlds"), of which there is one execution state (the root world) at the highest exception level (EL3), which is called the "root world" and manages the allocation of physical memory to these worlds.

[0124] A single system physical address space is virtualized into multiple "logical" or "architectural" physical address spaces (PAS), where each such PAS is an orthogonal address space with independent consistency properties. The system physical address is mapped to a single "logical" physical address space by extending the system physical address with a PAS tag.

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

[0126] The world uses fields in the translation table descriptor of the page table used for address translation to define the security attributes of that access (PAS tag). The hardware filter 20 has access to a table (the Granular 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 and (optionally) other granule protection attributes associated with it.

[0127] The hardware filter 20 checks the world ID and security attributes against the granule's GPI and decides whether access rights can be granted, forming a granular memory protection unit (GMPU).

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

[0129] Locating the GMPU 20 on the requester side of the system (eg, on the MMU output) rather than on the completer side permits allocating access permissions at a page granularity while allowing the interconnect 8 to continue hashing / stripping the page across multiple DRAM ports.

[0130] Transactions remain tagged with the PAS TAG as they propagate throughout the system 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 compromising security guarantees compared to slave-side filtering. Since transactions propagate throughout the system, the PAS TAG can be used as a security-in-depth mechanism for address isolation: for example, a cache can add the PAS TAG 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 resistance to side-channel attacks. The PAS TAG can also be used as a context selector for a protection engine attached to the memory controller, which encrypts data before writing it to external DRAM.

[0131] The Point of Physical 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 on the completer side of the system below the cache, where access to physical DRAM is made (using the encryption context resolved by PASTAG). Alternatively, it can be located above the cache to simplify the system implementation at the expense of reduced security.

[0132] At any point in time, the world can request to transition a page from one PAS to another. The request is made to the monitor code 29 at EL3, which checks the current state of the GPI. EL3 may only allow a specific set of transitions 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 clean transitions, the system supports a command—"data clean and invalidate to physical alias point"—that EL3 can submit before transitioning a page to a new PAS. This ensures that any residual state associated with the previous PAS is flushed from any caches upstream of the PoPA 60 (closer to the requester side than the PoPA).

[0133] Another feature that can be achieved by attaching the GMPU 20 to the master side is efficient sharing of memory between worlds. It may be desirable to grant shared access to a physical granule to a subset of N worlds, while preventing other worlds from accessing that physical granule. This can be achieved by adding "restricted sharing" semantics to the granule protection information, while forcing it to use a specific PAS tag. As an example, the GPI may indicate that a physical granule is accessible only to the "Domain World" 88 and the "Secure World" 84, while being tagged with the PAS tag of the Secure PAS 84.

[0134] An example of this is the ability to quickly change the visibility characteristics of a particular physical granule. Consider a scenario where each world is assigned a dedicated PAS accessible only to that world. For a particular granule, that world can request that it be made visible to the non-secure world at any point in time by changing its GPI from "exclusive" to "restricted shared with non-secure world" without changing the PAS association. This allows the visibility of that granule to be increased without requiring expensive cache maintenance or data copying operations.

[0135] The GMPU (20) includes a PAS check circuit and may also include a device permission check circuit.

[0136] Figure 4 The concept of aliasing on physical memory provided by the respective physical address spaces in hardware is illustrated.As previously described, each of the domains 82, 84, 86, 88 has its own respective physical address space 61 .

[0137] At the point in time when the address translation circuitry 16 generates a physical address, 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 the generation of the 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, rather than the address translation circuitry 16 performing the selection of the PAS, the address translation circuitry (e.g., an MMU) may output the physical address and information derived from the page table entry (PTE) for selecting the PAS, and the PAS filter or GMPU 20 may then use this information to select the PAS.

[0138] The selection of a PAS for a given memory access request may be limited according to the rules defined in the following table, based on the current domain that the processing circuit 10 is operating at when the memory access request is issued:

[0139] Current domain Non-safe PAS Safe PAS Field PAS Root PAS Non-safe Accessible Inaccessible Inaccessible Inaccessible Safety Accessible Accessible Inaccessible Inaccessible field Accessible Inaccessible Accessible Inaccessible root Accessible Accessible Accessible Accessible

[0140] For those domains where there are multiple physical address spaces to choose from, information from the page table entries used to provide access to the physical addresses is used to select between the available PAS options.

[0141] Thus, at the point in time that the PAS filter 20 outputs a memory access request to the system fabric 24, 8 (assuming it passes any filtering checks), the memory access request is associated with a physical address (PA) and a selected physical address space (PAS).

[0142] From the perspective of memory system components operating before the physical point of alias (PoPA) 60 (such as caches, interconnects, snoop filters, etc.), the corresponding physical address space 61 is viewed as a completely separate address range corresponding to different system locations within the memory. This means that, from the perspective of the pre-PoPA memory system components, the address range identified by the memory access request is actually four times the size of the range 62 that can be output in the address translation, because the PAS identifier is effectively viewed as additional address bits alongside the physical address itself, so that the same physical address PAx can be mapped to multiple 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 the physical hardware, but the pre-PoPA memory system components view the alias addresses 63 as separate addresses. Thus, if there is any pre-PoPA cache or snoop filter that allocates 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.

[0143] A 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 addresses 65 are provided downstream of any post-PoPA components so that the system physical address space 64, which actually identifies the memory system location, is once again the same size as the physical address range that can be output in the address translation performed on the requester side. For example, at the PoPA 60, the PAS identifier can be stripped from these addresses, and to downstream components, these addresses can simply be identified using the physical address value without specifying a PAS. Alternatively, for some situations where some completer-side filtering of memory access requests is desired, the PAS identifier can still be provided downstream of the PoPA 60, but it may not be interpreted as part of the address, so 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 provided PAS identifier can still be used to perform any completer-side security checks.

[0144] Figure 5 The following illustrates how a granule protection table 56 can be used to divide the system physical address space 64 into blocks allocated for access within a specific architectural physical address space 61. The granule protection table (GPT) 56 defines which parts 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 multiple entries corresponding to physical address granules of a certain size (e.g., a 4K page) and may define the PAS allocated to the granule, which may be selected from a non-secure domain, a secure domain, a domain domain, and a root domain. By design, if a particular granule or set of granules is allocated to a PAS associated with one of these domains, it can 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 allocated to a secure PAS (for example) cannot be accessed from within the root PAS, the root domain 82 can access the physical address granule by specifying PAS selection information in its page table to ensure that the virtual address associated with the page of the region mapped to the physically addressed memory is converted into a physical address in the secure PAS (rather than the root PAS). Thus, the sharing of data across domains (to the extent permitted by the accessibility / inaccessibility rules defined in the previously described tables) can be controlled at the point in time when a PAS is selected for a given memory access request.

[0145] However, in some implementations, in addition to allowing access to physical address granules within the allocated PAS defined by the GPT, the GPT may also use other GPT attributes to mark certain areas of the address space as shared with another address space (e.g., an address space associated with a domain of lower or orthogonal permissions that is not normally allowed to select the allocated PAS for access requests from that domain). This can facilitate temporary sharing of data without requiring a change to the allocated PAS for a given granule. For example, in Figure 5 In the example, area 70 of the domain PAS is defined in the GPT as being allocated to the domain domain and is therefore not normally 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, then normally non-secure code cannot see the data in area 70. However, if the domain temporarily wishes to share some of its data in its allocated area of ​​memory with the non-secure domain, it can request that the monitoring code 29 operating in the root domain 82 update the GPT 56 to indicate that area 70 is to be shared with the non-secure domain 86, and this can make area 70 also accessible from the non-secure domain 86. Figure 5 , without changing which domain is the assigned domain of region 70. If a domain domain has designated a region of its address space as shared with a non-secure domain, then although a memory access request 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 view the request as always being issued from the domain domain. This sharing may improve performance because the operations used to assign different domains to a particular memory region may be more performance intensive, involving a greater degree of cache / TLB invalidation and / or zeroing of data in memory or copying of data between memory regions (which may be unwarranted if the sharing is expected to be only temporary).

[0146] Figure 6 1 is a flow chart showing how to determine the current operating domain, which may be performed by processing circuitry 10 or by address translation circuitry 16 or PAS filter 20. At step 100, a determination is made as to whether the current exception level 15 is EL3, and if so, 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 within the processor's EL3 control register (since the root domain is indicated by the current exception level being EL3, it may not be necessary to have an encoding of the domain indication bit 14 corresponding to the root domain, so at least one encoding of the domain indication bits may be reserved for other purposes). The EL3 control register is writable when operating at EL3 and cannot be written from other exception levels EL2-EL0.

[0147] Figure 7 Examples of page table entry (PTE) formats that may be used for page table entries in a page table structure are shown, which are used by the address translation circuitry 16 to map a virtual address to a physical address, to map a virtual address to an intermediate address, or to map an intermediate address to a physical address (depending on whether the translation is performed in an operating state that fully requires a stage 2 translation, and if so, whether the translation is a stage 1 translation or a stage 2 translation). Generally speaking, a given page table structure may be defined as a multi-level table structure implemented as a tree of page tables, wherein a first level of the page table is identified based on a base address stored in a processor's translation table base address register, and an index within the page table that selects a particular level 1 page table entry is derived from a subset of bits of an input address for which a translation lookup is performed (the input address may be a virtual address for a stage 1 translation or an intermediate address for a stage 2 translation). A level 1 page table entry may be a "table descriptor" 110 that provides a pointer 112 to a next-level page table, from which further page table entries may then be selected based on further subsets of bits of the input address. Finally, after one or more lookups in successive levels of the page table, 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 a stage 1 translation performed in an operating state where further stage 2 translation is also being performed) or a physical address (for a stage 2 translation or a stage 1 translation when stage 2 is not required).

[0148] To support the different physical address spaces described above, the page table entry format specifies some additional state for physical address space selection 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 block of memory.

[0149] For the table descriptors 110, the PTEs used by any domain other than the non-secure domain 86 include a non-secure table indicator 124 which indicates whether the next level page table is to be accessed from the non-secure physical address space or from the physical address space of the current domain. This helps to facilitate more efficient management of page tables. Typically the page table structure used by the root domain, realm domain or security domain 24 may only need to define special page table entries for a portion of the virtual address space, and for the other portion the same page table entries used by the non-secure domain 26 may be used, so by providing the non-secure table indicator 124 this may allow higher levels of the page table structure to provide dedicated realm / security table descriptors, while at a certain point in the page table tree the root realm domain or security domain may switch to using 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 obtained from the relevant physical address space associated with the root domain, realm domain or security domain.

[0150] On the other hand, the block / page descriptors 114, 116, 118 may include physical address space selection information 126 depending on which domain they are associated with. The non-secure block / page descriptors 118 used in the non-secure domain 86 do not include any PAS selection information because the non-secure domain can only access the non-secure PAS. However, for other domains, the block / page descriptors 114, 116 include PAS selection information 126, which is used to select which PAS the input address is to be converted into. For the root domain 22, the EL3 page table entry may have PAS selection information 126, which includes at least 2 bits to indicate the PAS associated with any of the four domains 82, 84, 86, 88 as the selected PAS to which the corresponding physical address will be converted. 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 selects between the domain PAS and the non-secure PAS for the domain domain, and selects between the secure PAS and the non-secure PAS for the security domain. To improve the efficiency of circuit implementation and avoid increasing the size of page table entries, the block / page descriptor 116 can encode the PAS selection information 126 at the same position within the PTE for the domain domain and the security domain, regardless of whether the current domain is the domain domain or the security domain, so that the PAS selection bit 126 can be shared.

[0151] thereby, Figure 81 is a flow chart illustrating a method for selecting a PAS based on the current domain and information 124, 126 from the block / page PTE used to generate a physical address for a given memory access request. The PAS selection may be performed by the address translation circuit 16, or if the address translation circuit forwards the PAS selection information 126 to the PAS filter 20, the PAS selection may be performed by a combination of the address translation circuit 16 and the PAS filter 20.

[0152] exist Figure 8 At step 130 in the processing circuitry 10, the processing circuitry 10 issues a memory access request specifying a given virtual address (VA) as the target VA. At step 132, the address translation circuitry 16 looks up any page table entries (or cached information derived from such page table entries) in its TLB 18. If any required page table information is not available, the address translation circuitry 16 initiates a page table walk to memory to obtain the required PTE (potentially requiring a series of memory accesses to step through the corresponding levels of the page table structure, and / or potentially requiring multiple stages of address translation to obtain a mapping from VA to an intermediate address (IPA) and then from IPA to PA). Note that any memory access request issued by the address translation circuitry 16 in a page table walk operation may itself be subject to address translation and PAS filtering, so the request received at 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 converted to a physical address (possibly via the IPA in two stages). At step 134, the address translation circuitry 16 or the PAS filter 20 uses Figure 6 The method shown determines which domain is the current domain.

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

[0154] If the current domain is a secure domain, then at step 138 , an output PAS is selected based on the PAS selection information 126 provided in the block / page descriptor PTE providing the physical address, wherein the output PAS will be selected as a secure PAS or a non-secure PAS.

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

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

[0157] Control hardware device access to physical address space

[0158] Figure 9 An example of an access control circuit 23 is shown. The access control circuit 23 includes a PAS check circuit 20 (eg, the PAS filter discussed above) and a device permission check circuit 92. The device permission check circuit 92 is not Figure 1 Explicitly shown in , but can be combined with Figure 1 The PAS filter 20 shown is provided in parallel (e.g., it may be located at a logical location along the path taken by a memory access request between the address translation circuitry and the interconnect). Alternatively, the device permission check circuitry may be provided at a different location. The PAS check circuitry 20 is responsible for controlling access to a given memory location based on granular protection information (GPI) defined for a given physical address. The GPI for a given physical address indicates which PASs are permitted to access the given physical address (e.g., Figure 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," "realm," or "root."

[0159] However, in addition to isolating regions from software processes, it may be useful to also provide mechanisms for isolating memory regions 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 region of memory visible only to a specific requestor device, and inaccessible to any other device. For example, this may allow multiple requestor devices in a data processing system (e.g., a system on a chip (SoC)) to be effectively partitioned into subsets of the PAS described above. An example of where this may be useful is to provide a dedicated secure processing unit to perform high security processing (e.g., this may be processing involved in managing biometric or facial recognition features) - allowing such processes to be isolated from other processing elements may be particularly useful as it limits the number of other processes / devices that need to be trusted.

[0160] It can be assumed that by executing such a high-security process within a secure domain or domain domain, and storing any data or code associated with the process in the corresponding secure or domain PAS, such a high-security process can be protected. However, while this will provide some protection by isolating the high-security process from processes associated with other PASs, other processes operating in the same PAS may still be able to access the code. Therefore, providing an additional level of isolation can provide a higher level of security, which may be warranted in some cases.

[0161] It is also contemplated to execute such high security processes within the root domain. However, it is preferred to minimize the number of processes permitted to operate within the root domain in order to reserve the root domain for those processes involved in managing handoffs between other operating domains.

[0162] Therefore, the present technology isolates these high security processes using device permission check circuitry 92. The device permission check circuitry 92 checks whether the requestor device issuing the access request is permitted to access the selected PAS (the PAS selected by the PAS selection circuitry). The identity of the requestor device can be determined based on a device identifier provided with the request (for example, this may be the case if the requestor is an external device, either as part of an SMMU (discussed below) or as part of the interconnect 8). Alternatively, the device identifier can be determined based on the contents of a register or other storage structure (for example, if the device permission check circuitry 92 is shared between multiple PEs - for example, it can be on the interconnect 8), or can be implicit (for example, if the device permission check circuitry 92 is set within the requestor device itself, such as Figure 1 If the device permission check circuitry determines that the request from the identified device is not permitted to access the selected PAS, the device permission check circuitry denies the request.

[0163] It should be noted that although some figures illustrate the access control circuit 20 as a single unit, the device permission check circuit 92 and the PAS check circuit 20 can be arranged in different locations. For example, because the check performed by the device permission check circuit 92 does not require a physical address, this circuit can be arranged before the address translation circuit 16 (assuming that some alternative PAS selection circuit is arranged before the device permission check circuit 92). Alternatively, in some examples, the address translation circuit 16 may be able to obtain the PAS midway through the address translation (for example, if multi-stage address translation is implemented, in the early stages of the address translation). Therefore, in some examples, the address translation circuit 16 can pass the PAS to the device permission check circuit 92 midway through the address translation, and the device permission check circuit 92 can perform its check in parallel with the final stage of the translation performed by the address translation circuit 16.

[0164] The device permission check circuit 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. Figure 10 An example of how these access permissions may be defined is shown in .

[0165] Figure 10 An example of a system register 96 associated with a particular device and accessible by the device permission check circuitry that defines the additional suggestion-based permissions described above is shown. In some specific examples, the register 96 may be one of the registers 12 located within the requester device 4, although the register may also be located external to the requester device. Register 96 is located in Figure 7 It is referred to as the "GPC Control Register" or "GPCCR" in this example, and its contents can only be modified by a process executing at the highest exception level (e.g., EL3 in this example).

[0166] The GPPCR includes a plurality of fields, each corresponding to one of the previously discussed PASs, and each of these fields holds information that can be used to indicate whether the associated device is permitted to access the corresponding PAS. Specifically, a "SPASD" field 95 defines permission information associated with a secure (S) PAS; an "NSPASD" field 97 defines permission information associated with a less secure (NS) PAS; and an "RLPASD" field 99 defines permission information associated with a realm (RL) PAS. There are no fields provided for the root PAS.

[0167] In a specific example, each field (referred to as a "PASD" field) holds a "PAS Disable" (PASD) bit. This is a single bit ("1" or "0") that indicates whether the device is prohibited from accessing the corresponding PAS. Thus, the PASD bits define an additional set of permissions for the associated device over and above the permissions enforced by the PAS check circuitry 20 (e.g., those defined in the GPT). For example, a value of "0" may indicate that no additional permissions are defined, while a value of "1" may indicate that access to the corresponding PAS is prohibited from the associated device. For example, the value held in each PASD bit may be interpreted as follows:

[0168] RLPASD bit :

[0169] - If RLPASD=0, access to the realm PAS is allowed when selected as the selected PAS, and the GPT-based granule protection check indicates that access to the realm PAS is permitted for the target physical address.

[0170] - If RLPASD=1, any access to the realm physical address space when granular protection checking is enabled will cause a GPF (granular protection fault).

[0171] SPASD bit :

[0172] - If SPASD=0, access to the secure PAS is allowed when selected as the selected PAS, and the GPT-based granular protection check indicates that access to the secure PAS is permitted for the target physical address

[0173] - If SPASD=1, any access to secure physical address space when granular protection checking is enabled will cause a GPF.

[0174] NSPASD bit :

[0175] - If NSPASD=0, access to a non-secure (less secure) PAS is allowed when selected as the selected PAS, and the GPT-based granular protection check indicates that access to the non-secure PAS is permitted for the target physical address

[0176] - If NSPASD=1, any access to non-secure (less secure) physical address space when granular protection checking is enabled will cause a GPF.

[0177] This is also illustrated in the table below:

[0178]

[0179] It will be appreciated that the interpretation applied to the values ​​of 0b0 and 0b1 may also be reversed, such that a value of 0b1 indicates that permission is GPI dependent.

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

[0181] As another example, more than one GPCCR 96 may be provided for a given requestor device, e.g., the permissions defined in each of the PASD fields 95, 97, 99 may instead be defined in separate registers.

[0182] Furthermore, in some examples, PASD permissions can be defined in different data structures. Specifically, the SMMU can access flow table entries to determine device permission information for external devices. Since the SMMU can manage hundreds of devices, defining permissions in a table in memory may be more feasible than using the GPCCR.

[0183] It may be useful to provide a mechanism for preventing the permissions defined in any PASD field from being modified. Preventing register 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.

[0184] Figure 10 The write ignore control register 98 shown can only be edited by a process 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 GPCCR should be ignored. For example, this field can store a single bit that, when set, indicates that write requests targeting the GPCCR 96 should be ignored. An additional field 103 is also provided to indicate whether writes to other named registers should also be ignored. For example, the bits held in these fields can be interpreted as follows:

[0185] "Named register" bits 101, 103 :

[0186] -0b0: Direct writes to "named registers" (e.g., for GPCCR field 101, the "named register" is the GPCCR) are not affected by this mechanism

[0187] -0b1: Direct writes to "named registers" are ignored, and "named registers"

[0188] Not updated.

[0189] It will be appreciated that, similarly, the interpretation applied to the values ​​of 0b0 and 0b1 can be reversed, such that a value of 0b0 indicates that a write should be ignored. Furthermore, while the above example illustrates 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.

[0190] In a specific 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 a value) is ignored, while a write of 0b1 is not ignored. Subsequently, upon a reset of the data processing apparatus, the "named register" bits 101, 103 may be reset to 0.

[0191] Note that in alternative implementations, 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.

[0192] It may be useful to provide a mechanism for disabling the above features (e.g., disabling PASD and / or write-ignore features). For example, this may help provide backward compatibility. Figure 10 Also shown is a feature register 94 that includes 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 may indicate that the corresponding features are enabled, while a value of 0 may indicate that they are disabled (or vice versa).

[0193] Figure 11 Another example arrangement of a data processing apparatus 2 is schematically illustrated. The apparatus 2 comprises a plurality of requester devices 4, which in this example comprise two central processing units (CPUs) 5 and an input / output unit 7 for controlling the input or output of data to / from peripheral devices. At least some of the requester devices may have an internal data or instruction cache 21 for caching instructions or data local to the device. Other master devices, such as the input / output interface 7, may be uncached masters. Coherence between the data in the respective caches and the data accessed by the respective master devices may be provided by a coherent interconnect 9, which is a Figure 1 The coherence interconnect is managed by an example of an interconnect 8 (shown in FIG. 1 ) that tracks requests for access to data from a given address and controls snooping of data in the caches of other masters when necessary to maintain coherence. It should be understood that in other embodiments, such coherence operations may be managed in software, but a benefit of providing a hardware interconnect 9 for tracking such coherence is that programmers of software executed by the system do not need to worry about coherence.

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

[0195] Figure 12 Another example of a data processing system 2 implementing the present technology is illustrated. In this example, memory (specifically, dynamic random access memory (DRAM) 146) is logically divided into multiple PASs: a root PAS, a realm (RL) PAS, a secure (S) PAS, and a less secure (NS) PAS. A plurality of requester devices are provided, including a plurality of PEs 5 and a plurality of external devices 7. In this example, each of the PEs 5 is permitted to operate in a secure domain 84, a less secure domain 86, or a root domain 82 (the root domain is reserved for certain processes, such as Figure 2 At the same time, each of the external devices 7 is permitted to execute software in either the less secure domain 86 or the domain domain 88. Thus, in this particular example, the domain domain 88 is used exclusively by the external devices 7, and the secure domain 84 is used exclusively by the PE 5.

[0196] 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 domain 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.

[0197] exist Figure 9 Hardware-enforced security (HES) mechanisms are also implemented in the SoC, for example to protect so-called “root of trust” (RoT) services, which may include processes performed by the SRC 144.

[0198] Figure 13is a flow chart illustrating an example method according to the present technology. In the example method, in step 106, a memory access request specifying a memory address (e.g., this can be a virtual address) is received from a device labeled "Device X." In step 108, a PAS is selected to be associated with the memory address—the selection is made based on the current execution domain. In step 148, a determination is made as to whether device X is permitted to access the selected PAS. If it is determined that the device is prohibited from accessing the selected PAS, the request is denied (step 156). On the other hand, if it is not determined that the device is prohibited from accessing the selected PAS, a GPI for the specified memory address is obtained in step 150. In step 152, a determination is made as to whether the selected PAS is permitted to access the PAS assigned to the memory address according to the GPI. If access is not permitted, access is denied in step 156. On the other hand, if the GPI does not prohibit access, access is allowed (step 154).

[0199] Simulator Implementation

[0200] Figure 14 A usable simulator implementation is shown. While the previously described embodiments implement the present invention in terms of apparatus and methods for operating specific processing hardware supporting the techniques involved, an instruction execution environment according to the embodiments described herein can also be provided that is implemented using a computer program. Such computer programs are often referred to as simulators, in part because they provide a software-based implementation of a hardware architecture. Types of simulator computer programs include emulators, virtual machines, models, and binary translators, including dynamic binary translators. Typically, a simulator implementation can run on a host processor 430, which optionally runs a host operating system 420 and supports a simulator program 410. In some arrangements, multiple simulation layers can exist between the hardware and the provided instruction execution environment and / or multiple different instruction execution environments provided on the same host processor. Historically, a powerful processor was required to provide a simulator implementation that executed at a reasonable speed, but this approach may be reasonable in certain circumstances, such as when it is desirable to run code native to another processor for compatibility or reuse reasons. For example, a simulator implementation can provide additional functionality to the instruction execution environment that is not supported by the host processor hardware, or provide an instruction execution environment that is typically associated with a different hardware architecture. An overview of simulation is given in: "Some Efficient Architecture Simulation Techniques", Robert Bedichek, Winter 1990 USENIX Conference, pp. 53-63.

[0201] To the extent that embodiments have been previously described with reference to specific hardware constructs or features, in simulated embodiments, equivalent functionality may be provided by appropriate software constructs or features. For example, specific circuits may be implemented as computer program logic in simulated embodiments. Similarly, memory hardware such as registers or cache memory may be implemented as software data structures in simulated embodiments. In arrangements where one or more of the hardware elements referenced in the previously described embodiments are present on host hardware (e.g., host processor 430), some simulated embodiments may utilize host hardware, where appropriate.

[0202] The simulator program 410 may be stored on a computer-readable storage medium (which may be a non-transitory medium) and provides a program interface (an instruction execution environment) to the target code 400 (which may include an application, an operating system, and a hypervisor) that is identical to the interface of the hardware architecture modeled by the simulator program 410. Thus, the program instructions of the target code 400 may be executed from within the instruction execution environment using the simulator program 410, so that a host computer 430 that does not actually have the hardware features of the apparatus 2 discussed above can emulate those features. This is useful, for example, to allow testing of target code 400 being developed for a new version of a processor architecture before hardware devices that actually support that architecture are available, because the target code can be tested by running within a simulator that is executed on a host device that does not support that architecture.

[0203] The simulator code includes handler logic 412 that emulates the behavior of the processing circuitry 10, including, for example, 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 code in the 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 state of architectural registers defined according to the target instruction set architecture associated with the target code 400. Thus, rather than Figure 1 Instead of storing this architectural state in hardware registers 12 as in the example of FIG, it is stored in the memory of the host processor 430, where register emulation program logic 413 maps register references of instructions of the target code 400 to corresponding addresses to obtain emulated 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 previously.

[0204] The emulation code includes address translator logic 414 and filter logic 416, which emulate the functionality of the address translation circuitry 16 and the PAS filter 20, respectively, with reference to the same page table structures and GPT 56 as previously described. Thus, the address translator logic 414 translates virtual addresses specified by the target code 400 into emulated physical addresses in one of the PASs (which, from the target code's perspective, refers to physical locations in memory), but these emulated physical addresses are actually mapped into the (virtual) address space of the host processor by the address space mapper logic 415. The filter logic 416 performs a lookup of the granule protection information in the same manner as the PAS filter described above to determine whether to allow the memory access triggered by the target code to proceed.

[0205] In this application, the phrase "configured to..." is used to mean that elements of a device have a configuration that enables them to perform a defined operation. In this context, "configuration" refers to 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 elements need to be modified in any way in order to provide the defined operation.

[0206] Furthermore, the phrase "at least one of..." in this application is used to indicate any one or any combination of the following options. For example, "at least one of A; B and C" means 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).

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

Claims

1. A device, comprising: a PAS selection circuit responsive to a memory access request issued by a requestor device to select one of a plurality of physical address spaces (PASs) 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, the access control circuitry responsive to the memory access request to determine whether to deny the memory access request based on the selected PAS, wherein the access control circuitry comprises: a PAS checking circuit to deny the memory access request in response to address space permission information defined for the identified memory location, the address space permission information indicating that the memory access request associated with the selected PAS is prohibited from accessing the identified memory location; and A device permission checking circuit is configured to deny the memory access request in response to device permission information defined for the requester device, the device permission information indicating that the memory access request issued by the requester device is prohibited from accessing the selected PAS.

2. The device according to 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 circuit is permitted to deny the first memory access request based on the device permission information without denying the second memory access request, 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.

3. The device according to claim 1 or claim 2, wherein The device permission check circuit is configured to identify the device permission information based on the contents of at least one data structure accessible to the device permission check circuit.

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

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

6. The device according to claim 5, wherein The threshold exception level includes the highest authority exception level.

7. The device according to any one of claims 3 to 6, wherein 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 apparatus is inhibited from writing data to at least a portion of the system registers in response to the register lock value being set.

8. The device according to claim 7, wherein Unless the requester device is reset, the apparatus is prevented from clearing the register lock value after the register lock value is set.

9. A device according to any preceding claim, comprising Address translation circuitry is responsive to the memory access request to translate the memory address specified by the memory access request into a physical address in the selected PAS associated with the memory access request.

10. The device according to claim 9, wherein The address conversion circuit includes the PAS selection circuit.

11. The device according to claim 10, wherein The PAS selection circuit is responsive to the memory access request to select a 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.

12. The device according to any one of claims 9 to 11, wherein: The address translation circuit 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.

13. An apparatus according to any preceding claim, wherein The requester device comprises a processing element or an external device.

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

15. An apparatus according to any preceding claim, comprising: At least one pre-PoPA memory system component is disposed upstream of the physical point of alias PoPA to treat alias physical addresses corresponding to the same memory system resource from different PASs as corresponding to different memory system resources.

16. The apparatus according to claim 15, comprising: A PoPA memory system component is 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.

17. 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, based on a current operating domain of the requester device, a physical address space PAS of a plurality of physical address spaces PAS to be associated with the memory access request; determining whether to deny the memory access request based on the selected PAS, Wherein said determining comprises: denying the memory access request in response to address space permission information defined for the identified memory location, the address space permission information indicating that the memory access request associated with the selected PAS is prohibited from accessing the identified memory location; as well as The memory access request is denied in response to device permission information defined for the requester device, the device permission information indicating that memory access requests issued by the requester device are prohibited from accessing the selected PAS.

18. A computer program comprising instructions that, when executed by a host data processing device, control the host data processing device to provide an instruction execution environment for executing target program code, the computer program comprising: PAS selector logic responsive to a memory access request issued by a requestor to select one of a plurality of physical address spaces (PASs) to be associated with the memory access request based on a current operating domain of the requestor, the memory access request specifying a memory address identifying a memory location; and access control program logic responsive to the memory access request to determine whether to deny the memory access request based on the selected PAS, wherein the access control program logic comprises: PAS checker logic to deny the memory access request in response to address space permission information defined for the identified memory location, the address space permission information indicating that the memory access request associated with the selected PAS is prohibited from accessing the identified memory location; and Device permission checker logic is configured to deny the memory access request in response to device permission information defined for the requester, the device permission information indicating that the memory access request issued by the requester is prohibited from accessing the selected PAS.

19. A computer-readable storage medium for storing the computer program according to claim 18.

20. A computer-readable medium for storing computer-readable code for manufacturing the apparatus according to any one of claims 1 to 16.

Images