Determining whether to reject a memory access request issued by a requesting device.

Abstract

The device comprises a PAS selection circuit (16) and an access control circuit (23). The PAS selection circuit, in response to a memory access request issued by a requester device, which specifies a memory address identifying a memory location, selects one of a plurality of physical address spaces (PAS) associated with the memory access request based on the current operating area of ​​the requester device. The access control circuit comprises a PAS check circuit (20) for rejecting a memory access request in response to address space authorization information defined for the identified memory location indicating that the memory access request associated with the selected PAS is prohibited from accessing the identified memory location, and a device authorization check circuit (92) for rejecting a memory access request in response to device authorization information defined for the requester device indicating that the memory access request issued by the requester device is prohibited from accessing the selected PAS.

Description

Technical Field

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

[0002] A data processing system may have an address translation circuit for converting an address identified by a memory access request (e.g., this may be a virtual address) into a physical address corresponding to the accessed location within the memory system.

[0003] Viewed from a first example of this technology, an apparatus is provided, and this apparatus a PAS selection circuit that, in response to a memory access request issued by a requester device, designating a memory address that identifies a memory location, selects one of a plurality of physical address spaces (PAS) associated with the memory access request based on the current operating area of the requester device; an access control circuit that, in response to the memory access request, determines whether the memory access request should be rejected based on the selected PAS, and The access control circuit a PAS check circuit for rejecting the memory access request in response to the identified address space permission information defined for the identified memory location indicating that a memory access request associated with the selected PAS is prohibited from accessing the identified memory location; a device permission check circuit for rejecting the memory access request in response to the identified device permission information defined for the requester device indicating that a memory access request issued by the requester device is prohibited from accessing the selected PAS.

[0004] Viewed from a second example of this technology, a method is provided, and this method A memory access request issued by a requester device, which specifies a memory address that identifies a memory location, in response to the memory access request, Based on the current operating region of the requester device, one of several physical address spaces (PAS) associated with the memory access request is selected, This includes determining whether to reject the memory access request based on the selected PAS, To make a determination, In response to the address space permission information defined for the identified memory location indicating that the memory access request associated with the selected PAS is prohibited from accessing the identified memory location, the memory access request is rejected. This includes rejecting a memory access request in response to device authorization information defined for the requester device indicating that the memory access request issued by the requester device is prohibited from accessing the selected PAS.

[0005] In a third example of this technology, a computer program containing instructions is provided, and when the instructions are executed by the host data processing unit, the host data processing unit controls the host data processing unit to provide an instruction execution environment for executing target program code, and the computer program is A memory access request issued by a requester, which specifies a memory address identifying a memory location, and in response to the memory access request, PAS selection program logic for selecting one of several physical address spaces (PAS) associated with the memory access request based on the requester's current operating area, Includes, in response to a memory access request, access control program logic for determining whether the memory access request should be rejected based on the selected PAS, The access control program logic is: In response to the address space permission information defined for the identified memory location indicating that the memory access request associated with the selected PAS is prohibited from accessing the identified memory location, the PAS check program logic rejects the memory access request. The system includes device authorization check program logic for rejecting a memory access request in response to device authorization information defined for the requester indicating that the memory access request issued by the requester is prohibited from accessing the selected PAS.

[0006] A third example of this technology provides a computer-readable storage medium for storing the above-mentioned computer program. The computer-readable storage medium may be temporary or non-temporary. [Brief explanation of the drawing]

[0007] Further aspects, features, and advantages of this technology will become apparent from the following example description, which should be read in conjunction with the attached drawings. [Figure 1] Let's illustrate this with an example of a data processing device. [Figure 2] Let's illustrate some of the regions in which a processing circuit can operate. [Figure 3] This section illustrates an example of a processing system that supports granule-protected lookup. [Figure 4] This paper provides a schematic example of aliasing several physical address spaces within the system's physical address space to identify locations within the memory system. [Figure 5] This example illustrates how to partition the effective hardware physical address space, thereby allowing different architectures of physical address spaces to access their respective parts of the system physical address space. [Figure 6] This flowchart illustrates a method for determining the current operating range of a processing circuit. [Figure 7]This shows an example of the page table entry format for a page table entry used to translate a virtual address to a physical address. [Figure 8] This flowchart illustrates how to select the physical address space to be accessed by a given memory access request. [Figure 9] An example of an access control circuit will be used to illustrate this point. [Figure 10] Let's illustrate this with an example of a system register. [Figure 11] Let's illustrate another example of a data processing device. [Figure 12] Further examples of data processing devices are illustrated. [Figure 13] This flowchart illustrates an exemplary method for checking whether a memory access request should be rejected. [Figure 14] Examples of simulators that may be used are shown.

[0008] Before considering exemplary implementation configurations with reference to the attached drawings, the following description of exemplary implementation configurations and their associated advantages is provided.

[0009] A data processing system may support the use of virtual memory, and an address translation circuit is provided to translate a virtual address specified by a memory access request to a physical address associated with the location in the memory system being accessed. The mapping between virtual and physical addresses may be defined by one or more page table structures. Page table entries within a page table structure may also define several access permission pieces of information that can control whether a given software process running on the processing circuit is allowed to access a particular virtual address.

[0010] In some processing systems, all virtual addresses may be mapped by address translation circuits onto a single physical address space used by the memory system to identify the location in memory being accessed. In such systems, control over whether a particular software process can access a particular address is provided solely on a page table structure used to provide virtual-to-physical address translation mappings. However, such a page table structure may typically be defined by the operating system and / or hypervisor. Unauthorized access to the operating system or hypervisor can lead to a disclosure of sensitive information, potentially making it accessible to the attacker.

[0011] Therefore, in some systems where a particular process needs to be isolated from other processes and run securely, the system may support operation in several regions and support several distinct physical address spaces, and for at least some components of the memory system, a memory access request where a virtual address is translated to a physical address in a different physical address space is treated as if it were accessing a completely different address in memory, even if the physical addresses in each physical address space actually correspond to the same location in memory. By isolating access to each distinct physical address space from different operating regions of the processing circuitry, as seen in some memory system components, a stronger security guarantee can be provided that does not rely on page table authorization information set by the operating system or hypervisor.

[0012] Note that providing translation from virtual addresses to physical addresses is not mandatory in this technology. However, if this translation is provided, note that multiple different physical address spaces will be different from the multiple virtual address spaces that may be provided.

[0013] According to this technology, the apparatus is provided with a PAS selection circuit that responds to a memory access request issued by a requester device. The memory access request specifies a memory address that identifies a memory location and selects one of a plurality of physical address spaces (PASs) associated with the memory access request based on the current operating region of the requester device.

[0014] For example, the memory address specified by the memory access request can be a memory address within an input address space (e.g., a virtual address within 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 can be identified by converting the memory address to a physical address. Alternatively, the memory address can be a physical address within a system physical address space (e.g., the apparatus can provide a single "system" physical address space in which each memory location is mapped to a single memory system resource, and this system PAS is then mapped onto the plurality of PASs described above).

[0015] The apparatus of this technology supports the use of a plurality of PASs. For example, the requester device can operate in any of several operating regions (e.g., execute instructions and / or perform data processing), and for each operating region, a separate PAS can be defined. 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 specific PAS depending on the current operating region of the requester device (e.g., the operating region of the requester device at the time the memory access request is issued). The PAS selection circuit is responsible for selecting the PAS associated with a given memory access request. As discussed above, providing a plurality of separate PASs can provide isolation between memory accesses from different operating regions.

[0016] The apparatus of the present technology also includes an access control circuit for determining whether to reject a memory access request based on the selected PAS in response to a memory access request. The access control circuit can perform any number of checks to determine whether the memory access request should be rejected (as opposed to being passed to another component downstream of the access control circuit (e.g., closer logically 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, additional checks may also be performed, and thus it will be understood that memory access requests that pass both of these checks may still be rejected by the access control circuit if they fail another check.

[0017] In the present technology, the access control circuit includes a PAS check circuit for performing a check based on the selected PAS and the identified memory location, and a device permission check circuit for performing a check based on the selected PAS and the requester device. In particular, the PAS check circuit rejects the memory access request in response to the address space permission information defined for the identified memory location indicating that the memory access request associated with the selected PAS is prohibited from accessing the identified memory location. Thus, the PAS check circuit (which may sometimes be referred to as a "PAS filter") implements address space permission information that determines which PASes are permitted to access which memory resources. Note that the address space permission information may include "granule protection information" (GPI) in some examples.

[0018] The device authorization check circuit rejects a memory access request in response to the device authorization information defined for the requester device indicating that the memory access request issued by the requester device is prohibited from accessing the selected PAS. Therefore, the device authorization check circuit is responsible for implementing the device authorization information that determines which devices are authorized to access which PAS. Thus, the checks performed by the device authorization check circuit may depend on the device identification information and the selected PAS. The device identification information can be determined in one of several ways, which may depend on the type of requester device and / or how the device authorization check circuit is configured. For example, if the device authorization check circuit is associated with a particular requester device (e.g., if the requester device is isolated from the memory system by an interconnect, the device authorization check circuit may be located on the requester side of the interconnect (e.g., memory access requests may be filtered by the device authorization check circuit before being passed to the interconnect)), the requester device identification information may be implicit. In contrast, if a device authorization check circuit is associated with multiple requester devices, the device authorization check circuit may determine the identification information of a requester device based on the device identifier associated with the memory access request (for example, if the requester device is an external device), or based on requester identification information held in a register or other storage circuit.

[0019] Therefore, the device authorization check circuit provides an additional layer of security on top of the security provided by the PAS check circuit, enabling the isolation of memory regions from specific devices. This can be particularly useful, for example, in systems that have a secure processing element or secure device responsible for performing particularly high-security processes, which may include, for example, facial unlocking or biometric authentication processes. The device authorization check circuit of this technology improves the security of the device by enabling the isolation of data associated with such processes from other devices, even if those devices can generate requests with the same selected PAS.

[0020] As suggested above, the PAS check circuit and the device authorization check circuit do not necessarily have to be located in the same physical location. Furthermore, the checks performed by the PAS check circuit and the device authorization check circuit may be performed alternately (optionally, with a time interval between the two checks during which other operations (such as other checks) may be performed) or in parallel. In addition, if a memory access request is rejected as a result of one check, other checks may not be performed (for example, a memory access request may be rejected in response to a failure in any one of the checks, which may mean that other checks are not performed).

[0021] In some examples, a device authorization check circuit is authorized to reject a first memory access request issued by a requester device and a second memory access request issued by a further requester device, where the first and second memory access requests are associated with the same selected PAS and identify the same memory location, and in response to the first and second memory access requests, it is authorized to reject the first memory access request without rejecting the second memory access request, depending on the device authorization information.

[0022] If a memory access request passes the check performed by the PAS check circuit, this does not necessarily mean that the memory access request will pass the check performed by the device authorization check circuit. In fact, even if two memory access requests identify the same memory location and are associated with the same PAS, as in this example, the device authorization check circuit may reject one of the memory access requests while not rejecting the other (for example, even if both pass the check performed by the PAS check circuit). For example, the first and second memory access requests may be issued by two different requester devices, in which case the first requester device may be authorized to access the selected PAS, while the second requester device may be denied access to the selected PAS.

[0023] In some examples, a device authorization check circuit is configured to identify device authorization information by relying on the contents of at least one data structure accessible to the device authorization check circuit.

[0024] For example, a device authorization check circuit may, in response to a memory access request, read the contents of at least one data structure (for example, there may be at least one data structure for each requester device, or a single data structure having at least one entry or field corresponding to each of multiple requester devices) to determine device authorization information.

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

[0026] In this way, a single value held in at least one data structure can be set to prevent a requester device from accessing a given PAS, and this value effectively disables the PAS from the requester device's perspective, and therefore the value can be inverted as a "PAS disable" (PASD) value. For example, at least one data structure may hold a value corresponding to each available PAS, e.g., a separate field or entry may be provided for each PAS. However, it should be noted that there is not necessarily a value held for all available PAS, for example, in a particular example where the available PAS includes a root PAS (e.g., a PAS that has access to the code responsible for managing switching between different operating regions), there may not be a value held in at least one data structure corresponding to the root PAS. This may be because the root PAS is already, typically, accessible only to the most trusted processes, and therefore the additional protection provided by the PASD value may not be necessary.

[0027] In some cases, a device is prohibited from writing data to at least one data structure in response to an instruction executed at an exception level with privileges lower than a threshold exception level.

[0028] This ensures that device authorization information recorded in at least one data structure cannot be modified by untrusted software (for example, software operating at an exception level with privileges lower than the threshold exception level). This further improves the security of the system.

[0029] In some examples, the threshold exception level includes the most privileged exception level.

[0030] Therefore, in this example, only the most trusted process (for example, a process permitted to operate at the highest privilege level) is allowed to modify device authorization information held in at least one data structure. This further improves the system's security.

[0031] At least one data structure may, in some examples, include at least one system register, but it may also (or instead) include another type of data structure. In a specific example, if the requester device is an external device and the device authorization check circuit is located within a system memory management unit (SMMU), the device authorization information state for each device may come from a Stream Table Entry (STE). For example, each data flow through the SMMU may be called a stream, a single stream may be shared by two or more devices, and / or a single device may have multiple streams. Therefore, device authorization information may be represented within an STE.

[0032] Furthermore, the stream table may not be the only table describing 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 the same information as the SMMU and be used by devices with different configurations. Thus, these other data structures may also function as at least one data structure.

[0033] In some examples, at least one data structure includes system registers, and the device is prohibited from writing data to at least a portion of the system registers in response to a register lockdown value being set, in response to a register lockdown value being held in at least one control register.

[0034] The inventors of this technology have recognized that in some cases it may be beneficial to prevent even the most reliable processes from modifying device authorization information held in at least one system register. Therefore, in this example, a register lockdown value (also referred to herein as the “write ignore” value) is defined, which, when set to a given value, indicates that any write request targeting a system register, or an identified portion of a system register, should be ignored. For example, this value may include a single bit, 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 be in place, e.g., depending on the current exception level). However, it will be understood that the assignment of “1” or “0” to indicate whether a write should be ignored or not is arbitrary, and instead, the value could be “0” to indicate that the write should be ignored. Furthermore, in some specific examples, there may be separate lockdown values ​​defined for each of at least one system register (e.g., in separate fields of a control register). Furthermore, the control registers that hold the register lockdown values ​​may, in some examples, be separate from the system registers, while in others, at least one of the control registers may be the same as the system registers. In such examples, the register lockdown values ​​may actually be values ​​held in a given field of the system register itself.

[0035] Furthermore, the register lockdown values ​​described herein can also be used to protect other registers within the device (e.g., not just system registers responsible for storing device authorization information). For example, a control register may hold a register lockdown value corresponding to any designated register in the system.

[0036] In some cases, the device is prevented from clearing the register lockdown value after it has been set, unless the requester device is reset.

[0037] Therefore, register lockdown values ​​can be "sticky." This improves security by making it more difficult to clear the register lockdown value, and thus re-enable the corresponding PAS for the requester device. Note that the device is permitted to set the register lockdown value (for example, the value is not "sticky" unless set). It will be understood that the level of security associated with setting the register lockdown value does not necessarily have to be the same as the level of security associated with clearing the register lockdown value, since setting the value only increases the level of protection provided to at least one system register.

[0038] In some examples, the device includes an address translation circuit for, in response to a memory access request, translating the memory address specified by the memory access request to a physical address in the selected PAS associated with the memory access request.

[0039] In this example, the memory address resides in an input address space distinct from the selected physical address space, and therefore, an address translation circuit is provided to translate the memory address to a physical address within the selected PAS. In 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.

[0040] In some examples, the address translation circuit includes a PAS selection circuit.

[0041] Therefore, in this example, the selection of the PAS is performed when translating a memory address to a physical address. In certain examples, this may involve associating a PAS identifier with a memory access request.

[0042] In some examples, the PAS selection circuit, in response to a memory access request, selects a PAS to associate with the memory access request based on information defined in the page table entry for the memory address specified by the memory access request.

[0043] In this example, the address translation circuit translates memory addresses to physical addresses using address translation information defined in a page table (which may be stored in memory, and some of the information from the page table may be optionally cached in a translation lookaside buffer, for example). The page table entry corresponding to a memory address provides the translated PAS, and in this example, also provides information to be used when selecting the PAS associated with the memory access request. Any such information defined in the page table entry is used in combination with the identifier of the current operating region to select the PAS.

[0044] In some examples, the address translation circuit is, A memory management unit (MMU) associated with at least one processing element, and It comprises at least one system MMU (SMMU), which is associated with at least one external device.

[0045] The MMU is a specific example of an address translation circuit and may also be responsible for implementing 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 the MMU for memory access requests received from one or more external devices. In this example of the technology, the device may comprise either or both an MMU and an SMMU, each of which may provide the functionality of the PAS selection circuit described above.

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

[0047] Therefore, the requester device can be a processing element (PE) such as a central processing unit (CPU), a graphics processing unit (GPU), or a neural processing unit (NPU), or it can be some external (e.g., peripheral or I / O) device. Note that the device can be adapted to receive memory access requests from multiple requester devices (for example, a requester device may be one of multiple requester devices) which may include both PEs and external devices.

[0048] In some examples, the PAS check circuit is configured to identify address space permission information based on permission information defined in a table entry of a table in memory, where permission information defines which of several PAS is permitted for the identified memory location.

[0049] For example, this could be a different table from the page table discussed above and could be called a "Granule Protection Table" (GPT). This GPT may hold information (called "Granule Protection Information" (GPI)) indicating which PAS are permitted to access a given memory location. Therefore, the PAS check circuit in this example uses the GPI to determine whether to reject the memory access request (for example, because the GPI does not identify the selected PAS as an permitted PAS for the memory location).

[0050] In some examples, the device includes at least one pre-PoPA memory system component located upstream of a physical aliasing point (PoPA) for treating aliased physical addresses from different PASs corresponding to the same memory system resource as if the aliased physical addresses corresponded to different memory system resources.

[0051] A memory system may include physical aliasing points (PoPAs), which are points where aliased physical addresses from different physical address spaces corresponding to the same memory system resource are mapped to a single physical address that uniquely identifies that memory system resource. The memory system may also include at least one pre-PoPA memory system component located upstream of the PoPA, which treats the aliased physical addresses as if they corresponded to different memory system resources.

[0052] For example, at least one pre-PoPA memory system component may include a cache or translation lookaside buffer, which can cache data, program code, or address translation information for aliased physical addresses in separate entries. Therefore, when the same memory system resource is requested to be accessed from a different physical address space, the access will allocate a separate cache or TLB entry. Furthermore, the pre-PoPA memory system component may include a coherence control circuit, such as a coherent interconnect, a snoop filter, or other mechanism for maintaining coherence between cached information in the respective master devices. The coherence control circuit can assign a separate coherence state to each aliased physical address in a different physical address space. Thus, aliased physical addresses are treated as separate addresses for the purpose of maintaining coherence, even if they actually correspond to the same underlying memory system resource. At first glance, it might seem that tracking coherency separately for aliased physical addresses could lead to coherency loss issues. However, this is not actually a problem because processes operating in different regions can access a particular memory system resource using less secure physical addresses (or using the limited sharing feature described below to access the resource using one of the other physical address spaces) if they are intended to actually share access to that resource. Another example of a pre-PoPA memory system component could be a memory protection engine provided to protect data stored in off-chip memory from loss of confidentiality and / or tampering. Such a memory protection engine could, for example, treat aliased physical addresses as if they corresponded to effectively different memory system resources by separately encrypting the data associated with a particular memory system resource using different encryption keys depending on the physical address space from which the resource was accessed (for example, an encryption scheme that makes encryption address-dependent could be used, and the physical address space identifier could be considered part of the address for this purpose).

[0053] Regardless of the form of the pre-PoPA memory system component, it may be useful for such a pre-PoPA memory system component to treat aliased physical addresses as if they corresponded to different memory system resources, because this provides hardware-implemented isolation between accesses issued to different physical address spaces, and as a result, information associated with one region is not leaked to another region, due to features such as cache timing side channels or side channels accompanied by coherence changes triggered by coherence control circuits.

[0054] In some examples, the device includes a PoPA memory system component configured to de-aliase multiple aliased physical addresses in order to obtain an aliased physical address provided to at least one downstream memory system component.

[0055] In some implementations, aliased physical addresses in different physical address spaces may be represented using different numerical physical address values ​​for each of those different physical address spaces. This technique may require a mapping table in PoPA to determine which different physical address values ​​correspond to the same memory system resource. However, this overhead of maintaining a mapping table may be considered unnecessary, and in some implementations, it may be simpler if the aliased physical addresses include physical addresses that are represented using the same numerical physical address value in each of the different physical address spaces. When this technique is adopted, at the physical aliasing point, it may be sufficient to simply discard the physical address space identifier that identifies which physical address space is accessed using memory access, and then provide the remaining physical address bits downstream as an unaliased physical address.

[0056] Therefore, in addition to pre-PoPA memory system components, the memory system may also include a PoPA memory system component configured to de-alias multiple aliased physical addresses and obtain the de-aliased physical addresses to be provided to at least one downstream memory system component. A PoPA memory system component may be a device that accesses a mapping table to find the de-aliased addresses corresponding to aliased addresses within a particular address space, as described above. However, a PoPA component may simply be a location within the memory system where a physical address tag associated with a given memory access is discarded, and as a result, the physical address provided downstream uniquely identifies the corresponding memory system resource, regardless of which physical address space it is provided from. Alternatively, in some cases, a PoPA memory system component may still provide physical address space tags to at least one downstream memory system component (for example, for the purpose of enabling completer-side filtering as further considered below), but the PoPA marks a point within the memory system so that downstream memory system components no longer treat the aliased physical addresses as different resources and map the same memory system resource considering each of the aliased physical addresses. For example, if a memory controller or hardware memory storage device downstream of a PoPA receives a physical address tag and physical address for a given memory access request, and that physical address corresponds to the same physical address as a previously seen transaction, then any hazard checks or performance improvements that would normally be performed for each transaction accessing the same physical address (such as merging accesses to the same address) may be applied, even if each transaction specifies a different physical address space tag. In contrast, for memory system components upstream of a PoPA, such hazard checks or performance improvement steps taken for transactions accessing the same physical address may not be triggered if those transactions specify the same physical address in different physical address spaces.

[0057] The technologies discussed above can be implemented within a hardware device having circuit hardware that implements the PAS selection circuit and access control circuit described above.

[0058] However, in another embodiment, the same technique may be implemented in a computer program (e.g., an architecture simulator or model) which may be provided to control a host data processing device to provide an instruction execution environment for executing instructions from target code. The computer program may include PAS selection program logic for selecting a PAS associated with a memory access request, and thus this PAS selection program logic emulates the functionality of a PAS selection circuit. The computer program may also include PAS check program logic and device allow check program logic for emulating the functionality of a PAS check circuit and a device allow check circuit, respectively. The PAS check program logic and device allow check program logic together can be considered as part of the access control program logic.

[0059] In certain examples, a program may also include register-maintaining program logic that maintains (either in the host device's memory or within the architecture registers) data structures that represent (emulate) the architecture registers of the instruction set architecture being simulated by the program. The emulated registers may include at least one system register and / or at least one control register, as described in some of the examples above. Thus, such a simulator computer program may present a similar instruction execution environment to that provided by actual hardware capable of directly executing the target instruction set for target code running on the simulator computer program, even if no actual hardware providing these functions exists on the host computer running the simulator program. This can be useful for running code written for one instruction set architecture on a host platform that does not actually support that architecture. Simulators can also be useful during the development of software for a new version of an instruction set architecture while software development is running in parallel with the development of hardware devices that support the new architecture. This can allow software to be developed and tested on a simulator so that software development can begin before hardware devices supporting the new architecture become available.

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

[0061] For example, computer-readable code for fabricating a device that embodies a concept described herein may be embodied in code that defines a Hardware Description Language (HDL) representation of the concept. For example, the code may define a Register-Transfer-Level (RTL) abstraction of one or more logic circuits for defining a device that embodies a concept. The code may define an HDL representation of one or more logic circuits that embodies the device in Verilog, SystemVerilog, Chisel, or VHDL (Very High-Speed ​​Integrated Circuit Hardware Description Language), as well as an intermediate representation such as FIRRTL. Computer-readable code may provide a definition that embodies a concept using a system-level modeling language such as SystemC and SystemVerilog, or other behavioral representations of the concept that can be interpreted by a computer to enable simulation, functional and / or formal verification, and testing of the concept.

[0062] Additionally or alternatively, computer-readable code may embody computer-readable representations of one or more netlists. These netlists may be generated by applying one or more logic synthesis processes to the RTL representations. Alternatively or additionally, one or more logic synthesis processes may generate from the computer-readable code bitstreams to be loaded into a Field Programmable Gate Array (FPGA) to embody the described concept. The FPGA may be deployed for verification and testing purposes before fabrication in an integrated circuit, or the FPGA may be deployed directly into a product.

[0063] Computer-readable code may include, for example, a mixture of code representations for the fabrication of a device, including one or more RTL representations, netlist representations, or other computer-readable definitions used in semiconductor design and fabrication processes for fabricating a device embodying the present invention. Alternatively or additionally, the concept may be defined as a combination of computer-readable definitions used in semiconductor design and fabrication processes for fabricating a device and computer-readable code that defines instructions to be executed by the device once it is defined to be fabricated.

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

[0065] Here, a specific embodiment will be described with reference to the drawings.

[0066] Software-based control of access to the physical address space. Figure 1 schematically illustrates an example of a data processing system 2 having at least one requester device 4 and at least one completer device 6. The interconnect 8 provides communication between the requester device 4 and the completer device 6. The requester device can issue memory access requests that request memory access to a specific addressable memory system location. The completer device 6 is the device responsible for processing the memory access requests directed to it. Although not shown in Figure 1, some devices may be able to function as both a requester device and a completer device. The 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 device, a network interface controller, a display controller, or an external device (also referred to as a "peripheral" or "input / output (I / O) device"). The completer device may include a memory controller responsible for controlling access to the corresponding memory storage device, a peripheral controller for controlling access to peripheral devices, etc. Figure 1 shows in more detail one exemplary configuration of requester device 4, but it should be understood that other requester devices 4 may have a similar configuration. Alternatively, other requester devices may have a different configuration from requester device 4 shown on the left side of Figure 1.

[0067] The requester device 4 has a processing circuit 10 for performing data processing in response to an instruction by referencing data stored in register 12. Register 12 may include not only general-purpose registers for storing operands and the results of processed instructions, but also control registers for storing control data that configures how the processing is performed by the processing circuit. For example, the control data may include a current region index 14 used to select which operating region is the current region, and a current exception level index 15 indicating which exception level is the current exception level on which the processing circuit 10 is operating. The register may also include further system registers 13, which will be discussed in more detail below.

[0068] The processing circuit 10 may issue a memory access request specifying a virtual address (VA) that identifies the addressable location to be accessed, and a region identifier (region ID or "security state") that identifies the current region. The address translation circuit 16 (e.g., a memory management unit (MMU)) translates the virtual address to a physical address (PA) through one of several stages of address translation, based on page table data defined in a page table structure stored in the memory system. The translation lookaside buffer (TLB) 18 functions as a lookup cache to cache a portion of the page table information for faster access than if the page table information had to be fetched from memory each time address translation was needed. In this example, in addition to generating a physical address, the address translation circuit 16 also selects one of several physical address spaces associated with the physical address and outputs a physical address space (PAS) identifier that identifies the selected physical address space. Thus, the address translation circuit 16 in this example functions as a PAS selection circuit. The selection of the PAS will be discussed in more detail below, and it should be noted that in some other examples, the PAS selection circuit may be separate from the address translation circuit 16.

[0069] The PAS filter 20 functions as a requester filtering circuit to determine, based on the translated physical address and PAS identifier, whether the physical address is permitted to be accessed within the physical address space identified and specified by the PAS identifier. This lookup is based on granule protection information stored in a granule protection table structure stored in the memory system. Granule protection information can be cached in a granule protection information cache 22, similar to the cache of page table data in the TLB 18. In the example in Figure 1, the granule protection information cache 22 is shown as a separate structure from the TLB 18, but in other examples, these types of lookup caches can be combined as a single lookup cache structure, and as a result, a single lookup of entries in the combined structure provides both page table information and granule protection information. The granule protection information defines information that restricts the physical address space in which a given physical address can be accessed, and based on this lookup, the PAS filter 20 determines whether it is possible to proceed with issuing a memory access request to one or more caches 24 and / or interconnect 8. If the specified PAS for a memory access request is not permitted to access the specified physical address, the PAS filter 20 may block the transaction and signal the malfunction.

[0070] Figure 1 shows an example of a system having multiple requester devices 4, but the characteristics shown for the single requester device on the left side of Figure 1 can also be found in systems with only one requester device, such as a single-core processor.

[0071] Figure 1 shows an example where the PAS selection for a given request is performed by the address translation circuit 16. In other examples, the address translation circuit 16 can output information to the PAS filter 20 along with the PA to determine which PAS to select, and the PAS filter 20 can select a PAS and check whether the PA can be accessed within the selected PAS. Alternatively, the PAS selection may be independent of both the address translation circuit 16 and the PAS filter 20.

[0072] The provision of the PAS filter 20 helps support a system that can operate in multiple operating regions, each associated with its own isolated physical address space, where, for at least a portion of the memory system (for example, for some cache or snoop filter coherence enforcement mechanisms), separate physical address spaces are treated as if they pointed to a separate set of addresses identifying entirely separate memory system locations, even though the addresses within those address spaces actually point to the same physical locations within the memory system. This can be useful for security purposes.

[0073] Figure 2 shows examples of different operating states and domains in which the processing circuit 10 can operate, as well as examples of types of software that can run at different exception levels and domains (it should be understood that, naturally, the specific software installed on the system is selected by the party managing the system and is therefore not an essential feature of the hardware architecture).

[0074] The processing circuit 10 can operate with several different exception levels 80, four exception levels labeled EL0, EL1, EL2, and EL3 in this embodiment, where EL3 refers to the highest privileged exception level and EL0 refers to the lowest privileged exception level. In other architectures, it will be understood that the reverse numbering may be chosen, with the exception level having the highest number being considered to have the lowest privileges. In this embodiment, the lowest privileged exception level EL0 is for application-level code, the next highest privileged exception level EL1 is used for operating system-level code, the next highest privileged exception level EL2 is used for hypervisor-level code that manages switching between several virtual operating systems, and the highest privileged exception level EL3 is used for monitor code that manages switching between each region and the allocation of physical addresses to the physical address space, as will be described later.

[0075] When an exception occurs at a specific exception level while processing software, for some types of exceptions, the exception is accepted at a higher (more privileged) exception level, and the specific exception level to which the exception is accepted is selected based on the attributes of the specific exception that occurred. However, in some situations, other types of exceptions may be accepted at the same exception level associated with the code being processed when the exception was accepted. When an exception is accepted, information characterizing the state of the processor at the time the exception was accepted may be stored, including, for example, the current exception level at the time the exception was accepted. Therefore, when an exception handler is processed to address the exception, processing can revert to previous processing, and the stored information can be used to identify the exception level to which processing should return.

[0076] In addition to different exception levels, the processing circuit also supports several operating regions, including the root region 82, the secure (S) region 84, the less secure region 86, and the realm region 88. For ease of reference, the less secure region will be described below as the “non-secure” (NS) region, but it should be understood that this is not intended to imply a particular level (or lack thereof) of security. Instead, “non-secure” simply indicates that the non-secure region is intended for code that is less secure than the code operating in the secure region. The root region 82 is selected when the processing circuit 10 is at the highest exception level, EL3. When the processing circuit is at one of the other exception levels, EL0 through EL2, the current region is selected based on the current region indicator 14, which indicates which of the other regions 84, 86, and 88 is active. For each of the other regions 84, 86, and 88, the processing circuit can be at any of the exception levels EL0, EL1, or EL2.

[0077] During boot time, several boot codes (e.g., BL1, BL2, OEM boot) may be executed, for example, within a higher privileged exception level, such as EL3 or EL2. Boot codes BL1 and BL2 may be associated with the root area, for example, while the OEM boot code may operate in the secure area. However, once the system is booted, during execution, the processing circuit 10 can be considered to operate in one of areas 82, 84, 86, and 88 at a time. Each of areas 82-88 is associated with its own associated physical address space (PAS). This allows for isolation of data from different areas within at least a portion of the memory system. This will be explained in more detail below.

[0078] The non-secure area 86 can be used for normal application-level processing and for operating system and hypervisor activities to manage such applications. Therefore, application code 30 running in EL0, operating system (OS) code 32 running in EL1, and hypervisor code 34 running in EL2 may reside within the non-secure area 86.

[0079] The secure region 84 allows certain system-on-chip security, media, or system services to be isolated in a physical address space separate from the physical address space used for non-secure processing. The secure region and the non-secure region are not equivalent in that non-secure region code cannot access resources associated with the secure region 84, while the secure region can access both secure and non-secure resources. An example of a system that supports such partitioning of secure and non-secure regions 84, 86 is a system based on the TrustZone® architecture provided by Arm® Limited. The secure region can run trusted applications 36 in EL0, trusted operating systems 38 in EL1, and optionally a secure partition manager 40 in EL2, where EL2 can use a two-page table to support isolation between different trusted operating systems 38 running within the secure region 84 in a manner similar to how a hypervisor 34 can manage isolation between virtual machines or guest operating systems 32 running within the non-secure region 86.

[0080] Extending systems to support secure regions 84 has become common in recent years because it allows a single hardware processor to support isolated secure processing and avoids the need for processing to be performed on separate hardware processors. However, as the popularity of using secure regions increases, many practical systems with such secure regions now support a relatively high degree of mixed environments of services provided by a wide range of different software providers within the secure region. For example, the code running within the secure region 84 may contain different software, and its providers may include (among others) silicon providers that manufacture integrated circuits, original equipment manufacturers (OEMs) that assemble integrated circuits provided by silicon providers into electronic devices such as mobile phones, operating system vendors (OSVs) that provide operating systems 32 for devices, and / or cloud platform providers that manage cloud servers that support services for several different customers via the cloud.

[0081] However, there is a growing demand for a secure computing environment that provides reliable assurance that providers of user-level code (which would typically be expected to run as applications 30 in the non-secure area 86) will not leak information to other parties running their code on the same physical platform. Such a secure computing environment would ideally be dynamically allocatable during execution and guaranteed and verifiable so that users can verify that sufficient security assurances are provided on the physical platform before entrusting the processing of potentially sensitive code or data to the device. Users of such software may not want to trust providers of feature-rich operating systems 32 or hypervisors 34 that would typically run in the non-secure area 86 (or, even if the providers themselves are trustworthy, users may want to protect themselves from unauthorized access to the operating system 32 or hypervisor 34 by attackers). Furthermore, while a secure area 84 could be used for such user-provided applications requiring secure processing, in practice this poses problems for both users providing code that requires a secure computing environment and providers of existing code running within the secure area 84. For providers of existing code operating within secure area 84, the addition of arbitrary user-provided code within the secure area increases the attack surface for potential attacks against that code, which may be undesirable, and therefore they may be strongly advised not to allow users to add code to secure area 84.On the other hand, users who provide code that requires a secure computing environment may find it difficult to audit and certify all separate codes provided by different software providers operating in secure area 84, if the assurance and certification of code operating in a specific area is required as a prerequisite for the user-provided code to perform processing. They may also be reluctant to entrust access to their data or code to all providers of different codes operating in secure area 84, which could limit the opportunity for third parties to provide more secure services.

[0082] Therefore, as shown in Figure 2, an additional region 88 called the realm region is provided and can be used by user-introduced code to provide a secure computing environment orthogonal to any secure computing environment associated with components operating in the secure region 24. In the realm region, the software being executed can contain several realms, each realm can be isolated from other realms by a realm management module (RMM) 46 operating at exception level EL2. The RMM 46 can control the isolation between each realm 42, 44 running in the realm region 88 by defining access permissions and address mappings in a page table structure, for example, in the way that the hypervisor 34 manages the isolation between different components operating in the non-secure region 86. In this example, the realms include an application-level realm 42 running at EL0 and an encapsulated application / operating system realm 44 running across exception levels EL0 and EL1. It will be understood that it is not mandatory to support both EL0 and EL0 / EL1 type realms, and multiple realms of the same type can be established by the RMM 46.

[0083] Realm region 88, like secure region 84, has its own allocated physical address space, but while realm region and secure regions 88, 84 can each access the non-secure PAS associated with non-secure region 86, they are orthogonal to secure region 84 in the sense that realm region and secure regions 88, 84 cannot access each other's physical address spaces. This means that the code running in realm region 88 and secure region 84 have no dependencies on each other. Code in realm region only needs to trust the hardware, RMM46, and the code running in root region 82 which manages switching between regions, which means that proof and assurance are more feasible. Proof allows given software to require verification that the code installed on a device matches certain expected characteristics. This can be done 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. RMM46 and monitor code 29 can be verified, for example, by checking whether the hash of this software matches an expected value signed by a trusted party, such as the silicon provider that manufactured the integrated circuit including processing system 2, or the architecture provider that designed the processor architecture that supports region-based memory access control. This allows user-provided codes 42 and 44 to verify whether the integrity of the region-based architecture is trustworthy before executing any secure or confidential functions.

[0084] Therefore, as indicated by the dotted lines showing the gaps in the non-secure region where these processes would have previously been performed, the code associated with realms 42 and 44, which would have previously been running in the non-secure region 86, can now be moved to a realm region where they can have stronger security guarantees, since their data and code are no longer accessible by other code running in the non-secure region 86. However, the fact that realm region 88 and secure region 84 are orthogonal and therefore cannot see each other's physical address spaces means that providers of code in the realm region do not need to trust providers of code in the secure region, and vice versa. Code in the realm region can simply trust the firmware that provides the monitor code 29 for root region 82 and RMM46, which may be provided by a silicon provider or a provider of the instruction set architecture supported by the processor, and these providers may need to be inherently trusted from the outset when the code is running on their device, and as a result, no further trust relationships with other operating system vendors, OEMs, or cloud hosts are required by the user in order for the user to be able to provide a secure computing environment.

[0085] This is useful for a variety of applications and use cases, including, for example, mobile wallet and payment applications, anti-fraud and anti-copyright infringement mechanisms in games, operating system platform security extensions, secure virtual machine hosting, confidential computing, networking, or gateway processing for the Internet of Things. Users will understand that they may find many other applications where Realm Support is useful.

[0086] To support the security assurances provided to the Realm, the processing system may support a certification reporting function, which measures the image and configuration of the firmware, for example, the image and configuration of the monitor code or the image and configuration of the RMM code, at boot time or during execution, and measures the content and configuration of the Realm during execution, thereby allowing the Realm owner to trace back relevant certification reports against known implementations and assurances and make a confidence decision about whether it will work on that system.

[0087] As shown in Figure 2, a separate root region 82 is provided to manage region switching, and this root region has its own isolated root physical address space. Creating a root region and isolating resources from the secure region allows for a more robust implementation, even in systems that have only non-secure and secure regions 86, 84 and no realm region 88, although it can also be used in implementations that support the realm region 88. The root region 82 can be implemented using monitor software 29 provided (or guaranteed) by the silicon provider or architecture designer and can be used to provide secure boot functionality, trusted boot measurement, system-on-chip configuration, debug control, and firmware update management for firmware components provided by other parties such as the OEM. The code for the root region can be developed, guaranteed, and deployed by the silicon provider or architecture designer without any dependency on the final device. In contrast, the secure region 84 can be managed by the OEM to implement certain platform and security services. The management of the non-secure area 86 can be controlled by the operating system 32 that provides operating system services, while the realm area 88 is isolated from the existing secure software environment in the secure area 84, and at the same time, it enables the development of new forms of trusted execution environments that can be dedicated to the user or third-party applications.

[0088] Figure 3 schematically illustrates another example of processing system 2 to support these technologies. Elements that are the same as those in Figure 1 are illustrated with the same reference numbers. Figure 3 shows more detail of the address translation circuit 16, including a Stage 1 memory management unit 50 and a Stage 2 memory management unit 52. The Stage 1 MMU 50 may be responsible for translations from virtual addresses to physical addresses (when the translation is triggered by an EL2 or EL3 code) or to intermediate addresses (when the translation is triggered by an 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 intermediate addresses to physical addresses. The Stage 1 MMU may be based on a page table controlled by the operating system for translations initiated from EL0 or EL1, a page table controlled by the hypervisor for translations from EL2, or a page table controlled by monitor 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, RMM 46, or secure partition manager 14, depending on which region is being used. By separating the translation into these two stages, operating systems can manage address translation for themselves and for applications, under the assumption that they are the only operating systems running on the system, while the RMM 46, hypervisor 34, or SPM 40 can manage isolation between different operating systems running within the same region.

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

[0090] GMPU20 enables the allocation of memory to separate address spaces while simultaneously providing strong hardware-based isolation guarantees, offering not only spatial and temporal flexibility in how physical memory is allocated to these address spaces, but also an efficient sharing scheme. As previously described, execution units in the system are logically divided into virtual execution states (regions or "worlds") in which there is one execution state (root world) located at the highest exception level (EL3), referred to as the "root world," and the root world manages the allocation of physical memory to these worlds.

[0091] A single system physical address space is virtualized into multiple “logical” or “architectural” physical address spaces (PAS), each such PAS being an orthogonal address space with independent coherence attributes. System physical addresses are mapped to a single “logical” physical address space by extending it with PAS tags.

[0092] A given world is granted access to a subset of the logical-physical address space. This is accomplished by a hardware filter 20, which can be attached to the output of the memory management unit 16.

[0093] The world defines access security attributes (PAS tags) using fields in the translation table descriptor of the page table used for address translation. The hardware filter 20 has access to a table (granule protection table 56, or GPT) that defines granule protection information (GPI) for each page in the system physical address space, where the granule protection information indicates the PAS TAG to which it is associated, and (optionally) other granule protection attributes.

[0094] The hardware filter 20 checks the world ID and security attributes of the granule's GPI to determine whether access may be permitted, and thus forms a Granular Memory Protection Unit (GMPU).

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

[0096] By locating GMPU20 on the system's requester side (e.g., on the MMU output) rather than the completer side, interconnect 8 can allocate access permissions at the page granularity while allowing continuous page hashing / striping across multiple DRAM ports.

[0097] Transactions propagate throughout the entire system fabric 24,8 until they reach a location defined as a physical aliasing point 60, so the PAS TAG remains tagged. This allows filtering to be placed on the master side without weakening security guarantees compared to slave-side filtering. As transactions propagate throughout the system, the PAS TAG can be used as a detailed security mechanism for address isolation. For example, a cache can add the PAS TAG to address tags in the cache to prevent access made using the wrong PAS TAG for the same PA from hitting the cache, thereby improving side-channel resistance. The PAS TAG can also be used as a context selector for a protection engine attached to a memory controller that encrypts data before it is written to external DRAM.

[0098] A Point of Physical Aliasing (PoPA) is a location within the system where a PAS TAG is detached and the address returns from a logical physical address to a system physical address. A PoPA can be located below the cache on the system's completer side, where access to physical DRAM is performed (using the cryptographic context resolved via the PAS TAG). Alternatively, it can be located above the cache to simplify the system implementation at the expense of reduced security.

[0099] At any given time, the world can request to transition a page from one PAS to another. The request is made by EL3 to monitor code 29, which checks the current state of the GPI. EL3 may allow only a specific set of transitions to occur (e.g., from a non-secure PAS to a secure PAS, rather than from a realm PAS to a secure PAS). To provide a clean transition, the instruction "clear data and invalidate up to the physical aliasing point" is supported by the system, and EL3 can submit this before transitioning the page to the new PAS, thereby ensuring that any residual state associated with the previous PAS is flushed out of any cache upstream of PoPA60 (closer to the requester side).

[0100] Another characteristic that can be achieved by installing GMPU20 on the master side is the efficient sharing of memory between worlds. It may be desirable to allow a subset of N worlds shared access to a physical granule while preventing other worlds from accessing it. This can be achieved by adding the semantic "limited sharing" to the granule protection information and enforcing the use of a specific PAS TAG. As an example, GPI can indicate that a physical granule can only be accessed by "realm world" 88 and "secure world" 84 while it is tagged with the PAS TAG of secure PAS 84.

[0101] The above example of characteristics results in a rapid change in the visibility characteristics of a particular physical granule. Consider a case where each world is assigned a private PAS that is accessible only to that world. For a particular granule, a world can request to be visible to non-secure worlds at any time without changing the PAS association by changing its GPI from "exclusive" to "limitedly shared with non-secure worlds". In this way, the visibility of that granule can be increased without requiring costly cache maintenance or data copy operations.

[0102] GMPU(20) includes a PAS check circuit and may also include a device authorization check circuit.

[0103] Figure 4 illustrates the concept of renaming each physical address space on the physical memory provided in the hardware. As explained earlier, each of regions 82, 84, 86, and 88 has its own physical address space 61.

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

[0105] The selection of PAS for a given memory access request may be limited depending on the current region in which the processing circuit 10 is operating when it issues the memory access request, according to the rules defined in the table below.

[0106] [Table 1]

[0107] For regions where multiple physical address spaces are available for selection, the system uses information from accessed page table entries used to provide the physical address to select from among the available PAS options.

[0108] Therefore, by the time the PAS filter 20 outputs a memory access request to the system fabric 24, 8 (assuming it has passed any filtering checks), the memory access request is associated with a physical address (PA) and a selected physical address space (PAS).

[0109] From the perspective of memory system components (caches, interconnects, snoop filters, etc.) operating before the Physical Aliasing (PoPA) point 60, each physical address space 61 is considered a completely separate address range corresponding to a different system location in memory. This means that, from the perspective of pre-PoPA memory system components, the address range identified by a memory access request is actually four times the size of the range 62 that can be output in address translation, because, in effect, the PAS identifier is treated as an additional address bit alongside the physical address itself, and therefore, depending on the selected PAS, the same physical address PAx can be mapped to a number of aliased physical addresses 63 in separate physical address spaces 61. Although all of these aliased physical addresses 63 actually correspond to the same memory system location implemented in the physical hardware, pre-PoPA memory system components treat aliased addresses 63 as different addresses. Therefore, if there is any pre-PoPA cache or snoop filter that allocates entries to such addresses, the aliased addresses 63 will be mapped to different entries with different cache hit / miss decisions and different coherency management. This reduces the likelihood or effectiveness of attackers using caches or coherence channels as a mechanism to explore the behavior of other domains.

[0110] The system may contain multiple PoPAs 60. In each PoPA 60, the aliased physical address is folded into a single unaliased address 65 within the system physical address space 64. The unaliased address 65 is provided downstream of any post-PoPA component, and as a result, the system physical address space 64 that actually identifies the memory system location is again the same size as the range of physical addresses that can be output in the address translation performed on the requester side. For example, in a PoPA 60, the PAS identifier may be detached from the address, and for downstream components, the address may be identified simply using the physical address value without specifying the PAS. Alternatively, if some completer-side filtering of memory access requests is desired, the PAS identifier may still be provided downstream of the PoPA 60, but may not be interpreted as part of the address, and as a result, the same physical address appearing in different physical address spaces 60 will be interpreted to point to the same memory system location downstream of the PoPA, however, the provided PAS identifier may still be used to perform completer-side security checks.

[0111] Figure 5 illustrates how the system physical address space 64 can be divided into chunks allocated for access within specific architectural physical address spaces 61 using a granule protection table 56. The granule protection table (GPT) 56 defines which parts of the system physical address space 65 are accessible from each architectural physical address space 61. For example, the GPT 56 may contain several entries corresponding to granules of a certain size of physical address (e.g., 4K pages), and may define the PAS to which that granule is allocated, which can be selected from non-secure, secure, realm, and root regions. By design, if a particular granule or set of granules is allocated to a PAS associated with one of the regions, it can only be accessed within the PAS associated with that region and not within the PAS of other regions. However, it should be noted that even though a granule allocated to a secure PAS (for example) cannot be accessed from within the root PAS, the root region 82 can still access that granule at a physical address by specifying PAS selection information in its page table to ensure that the virtual addresses associated with pages mapped to that region of physically addressed memory are translated to physical addresses in the secure PAS instead of the root PAS. Thus, data sharing between regions (to the extent permitted by the accessibility rules defined in the table described above) can be controlled at the time of selecting the PAS for a given memory access request.

[0112] However, in some implementations, in addition to enabling access to granules of physical addresses within an assigned PAS as defined by GPT, GPT may use other GPT attributes to mark certain regions of the address space (e.g., address spaces associated with lower or orthogonal privilege regions that are not normally permitted to select the assigned PAS for access requests to that region) as shared with another address space. This can facilitate the temporary sharing of data without the need to change the PAS assigned to a given granule. For example, in Figure 5, region 70 of the realm PAS is defined in GPT as being assigned to a realm region, and therefore, the non-secure region 86 cannot select the realm PAS for its access requests, and thus, that region is normally inaccessible from the non-secure region 86. Since the non-secure region 26 cannot access the realm PAS, the non-secure code could normally not see the data in region 70. However, if a realm primarily desires to share some of its data within its allocated region of memory with an insecure region, the realm may request that monitor code 29 operating in the root region 82 update GPT56 to indicate that region 70 may be shared with the insecure region 86, thereby making region 70 accessible from an insecure PAS, as shown on the left side of Figure 5, without needing to change which region is allocated to region 70. If a realm region points to a region of its address space as being shared with an insecure region, a memory access request issued from an insecure region and targeting that region may initially specify an insecure PAS, but the PAS filter 20 may remap the request's PAS identifier to specify a realm PAS instead, so that downstream memory system components treat the request as if it had been issued from the realm region from the beginning.This sharing can improve performance because the operation of allocating different regions to a specific memory area may be more performance-intensive, involving a higher degree of cache / TLB invalidation and / or data zeroing in memory or data copying between memory areas, which may not be justified if the sharing is expected to be only temporary.

[0113] Figure 6 is a flowchart showing how the current operating region is determined, which may be performed by the processing circuit 10, or by the address translation circuit 16 or the PAS filter 20. In step 100, it is determined whether the current exception level 15 is EL3, and if so, then in step 102, it is determined that the current region is the root region 82. If the current exception level is not EL3, then in step 104, it is determined that the current region is one of the non-secure, secure, and realm regions 86, 84, or 88, as indicated by at least two region indicator bits 14 in the processor's EL3 control register (since the root region is indicated by the current exception level being EL3, it may not be necessary to have a code for the region indicator bit 14 corresponding to the root region, and therefore the code for at least one region indicator bit 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 to EL0.

[0114] Figure 7 shows an example of a page table entry (PTE) that can be used by the address translation circuit 16 for page table entries in a page table structure used for mapping from virtual addresses to physical addresses, from virtual addresses to intermediate addresses, or from intermediate addresses to physical addresses (depending on whether the translation is performed in an operating state where a stage 2 translation is required in the first place, and if a stage 2 translation is required, whether the translation is stage 1 or stage 2). Generally, a given page table structure can be defined as a multilevel table structure in which the first level of the page table is implemented as a page table tree identified based on a base address stored in the processor's translation table base address register, and the index for selecting a particular level 1 page table entry in the page table is derived from a subset of bits of the input address from which the translation lookup is performed (the input address may be a virtual address for stage 1 translation, or an intermediate address for stage 2 translation). A level 1 page table entry may be a “table descriptor” 110 that provides a pointer 112 to the next level of the page table from which further page table entries may be selected based on a further subset of bits of the input address. Finally, after one or more lookups into successive levels of page tables, blocks or page descriptors PTEs 114, 116, 118 can be identified that provide an output address 120 corresponding to an input address. The output address may be an intermediate address (for a Stage 1 translation performed in an operating state where further Stage 2 translations are also performed) or a physical address (for a Stage 2 translation, or a Stage 1 translation when Stage 2 is not required).

[0115] To support the separate physical address spaces described above, the page table entry format may specify several additional states for use in physical address space selection, in addition to the next level page table pointer 112 or output address 120 and any attributes 122 for controlling access to the corresponding block in memory.

[0116] For table descriptor 110, the PTE used by any realm other than the non-secure realm 86 includes a non-secure table indicator 124 indicating whether the next level of page tables should be accessed from the non-secure physical address space or the physical address space of the current realm. This helps facilitate more efficient management of page tables. Often, the page table structure used by the root, realm, or secure realm 24 may only need to define special page table entries for a portion of the virtual address space, and for other portions, the same page table entries used by the non-secure realm 26 may be available. Thus, by providing the non-secure table indicator 124, it is possible for higher levels of the page table structure to provide realm / secure-only table descriptors, while at some point in the page table tree, the root realm or secure realm may switch to using page table entries from the non-secure realm for portions of the address space where higher security is not required. Other page table descriptors in other parts of the page table tree can still be fetched from the associated physical address space associated with the root, realm, or secure realm.

[0117] On the other hand, block / page descriptors 114, 116, and 118 may contain physical address space selection information 126, depending on which region they are associated with. A non-secure block / page descriptor 118 used within a non-secure region 86 does not contain any PAS selection information, since the non-secure region can only access non-secure PAS. However, for other regions, block / page descriptors 114 and 116 contain PAS selection information 126 used to select the PAS that translates the input address. For the root region 22, the EL3 page table entry may have PAS selection information 126 containing at least two bits to indicate the PAS associated with one of the four regions 82, 84, 86, and 88 as the selected PAS to which the corresponding physical address is translated. In contrast, for realm and secure regions, the corresponding block / page descriptor 116 must contain only one bit of PAS selection information 126, thereby selecting between the realm and a non-secure PAS for the realm region, and between a secure PAS and a non-secure PAS for the secure region. To improve the efficiency of circuit implementation and avoid increasing the size of page table entries, for realm and secure regions, the block / page descriptor 116 can code the PAS selection information 126 at the same location in the PTE regardless of whether the current region is a realm or secure, thus allowing the PAS selection bits 126 to be shared.

[0118] Therefore, Figure 8 is a flowchart showing how to select a PAS based on the current region and information 124, 126 from the block / page PTE used to generate a physical address for a given memory access request. PAS selection can be performed by the address translation circuit 16, or by a combination of the address translation circuit 16 and the PAS filter 20, if the address translation circuit sends the PAS selection information 126 to the PAS filter 20.

[0119] In step 130 of Figure 8, the processing circuit 10 issues a memory access request specifying a given virtual address (VA) as the target VA. In step 132, the address translation circuit 16 looks up any page table entry (or cache information derived from such a page table entry) in its TLB 18. If any required page table information is unavailable, the address translation circuit 16 initiates a page table walk to memory to fetch the required PTE (potentially requiring a series of memory accesses to step through each level of the page table structure and / or multiple stages of address translation to obtain a mapping from VA to an intermediate address (IPA), and then from IPA to PA). Note that any memory access request issued by the address translation circuit 16 in the page table walk operation may itself be subject to address translation and PAS filtering, and therefore the request received in step 130 may be a memory access request issued to request a page table entry from memory. Once relevant page table information is identified, the virtual address is translated to a physical address (possibly in two stages via IPA). In step 134, the address translation circuit 16 or the PAS filter 20 determines which region is the current region using the method shown in Figure 6.

[0120] If the current area is an insecure area, then in step 136, the output PAS selected for this memory access request is an insecure PAS.

[0121] If the current region is a secure region, in step 138 an output PAS is selected based on the PAS selection information 126 contained in the block / page descriptor PTE that provided the physical address, and the output PAS is selected as either a secure PAS or a non-secure PAS.

[0122] If the current region is a realm region, in step 140 an output PAS is selected based on the PAS selection information 126 contained in the block / page descriptor PTE from which the physical address was derived, in which case the output PAS is selected as either a realm PAS or a non-secure PAS.

[0123] If step 134 determines that the current region is the root region, step 142 selects an output PAS based on the PAS selection information 126 in the root block / page descriptor PTE 114 from which the physical address was derived. In this case, the output PAS is selected as one of the physical address spaces associated with the root, realm, secure, and non-secure regions.

[0124] Control of access to the physical address space by hardware devices Figure 9 shows an example of an access control circuit 23. The access control circuit 23 includes a PAS check circuit 20 (e.g., the PAS filter discussed above) and a device authorization check circuit 92. The device authorization check circuit 92 is not explicitly shown in Figure 1, but may be located alongside the PAS filter 20 shown in Figure 1 (e.g., it may be in a logical location along the path taken by memory access requests between the address translation circuit and the interconnect). Alternatively, the device authorization check circuit may be located in a different location. The PAS check circuit 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 PAS is authorized to access the given physical address (e.g., as shown in Figure 5). As discussed above, this makes it possible to protect data stored in a specific area of ​​memory from access by software running in other specific areas—for example, software running in an "unsecure" area typically cannot access data stored in areas of memory designated as "secure," "realm," or "root."

[0125] However, in addition to isolating regions from software processes, it may also be useful to provide mechanisms for isolating regions of memory from specific hardware elements (e.g., requester devices). For example, there may be situations where it is useful to be able to isolate certain data or code from a particular processing element (PE), regardless of the region the PE is currently executing in. Similarly, it may be desirable to make a particular region of memory visible only to a specific requester device, without making it accessible to any other device. For example, this may allow multiple requester devices within a data processing system (e.g., a system-on-chip (SoC)) to be effectively partitioned into subsets of the PAS described above. An example where this may be useful is when a dedicated secure processing unit is provided to perform high-security processing (e.g., this could be processing involving the management of biometric or facial recognition features), and enabling such processing to be isolated from other processing elements may be particularly useful as it limits the number of other processing / devices that need to be trusted.

[0126] It might be assumed that such high-security processes can be protected by running them within a secure or realm area and storing any data or code associated with the process within the corresponding secure or realm PAS. However, while this provides 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 guaranteed in certain cases.

[0127] It is also conceivable to run such high-security processes within the root area. However, it is preferable to minimize the number of processes allowed to operate within the root area in order to preserve the root area for those processes involved in managing the switching between other operating areas.

[0128] Therefore, this technology isolates these high-security processes using a device authorization check circuit 92. The device authorization check circuit 92 checks whether the requester device that issued the access request is authorized to access the selected PAS (the PAS selected by the PAS selection circuit). The identification information of the requester device may be determined based on the device identifier provided with the request (for example, this may be either as part of the SMMU (considered below) or as part of the interconnect 8 if the requester is an external device). Alternatively, the device identifier may be determined based on the contents of a register or other storage structure (for example, if the device authorization check circuit 92 is shared among multiple PEs that may be on the interconnect 8, for example), or it may be implicit (for example, if the device authorization check circuit 92 is located within the requester device itself, for example, as shown in Figure 1). If the device authorization check circuit determines that the request from the identified device is not authorized to access the selected PAS, it rejects the request.

[0129] While some of the figures illustrate the access control circuit 20 as a single unit, it should be noted that the device authorization check circuit 92 and the PAS check circuit 20 can be located in different places. For example, since the physical address is not required for the check performed by the device authorization check circuit 92, this circuit may be provided before the address translation circuit 16 (assuming some alternative PAS selection circuit is provided before the device authorization check circuit 92). Alternatively, in some examples, the address translation circuit 16 may acquire the PAS midway through the address translation (for example, earlier in the address translation if multi-stage address translation is implemented). Therefore, in some examples, the address translation circuit 16 may pass the PAS to the device authorization check circuit 92 midway through the address translation, and the device authorization check circuit 92 may perform its check in parallel with the address translation circuit 16, which performs the final stage of the translation.

[0130] The device authorization check circuit 92 determines whether to reject an access request from a particular device, depending on the access permissions defined for that particular device and the selected PAS. An example of how these access permissions can be defined is shown in Figure 10.

[0131] Figure 10 shows an example of a system register 96 associated with a specific device and accessible to the device authorization check circuit, which defines the additional advice-based authorization described above. In some specific examples, this register 96 may be one of the registers 12 located within the requester device 4, although the register may also be located outside the requester device. Register 96 is referred to as the “GPC control register” or “GPCCR” in Figure 7, and in this example, its contents can only be modified by a process running at the highest exception level (e.g., EL3 in this example).

[0132] The GPPCR contains several fields, each corresponding to one of the previously considered PASs, and each of these fields holds information that can be used to indicate whether the associated device is authorized to access the corresponding PAS. Specifically, the "SPASD" field 95 defines authorization information for secure (S)PAS, the "NSPASD" field 97 defines authorization information for low-secure (NS)PAS, and the "RLPASD" field 99 defines authorization information for realm (RL)PAS. There is no field for root PAS.

[0133] In a particular example, each of the fields (referred to as the "PASD" field) holds a "PAS Disable" (PASD) bit. This is a single bit (either "1" or "0") indicating whether a device is prohibited from accessing the corresponding PAS, and therefore the PASD bit defines an additional set of permissions for the associated device, in addition to the permissions implemented by the PAS check circuit 20 (e.g., those defined in GPT). For example, a value of "0" may indicate that no additional permissions are defined, and a value of "1" may indicate that the associated device is prohibited from accessing the corresponding PAS. For example, the values ​​held in each of the PASD bits can be interpreted as follows: RLPASD bit If -RLPASD=0, when selected as the chosen PAS, access to the realm PAS is permitted, and the GPT-based granule protection check indicates that access to the realm PAS is permitted for the target physical address. If -RLPASD=1, any access to the realm physical address space will result in a GPF (Granule Protection Failure) when granule protection checks are disabled. SPASD bits: -SPASD=0 allows access to the secure PAS when selected as the chosen PAS, and the GPT-based granule protection check indicates that access to the secure PAS is permitted for the target physical address. -When SPASD=1, any access to the secure physical address space will result in a GPF when granule protection checks are enabled. NSPASD bit: -NSPASD=0 allows access to an insecure (low-secure) PAS when selected as the chosen PAS, and the GPT-based granule protection check indicates that access to the insecure PAS is permitted for the target physical address. -When NSPASD=1, any access to an insecure (less secure) physical address space will result in a GPF when granular protection checks are enabled.

[0134] This is illustrated in the following table:

[0135] [Table 2]

[0136] The interpretation applied to the values ​​of 0b0 and 0b1 should be understood as also being inverted so that the value of 0b1 indicates that permission depends on the GPI.

[0137] While a separate GPCCR96 can be provided for each of the multiple requester devices, it should be noted that it is not necessarily required to provide a GPCCR96 for each requester device within the data processing system.

[0138] In another example, there may be two or more GPCCR96 provided for a given requester device, and for example, the permissions defined in each of the PASD fields 95, 97, and 99 may instead be defined in separate registers.

[0139] Furthermore, in some cases, PASD authorizations can be defined in different data structures. In particular, an SMMU can access stream table entries to determine device authorization information for external devices—since an SMMU can manage hundreds of devices, defining authorizations in an in-memory table is more feasible than using GPCCR.

[0140] It may be useful to provide a mechanism to prevent modifications to permissions defined in any of the PASD fields. Some protection is provided by preventing modifications to register 96 by programs running at exception levels other than the highest exception level (EL3 in this case), but further protection can be provided by implementing a “write ignore” feature. For example, a “write ignore control register” 98 may be provided to identify one or more registers (which may include GPCCR) and / or one or more specific parts of registers that a write request should, under certain circumstances, be ignored.

[0141] The write ignore control register 98 shown in Figure 10 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 lockdown value indicating whether direct writes to GPPCR should be ignored. For example, this field may store a single bit indicating that write requests targeting GPCCR96 should be ignored when set. A further 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 may be interpreted as follows:

[0142] "Named register" bits 101, 103: -0b0: Direct writes to "named registers" (for example, for GPCCR field 101, the "named register" is GPCCR) are not affected by this mechanism. -0b1: Direct writes to named registers are ignored, and the named registers are not updated.

[0143] Here again, it will be understood that the interpretation applied to the values ​​of 0b0 and 0b1 can also be inverted so that the value of 0b0 indicates that the write should be ignored. Furthermore, while the above example shows how an entire “named register” can be locked down, in some examples a write ignore control register may identify a specific bit / field of a given register whose write request should be ignored.

[0144] In certain cases, these “named register” bits (also referred to herein as “register lockdown values” or “write ignore values”) are “sticky,” so that any request to write the value 0b0 (e.g., a request to clear the value) is ignored, while a write of 0b1 is not. Subsequently, “named register” bits 101 and 103 may be reset to 0 when the data processing unit is reset.

[0145] Note that in alternative implementations, the register lockdown value for GPCCR may be provided as field 105 of GPCCR itself, rather than as a field in a separate register.

[0146] Providing a mechanism to disable the features described above (e.g., disabling PASD and / or write ignore features) may be useful. For example, this may help provide backward compatibility. Thus, Figure 10 also shows a feature register 94 which includes a PASD enable field 91 indicating whether the PASD feature is enabled and an 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 feature is enabled, while a value of 0 may indicate that they are disabled (or vice versa).

[0147] Figure 11 schematically illustrates another exemplary configuration of the data processing device 2. In this example, the device 2 includes several requester devices 4, which include two central processing units (CPUs) 5 and input / output units 7 for controlling the input or output of data to and 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 masters, such as input / output interfaces 7, may be non-cached masters. Coherence between data in each cache and data accessed by each master may be managed by a coherent interconnect 9 (an example of interconnect 8 as shown in Figure 1) that tracks requests for access to data from a given address and controls snooping of data in other masters' caches when necessary to maintain coherence. In other embodiments, such coherent behavior may be managed in software, but it will be understood that the benefit of providing a hardware interconnect 9 for tracking such coherence is that the programmer of the software run by the system does not need to consider coherence.

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

[0149] Figure 12 illustrates another example of a data processing system 2 in which this technology is implemented. In this example, memory, specifically dynamic random access memory (DRAM) 146, is logically divided into multiple PASs, namely, a root PAS, a realm (RL) PAS, a secure (S) PAS, and a low-secure (NS) PAS. Multiple requester devices are provided, including multiple PEs 5 and multiple external devices 7. In this example, each PE 5 is permitted to execute software in either the secure area 84, the low-secure area 86, or the root area 82 (for example, as shown in Figure 2, the root area is reserved for a particular process). On the other hand, each external device 7 is permitted to execute software in either the low-secure area 86 or the realm area 88. Therefore, in this particular example, the realm area 88 is exclusively used by the external device 7, and the secure area 84 is exclusively used by the PEs 5.

[0150] As in the example described above, the root PAS 82 is isolated from all other PAS, while the realm PAS 88 and secure PAS 84 are isolated from each other and from the low-secure PAS 86. Isolation between different PAS is achieved by the system realm controller (SRC) 144, which owns (controls) the GPT and operates within the root realm 82. The SRC 144 may also optionally be responsible for programming the realm SMMU context.

[0151] Hardware-enforced security (HES) mechanisms are also implemented in Figure 9 to protect so-called "root of trust" (RoT) services, which may include processes performed by SRC144, for example.

[0152] Figure 13 is a flowchart illustrating an exemplary method of this technology. In this exemplary method, in step 106, a memory access request specifying a memory address (for example, this may be a virtual address) is received from a device labeled "device X". In step 108, a PAS associated with the memory address is selected, and this selection depends on the current execution area. In step 148, it is determined whether device X is permitted to access the selected PAS. If it is determined that the device is prohibited from accessing the selected PAS, the request is rejected (step 156). On the other hand, if it is determined that the device is not prohibited from accessing the selected PAS, the GPI for the specified memory address is obtained in step 150. In step 152, it is determined whether the selected PAS is permitted to access the PAS assigned to the memory address according to the GPI. If access is not permitted, the access is rejected in step 156. On the other hand, if access is not prohibited by the GPI, the access is permitted (step 154) and proceeds.

[0153] Simulator implementation form Figure 14 illustrates possible implementations of a simulator. While the above embodiments implement the present invention in terms of devices and methods for operating specific processing hardware that supports the technology, it is also possible to provide an instruction execution environment according to the embodiments described herein, which are implemented using a computer program. Such a computer program is often referred to as a simulator, insofar as it provides a software-based implementation of a hardware architecture. Various simulator computer programs include emulators, virtual machines, models, and binary translators, including dynamic binary translators. Typically, a simulator implementation may run on a host processor 430, optionally running a host operating system 420 and supporting a simulator program 410. In some configurations, there may be multiple layers of simulation between the hardware and the provided instruction execution environment, and / or multiple different instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations that run at reasonable speeds, but such techniques may be justified in certain circumstances, such as when it is desirable to run native code on a different processor for reasons of compatibility or reuse. For example, a simulator implementation may provide an instruction execution environment with additional functionality not supported by the host processor hardware, or it may provide an instruction execution environment typically associated with a different hardware architecture. An overview of the simulation is provided in "Some Efficient Architecture Simulation Techniques," Robert Bedichek, 1990 Winter USENIX Conference, pp. 53-63.

[0154] While embodiments have been described so far with reference to specific hardware components or features, in simulated embodiments, equivalent functionality may be provided by suitable software components or features. For example, certain circuits may be implemented as computer program logic in simulated embodiments. Similarly, memory hardware such as registers or caches may be implemented as software data structures in simulated embodiments. In configurations where one or more of the hardware elements referenced in the embodiments described earlier reside on host hardware (e.g., host processor 430), some simulated embodiments may, if preferred, utilize the host hardware.

[0155] The simulator program 410 may be stored on a computer-readable storage medium (which may be a non-temporary medium) and provides a program interface (instruction execution environment) to target code 400 (which may include an application, operating system, and hypervisor) that is the same as the interface of the hardware architecture modeled by the simulator program 410. Thus, program instructions of target code 400 can be executed from within the instruction execution environment using the simulator program 410, and for this reason, a host computer 430 that does not actually possess the hardware features of device 2 considered above can emulate these features. This can be useful, for example, to enable testing of target code 400 being developed for a new version of a processor architecture before a hardware device that actually supports that architecture becomes available, since the target code can be tested by running it in a simulator running on a host device that does not support the new version of the processor architecture.

[0156] The simulator code includes, for example, instruction decoding program logic that decodes instructions of target code 400, and processing program logic 412 that performs the function equivalent to the decoded instructions by mapping the instructions to a sequence of corresponding instructions in the native instruction set supported by the host hardware 430. Processing program logic 412 also simulates the processing of the code in different exception levels and regions, as described above. Register emulation program logic 413 maintains data structures in the host address space of the host processor that emulate architecture register states defined according to the target instruction set architecture associated with target code 400. Thus, instead of such architecture states being stored in hardware registers 12 as in the embodiment of Figure 1, they are instead stored in the memory of the host processor 430, and register emulation program logic 413 maps register references of instructions in target code 400 to the corresponding addresses for retrieving the simulated architecture state data from host memory. This architectural state may include the current region index 14, the current exception level index 15, and other system registers 13, as described above.

[0157] The simulation code, referencing the same page table structure and GPT56 as described above, includes address translation program logic 414 and filtering program logic 416 that emulate the functions of the address translation circuit 16 and PAS filter 20, respectively. Thus, the address translation program logic 414 translates the virtual address specified by the target code 400 to a simulated physical address in one of the PAS (pointing to a physical location in memory from the target code's perspective), but these simulated physical addresses are actually mapped onto the host processor's (virtual) address space by the address space mapping program logic 415. The filtering program logic 416, similar to the PAS filter described above, performs a lookup of granule protection information to determine whether to allow the memory access triggered by the target code to proceed.

[0158] In this application, the phrase "configured to..." is used to mean that an element of the device has a configuration that enables it to perform a defined operation. In this context, "configuration" means the arrangement or interconnection of hardware or software. For example, the device may have dedicated hardware to provide the defined operation, or a processor or other processing device may be programmed to perform the function. "Configured to" does not mean that an element of the device must be modified in any way to provide the defined operation.

[0159] Furthermore, the phrase "including at least one of..." in this application is used to mean that any one of the following options or any combination of the following options is included. For example, "at least one of A, B, and C" is intended to mean A or B or C or any combination of A, B and C (e.g., A and B or A and C or B and C).

[0160] While illustrative embodiments of the present invention are described in detail herein with reference to the accompanying drawings, it will be understood that the present invention is not limited to those exact embodiments, and that various changes and modifications can be made to the embodiments without departing from the scope of the present invention as defined by the appended claims.

Claims

1. It is a device, A PAS selection circuit for selecting one of a plurality of physical address spaces (PAS) associated with a memory access request, based on the current operating area of ​​the requester device, in response to a memory access request issued by a requester device, which specifies a memory address identifying a memory location. The system includes an access control circuit for determining whether to reject the memory access request based on the selected PAS in response to the memory access request, The aforementioned access control circuit is The address space permission information defined for the identified memory location indicates that the memory access request associated with the selected PAS is prohibited from accessing the identified memory location. In response, a PAS check circuit for rejecting the memory access request, A device comprising: a device authorization check circuit for rejecting a memory access request in response to the device authorization information defined for the requester device indicating that the memory access request issued by the requester device is prohibited from accessing the selected PAS.

2. The device authorization check circuit is authorized to reject the first memory access request without rejecting the second memory access request, depending on the device authorization information, in response to the first and second memory access requests, which are associated with the same selected PAS and identify the same memory location. The apparatus according to claim 1.

3. The device authorization check circuit is configured to identify the device authorization information depending on the contents of at least one data structure accessible to the device authorization check circuit. The apparatus according to claim 1 or 2.

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

5. The device is prohibited from writing data to the at least one data structure in response to an instruction executed at an exception level with privileges lower than the threshold exception level. The apparatus according to claim 3 or 4.

6. The aforementioned threshold exception level includes the highest privileged exception level. The apparatus according to claim 5.

7. The aforementioned at least one data structure includes a system register, The device is prohibited from writing data to at least a portion of the system registers in response to a register lockdown value being held in at least one control register, in response to the register lockdown value being set. The apparatus according to any one of claims 3 to 6.

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

9. In response to the memory access request, the system includes an address translation circuit for translating the memory address specified by the memory access request to a physical address in the selected PAS associated with the memory access request. The apparatus according to any one of claims 1 to 8.

10. The address translation circuit includes the PAS selection circuit, The apparatus according to claim 9.

11. The PAS selection circuit, in response to the memory access request, selects the selected PAS associated with the memory access request based on the information defined in the page table entry for the memory address specified by the memory access request. The apparatus according to claim 10.

12. The address translation circuit, A memory management unit (MMU) associated with at least one processing element, and Including at least one of the system MMUs (SMMUs) associated with at least one external device, The apparatus according to any one of claims 9 to 11.

13. The requester device includes a processing element or an external device. The apparatus according to any one of claims 1 to 12.

14. The PAS check circuit is configured to identify the address space permission information depending on permission information defined in a table entry of a table in memory, wherein the permission information defines which of the plurality of PAS is the permitted PAS for the identified memory location. The apparatus according to any one of claims 1 to 13.

15. A memory system component located upstream of a physical aliasing point (PoPA) is provided for processing aliased physical addresses from different PASs corresponding to the same memory system resource as if the aliased physical addresses corresponded to different memory system resources, wherein the system includes at least one pre-PoPA memory system component. The apparatus according to any one of claims 1 to 14.

16. A PoPA memory system component is configured to de-aliase the plurality of aliased physical addresses in order to obtain an unaliased physical address provided to at least one downstream memory system component, The apparatus according to claim 15.

17. It is a method, A memory access request issued by a requester device, which specifies a memory address that identifies a memory location, in response to the memory access request, Based on the current operating region of the requester device, select one of the multiple physical address spaces (PAS) associated with the memory access request, This includes determining whether the memory access request should be rejected based on the selected PAS, The above determination means that The address space permission information defined for the identified memory location will reject the memory access request in response to indicating that the memory access request associated with the selected PAS is prohibited from accessing the identified memory location. A method comprising: rejecting a memory access request in response to the device authorization information defined for the requester device indicating that the memory access request issued by the requester device is prohibited from accessing the selected PAS.

18. A computer program including instructions, wherein when the instructions are executed by a host data processing device, the computer program provides an instruction execution environment for controlling the host data processing device to execute target program code, and the computer program includes instructions. A memory access request issued by a requester, which specifies a memory address identifying a memory location, and in response to the memory access request, PAS selection program logic for selecting one of a plurality of physical address spaces (PAS) associated with the memory access request, based on the current operating area of ​​the requester, Includes, in response to the memory access request, access control program logic for determining whether the memory access request should be rejected based on the selected PAS, The aforementioned access control program logic is The address space permission information defined for the identified memory location indicates that the memory access request associated with the selected PAS is prohibited from accessing the identified memory location. In response, the PAS check program logic rejects the memory access request. A computer program comprising: device authorization information defined for the requester, and device authorization check program logic for rejecting the memory access request in response to an indication 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 described in claim 18.

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

Images