Memory Management

Abstract

A target virtual address is translated to a target physical address for a memory access request. At least for a write request, the memory access request is rejected when the target stage 1 translation table entry specifies that the target memory region corresponding to the target virtual address is a guard control stack (GCS) region for storing a GCS data structure for protecting return state information and the memory access request is not a GCS memory access request triggered by one of a restricted subset of GCS access instruction types. If anti-aliasing properties are specified for the target memory region, the memory access request is rejected if the target stage 1 translation table entry or another stage 1 translation table entry used to find the target stage 1 translation table entry is a non-hardened entry that is not protected by a translation hardening mechanism. In at least one operating state, the GCS memory access request is rejected if anti-aliasing properties are not specified for the target memory region.

Description

[Technical field]

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

[0002] In a data processing apparatus, memory management circuitry is provided for controlling access to a memory system. The memory management circuitry is responsible for performing address translation to convert a target virtual address specified based on an operand of an instruction executed by the processing circuitry into a target physical address identifying a location in the memory system to be accessed. The memory management circuitry may also enforce access permissions based on information specified in, for example, a translation table structure used to specify the mapping from target virtual addresses to target physical addresses.

[0003] At least some examples provide an apparatus that includes a processing circuit that executes instructions in one of a plurality of execution states; and a memory management circuit that, in response to a memory access request specifying a target virtual address corresponding to a target memory region to be accessed, translates the target virtual address into a target physical address, where the mapping from the target virtual address to the target physical address depends at least on a stage 1 address mapping specified for the target virtual address by a target stage 1 translation table entry in a stage 1 translation table structure, the stage 1 translation table structure being accessible using a stage 1 base address settable by an instruction executed by the processing circuit in the first execution state; and, at least if the memory access request is a write request, the stage 1 permission information specified by the target stage 1 translation table entry specifies that the target memory region is a guarded control stack (GCS) region for storing a GCS data structure for protecting return state information for returning from a function call or an exception; the memory management circuit is configured to deny the memory access request in response to determining that both conditions are met: the memory access request is other than a GCS memory access request triggered by one of a restricted subset of GCS access type instructions; and the memory management circuit is configured to support a translation hardening mechanism for defining at least one hardened stage 1 translation table entry that is protected by the translation hardening mechanism from being tampered with by instructions executed in the first execution state based at least on translation hardening information settable by instructions executed by the processing circuit in a second execution state having greater privilege than the first execution state; and if anti-aliasing properties are specified for the target memory region, the memory management circuit is configured to detect that the target stage 1 translation table entry or another stage 1 translation table entry used to find the target stage 1 translation table entry is a non-hardened translation table entry that is not protected by the translation hardening mechanism.and configured to reject the memory access request, and in at least one operating state of the processing circuit, the memory management circuit is configured to reject the memory access request in response to determining that the memory access request is a GCS memory access request and that anti-aliasing properties are not specified for the target memory region.

[0004] At least some examples provide a method that includes executing instructions in one of a plurality of execution states; and, in response to a memory access request specifying a target virtual address corresponding to a target memory region to be accessed, translating the target virtual address to a target physical address, wherein the mapping from the target virtual address to the target physical address depends at least on a stage 1 address mapping specified for the target virtual address by a target stage 1 translation table entry in a stage 1 translation table structure, the stage 1 translation table structure being accessible using a stage 1 base address settable by an instruction executed by the processing circuitry in the first execution state; and, at least if the memory access request is a write request, stage 1 permission information specified by the target stage 1 translation table entry specifies that the target memory region is a guard control stack (GCS) region for storing a GCS data structure for protecting return state information for returning from a function call or exception; and, wherein the memory access request is a write request, the stage 1 permission information specified by the target stage 1 translation table entry specifies that the target memory region is a guard control stack (GCS) region for storing a GCS data structure for protecting return state information for returning from a function call or exception; the memory access request is rejected in response to determining that both of the following conditions are met: the memory access request is a GCS memory access request other than a GCS memory access request triggered by one of the restricted subset of instructions of the first execution state; and a translation hardening mechanism is supported to define at least one hardened stage 1 translation table entry that is protected by the translation hardening mechanism from being tampered with by instructions executing in the first execution state based at least on translation hardening information settable by instructions executing in a second execution state having greater privilege than the first execution state, and the method includes: rejecting the memory access request in response to detecting that the target stage 1 translation table entry or another stage 1 translation table entry used to find the target stage 1 translation table entry is a non-hardened translation table entry not protected by the translation hardening mechanism when anti-aliasing properties are specified for the target memory region;and in response to determining that anti-aliasing properties are not specified for the target memory region, denying the memory access request.

[0005] At least some examples provide a computer program including instructions that, when executed by a host data processing apparatus, control a host data processing apparatus to provide an instruction execution environment for executing target code, the computer program including: processing program logic that simulates execution of instructions of the target code in one of a plurality of execution states; and memory management program logic that, in response to a memory access request specifying a target virtual address corresponding to a target memory region to be accessed, translates the target virtual address into a simulated target physical address, the mapping from the target virtual address to the simulated target physical address being dependent at least on a stage 1 address mapping specified for the target virtual address by a target stage 1 translation table entry in a stage 1 translation table structure, the stage 1 translation table structure being accessible using a stage 1 base address settable by the instruction simulated to be executed in the first execution state, and at least the memory access request being written to a stage 1 base address. In response to determining that both conditions are met, if the memory access request is a request only for a first execution state, the memory manager logic is configured to deny the memory access request in response to determining that both conditions are met: the stage 1 permission information specified by the target stage 1 translation table entry specifies that the target memory region is a guard control stack (GCS) region for storing a GCS data structure for protecting return state information for returning from a function call or an exception, and the memory access request is a request other than a GCS memory access request triggered by one of the restricted subset of instructions of a GCS access type, and the memory manager logic is configured to support a translation hardening mechanism for defining at least one hardened stage 1 translation table entry that is protected by the translation hardening mechanism from being tampered with by instructions simulated to be executed in the first execution state based at least on translation hardening information settable by instructions simulated to be executed in a second execution state having greater privilege than the first execution state;If anti-aliasing properties are specified for the target memory region, the memory manager program logic is configured to reject the memory access request in response to detecting that the target stage 1 translation table entry or another stage 1 translation table entry used to locate the target stage 1 translation table entry is a non-hardened translation table entry that is not protected by a translation hardening mechanism, and in at least one operating state of the processing circuit, the memory management circuit is configured to reject the memory access request in response to determining that the memory access request is a GCS memory access request and that anti-aliasing properties are not specified for the target memory region.

[0006] The computer program may be stored in a computer-readable storage medium. The storage medium may be a non-transitory storage medium. [Brief description of the drawings]

[0007] Further aspects, features, and advantages of the present technique will become apparent from the following description of examples, read in conjunction with the accompanying drawings. [Figure 1] 1 illustrates an example of a data processing apparatus having a processing circuit and a memory management circuit. [Diagram 2] 1 shows an example of an execution state of a processing circuit. [Diagram 3] Shows two stage address translation. [Figure 4] 13 shows an example of a translation table walk for stage 1 and stage 2 address translation, respectively. [Diagram 5] 13 shows an example of a translation table walk for stage 1 and stage 2 address translation, respectively. [Figure 6] 1 illustrates the table lookups performed for a full translation table walk for both stage 1 and stage 2 translations, when considering that each table base address and final intermediate address determined in stage 1 are translated to a physical address using the respective stage 2 translation. [Figure 7] 2 illustrates an example of a memory management circuit and control registers for controlling memory management. [Figure 8] 1 shows an example of a translation table entry for stage 1 and stage 2 address translation. [Figure 9] Indicates the types of write requests that are permitted and prohibited from writing to the partial read-only memory region defined by the stage 2 translation table entry. [Figure 10] We show how to perform address translation and permission checks. [Figure 11] FIG. 13 is a flow diagram illustrating a check based on partial read-only permission. [Figure 12] 13 illustrates the processing of different variants of a protection entry check type read check write instruction. [Figure 13-1] 13 illustrates the processing of different variants of a protection entry check type read check write instruction. [Figure 13-2] 13 illustrates the processing of different variants of a protection entry check type read check write instruction. [Figure 14-1] 13 illustrates the processing of different variants of a protection entry check type read check write instruction. [Figure 14-2] 13 illustrates the processing of different variants of a protection entry check type read check write instruction. [Figure 15] Indicates aliasing of virtual addresses onto the same intermediate address. [Figure 16] Indicates anti-aliasing check. [Figure 17] 3 shows stage 1 top-level table existence check and stage 1 top-level partial read-only check. [Figure 18] Indicates the permission information specified indirectly by the translation table entry. [Figure 19] An example of a function call and return is shown below. [Figure 20] 1 illustrates registers for controlling access to the Guard Control Stack (GCS) data structure. [Figure 21] Demonstrates the use of GCS data structures to preserve return state information for returning from function calls and exceptions. [Figure 22] FIG. 11 is a flow diagram illustrating the processing of a return state push instruction. [Figure 23] FIG. 11 is a flow diagram illustrating the processing of a return state pop instruction. [Figure 24] 1 illustrates the access permission checks performed by the memory management circuitry for memory access requests issued when GCS mode is enabled. [Diagram 25] 1 illustrates a simulator implementation that may be used.

[0008] The apparatus has a processing circuit for executing instructions in one of a number of execution states, and a memory management circuit for translating a target virtual address to a target physical address in response to a memory access request specifying a target virtual address corresponding to a target memory region to be accessed. The mapping from the target virtual address to the target physical address depends at least on a stage 1 address mapping specified for the target virtual address by a target stage 1 translation table entry in a stage 1 translation table structure. The stage 1 translation table structure is accessible using a stage 1 base address settable by an instruction executed by the processing circuit in the first execution state.

[0009] Attacks based on return-oriented programming (ROP) are a common class of attacks against data processing systems. A ROP attack is one that attempts to cause a program to behave in an unexpected way by corrupting the return state information used to return from a function call or an exception. Often, software stores return state information in memory, for example to facilitate the nesting of function calls and exceptions, and the return state information of an outer function call or exception (of a set of nested function calls or exceptions) is stored in memory before it can be overwritten in registers along with the return state information of the inner function call or exception. A ROP attack can attempt to tamper with the return state information while it is stored in memory before it is restored in registers and used to control a function return or exception return. A successful ROP attack can cause a function return or exception return that returns the program flow to an instruction other than the next instruction after the point at which the function was called or the exception was raised, allowing the attacker to control the processing circuitry to perform any sequence of operations other than the sequence of operations intended by the programmer.

[0010] To guard against ROP-based attacks, it may be useful to provide a guard control stack (GCS) data structure used to protect return state information for returning from a function call or an exception. The stage 1 translation table entry specifies whether a memory region corresponding to a given virtual address is a GCS region for storing a GCS data structure. In response to a memory access request that specifies a target virtual address, at least when the memory access request is a write request, the memory management circuitry denies the memory access request in response to determining that both of the following conditions are met: ●The stage 1 permission information specified by the target stage 1 translation table entry specifies that the target memory region is a guard control stack (GCS) region for storing GCS data structures for protecting return state information for returning from function calls and exceptions. A memory access request is a request other than a GCS memory access request that is triggered by one of a restricted subset of GCS access type instructions.

[0011] Thus, a region of memory may be designated by a corresponding stage 1 translation table entry as a GCS region used to reserve return state information for function calls and exceptions. The information stored in that region may be used to verify whether the return state information is appropriate before proceeding with a function return or exception return. Writes to a region designated as a GCS region are rejected if made in response to an instruction other than the restricted subset of GCS access type instructions. By restricting write access to a GCS region to only certain instruction types, the attack surface available to an attacker attempting to corrupt return state information may be reduced, since write requests triggered by other types of memory access instructions contained within the executing program code (if tricked into accessing the GCS region following modification of their address operands) cannot be used to successfully update information stored in the GCS region. It is not mandatory to apply this restriction to read requests because read requests cannot update the protection return state stored in a GCS area, but optionally, some implementations may choose to signal a failure if the target memory area of ​​a read request is specified by the stage 1 permission information as a GCS area and the read request is not triggered by one of the restricted subset of GCS access type instructions.

[0012] However, because stage 1 translation table entries are used to specify a GCS region and the stage 1 translation table structures are accessed via base registers controllable by instructions executing in a first execution state (e.g., this can be the state in which an operating system executes), if an attacker is able to compromise an operating system or other software executing in the first execution state, the attacker may attempt to circumvent the protection provided by the stage 1 translation table entries that specify a GCS region by modifying the stage 1 translation table entries that correspond to a GCS region such that the memory region is no longer designated as a GCS region, and / or by creating aliasing stage 1 translation table entries that map different virtual addresses to translated addresses in a GCS region without designating the corresponding memory region as a GCS region.

[0013] In an example described below, the memory management circuit supports a translation hardening mechanism for defining at least one hardened stage 1 translation table entry protected by the translation hardening mechanism from being tampered with by instructions executed in the first execution state based at least on translation hardening information settable by instructions executed by the processing circuit in a second execution state having greater privilege than the first execution state. If anti-aliasing properties are specified for the target memory region, the memory management circuit denies the memory access request in response to detecting that the target stage 1 translation table entry or another stage 1 translation table entry used to find the target stage 1 translation table entry is a non-hardened translation table entry not protected by the translation hardening mechanism. In at least one operating state of the processing circuit, the memory management circuit denies the memory access request in response to determining that the memory access request is a GCS memory access request and that anti-aliasing properties are not specified for the target memory region.

[0014] Therefore, the following combination of measures is implemented: -Writes to the GCS area (indicated using stage 1 permission information) are restricted to be performed using certain specified GCS access type instructions. A stage 1 translation table entry may be designated as hardened based on information settable by an instruction executing in a more privileged execution state than the first execution state that may control the base address of the stage 1 translation table structure. -Memory regions designated as having anti-aliasing properties are inaccessible based on non-hardened stage 1 translation table entries. -GCS memory access requests are rejected if the anti-aliasing property is not set for the target memory region.

[0015] This combination of measures allows the GCS data structures to be much more secure from tampering since it enforces the requirement that anti-aliasing properties be applied to any GCS memory region (otherwise the GCS memory access request will fail), but on the other hand the anti-aliasing properties enforce that when anti-aliasing properties are defined for a GCS region, no non-hardened translation table entries (which may be vulnerable to modification by an attacker, or which may be aliasing translation table entries defined by the attacker to circumvent the hardened translation table entries) may be used to enable access to the GCS region. This approach therefore provides much greater protection against attacks based on return oriented programming.

[0016] GCS memory access requests may include read requests and write requests. GCS read requests may be triggered by one or more types of GCS access load instructions, and GCS write requests may be triggered by one or more types of GCS access store instructions that trigger a write request. As described above, GCS memory access requests are subject to the requirement that, in at least one operating state, a failure is signaled if anti-aliasing properties are not specified for a target memory region. This failure may be signaled regardless of whether the GCS memory access request is a read or write request. Thus, both GCS access load instructions and GCS access store instructions may trigger a check for anti-aliasing properties and a failure if anti-aliasing properties are not specified for a target memory region (even though a read request to a GCS region of memory does not trigger a failure when caused by an instruction other than a GCS access type instruction).

[0017] The memory management circuitry may support two-stage address translation, where the stage 1 address mapping includes a mapping from a target virtual address to a target intermediate address, and the address mapping from the target virtual address to the target physical address also depends on a stage 2 address mapping from the target intermediate address to the target physical address specified for the target intermediate address by a target stage 2 translation table entry in a stage-2 translation table structure. The stage 2 translation table structure is accessible using a stage 2 base address settable by instructions executed by the processing circuitry in the second execution state. The two-stage address translation may be useful for supporting virtualization where multiple guest operating systems coexist on the same hardware platform. The second execution state may be an execution state for executing a hypervisor used to control virtualization of the guest operating systems.

[0018] The anti-aliasing properties may be configurable by instructions executed in the second execution state. The anti-aliasing properties may be specified for the target memory region in a data structure maintained by software executing in the second execution state, separate from the stage 2 translation table structure.

[0019] However, since the stage 2 translation table structure may in any case be managed by software executing in the second execution state, it may be most efficient for the target stage 2 translation table entry to specify whether anti-aliasing properties are specified for the target memory region.

[0020] Similarly, the translation hardening information may include information defined by software executing in the second execution state using a data structure separate from the stage 2 translation table structure, although it may be more efficient to reuse the stage 2 translation table structure to define permission information that includes the translation hardening information. Thus, for a given stage 1 translation table entry stored in a given memory region corresponding to a given intermediate address, the translation hardening information for specifying whether the given stage 1 translation table entry is a hardened stage 1 translation table entry includes the stage 2 permission information specified by the corresponding stage 2 translation table entry corresponding to the given intermediate address.

[0021] It is not mandatory to provide architectural mechanisms to enforce that software set appropriate access permissions or address mappings to ensure that stage 2 translation table entries are protected from being updated by software executing in the first execution state or in a less privileged state. It is typical that hypervisor software executing in the second execution state that is responsible for the stage 2 translation table structures will take steps to protect those structures against modification by operating system software or other software executing in the first execution state (or in an execution state less privileged than the first execution state). For example, the hypervisor could do this by allocating entries for the stage 2 translation table structures in memory regions that correspond to physical addresses that do not map to any intermediate physical addresses in the stage 2 translation table structures used by software executing in the first execution state (or in a less privileged state), so that software in the first execution state has no way to access those regions (read-only permissions could be used instead to protect the stage 2 translation table structures). To ensure that the memory area that stores the stage 2 translation table structures is protected against access by software executing in the first execution state, it may be the responsibility of software executing in the second execution state that controls the stage 2 translation table structures to define appropriate translation table mappings and / or permissions.Thus, while it may be preferable for the hypervisor (or other software executing in the second execution state) to configure stage 2 translation table structures with address mappings and access permissions appropriate to its own needs when the device is in use, so that anti-aliasing properties and translation hardening information specified using stage 2 translation table entries can be restricted to be set by instructions executing in the second execution state (or more privileged execution state) and not set by instructions executing in the first execution state (or less privileged execution state), it is not necessary for the hardware architecture of the device to provide special architectural means to enforce that those mappings / access permissions have actually been set in order to protect the stage 2 translation table structures from modification by software executing in the first execution state or less privileged execution states. For example, there is no need for architecturally defined checks to verify whether the stage 2 translation table entries used to define the anti-aliasing properties (or translation hardening information) are themselves protected against tampering. It may be assumed that the hypervisor software sets the appropriate stage 2 address mappings / permissions to protect its own operation.

[0022] A translation hardening mechanism can be implemented in a variety of ways. In general, a translation hardening mechanism can be any architectural mechanism that allows a particular hardened stage 1 translation table entry to be provided with greater protection against tampering than an unprotected stage 1 translation table entry. For example, a stage 1 translation table entry can be provided with a particular encoding that marks the entry as hardened, and a processing circuit or memory management circuit can check, upon a write to memory, whether the data being written has the hardened encoding of the stage 1 translation table entry, in which case the write can be suppressed. In practice, however, enforcing such a check on every write to memory (including writes to memory areas that do not store translation table entries) can be very performance intensive and consume a lot of power.

[0023] A more efficient mechanism for the translation hardening mechanism may be to specify stage 2 permission information using stage 2 translation table entries used to provide stage 2 address mappings for regions that store hardening stage 1 translation table entries, the stage 2 permission information having at least one encoding indicating a permission type that limits the ability of data in the corresponding region to be modified. For example, the permission type may be a read-only permission, indicating that write requests are prohibited, and / or a partial read-only permission type, indicating that write requests are permitted only for a limited subset of write request types.

[0024] For example, each hardened stage 1 translation table entry may include a stage 1 translation table entry for which a given memory region storing that stage 1 translation table entry is indicated by the stage 2 permission information of the corresponding stage 2 translation table entry to be one of the following: A read-only memory area where write requests are prohibited; A partial read-only memory region in which write requests to the partial read-only memory region are permitted for a restricted subset of write request types and prohibited for write request types other than the restricted subset, the restricted subset of write request types including at least metadata update write requests generated by a memory management circuit to update access tracking metadata in a translation table entry.

[0025] Some implementations may only support a read-only option for hardening stage 1 translation table entries. This may simplify the implementation because read-only permissions may already be supported in stage 2 and enforcing read-only permissions does not require as complex control logic.

[0026] Other implementations may choose to support partial read-only permission, which may be useful because full read-only permission may prevent the access tracking metadata in the translation table entry from being updated by the memory management circuitry. Such metadata update write requests may be useful to allow tracking of the frequency of access to each memory region, which may be useful for software such as an operating system to determine, for example, which memory regions should be paged out to external storage and which should be kept in on-chip memory for faster access. Since the access tracking metadata may not affect the permissions that define which memory accesses are allowed for the corresponding address region, the access tracking metadata may be safely updated even if write accesses are not allowed for other parts of the stage 1 translation table entry. Thus, supporting partial read-only permission may provide a good balance between security and ease of programming for software developers.

[0027] In some implementations, for hardened stage 1 translation table entries, the only type of permission allowed in stage 2 may be partial read-only permission.

[0028] However, in other implementations, a given stage 1 translation table entry may be considered a hardened stage 1 translation table entry if either read-only or partial read-only permissions are defined in the stage 2 permission information of the corresponding stage 2 translation table entry that defines the stage 2 address mapping of the memory region that stores the given stage 1 translation table entry. Thus, it may be useful for the stage 2 permission information to have encodings to indicate both read-only and partial read-only memory regions, and for both of these encodings to allow the corresponding stage 1 translation table entry (stored in the memory region to which the stage 2 permission information applies) to be considered hardened. This gives the programmer of the hypervisor or other software executing in the second execution state the option to select whether read-only or partial read-only permissions are preferred to prevent tampering with the corresponding stage 1 translation table entry.

[0029] Setting stage 2 permissions to read-only or partial read-only may be useful to harden stage 1 translation table entries stored in the corresponding memory region, but in practice, stage 2 permissions are set at the granularity of a page, and many stage 1 translation table entries may be stored in a single page. It may not be necessary to protect all of the stage 1 translation table entries stored in a given page from tampering by a compromised operating system or other software executing in the first execution state. However, if any stage 1 translation table entries stored in a given page require hardening, then a read-only or partial read-only stage 2 permission set for that page may cause a write request (or, at least in the case of partial read-only permission, write requests other than the restricted subset of write requests) to fail, causing an exception handler to be executed. If it is still desired to allow the operating system to update a stage 1 translation table entry associated with non-sensitive information even though the corresponding memory region has been configured in stage 2 access permissions to have read-only or partial read-only permissions to protect other entries in that region from tampering, this may not be a problem because one approach may be to trap each update to the hypervisor, which can decide whether the update is allowed. However, such update requests may be relatively frequent, so trapping each regular translation table entry update to the hypervisor may cause a loss of performance.

[0030] Such a trap to the hypervisor can be avoided in the following implementation. -Supports partial read-only permissions as defined in the stage 2 permissions information, as described above; providing an encoding for each stage 1 translation table entry that specifies whether the stage 1 translation table entry is a protected entry that is restricted from updates as compared to non-protected stage 1 translation table entries that are not designated as protected entries; - Supports write request types that are included as one of a restricted subset of write request types that are permitted to write to partial read-only regions of memory, which are permitted to update unprotected stage 1 translation table entries but prohibited from updating at least a subset of the bits of protected stage 1 translation table entries.

[0031] In this approach, memory regions marked with partial read-only permissions using stage 2 permission information can contain a mix of protected and unprotected entries, so that the memory management circuitry hardware can prevent at least a subset of the protected bits in the protected stage 1 translation table entries from being updated, while the unprotected entries can still be updated by software despite being stored in the partial read-only region. This improves performance by eliminating the need to trap each update of the unprotected entries to the hypervisor.

[0032] For example, the restricted subset of write request types (which may update unprotected stage 1 translation table entries stored in a partial read-only region of memory) may include write requests issued in response to a protected entry check type read check write instruction. The device may have a protected entry check circuit responsive to the processing circuit executing a protected entry check type read check write instruction to request updates to a given memory system location, which reads data from the given memory system location, checks whether the data read from the given memory system location has a value matching a stage 1 translation table entry designated as a protected entry, and in response to determining that the data read from the given memory system location has a value matching a stage 1 translation table entry designated as a protected entry, prevents a subset of update-restricted bits of the stage 1 translation table entry from being updated in response to the read check write instruction. The update-restricted subset of bits may be all of the bits of the stage 1 translation table entry, or may be a suitable subset (less than all bits) of the bits of the stage 1 translation table entry. The update-restricted subset of bits may be defined as a fixed subset of the bits of the stage 1 translation table entry, or as a programmably defined subset of the bits of the protected stage 1 translation table entry (e.g., using control information stored in a control register that indicates which bits are the programmably defined subset of bits).By defining a special type of write request triggered by a particular type of read-check-write instruction that is permitted to update unprotected entries (and optionally the unprotected bits of protected entries) in the partial read-only region of memory (other types of write requests triggered by other load / store operations may not be considered one of the restricted subset of write request types that are permitted to update data stored in the partial read-only region), this can avoid the need to trigger an exception that traps to the hypervisor (to check whether the data being updated for a given write request is a protected entry) for every write to the partial read-only region of memory.

[0033] In implementations that support defining stage 1 translation table entries as protected, information indicating whether a given stage 1 translation table entry is designated as a protected entry may also be considered part of the translation hardening information. The memory management circuit may treat an unprotected stage 1 translation table entry as a non-hardened stage 1 translation table entry if the stage 2 permission information specified by the corresponding stage 2 translation table entry specifies that the given memory region is a partial read-only memory region (unprotected entries stored in a read-only memory region may still be considered hardened). Thus, each hardened stage 1 translation table entry may include one of a stage 1 translation table entry where the stage 2 permission information indicates that the given memory region is a read-only memory region where write requests are prohibited, and a stage 1 translation table entry where the stage 2 permission information indicates that the given memory region is a partial read-only memory region. Because unprotected stage 1 translation table entries can be modified in any way by software operating in a first execution state executing a read-check-write instruction of the protected-entry-check type, it is safest to treat them as not hardened, even when stored in a partial read-only memory region defined by stage 2 permission information. Because unprotected entries are not modifiable when stored in a read-only memory region, there is no need to impose a requirement that they be protected entries on entries stored in a read-only memory region.

[0034] It will be understood that designating translation table entries as protected or unprotected is not an essential feature and some implementations may not support it. For example, an implementation that is restricted to using stage 2 read-only permissions (but not partial read-only permissions) to harden stage 1 translation table entries may not need to support the protected entry encoding, and even if partial read-only permissions are supported, an implementation that does not support the protected / unprotected stage 1 translation table entry encoding may allocate only translation table entries that are intended to be hardened in stage 2 to specific pages marked with partial read-only permissions, or trap all writes to the corresponding regions to the hypervisor, which can then determine whether updates requested by the operating system in the first execution state are allowed depending on whether the data being updated is a stage 1 translation table entry that is intended to be hardened against tampering.

[0035] The above-mentioned translation hardening mechanism and anti-aliasing properties are not specifically directed to protecting translation entries used to access GCS data structures, but may be general architectural mechanisms that may also be used to protect against tampering and aliasing of other stage 1 translation table entries used for other data structures that provide sensitive information that is desired to be protected against tampering by a compromised operating system. An alternative approach is to define a dedicated encoding in the stage 2 permission information that identifies the corresponding memory region as a GCS memory region reserved for providing a guard control stack structure. In this alternative approach, the GCS stage 2 permission is applied to the memory region that actually stores the GCS data structure, as opposed to the above-mentioned translation hardening information (e.g., read-only or partial read-only permission) that is applied in stage 2 (by software when the device is in use) to the memory region that stores the stage 1 translation table entries used to provide access to the GCS data structure. However, a drawback of defining a dedicated GCS permission in stage 2 is that the amount of encoding space available to define permission information for a given stage 2 translation table entry may be limited, and thus defining a dedicated GCS permission may waste valuable encoding space that may be more useful for other purposes. By reusing generic architectural mechanisms applicable to harden stage 1 address translations against general tampering for the purposes of protecting the GCS structures, but rejecting GCS memory access requests if anti-aliasing properties are not specified for the target memory region (preventing GCS accesses when there is a risk that the translation hardening mechanisms have not been applied), the need to spend encoding space in stage 2 translation table entries on dedicated protection for the guard control stack data structures used to protect the return state information can be avoided, resulting in a more efficient encoding of the translation table structures.

[0036] Anti-aliasing properties need not be checked for GCS memory access requests issued in all operational states of the processing circuit. A GCS translation hardening check enable control parameter may be provided (e.g., in a control register) that may be set to an enabled state and a disabled state. At least one operational state of the processing circuit (in which the GCS memory access request is rejected if the anti-aliasing properties are not set for the target memory region) may include an operational state in which the GCS translation hardening check enable control parameter is set to an enabled state indicating that the GCS memory access request should be checked for whether the anti-aliasing properties are specified for the target memory region. When the GCS translation hardening check enable control parameter is in a disabled state, whether the GCS memory access request is allowed may be determined independently of whether the anti-aliasing properties are set for the target memory region (thus, when the GCS translation hardening check is disabled, the GCS memory access request may be allowed even if the anti-aliasing properties are not set for the target memory region). Providing enable / disable control for GCS transform hardening checks can be useful to allow backwards compatibility when running legacy software that may have been written for architectures that do not support anti-aliasing features, in which case the GCS anti-aliasing checks can be disabled.

[0037] As described above, a write request to a GCS region is rejected if it is not triggered by one of the restricted subset of GCS access type instructions (optionally, a read request can also be rejected if it is not triggered by a GCS access type instruction, but this is not required). The memory management circuitry may also reject a memory access request (including both write and read requests) in response to determining that the memory access request is a GCS memory access request and that the stage 1 permission information does not specify that the memory region corresponding to the target virtual address is a GCS region. This reduces the attack surface available to an attacker, since it means that a GCS memory access request can only be used to access a GCS region, and cannot be used to access normal memory regions used to store other data. This means that if the address operand of a GCS access type instruction is modified by an attacker (or made incorrect by an attacker forcing an incorrect sequence of program flow) such that the GCS memory access request accesses a non-GCS region, this is detected as an error and the memory access request is rejected.

[0038] A number of different types of instructions may be supported as part of the restricted subset of GCS access type instructions.

[0039] For example, the restricted subset of GCS access type instructions may include a return state push instruction that controls a processing circuit to push return state information obtained based on information indicated in one or more registers of the processing circuit into a GCS data structure. In some examples, the return state push instruction may be a dedicated GCS-specific instruction specialized in controlling the pushing of return state information into a GCS data structure. However, it is also possible that at least one variant of the return state push instruction is an instruction that, in addition to pushing return state information into a GCS data structure, controls the processing circuit to perform another operation (e.g., an operation often performed by software when calling a function or handling an exception). For example, the other operation may be a function call branch operation that triggers a branch to a target address and controls a function return address that is saved in a register (e.g., a register called a "link register"). For example, a "branch with link" instruction (for controlling a processing circuit to perform such a function call branch operation) may also function as a return state push instruction when executed in a GCS mode of the processing circuit to support use of the GCS data structure. When the GCS mode is disabled, a branch-with-link instruction may cause the processing circuitry to perform a function call branch operation but not to push return state information onto a stack data structure. When the GCS mode is enabled, a branch-with-link instruction may cause the processing circuitry to both perform a function call branch operation and push return state information onto a stack data structure (in this particular example, the return state information may include a function return address that was saved in a link register in response to the branch-with-link instruction).

[0040] The restricted subset of GCS access type instructions may also include a return state pop instruction that controls the processing circuit to pop return state information from the GCS data structure. In some examples, the return state pop instruction may also control the processing circuit to signal a failure condition in response to determining a mismatch between the return state information popped from the GCS data structure and the current return state information determined based on the information indicated in one or more registers of the processing circuit. In other examples, a separate return state verification instruction may be defined that does not itself pop return state information from the GCS data structure, but verifies whether the protective return state popped from the GCS data structure by a previous return state pop instruction matches the current return state information determined based on the information in the register. Many variants of the return state push and pop instructions may be supported in the instruction set architecture supported by the processing circuit, including, for example, variants specialized for pushing / popping exception return state information and function (procedure) return state information, respectively.

[0041] Again, the return state pop instruction may be a dedicated GCS specific instruction or a reused variant of another type of instruction that also performs another operation. For example, the return state pop instruction may also control the processing circuitry to perform an exception return. For example, when executed when GCS mode is disabled, the exception return instruction may control the processing circuitry to perform an exception return based on the intended exception return state information defined in a register (but without popping the protected return state information from the GCS data structure and verifying the intended exception return state information against the protected return state information). When the exception return instruction is executed in GCS mode, the exception return instruction may control the processing circuitry to perform both an exception return and popping the protected return state information from the GCS data structure and verifying the intended exception return state information against the protected return state information.

[0042] The apparatus may have at least one GCS pointer register for storing a stack pointer that indicates an address of a guard control stack data structure. GCS access type instructions may reference the stack pointer stored in the GCS pointer register to determine their target virtual address. In some examples, there may be one or more GCS pointer registers, each GCS pointer register indicating a stack pointer used in a respective execution state of the processing circuit.

[0043] When information is specified by a particular translation table entry (whether a stage 1 or stage 2 translation table entry), the information is either specified directly in the encoding of the translation table entry or indirectly specified by reference to information stored in a register referenced by the translation table entry. For example, in the case of indirect reference, a permission indirect register may be provided that contains a number of fields that can be set by software to indicate a particular permission type, and the translation table entry may specify field selection information that indicates which fields of the permission indirect register specify the permissions that apply to the corresponding memory region. This indirect permission approach can be used for a number of different permission types, including read-only or partial read-only permissions provided in stage 2 as described above, and / or defining a particular memory region as a GCS region in stage 1, and / or defining anti-aliasing characteristics for the target memory region. For example, stage 1 permission information specifying whether the target memory region is a GCS region may be specified in a field of the permission indirect register referenced by the target stage 1 translation table entry. Similarly, stage 2 permission information (specifying whether the target memory region is read-only or partial read-only) may also be specified in a field of the permission indirect register referenced by the target stage 2 translation table entry. Indirect permissions using the permission indirect register can be useful for a number of reasons. For example, indirect permission specification allows software to update the permission types that apply to two or more different memory regions (that all reference the same field in the permission indirect register) using a single write to the register, without having to update each separate translation table entry that corresponds to those memory regions.Also, because in some translation table entry formats there may be insufficient encoding space to encode all possible permission types that one wishes to encode, the use of permission indirection may allow a limited number of bits in the entry encoding itself to reference a larger field in the permission indirect register that may select from a wider range of permissions than is possible in the entry itself. Nonetheless, other approaches may specify the relevant permissions directly in the translation table entry encoding. Thus, where the application indicates that information is "specified by" a translation table entry, it will be understood that this information may be either directly specified in the translation table entry encoding or indirectly specified via the permission indirect register (or a mixture of both direct and indirect specification of information).

[0044] Also, in some implementations, a particular bit of a translation table entry, or permission information specified directly or indirectly by a translation table entry, may be interpreted differently depending on a control state specified in a control register of the device. For example, a control parameter stored in a control register may control whether a particular bit (or bit field) of the permission information is interpreted in a first way or a second way. This is useful for allowing legacy software to operate according to a legacy encoding scheme and newer software to interpret the same bit according to a different encoding scheme. Thus, when permission information is described as specifying some information (or having an encoding that identifies that information), in some cases, whether the permission information is considered to specify that information may depend on the current setting of at least one control parameter stored in at least one control register, so the permission information need not specify that information in all operating modes of the device.

[0045] The techniques described above may be implemented within a data processing apparatus having hardware circuitry provided for implementing the processing circuitry and memory management circuitry described above.

[0046] However, the same technique may also be implemented in a computer program that runs on a host data processing device to provide an instruction execution environment for execution of the target code. Such a computer program may control the host data processing device to simulate an architectural environment provided on a hardware device that actually supports the target code according to a particular instruction set architecture, even if the host data processing device itself does not support that architecture. The computer program may have processing program logic and memory management program logic that emulate the functionality of the processing circuitry and memory management circuitry described above, including support for GCS regions, translation hardening mechanisms, anti-aliasing properties, and monitoring (for GCS memory access requests) whether anti-aliasing properties are specified for the target memory region, as described above. Such a simulation program may be useful, for example, when legacy code written for one instruction set architecture is being executed on a host processor that supports a different instruction set architecture. Also, running the software on a simulation execution environment may enable testing of the software in parallel with ongoing development of hardware devices that support the new architecture, so that the simulation may enable software development of a new version of the instruction set architecture to begin before processing the hardware that supports the new architecture version. The simulation program may be stored on a storage medium, which may be a non-transitory storage medium.

[0047] Examples of data processing devices FIG. 1 shows a schematic diagram of an example of a data processing apparatus 2. The data processing apparatus has a processing pipeline 4 including several pipeline stages. In this example, the pipeline stages include a fetch stage 6 for fetching instructions from an instruction cache 8, a decode stage 10 for decoding the fetched program instructions to generate micro-operations (decoded instructions) that are processed by the remaining stages of the pipeline, an issue stage 12 for checking whether operands required for the micro-operation are available in a register file 14 and for issuing the micro-operation for execution once the operands required for a given micro-operation are available, an execute stage 16 for executing the data processing operation corresponding to the micro-operation by processing the operands read from the register file 14 to generate a result value, and a writeback stage 18 for writing the result of the processing back to the register file 14. It will be appreciated that this is just one example of a possible pipeline architecture and other systems may have additional stages or different arrangements of stages. For example, in an out-of-order processor, a register renaming stage may be included for mapping architectural registers specified by a program instruction or micro-operation to physical register specifiers that identify physical registers in the register file 14. In some examples, there may be a one-to-one relationship between program instructions decoded by the decode stage 10 and corresponding micro-operations processed by the execute stage. There may also be a one-to-many or many-to-one relationship between program instructions and micro-operations, such as a single program instruction being split into two or more micro-operations or two or more program instructions being fused together and processed as a single micro-operation.

[0048] The execution stage 16 includes several processing units for performing different classes of processing operations. For example, the execution units may include a scalar arithmetic / logic unit (ALU) 20 for performing arithmetic or logical operations on scalar operands read from the registers 14, a floating point unit 22 for performing operations on floating point values, a branch unit 24 for evaluating the results of branch operations and adjusting a program counter representing the current execution point accordingly, and a load / store unit 26 for performing load / store operations to access data in the memory system 8, 30, 32, 34. A memory management unit (MMU) 28, an example of a memory management circuit, is provided for performing address translation between a virtual address specified by the load / store unit 26 based on the operands of a data access instruction and a physical address that identifies a storage location of the data in the memory system. The MMU has a translation lookaside buffer (TLB) 29 for caching address translation data from page tables stored in the memory system, whose page table entries define the address translation mappings and may also specify access permissions that govern, for example, whether a given process executing on the pipeline is allowed to read, write, or execute instructions from a given memory region.

[0049] In this example, the memory system includes a level 1 data cache 30, a level 1 instruction cache 8, a shared level 2 cache 32, and a main system memory 34. It will be appreciated that this is only one example of a possible memory hierarchy and other arrangements of caches can be provided. The particular types of processing units 20-26 shown in the execution stage 16 are only one example and other implementations may have different sets of processing units or may include multiple instances of the same type of processing unit such that multiple micro-operations of the same type can be processed in parallel. It will be appreciated that FIG. 1 is only a simplified representation of some components of a possible processor pipeline implementation and that the processor may include many other elements that are not shown for the sake of brevity. Although FIG. 1 shows a single processor core with access to memory 34, device 2 may also have one or more further processor cores sharing access to memory 34, each core having a respective cache 8, 30, 32.

[0050] 2 is a diagram illustrating different execution states (also called exception levels) that a processing circuit 4 may operate in when executing instructions. In this example, there are four exception levels EL0, EL1, EL2, EL3, with exception level EL0 being the least privileged exception level and exception level EL3 being the most privileged exception level. In general, when executing at a more privileged exception level, the processing circuit may access some memory locations or registers 14 that are inaccessible to less privileged exception levels.

[0051] In this example, exception level EL0 is for running applications managed by a corresponding operating system or virtual machine running at exception level EL1. When multiple virtual machines coexist on the same physical platform, a hypervisor operating at EL2 may be provided to manage each virtual machine. Although Figure 2 shows an example in which the hypervisor manages the virtual machines and the virtual machines manage the applications, it is also possible for the hypervisor to directly manage applications at EL0.

[0052] Although not required, some implementations may implement separate hardware partitioned secure and non-secure operating domains for processing circuitry. Data processing system 2 may have hardware features implemented in the processor and memory systems to ensure that data and code associated with software processes operating in the secure domain are isolated from access by processes operating in the non-secure domain. For example, a hardware architecture such as the TrustZone® architecture offered by Arm® Limited of Cambridge, UK may be used. Alternatively, other hardware-enforced security partitioning architectures may be used. Secure applications (trusted services) may run at exception level EL0 in the secure domain, and secure (trusted) operating systems or virtual machines may run at exception level EL1 in the secure domain. In some implementations, there is no support for EL2 in the secure state, and the hypervisor may only run in non-secure EL2. In other implementations, there may be support for a secure hypervisor running in secure EL2, as indicated by the asterisk in FIG. 2. In some examples, a secure monitor program may be provided running at exception level EL3 to manage transitions between non-secure and secure domains. Other implementations may monitor transitions between security domains in hardware, such that a secure monitor program may not be required.

[0053] Address Translation One task performed by the MMU 28 is address translation between virtual addresses (VA) and physical addresses (PA). Software executing on the processing circuitry 4 uses virtual addresses to specify memory locations, but these virtual addresses may be translated by the MMU 28 into physical addresses that identify the memory system locations to be accessed. An advantage of using virtual addresses is that it allows management software, such as an Operating System (OS), to control the view of memory that is presented to the software. The OS can control what memory is visible, the virtual addresses to which that memory is visible, and what accesses are allowed to that memory. This allows the OS to sandbox applications (hide the resources of one application from another) and provide abstraction from the underlying hardware. Another advantage of using virtual addresses is that the OS can present multiple fragmented physical regions of memory to an application as a single contiguous virtual address space. Virtual addresses also benefit software developers who do not know the exact memory addresses of the system when writing their applications. With virtual addresses, software developers do not need to be concerned with physical memory. Applications know that it is up to the OS and hardware to cooperate to perform the address translation.

[0054] In practice, each application can use its own set of virtual addresses that are mapped to different locations in the physical system. When the operating system switches between different applications, it reprograms the maps, which means that the virtual addresses of the current application are mapped to the correct physical locations in memory.

[0055] Virtual addresses are translated to physical addresses through a mapping. The mapping between virtual and physical addresses is stored in a translation table (sometimes called a page table). The translation table is stored in memory and managed by software, typically an OS or a hypervisor. The translation table is not static; the table can be updated as the needs of the software change. This changes the mapping between virtual and physical addresses.

[0056] For memory accesses performed when the processing circuitry 4 is in a particular subset of execution states (in particular, when the processing circuitry 4 is in non-secure EL0 or non-secure EL1), a two-stage address translation is used as shown in FIG. 3 (for other execution states, one stage of address translation using stage 1 page tables is sufficient). Thus, virtual addresses from non-secure EL0 and non-secure EL1 are translated using two sets of tables. These tables support virtualization and allow the hypervisor to virtualize the view of physical memory seen by a given virtual machine (VM) (a virtual machine corresponding to a guest operating system and the applications controlled by that guest operating system). The set of translations controlled by the OS is called stage 1. The stage 1 tables translate virtual addresses into intermediate physical addresses (IPAs - an example of the intermediate addresses mentioned above). In stage 1, the OS thinks that the IPA is a physical address space. However, the hypervisor controls a second set of translations called stage 2. This second set of translations translates the IPA into a physical address.

[0057] The stage 1 translation table and the stage 2 translation table are implemented as a hierarchical table structure that includes several levels of translation tables as shown in Figures 4 and 5 for stage 1 and stage 2, respectively. In this example, both the stage 1 table and the stage 2 table can have up to four levels of page tables, namely level 0 (level 0, L0), level 1 (level 1, L1), level 2 (level 2, L2), and level 3 (level 3, L3).

[0058] To find a physical address mapping for a given address, a translation table walk is performed that includes one or more translation table lookups. A translation table walk is the set of lookups required to translate a virtual address to a physical address. For the non-secure EL1&0 translation regime, this set includes both stage 1 and stage 2 translation lookups (see FIG. 6 below). The information returned by a successful translation table walk using stage 1 and stage 2 lookups is as follows: ● The required physical address (translated based on the stage 1 mapping to intermediate addresses and the stage 2 mapping to physical addresses). Access permissions and / or memory attributes for the target memory region, providing information about how to control access to that memory region. These may include stage 1 access permissions and / or attributes defined in the stage 1 table structures, and stage 2 access permissions and / or attributes defined in the stage 2 table structures.

[0059] To traverse a given one of the Stage 1 and Stage 2 structures, the walk begins with reading the top-level (L0) translation table for an initial lookup, based on the address specified in the Translation Table Base Address Register (TTBR for Stage 1, VTTBR_EL2 for Stage 2). Each translation table lookup returns a descriptor indicating one of the following: ● The entry is the last entry in the traversal of the stage 1 or stage 2 structures and provides the address mapping that is sought. If the entry is in the last L3, this entry is called a page descriptor (D_Page), while if the entry providing the last entry of the walk is in one of the higher levels, it is called a block descriptor (D_Block). The last entry of the traversal contains the output address (OA, i.e. IPA in stage 1 or PA in stage 2) and the access permissions and attributes. If a block descriptor is found at a higher level of the translation table structure, this means that the block descriptor represents a memory region of a size larger than the 4kB memory page represented by a single entry in L3 (the specific size represented by the block descriptor in L1 and L2 depends on the number of index bits used to index the L1 or L2 table, in this example the L1 and L2 block descriptors represent 1GB and 2MB regions, respectively). An additional level of lookup is required. In this case, the entry is called a Table Descriptor (D_Table) because it provides the translation table base address for that lookup in the further level table. The table descriptor can optionally also provide other hierarchical attributes that can be applied to the final translation. The encoding of the translation table entries at level 1 and level 2 distinguishes block descriptors from table descriptors. The descriptor is invalid. In this case, the memory access generates a conversion failure.

[0060] FIG. 4 illustrates indexing of the stage 1 translation tables using respective bits of the virtual address provided as the input address for the table lookup. The base address of the top level table L0 is read from the TTBR, and the base addresses of the L1, L2, and L3 tables are indicated by the addresses stored in the indexed table descriptors in the L0, L1, and L2 tables, respectively (if no block descriptor is identified in the L1 or L2 tables, and if a block descriptor is found in the indexed entry of L1 or L2, the traversal stops at that level since the output address mapping has already been found). The particular entry to select within a given level of the stage 1 translation table is determined based on index values ​​a, b, c, and d that correspond to some subset of the bits of the virtual address provided as the input address for the lookup. FIG. 4 illustrates which bits of the input address are used for each index value a, b, c, and d in one particular example. The address of the associated entry in a given table is obtained by adding a multiple of index bits a, b, c, or d to the base address of that given table, as determined based on the TTBR, or to the address specified in the previous level table descriptor (the multiplier is applied to the index value corresponding to the size of one translation table entry).

[0061] Similarly, FIG. 5 illustrates indexing of the stage 2 translation table using respective bits of the intermediate address provided as the input address for the stage 2 table lookup. The indexing is similar to that shown in FIG. 4 for stage 1, but uses a different base address register VTTBR_EL2 to provide the base address of the L0 table. As shown in the example of FIG. 5, for stage 2 lookup, it is possible to change the starting level at which the walk of the stage 2 translation table begins based on the value stored in a control register VTCR_EL2.SL0, which can specify that the lookup should start from either L0 or L1. If the stage 2 lookup starts from L0, the indexing for levels 0, 1, 2, 3 uses index values ​​a, b1, c, d respectively, as in FIG. 4 for stage 1. If the stage 2 lookup starts from L1, the indexing is performed in a similar manner, but now more index bits b2 are used at the top level (L1) of the lookup, as shown in FIG. 5. Providing a variable starting level is not an essential feature and can be omitted if desired. Although not shown in FIG. 4, it is also possible to provide a variable starting level for the lookup in stage 1.

[0062] 6, in practice, when a full translation table walk is performed that includes both stage 1 and stage 2 translations, each stage 1 table base address obtained from the TTBR and table descriptor accessed in the stage 1 L0, L1, L2 translation tables becomes an intermediate address that itself needs to be translated using the stage 2 translation table. Thus, if the translation table walk does not encounter a block descriptor and continues all the way to L3 where a page descriptor is found, the full page table walk process can include accessing multiple levels of page tables in the following sequence: ●Stage 2 translation of the stage 1 L0 page table base address to a physical address (the stage 1 L0 base address is usually an intermediate physical address because the stage 1 translation is constructed by the operating system). The stage 2 translation is four lookups (stage 2 L0; stage 2 L1; stage 2 L2; stage 2 L3). ● Stage 1 L0 lookup of an entry at the address obtained based on the L0 index portion “a” of the target virtual address and the translated stage 1 L0 base address to obtain the stage 1 L1 base address (intermediate physical address). ●Stage 2 translation of Stage 1 L1 base address to physical address (again involving 4 lookups). ● Stage 1 L1 lookup of an entry at the address obtained based on the L1 index portion 'b' of the target virtual address and the translated stage 1 L1 base address to obtain the stage 1 L2 base address (intermediate physical address). ●Stage 1 Stage 2 translation of L2 base address to physical address (again involving 4 lookups). ● Stage 1 L2 lookup of an entry at the address obtained based on the L2 index portion 'c' of the target virtual address and the translated stage 1 L2 base address to obtain the stage 1 L3 base address (intermediate physical address). ●Stage 2 translation of Stage 1 L3 base address to physical address (again involving 4 lookups). ● Stage 1 L3 lookup of an entry at the address obtained based on the L3 index portion "d" of the target virtual address and the translated stage 1 L3 base address to identify a target intermediate physical address corresponding to the target virtual address. Stage 2 translation of the target intermediate physical address to a target physical address (again involving four lookups), which represents the location in memory to access corresponding to the original target virtual address.

[0063] Thus, assuming no caching and the stage 2 starting level is L0, the translation will involve a total of 24 lookups. If the starting level for stage 2 is L1, this can reduce the number of lookups to 19 (one less lookup for each of the five stage 2 translations performed). Nevertheless, as can be seen from the above sequence, performing the entire page table walk process can be very slow as it may require numerous accesses to memory to step through each of the levels of page tables in each of the stages of the address translation. This is why it is often desirable to cache information derived from the translation table walk in the TLB 29 of the MMU 28. The cached information may include not only the final stage 1 address mapping of VA to IPA, the final stage 2 mapping of IPA to PA, or the combined stage 1 and stage 2 mapping directly from VA to PA (derived from previous lookups of the stage 1 and stage 2 structures), but also entries from the higher level page tables of the stage 1 and stage 2 tables may be cached in the TLB 29 of the MMU 28. This allows at least some steps of a full page table walk to be bypassed even if the last level address mapping for a given target address is not currently in the address translation cache.

[0064] 6 is annotated with information specifying certain permissions or characteristics that may be defined for some of the translation table entries involved in the two-stage address translation. These permissions and characteristics will be described below and in more detail later.

[0065] Memory Management Unit ExampleFIG. 7 illustrates memory management unit 28 in more detail. Although FIGS. 1 and 7 illustrate a single MMU 28 for simplicity, separate instruction-side and data-side MMUs may be provided to handle memory management operations for instruction fetch accesses initiated by fetch stage 6 and data accesses initiated by load / store unit 26, respectively, in which case both the instruction-side and data-side MMUs may have the components shown in FIG. 7. Similar to TLB 29, MMU 28 includes access control circuitry 50 for checking access permissions specified in looked-up translation table entries and controlling processing of memory access requests in accordance with those access permissions. For example, access control circuitry 50 may implement a check to determine whether a particular type of memory access request (e.g., based on whether the request is a read request, a write request, or an instruction fetch request, or based on the type of instruction executed that caused the request to be issued) satisfies the permissions specified in the corresponding translation table entry for a given region of memory being accessed. The MMU also includes a translation table walk control circuit 52 that issues memory access requests to memory to request the reading of translation table entries during the translation table walk process illustrated above in FIGS. 4-6 if the required information from the translation table is not already available in the TLB 29. The translation table walk control circuit 52 may be responsible for generating addresses of memory system locations that are read to obtain associated translation table entries in the stage 1 or stage 2 translation table structures. Additionally, while performing a translation table walk, the translation table walk control circuit 52 may generate metadata update write requests requesting updates to access tracking metadata in a particular translation table entry being traversed in the translation table walk. These metadata update write requests may update the access tracking metadata to reflect that a particular memory region has been accessed, which may be useful for managing operations such as paging.Because the address of a metadata update write request is the address of a translation table entry accessed in a translation table walk, rather than the address of the data or instruction being accessed, the metadata update write request is generated in hardware to specify an address that is not directly specified as the instruction fetch address, or a load / store target address that is derived from an operand of the load / store instruction executed by processing circuitry 4.

[0066] MMU 28 has access to various control registers for controlling translation table walks and other aspects of memory management operations. For example, the control registers may include a stage 1 base address register TTBR_EL1 and a stage 2 base address register VTTBR_EL2, as described above with respect to Figures 4 and 5. The stage 1 base address in register TTBR_EL1 is writable in response to an instruction executing at exception level EL1, EL2, or EL3 (i.e., in a first execution state or an execution state with greater privileges than the first execution state). The stage 2 base address in register TTBR_EL2 is writable in response to an instruction executing at exception level EL2 or EL3 (i.e., in a second execution state or an execution state with greater privileges than the second execution state). In some cases, a control value may be set to indicate that a write to TTBR_EL1 triggered by an instruction executing at EL1 should be trapped to EL2, allowing a hypervisor running at EL2 to check for updates being requested by the operating system and prevent the updates if necessary. The control registers also include registers TCR_EL1, VTCR_EL2, which are used to specify various control status values ​​that affect how stage 1 and stage 2 translation and access permission checks are performed. For example, a control value that specifies the starting level for the stage 2 walk may be specified in VTCR_EL2. The TCR_EL1 or VTCR_EL2 control registers may also specify control values ​​that specify what types of security checks are enabled / disabled. As will be described in more detail below, the control registers may also include mask registers (labeled RCWMask_Valid_EL2 and RCWMask_Invalid_EL2) to specify a subset of update-restricted bits that are restricted from being updated in the protected stage 1 translation table entries for valid and invalid entries, respectively. It will be understood that additional control registers may be provided and that the labels used for the control registers may be modified.For example, one or more permission indirect registers may be provided to specify indirect access permission information that may be referenced by a given translation table entry to specify access permission information for the given translation table entry. Also, the same information may be placed in the control registers in different formats, and thus the particular assignment of information to one control register or another is not an essential feature.

[0067] As shown in FIG. 7, the device may have a protection entry check circuit 54 for performing a protection entry check when an update is requested for a stage 1 translation table entry encoded as a protection entry (as described in more detail below). As indicated by the dotted lines in FIG. 7, it is possible to implement the protection entry check circuit 54 at different locations within the processing system. For example, the protection entry check circuit 54 may be part of the access control circuit 50 of the MMU 28. Alternatively, the protection entry check circuit may be implemented within a memory system component 56 that is closer to the physical memory system location being accessed by a given memory access request that is to be checked using the protection entry check circuit 54. For example, the memory system component 56 may be a cache 30, 32, an interconnect used to manage access to a shared memory by multiple processor cores, or a memory controller associated with a particular memory storage unit. Also, the protection entry check circuit 54 may include distributed logic at multiple locations within the system (e.g., the MMU 28, the load / store unit 26, and / or the memory system component 56).

[0068] Translation table access permissions and attributes 8 illustrates an example format of a translation table entry in a stage 1 translation table structure and a stage 2 translation table structure. It will be understood that the same information may be represented in different arrangements, and thus the particular ordering and layout of the fields in the descriptor may differ from that shown in FIG.

[0069] In this example, a valid translation table descriptor has its least significant bit set to 1 and an invalid translation table descriptor has its least significant bit set to 0. For a valid descriptor read at one of levels 0, 1, 2 of the translation table structure, the second least significant bit distinguishes whether the descriptor is a table descriptor (second least significant bit set to 1) or a block descriptor (second least significant bit set to 0). A page descriptor in L3 of the stage 1 or stage 2 structure may have its second least significant bit set to 1 to allow page descriptors to be distinguished from block descriptors. Of course, valid / invalid entries and table / block / page descriptors can also be distinguished by other encoding methods.

[0070] For both stage 1 and stage 2 entries, the valid table descriptor provides a next level table address 60 that indicates the base address of the translation table at the next level of the stage 1 or stage 2 translation table structure. The valid stage 1 block or page descriptor provides an intermediate address mapping 62 that corresponds to the virtual address used to index the stage 1 translation table structure. The valid stage 2 block or page descriptor provides a physical address mapping 64 that corresponds to the intermediate address used to index the stage 2 translation table structure.

[0071] The stage 1 block and page descriptors also provide stage 1 access permissions 66 that are used to control access to the corresponding memory region. For example, stage 1 access permissions 66 (typically set by the OS in EL1) may specify whether a region is permitted to be read, written, and / or used for instruction fetching of executable instructions.

[0072] Similarly, the stage 2 block and page descriptors provide stage 2 access permissions 68 that are used to control access to the corresponding memory region. Again, the stage 2 access permissions 68 (typically set by the hypervisor in EL2) may specify whether the region is permitted to be read, written, and / or used for instruction fetching of executable instructions. If there is a conflict between the stage 1 access permissions 66 and the stage 2 access permissions 68, the more restrictive set of attributes may take precedence.

[0073] A stage 1 block / page descriptor or stage 2 block / page descriptor may also specify other attributes associated with a memory region that are not shown in Figure 8. For example, these attributes may specify characteristics such as whether caching of data from the corresponding memory region is permitted, whether the region is defined as device memory such that reordering or merging of different memory accesses to device memory is not permitted, etc.

[0074] Stage 1 block / page descriptors may also specify access tracking metadata that may be used by the operating system to track the frequency of access to a given memory region. For example, the metadata may include access flags (AF) 70 and dirty bit modifiers (DBM) 72.

[0075] Periodically, the operating system may clear the access flags in the entries corresponding to the set of memory regions being monitored. When a read access is made to one of these memory regions, the access flag 70 may be set in the corresponding stage 1 block or page descriptor (if not already set following a previous access) (the memory access request that causes the access flag 70 to be set may be one of the metadata update write requests generated by the translation table walk control circuit 52 described above). After a monitoring period, the operating system may check the access flag 70 to assist operations that may benefit from information about how frequently a particular page is accessed. For example, the operating system may maintain in memory a further tracking data structure having an entry for each memory region that tracks how many times the memory region has been accessed, and thus increment the entries in that further tracking structure that correspond to memory regions that have the access flag 70 set at the end of each monitoring period. Thus, after several monitoring periods, the further tracking structure provides an indication of the relative frequency of accesses to the corresponding memory region. This can provide useful information for controlling operations such as paging; it can be useful to know the least frequently accessed pages of memory whose corresponding data may be prioritized for paging out to external storage compared to other, more frequently accessed pages.

[0076] Similarly, DBM 72 helps track which pages have been written to. If the operating system wants to track whether a given page has been written to, then when the page is mapped or at the start of a monitoring period, the operating system can set the access permissions for that page as "read-only" (even though the page is intended to be allowed to be written to) and set DBM bit 72. If a access permission failure is caused by a write to a read-only page when DBM bit 72 is set, the operating system can determine that this is not a "true" violation of read-only permissions because DBM bit 72 is set, and can instead cause the operating system to update data structures stored in memory that track pages that receive write requests, and update the write access permissions for the page to indicate that the page can now be written to without triggering a failure. After a monitoring period, the tracking data structures in memory can be used by software to determine whether modified data from a particular region needs to be written back to external storage when paging out that region, or (if no write has occurred) whether the corresponding data in external memory can be assumed to still be the same if the data is clean, and therefore the data stored in the on-chip memory can simply be discarded when paging out the region.

[0077] The access flags 70 and dirty bit modifiers 72 are merely some examples of possible access tracking data that may be stored in a translation table entry, and other examples may provide other types of access tracking metadata. For example, in another example, a multi-bit access counter may be provided as the access tracking metadata. Also, in another example, instead of the DBM bits 72 being used to modify the handling of read-only access permission violations for write requests and trigger updates to the write permissions, the DBM flags 72 may be updated directly in response to the first write to the page after clearing the DBM flags 72, in a manner similar to how the access flags 70 are updated on the first access to the page, as described above.

[0078] As shown in Figure 8, the various translation table descriptors may also contain several other information that may be useful in protecting stage 1 translation table entries from corruption by operating system code under attack by an attacker. Typical operating system code may contain many lines of code that may be difficult to fully verify as safe against attack, and therefore it is desirable to provide an architectural mechanism to protect against the possibility that an attacker may be able to modify the behavior of the operating system code to cause writes to memory regions used to store translation table entries, and may be able to modify the address mappings or permissions within these entries to give the attacker the right to access memory regions in an unauthorized manner.

[0079] As shown in FIG. 8, to provide a translation hardening mechanism, the additional attributes and permissions described below for hardening the stage 1 translation table against attacks include: ●The stage 2 block / page descriptor specifies stage 2 access permissions 68 having an encoding that indicates whether the corresponding memory region has partially read-only (PRO) permission (partially read-only permission can also be referred to as ``mostly read-only'' permission). ● Valid stage 1 descriptors (including table descriptors and block / page descriptors) at all levels of the stage 1 translation table structure have an encoding that specifies whether the translation table entry is a "protected" entry, which provides additional protection against unauthorized updates compared to non-protected entries. For example, a bit field 76 in the valid stage 1 descriptor may indicate whether the entry is a protected entry. ● Invalid stage 1 descriptors at all levels of the stage 1 translation table structure may also have an encoding that specifies whether the translation table entry is a "protected" entry. This may be indicated using a bit field 78 that may be in a different position within the translation table entry encoding compared to the bit field 76 used to represent a protected entry for a valid stage 1 translation table entry. ● A stage 2 block / page descriptor may have an indicator 79 that specifies whether the corresponding memory region has anti-aliasing properties. In some examples, the presence or absence of anti-aliasing properties may be encoded in a combined bit field that may also signal other types of properties, or alternatively, the anti-aliasing bit field may be a standalone bit field that does not signal other information. If specified, the anti-aliasing property indicates that in order for access to the corresponding physical address to be permitted, all stage 1 translation table entries accessed in the translation table walk to obtain the intermediate address used to access that stage 2 descriptor must be designated as protected entries using bit field 76, and the corresponding stage 2 block / page descriptor must be stored in a region of memory that indicates partial read-only permission 74. ● The stage 2 block / page descriptor may also specify in stage 2 access permission 68 a stage 1 top level entry presence permission 80 indicating whether the corresponding memory region is permitted to hold a top level translation table for stage 1 translation (i.e., the stage 1 L0 table in the examples of Figures 4 and 6). In one example, the encoding of stage 2 access permission 68 may be such that the stage 1 top level entry presence permission is encoded as a further attribute of the PRO permission, and thus the values ​​allowed to be encoded for stage 2 access permission 68 may include values ​​indicating: ○ Stage 1 PRO permission without top-level entry existence permission, ○ PRO authorization with Stage 1 top-level entry existence authorization, or o One or more other types of permissions (eg, read-only, read / write, and / or execute) that do not have either PRO or stage 1 top-level entry existence permissions.

[0080] In this case, it may not be possible to specify the stage 1 top-level entry presence permission independently of the PRO permission. However, other implementations may encode the stage 1 top-level entry presence permission independently of the PRO permission, such that the stage 1 top-level entry presence permission may be specified even if the PRO permission is not provided.

[0081] The use of these attributes and permissions is described in more detail below. It will be understood that not all of these attributes need to be supported in every possible implementation. Although FIG. 8 shows an example where the S1 and S2 access permissions are specified directly in the encoding of the translation table entry, it is also possible to indirectly specify the same information using permissions specified in a permission register. For example, the S1 or S2 permission field 66, 68 can specify an index value that selects which of several permission fields of the permission register specify the access permissions for the corresponding translation table entry. It is also possible that some fields of the translation table entry can be interpreted differently depending on the control state stored in the control register. For example, the protected entry field 76 of the stage 1 translation table entry can be interpreted as indicating whether the stage 1 translation table entry is protected when the control value stored in the control register has a first value, and can be interpreted differently when the control value has a second value. Similarly, the anti-aliasing characteristics field 79 of the stage 2 translation table entry may be interpreted as indicating whether the stage 2 translation table entry has anti-aliasing characteristics when the control value stored in the control register has a first value, and may be interpreted in a different manner when the control value has a second value.

[0082] Although S1 permissions 66 and S2 permissions 68 are shown as being specified directly by the corresponding S1 or S2 descriptors, these permissions (or other information specified by a translation table entry) may also be specified indirectly using indirect registers, as shown below with respect to FIG. 18.

[0083] Partial Read-Only Permission 9 summarizes the write access control behavior for memory regions marked by stage 2 access permission 68 as having partial read-only (PRO) permission. A memory region with PRO permission is writable for a restricted subset of write request types, at least for write requests issued when the current execution state is EL1 (the state in which operating system code is expected to execute), but is treated as read-only for write request types. Since only some write request types consider the memory region read-only, the permission is therefore described as partial read-only permission.

[0084] FIG. 9 summarizes the types of write requests permitted and prohibited to write to memory regions where a corresponding stage 2 translation table entry defines the region as having PRO permission. The restricted subset of write request types permitted to write to PRO regions when the write is issued at EL1 includes metadata update write requests generated by MMU 28 to update access tracking metadata in a translation table entry, such as writes permitted when access flags 70 or dirty bit modifier 72 are set as described above. The restricted subset may also include at least one predetermined type of translation table entry update instruction executed in exception state EL1, which may be a dedicated type of instruction intended for use in updating translation table entries to express the intent of the program code to distinguish such writes to update translation table entries from writes to update data other than translation table entries. For example, the predetermined type of translation table entry update instruction may include a variant of the Protected Entry Check Read Check Write (RCW) instruction described with respect to FIGS. 12-14 below. 9, write requests issued in response to at least one other type of store instruction executed in one of exception states EL0 and EL1 are prohibited from writing to a PRO region of memory. For example, the prohibited write request types may include a majority of store instructions in the instruction set architecture supported by processing circuit 4. By restricting the ability to update translation table entries when a region is marked PRO-permitted to a limited set of instruction types, this reduces the attack surface available to an attacker when attempting to corrupt stage 1 translation table entries; for example, tampering with the address operand of a general purpose store that is not one of the restricted subset of write requests will disallow access to a PRO region of memory.

[0085] Optionally, a write request issued in response to a store instruction executed in one of execution states EL2 or EL3 may be permitted to write to a partial read-only region, even if the store instruction is of a type that would have been prohibited from writing to that region if executed in execution state EL0 or execution state EL1, although this is not required as discussed above.

[0086] FIG. 10 is a flow diagram illustrating a method for processing instructions and controlling memory management operations. In step 500, the processing circuitry 4 processes instructions in one of a plurality of execution states EL0-EL3 associated with different privilege levels. In step 502, in response to the memory access request, the MMU 28 performs a two-stage address translation of a target virtual address (VA) specified by the memory access request to a target physical address (PA), where the mapping of the target VA to the target PA depends on a stage 1 address mapping from the target VA to a target intermediate address (IPA) and a stage 2 address mapping from the target IPA to the target PA. In step 504, the access control circuitry 50 of the MMU 28 performs a permission check for the memory access request based at least on the stage 2 access permission information 68 specified in the corresponding stage 2 translation table entry. The permission check may also be based on the stage 1 access permission information 66. The stage 2 access permission information 66 has an encoding that specifies whether the memory region corresponding to the target IPA has PRO permission. In step 506, MMU 28 rejects the memory access request if the memory access request is a write request issued in a predetermined execution state (e.g., EL1), the stage 2 access permission information specifies PRO permission, and the write request is a write request type other than the restricted subset of write request types permitted for writing to a PRO region of memory. Optionally, MMU 28 can also reject the memory access request when the memory access request is a write request issued in an execution state other than the predetermined execution state (e.g., EL0) when PRO permission is specified by the stage 2 access permission information and the write request type is not one of the restricted subset of write request types.

[0087] 11 illustrates in more detail the partial read-only check performed by access control circuit 50 of MMU 28. In step 600, a write memory access request is issued when processing circuit 4 is in a predefined execution state (EL1). The write request specifies a target VA. The write request may have been issued by load / store unit 26 of processing circuit 4 in response to a load / store instruction executed by the processing circuit, or by fetch stage 6 when requesting an instruction fetch. The write request may be a metadata update write request issued by MMU 28 to update access tracking metadata in a translation table entry during a translation table walk process.

[0088] In step 602, the target VA is translated to a target PA that identifies the memory system location to be accessed. To perform the translation, MMU 28 may look up the target VA in TLB 29; if a mapping from the target VA to the target PA is already available in TLB 29, no translation table walk is required. Otherwise, at least a portion of the translation table walk process shown in FIG. 6 may be required, but it may be possible to skip some portions if information derived from the corresponding translation table entry for that portion of the translation table walk is already cached in TLB 29. For write memory access requests issued from non-secure EL1, the translation is performed as a two-stage address translation based on mappings defined in both the stage 1 translation table and the stage 2 translation table; however, this does not necessarily mean that two separate translations need to be performed, since a combined stage 1 / stage 2 TLB can be provided that caches a direct mapping from the target VA to the target PA (which depends on both the stage 1 and stage 2 mappings) along with the corresponding stage 1 permission information and stage 2 permission information to avoid the need for the target IPA to be explicitly determined.

[0089] In step 604, the access control circuit checks whether the corresponding stage-2 (S2) translation table entry (a stage-2 entry that specifies a mapping from a target IPA to a target PA) specifies PRO permission. If so, in step 606, the access control circuit checks whether the write request being processed is one of a restricted subset of write request types. If the current write request is not one of the restricted subset of write request types (including at least a metadata update write request), in step 608, the memory access request is rejected and a failure is notified. If the write request is one of the restricted subset of write request types, the partial read-only check passes, and thus the method proceeds to step 610. Also, in step 604, if the corresponding stage-2 translation table entry did not specify PRO permission, the partial read-only check in step 606 can be omitted, and thus the method proceeds directly from step 604 to step 610.

[0090] In step 610, the access control circuitry determines whether any other checks required to allow the write memory access request to proceed are satisfied. For example, these checks may include checks using stage 1 access permissions 66, checks using other stage 2 access permissions 68 if PRO permission is not specified, security checks based on whether the request was issued from a secure state or a non-secure state (in implementations that support a secure state), as well as other checks specific to a particular instruction type, such as the checks described below with respect to Figures 12-14 regarding whether the data at the target memory location is a protected translation table entry. If any of these other checks are not satisfied, then again in step 608, the memory access request is rejected and a failure is signaled. Failure syndrome information may be set to distinguish the cause of the failure. If the checks performed in step 610 are satisfied, then in step 612, the memory access request may be allowed to proceed, and thus the memory system location associated with the target PA may be updated with the write data specified by the write request.

[0091] Thus, as shown in FIG. 6 described above, PRO permissions may be specified in stage 2 access permissions 68 of stage 2 translation table entries used to provide physical addresses of memory system locations that hold various levels of stage 1 translation tables used in traversing the stage 1 table structures to obtain intermediate addresses of memory regions containing sensitive information. This protects those stage 1 translation entries from corruption by mis-functioning code or operating system code under attack by a malicious party, since PRO permissions restrict the ability to write to the corresponding memory regions to a limited subset of instruction types, greatly reducing the number of lines of code that may be vulnerable to corruption of the stage 1 translation tables. Nevertheless, hardware-generated write requests to update access tracking metadata in the translation table entries may still be permitted for such regions to avoid compromising the efficiency of paging operations by the operating system.

[0092] FIG. 11 illustrates the partial read-only check being performed for write memory access requests issued when in a given execution state EL1, but it can also be performed for other execution states. However, this may not be required since for write requests issued in the least privileged execution state EL0, the memory region holding the stage 1 translation table is likely to be marked as inaccessible to application level code running at EL0 by stage 1 access permission 66 in any case, and thus the stage 1 permission check can already prevent such write requests from corrupting the stage 1 translation table. Also, for code running at EL2 or EL3, the translation table is unlikely to use two-stage address translation and restrict writes to the region storing the stage 1 translation table entries, since the hypervisor or monitor code is likely to be the code controlling the restrictions on what updates are allowed to the stage 1 translation table. Thus, some implementations may restrict the partial read-only check to be performed only when the current execution state is EL1. Other implementations may apply the partial read-only check regardless of which execution state is the current execution state.

[0093] Protected entry encoding for stage 1 translation table entries Using PRO permissions to mark certain memory regions as read-only for write requests other than a restricted subset of write types helps protect the stage 1 tables from corruption. However, as shown in Figure 6, typically a given translation table at a given level of the translation table structure occupies an entire page in memory, and therefore PRO permissions apply to the entire translation table at a given level of the stage 1 translation table structure, which may include translation table entries for various memory regions, which may include some memory regions used for sensitive information that needs to be protected against unauthorized access and other memory regions that contain only non-sensitive information that does not require this protection.

[0094] As described further below, it is possible to provide implementations that do not support the use of protected entry encoding for stage 1 translation table entries. In this case, to allow an operating system to update certain stage 1 translation table entries associated with unprotected areas that contain non-sensitive information, a failure generated during a write access to a PRO area that is not one of the write request types permitted for writing to a PRO area may cause a trap to a hypervisor operating at EL2, which may determine in software whether the area in which the operating system wants to update a stage 1 translation table entry should be protected from being updated by the operating system, and if the area does not need to be protected, may allow the update requested by the operating system to proceed. In practice, however, an operating system may need to modify translation table entries in unprotected areas of memory relatively frequently, and therefore trapping to the hypervisor every time an update is needed may be slow in terms of performance.

[0095] The protected entry encoding for stage 1 translation table entries (e.g., using bits 76, 78) helps to allow the operating system to make updates to unprotected entries without hypervisor intervention (and, optionally, in some implementations, to make updates to the no-update restricted bits of protected entries without hypervisor intervention). This helps to improve performance because even if a given stage 1 translation table is stored in a PRO region of memory, it contains a mix of protected and unprotected entries, so hypervisor involvement can be avoided more frequently. The instruction decoder 10 and execution stage 16 of the processing circuitry 4 support at least one type of instruction, called a protected entry check type read check write (RCW) instruction, which can be used to request an update to a given memory system location, where the update is made subject to a protected entry check to check whether the data stored in the accessed memory system location has a value that matches the encoding of the protected stage 1 translation table entry. If data at an accessed memory system location is found to have a value matching data in a protected stage 1 translation table entry, updates to at least a subset of the update-restricted bits of the given memory system location are inhibited. The RCW instruction is permitted to be executed by an operating system executing at EL1. The RCW instruction is one of a restricted subset of instructions permitted to update data in a memory region marked with PRO permission by a corresponding stage 2 translation table entry.

[0096] The protection entry check is performed in hardware by a protection entry check circuit 54, which, as shown in Figure 7, may be implemented either within the MMU 28 or closer to the memory system location that stores the data, e.g., within a memory system component 56 such as a cache, interconnect, or memory controller. It is also possible to use a distributed set of logic with some parts of the protection entry check circuit 54 implemented within the MMU 28 (or execution stages 16 of the pipeline) and other parts implemented closer to the memory storage. The read, check, and write operations performed in the protection entry check are performed as atomic operations so that when access to a given memory system location is requested by another thread executing on the same processor circuit as the thread executing the RCW instruction, or by another processor core, the other access sees either the value of the given memory system location before processing the RCW instruction, or the value of the given memory system location after processing the RCW instruction, rather than any partial effect of the RCW instruction, and so that it is not possible to update the given memory system location in the period between the protection entry check reading the data at the given memory system location and the subsequent update of the data at the given memory system location in response to the RCW instruction. To implement atomicity, any known technique for performing atomic read / write operations on a memory system location can be used (e.g., locking the memory location against access by other operations during the period between the read and write, or allowing a conflicting access during that period, but resuming the RCW operation if a conflicting access is detected during the period between the read and write). By enforcing the atomicity of the read, check, and write, it avoids race conditions that can lead to incorrect processing results.Because the read, check, and write operations are performed atomically, it may be useful to implement the protection entry check circuitry 54 in a memory system component 56 closer to the storage location being updated to reduce the duration of the period between the read and write compared to the duration if the read data had to be returned all the way to the MMU 28 or another element of the processor pipeline 4 to perform a check before the write could proceed and be returned to the memory system location that stores the write data.

[0097] In the example shown in FIG. 8, both the valid and invalid stage 1 translation table entries have an encoding that allows the entries to be designated as protected entries. However, it is not required that invalid entries can be designated as protected, and other examples may omit the protected entry encoding bit field 78 from the invalid entry format. Also, different implementations may choose different options for how many bits of a protected entry are inhibited from updating in response to an RCW instruction. Some implementations may prevent any updates to a protected entry in response to an RCW instruction, and if the data at a given memory system location is not encoded as a protected entry, updates are only allowed in response to an RCW instruction. Other implementations may specify a subset of update-restricted bits and a subset of update-unrestricted bits, and thus updates to a subset of update-unrestricted bits may be permissible even for protected entries. There may be some fields that are not critical to security, such as, for example, access flags 70 and dirty bit modifier 72, that are allowed to be updated even in protected entries. Which bits are update-restricted or update-unrestricted may either be fixed in a non-programmable manner for a given architecture, or may be programmable by software using a selection value stored in a control register. For example, the selection value may be selected from one of several different modes, each mode associated with a different setting in which the bits are update-restricted. However, in the example of FIG. 7, the selection value is encoded as a bit mask that identifies the locations of the update-restricted bits, and the selection value is stored in a mask register (e.g., the RCWMask_Valid_EL2 and RCWMask_Invalid_EL2 registers shown in FIG. 7 are for selecting the update-restricted bits of valid and invalid entries, respectively, and the RCW_Mask_Invalid_EL2 register may be omitted in implementations in which invalid entries cannot be encoded as protected entries).Updates to the selection value may be restricted to program instructions executing at or above a threshold privilege level, e.g., only instructions executing at EL2 or EL3 may be permitted to update the selection value. There may be some bits that are forced to be restricted from being updated regardless of the state of the selection value. For example, the bit fields 76, 78 used to encode whether an entry is a protected entry may not be permitted to be updated regardless of what other bits are permitted to be updated. In general, RCW instructions may be prohibited from changing the status of a particular entry as protected or unprotected. The setting of the bit fields 76, 78 may instead be controlled by program code executing at a higher level of privilege, such as EL2 or EL3, which may access memory using a different set of stage 2 translation tables that do not mark the memory region storing the protected entries as partial read-only, and therefore may use standard general purpose store instructions to set the bit fields 76, 78 of the protected stage 1 entries.

[0098] There are various ways in which the protected entry check can be implemented. In one example, if the entry stored in the accessed memory system location is valid and protected, it cannot be modified, and if it is invalid, it can be modified, including enabling it (unless the entry is also protected). Alternatively, there may be a protected bit field 76 in valid entries and a protected bit field 78 in invalid entries, and modifications to protected entries may not be allowed, otherwise updates to non-protected (valid or invalid) entries are allowed (changing the status of whether the entry is protected or not). Another example may provide a protected bit field 76 in valid entries and a protected bit field 78 in invalid entries, and the RCW instruction can make any modifications to the entry if it is not protected (other than protected), while if it is protected, the RCW instruction can make modifications to some bits as described for valid entries and make modifications to some bits in the invalid entry. In some examples, the mechanism for describing which bits are protected is a hardwired architecture selection of any field except the protected field or the valid field. Alternatively, the mechanism for describing which bits are protected in valid entries can use a mask register owned by EL2, and / or the mechanism for describing which bits are protected in invalid entries is a mask register owned by EL2. Different choices for defining the update-restricted bits are possible for each of the valid and invalid entries, for example, one approach could be to define a mask register for defining the update-restricted bits of valid entries, but hardwire the update-restricted bits of invalid entries.

[0099] Also, there may be variations in how checks are applied when it is permitted to update some fields in a protected entry, but two exemplary options are: A) The protected entry check circuit 54 reads the current entry to check whether the entry is valid and / or protected, and then stores only the bits that are allowed to be written (without checking whether the RCW instruction was attempting to change update-restricted bits that are not allowed to be written). B) The protected entry check circuit 54 reads the current entry and checks if the entry is valid and / or protected. If it is protected and the RCW instruction is not trying to change a bit that is not allowed to be written, the write can proceed, but if the RCW instruction is trying to update an update-restricted bit, the write will fail and nothing will be written.

[0100] Both A and B are viable options.

[0101] In response to the RCW instruction, an indication of whether the write was successful or unsuccessful may be written to a condition status flag stored in a control register of the processing circuit 4. For example, the condition status register may include a number of condition flags (e.g., a negative flag N, a zero flag Z, a carry flag C, and an overflow flag V) that may be set depending on the outcome of the processing operation and that may be tested by a conditional instruction that may conditionally trigger an operation (such as a branch operation or an arithmetic / logic operation) depending on the state of the condition status flag. It may therefore be useful to update the condition status flag based on whether any part of the write requested by the RCW instruction was unsuccessful, to allow a subsequent instruction to take action depending on the outcome of the write without having to re-read the memory system location to check whether the write was successful.

[0102] 12, 13, and 14 show the processing of several variants of the guard entry check RCW instruction. FIG. 12 shows an example of the processing of either the store variant or the swap variant of the instruction (most of the processing steps are the same for both instructions, except for the final step 726 or 728 depending on the variant). Both the store variant and the swap variant specify a register Xd that provides an address operand used to generate the address of the given memory system location to be updated, and a source register Xs that provides the new data to be written to the given memory system location. At least the swap variant also specifies a destination register Xt to which the old data read from the given memory system location is written. The store variant differs from the swap variant in that the old data is not written to any destination register, so the store variant does not need to specify any destination register. However, in one example, the store variant and the swap variant may be encoded using the same encoding, except that the instruction may be treated as a store variant if the field used to specify the destination register Xt has a predetermined value. For example, some instruction set architectures may define a particular register specifier (e.g., register 31) as corresponding to the "0" register, which when specified as an operand of an instruction causes the operand to be treated as if it had a value of 0, without the operand having to actually be read from a register provided in hardware. Thus, in some examples, when destination register Xt is specified as the "0" register X31, the instruction may be treated as a store variant. In other examples, a store instruction may be encoded as an entirely different instruction type than a swap instruction.

[0103] In step 700 of FIG. 12, an address operand and new data to be written ("NewData") are read from registers identified by register specifiers Xd and Xs, respectively. In step 702, a target address for the memory access is determined based on the address operand. For example, the address operand can be treated as an absolute address that directly specifies the target address, or it can define an offset to a reference address, such as a value in a further base register or a program counter value that identifies the address of the RCW instruction itself. The target address calculated based on the address operand is a virtual address, which can be translated by the MMU 28 to a physical address. In step 704, assuming that any MMU checks (other than the protection entry check) on whether the target address is accessible to the current instruction are passed, a read request is issued to the memory system to obtain the data ("ReadData") read from the memory system location corresponding to the (translated) target address. This corresponds to the "read" of the RCW instruction.

[0104] As step 706, the protection entry check circuit 54 determines whether ReadData has a value consistent with the encoding of a protected stage-1 (stage-1, S1) translation table entry. This corresponds to the "check" portion of the RCW instruction. If ReadData does not have a value consistent with being a protected stage-1 translation table entry, then in step 708, the protection entry check circuit checks whether NewData is encoded as a protected stage-1 translation table entry. If so, in step 710, the write requested by the RCW instruction is denied, or alternatively, the non-update-restricted bit of the stage-1 translation table entry designated by the RCW instruction as NewData can be written to the corresponding bit of the memory system location, and at least the bit used to encode whether the entry is protected is considered to be a non-write update-restricted bit. In any case, in step 712, a condition status flag is set to report that the write requested by the RCW instruction could not be fully performed.

[0105] If, in step 706, it is determined that ReadData is encoded as a protected stage 1 translation table entry, then in step 716, protection entry check circuit 54 determines whether the read data has a value consistent with being a valid or invalid stage 1 translation table entry. If the read data has a value consistent with being an invalid protected stage 1 translation table entry, then in step 718, protection entry check circuit 54 determines whether NewData attempts to modify any invalid entry update restricted bits (including at least any bits used to encode whether the entry is protected) of the stage 1 translation table entry, and if so, the method again proceeds to steps 710 and 712 to suppress updates of at least the invalid entry update restricted bits and set a condition status flag (again, this can be done by denying writes entirely or by writing only to non-update restricted bits).

[0106] On the other hand, if, in step 716, it is determined that ReadData has a value consistent with being a valid stage 1 translation table entry encoded as a protected entry, then in step 720, protection entry check circuit 54 determines whether NewData is attempting to modify any valid entry update restricted bits (including at least any bits used to encode whether an entry is protected or not) of the stage 1 translation table entry read from the memory system location corresponding to the target address. If so, then again in step 710, the write is denied or only permitted to write non-update restricted bits, and in step 712, a condition status flag is set to report the failure of the write.

[0107] In implementations that do not support invalid translation table entries being encoded as protected entries, steps 716 and 718 can be omitted and the method can proceed directly from step 706 to step 720 when ReadData is encoded as a protected entry.

[0108] If in step 708, the NewData that would be written if the ReadData was not a protected entry, or in steps 718 or 720, the NewData (that would be written if the ReadData was a protected entry) does not attempt to change an update-restricted bit, then in step 714, the write of the RCW instruction is permitted and therefore the NewData is written to the memory system location corresponding to the target address.

[0109] Regardless of whether the write was successful or rejected (at least partially), the operation changes depending on whether the current RCW instruction being executed is a store variant or a swap variant, at step 724. If the instruction is a store variant, no further action is required and ReadData is not written to any destination register, at step 726. If the instruction is a swap variant, ReadData is written to destination register Xt, at step 728. Some implementations may not support both store and stop variants, in which case step 724 may be omitted and the method may proceed directly from step 714 to the relevant one of steps 726 and 728.

[0110] The read in step 704, the write in step 714, and the various checking operations performed between steps 704 and 714 are performed atomically as an inseparable set of operations such that it is not possible for an intervening write to a memory system location to occur between the read in step 704 and the write in steps 710 or 714, or to see the partial results of another thread of execution performing the set of operations.

[0111] FIG. 13 is a flow diagram illustrating the processing of a compare-and-swap (CAS) variant of the protection entry check RCW instruction. The steps in FIG. 13, designated with the same reference numbers as FIG. 12, are the same as those described above. Note that the notation used for the registers used to store ReadData and provide NewData has been swapped in FIG. 13 compared to FIG. 12, with Xt being the register providing NewData and Xs being the destination register to which the old value of ReadData was written before the write. FIG. 13 differs from FIG. 12 in that step 700 is replaced by step 750, since the CAS variant specifies an additional source operand called compare data ("CompareData"). In this example, to reduce the number of register fields required in the instruction encoding, CompareData is specified in the same register Xs used as the destination register for writing ReadData in step 728, although this is not required and other examples may specify the compare data in an additional register apart from Xs.

[0112] Steps 702 and 704 are the same as in FIG. 12. After step 704, an additional step 752 is performed to compare the ReadData read from a given memory system location corresponding to the target address with the CompareData specified by the RCW instruction in the register Xs. The protection entry check circuit 54 determines whether the comparison condition is met based on the comparison. For example, the comparison condition may be whether the CompareData and the ReadData are equal, or may be based on another comparison condition such as less than, greater than, not equal, etc. Some implementations may fix the comparison condition as an equal condition, while other implementations may allow a parameter of the instruction to select which type of comparison to perform. If the comparison condition is not met, in step 754, the write requested by the RCW instruction is rejected and a condition status flag is set to report the failure of the write caused by the comparison condition failure (e.g., set a negation flag N when the comparison condition fails). If the comparison condition is met, steps 706, 708, 710, 714, 716, 718, 720 are performed similarly to FIG. 12 to check the protection entry status of the data read from the memory system location corresponding to the target address and control whether the write is permitted based on the result of the check. If the write is permitted, step 714 is the same as described above and allows the write to write NewData to the memory system location. If the write is rejected or only partially performed in step 710, the subsequent step 712 of FIG. 12 is replaced by step 762 of FIG. 13, which is the same in that it sets a condition status flag to report a write failure, but in the case of the compare and swap variant, it can distinguish that the failure was caused by a protection entry check failure and set the condition status flag to a value different from the value used in step 754 in the case of a comparison condition failure.

[0113] Regardless of whether the comparison condition is met or the protection entry check is successful, steps 724, 726, and 728 are the same as in FIG. 12, optionally writing ReadData to destination register Xs (again, it is possible to suppress the update of destination register Xs when the destination register specifier specifies a predetermined value, e.g., 31).

[0114] Figure 13 illustrates the case where evaluation of the comparison condition takes precedence over the protection entry check, such that if the comparison condition fails but the entry is protected and the checks at steps 708, 718, and 720 fail, the condition status code indicates a CAS failure. It is also possible for the protection entry check to take precedence, such that if the entry is protected and the checks at steps 708, 718, or 720 fail, the condition status code indicates a write failure due to the protection entry check, even if the comparison condition failed. For example, Figure 13 could be modified to implement steps 752 and 754 after step 714 instead of before step 706.

[0115] FIG. 14 is a flow diagram illustrating the processing of a bit set / clear variant of a protection entry check RCW instruction. In FIG. 14, steps 700-728 are the same as in FIG. 12, except that in FIG. 14, NewData is calculated based on a bit mask ("BitMask") provided in a source register Xs that encodes the location of the bits to be set or cleared in the addressed memory system location, rather than being specified directly in the source register. Thus, the only difference from FIG. 12 is that in step 700, register Xs defines a BitMask rather than specifying NewData directly, and additional steps 770, 772, 774 are performed between steps 704 and 706. In step 770, the method differs depending on whether a bit set or bit clear instruction is being performed (it is not necessary to support both types of instructions, and thus if only one of these instructions is supported, step 770 may be omitted and the relevant one of steps 772, 774 may be performed after step 704). If a set bit instruction is being executed, then in step 774 NewData is set to the result of performing a bitwise OR operation on the ReadData read from the addressed memory system location and the BitMask specified by the RCW instruction (thus, for a set bit instruction, the bit positions marked as "1" in the BitMask are requested to be set to 1 in the addressed memory system location). In contrast, in step 772, if a clear bit instruction is being executed, then NewData is set to the result of performing a bitwise AND operation on the ReadData and the inverse of the BitMask (thus, for a clear bit instruction, the bit positions marked as "1" in the BitMask are requested to be cleared to 0 in the addressed memory system location). For both the set bit and clear bit variants, the bits of ReadData that correspond to "0" bits in the BitMask retain their original value in NewData and are therefore not changed by the RCW instruction.After calculating NewData in step 772 or 774, all subsequent steps in FIG. 14 are the same as in FIG.

[0116] For all of the flow diagrams in this application, it will be understood that the same functions may be implemented in different orders, and thus, although a flow diagram shows a sequential sequence of steps, for any steps that are not dependent on one another, it will be understood that the steps can be reordered or performed at least partially in parallel.

[0117] Thus, as shown in FIG. 6, various stage 1 translation table entries used to traverse the translation table tree structure to reach intermediate address mappings corresponding to sensitive memory pages (e.g., pages expected to be used for sensitive data or instructions) can be set to have a protected entry encoding. This may be true even if one of these entries is temporarily set as invalid to prohibit access to the page (e.g., as a result of a paging operation). Meanwhile, other entries in the same page table as the protected entry may be unprotected entries whose updates are less restricted. By supporting protected entry encoding, this allows a given page table stored in the PRO region of memory to contain a mix of protected and unprotected entries, where the unprotected entries can be updated by operating system code running at EL1 without hypervisor intervention by executing an RCW instruction according to any of the variants described above, while the protected entries can be subject to stricter restrictions. A dedicated type of instruction (e.g., one or more of the variants of the RCW instruction described above) is provided to trigger a protection entry check, and since the PRO permission prevents other types of instructions (such as most store instructions) from being able to update the PRO area of ​​memory, this avoids the need to perform a protection entry check on every write to memory, which would be very expensive in terms of performance.

[0118] Anti-aliasing CheckThe above-described mechanism is useful for protecting a particular stage 1 translation entry from corruption (either intentionally by hacked code or by erroneously written code by a malicious party). However, by defining stage 1 translation table entries that specify the same intermediate address mapping 62, as shown in FIG. 15, it is possible for several different virtual addresses to alias to the same intermediate address. To prevent an attacker from being able to circumvent the protection provided by the PRO permission and protection entry encoding described above for the first set of stage 1 translation entries that map VA1 to IPA by defining aliasing stage 1 entries that map different virtual addresses VA2 to the same intermediate address IPA, as shown in FIG. 8, the stage 2 translation table entries may have a bit field 79 that specifies whether the corresponding memory region has anti-aliasing properties (alternatively, the anti-aliasing properties 79 may be indirectly specified by the stage 2 translation table entries by reference to an indirect register). If a region is indicated as having anti-aliasing properties, an additional anti-aliasing check is performed on accesses to that region to check that all walked stage 1 translation table entries (that would be accessed in the translation table walk to find the corresponding stage 1 translation table entries that specify the virtual to physical stage 1 address mapping for that region) are either (a) stored in a PRO or read-only region of memory and encoded as protected entries, or (b) stored in a read-only region of memory. Note that this does not necessarily require a page table walk through those walked stage 1 translation table entries to actually be performed for every access to a memory region associated with a stage 2 translation table entry that has anti-aliasing properties.To avoid having to perform a full translation table walk every time, information can be cached in TLB 29 to indicate whether the anti-aliasing check passed (or, for certain walked stage 1 translation table entries, whether they are stored in the PRO area and / or have already been determined to be protected entries).

[0119] FIG. 16 is a flow diagram illustrating a method for performing an anti-aliasing check. In step 800, a memory access request is issued that specifies a target virtual address VAx. In step 802, the MMU 28 initiates an address translation from the target virtual address VAx to a target physical address PAz in response to a stage 1 mapping of VAx to an intermediate address IPAy and a stage 2 mapping of the intermediate address IPAy to the target physical address PAz. (It is not required to perform two separate actions for stage 1 and stage 2 translations, but this is an option; another example could be to have a combined stage 1 and 2 TLB that can directly map from VAx to PAz for translations that are already cached, but upon a miss in the TLB, a new VA to PA mapping is identified by performing a stage 1 and stage 2 walk, as shown in FIG. 6.)

[0120] In step 804, MMU 28 checks whether the stage 2 translation table entry (block or page descriptor) corresponding to IPAy indicates anti-aliasing properties. If so, in step 806, MMU checks whether all walked stage 1 translation table entries satisfy the anti-aliasing condition. A walked stage 1 translation table entry is an entry that would be accessed in a translation table walk to find a corresponding S1 translation table entry that specifies an S1 address mapping from VAx to IPAy if a full translation table walk corresponding to virtual address VAx was performed (this walk may not actually be needed for the current memory access, depending on what is already cached in TLB 29). For example, in FIG. 6, the walked stage 1 translation table entries are the entries marked D_Table in the L0, L1, and L2 stage 1 page tables, and the entry marked D_Page in the L3 stage 1 page table. The anti-aliasing condition is satisfied for a given walked stage 1 translation table entry when any of the following conditions are met: a) a given walked stage 1 translation table entry is designated as a protected entry, and the given walked stage 1 translation table entry is stored at physical address PAj, for which PRO permission or read-only permission is specified by the associated stage 2 translation table entry that provides the stage 2 address mapping used to derive PAj; or b) Read-only permission is specified by the associated stage 2 translation table entry that provides the stage 2 address mapping used to derive the physical address PAj of a given walked stage 1 translation table entry.

[0121] In the particular example of Figure 6, the associated stage 2 translation table entry for the L1 stage 1 entry used to derive the PA of the accessed page is the stage 2 L3 entry shown as "D_Page" in Figure 6. For the other walked stage 1 entries shown in Figure 6, there is similarly an associated stage 2 L3 entry (or stage 2 L1 or L2 entry, if a stage 2 block descriptor is found corresponding to IPAy) that must be marked with PRO or read-only permission in order for the anti-aliasing condition to be met (these are the last entries of the various stage 2 translation walks shown to obtain the physical address of each walked stage 1 translation table).

[0122] 16, if MMU 28 determines that any one or more of the walked stage 1 translation table entries do not satisfy an anti-aliasing condition, then the memory access is denied, at step 808. A failure may be signaled, which may trigger an exception handler (e.g., executing in EL2) to perform error handling actions.

[0123] If all walked stage 1 translation table entries satisfy the anti-aliasing condition, step 808 is omitted. In this case, in step 810, MMU 28 also checks whether any other checks are satisfied (such as any checks based on PRO permissions set for access to the memory region, protection entry checks whether the memory access request was issued in response to an RCW instruction, or any other specific checks to protect against other improper accesses, such as checks based on secure / non-secure state in implementations that support this). If any of the other checks are not satisfied, then again in step 808, the memory access is denied (the type of failure generated may depend on the cause of the access check failure). If so, in step 812, the memory access request is allowed to proceed.

[0124] Thus, as shown in Figure 6, the anti-aliasing property can be set on the stage 2 translation table entry that provides the physical address mapping for the memory region being accessed (this can be either a page descriptor or a block descriptor). If the anti-aliasing property is set for a valid access to the corresponding memory location, this requires that all walked stage 1 translation table entries on the path to the entry that provides the intermediate address mapping for that memory region are either (a) marked as protected and marked for the stage 2 entry that provides the physical address mapping for the region that stores those walked stage 1 translation table entries to specify PRO permission, or (b) stored in a PA with read-only permission specified by the stage 2 entry that provides the PA mapping for that PA. This means that an attacker cannot easily set up new aliasing stage 1 address mappings to circumvent the protections applied to the trusted address mappings expected to be used to access the corresponding region of memory. An attacker able to affect the behavior of operating system code at EL1 does not have control over the stage 2 entries used to control memory accesses, since this is based on the base address in the VTTBR_EL2 register, which cannot be updated by code executing at EL1 (and therefore cannot cause PRO or read-only permissions to be set for the area that stores the attacker's newly created aliased stage 1 address mapping). Also, the mechanism for code executing at EL1 to update the stage 1 translation table entries may be to execute a protection entry check type RCW instruction as described above (no other instructions are prohibited from writing to the PRO area of ​​memory), which cannot change the protection state of any translation table entry, so the attacker cannot cause the stage 1 entries to become protected. Also, the read-only area cannot be written to by any write instruction.Therefore, any new entries that an attacker could create would fail at least one of the anti-aliasing checks of whether the stage 1 entries used to obtain the VA-IPA mapping are protected and / or whether those entries are stored in a PRO or read-only area of ​​memory.

[0125] Protection against improper updates to the Stage 1 Top-Level Base Address Another attack that may be attempted by an attacker capable of affecting the behavior of operating system code executing at EL1 may be to modify the stage 1 top level base address (which identifies the location in memory of the L0 stage 1 page tables) indicated by the base address register TTBR_EL1. For example, the attacker may substitute the addresses of a new set of attacker-defined stage 1 tables to replace the addresses of authorized page table structures that are correctly formed and behave correctly as verified by the hypervisor. The attacker may also attempt to cause the MMU 28 to use an existing authorized stage 1 page table in an unexpected way, for example by substituting the base address of one of the L1, 2, or 3 page tables to replace the correct L0 base address, such that the next level table pointer or address mapping for a different memory region may be incorrectly used for the memory region being accessed due to the accessed table being used at the wrong level in the tree from the predicted level, and different bits of the virtual address being used to select the relevant entry from the table.

[0126] FIG. 17 illustrates a stage 1 top level base address check that may be performed to protect against these types of attacks. In step 1000, a page table walk is required for a memory access request that specifies a target virtual address (for memory access requests that do not require a page table walk because the necessary address mappings are already available from the TLB, no separate check needs to be performed because the necessary stage 1 top level base address checks have already been performed when these address mappings were allocated to the cache following a previous page table walk). In step 1002, a stage 1 top level base address is determined based on the value in the stage 1 translation table base address register TTBR_EL1. The base address is specified as the intermediate address IPA_base. In step 1004, MMU 28 retrieves information specified by the associated stage 2 translation table entry that provides the mapping from IPA_base to PA_base. For example, this information may be retrieved from TLB 29 if already cached in the TLB, or may be retrieved by performing a stage 2 translation table walk using the stage 2 base address specified in the stage 2 translation table base address register VTTBR_EL2.

[0127] In step 1006, MMU 28 determines whether stage 1 top-level table partial read-only checking is enabled. For example, this may be determined based on a stage 1 top-level table partial read-only checking enable control value stored in a control register (e.g., stage 2 translation control register VTCR_EL2, where updates are restricted to code executing at exception level EL2 or above). Alternatively, other implementations may consider stage 1 top-level table partial read-only checking to be permanently enabled. If stage 1 top-level table partial read-only checking is enabled, in step 1008, MMU 28 checks whether the associated stage 2 translation table entry specifies PRO permission, and if not, in step 1010, the memory access is denied and a failure is signaled. This means that if an attacker attempts to modify the stage 1 translation table base address register TTBR_EL1 to point to a new L0 page table created by the attacker, accesses based on the modified base address will fail since the attacker cannot modify the PRO region of memory and would therefore have written to a non-PRO region, and therefore the stage 1 top level table PRO check will fail.

[0128] If the stage 1 top level table PRO check is disabled at step 1006 or is enabled but passes at step 1008, then at step 1012 MMU 28 determines whether a stage 1 top level table existence check is enabled. Again, this may be determined based on a stage 1 top level table existence check enable control value stored in a control register (e.g., stage 2 translation control register VTCR_EL2). The enable control value used to determine whether the check is enabled at step 1012 may be the same as the enable control value described above for step 1006 (e.g., in some implementations, the checks at steps 1008 and 1014 may be considered as two steps of a single check that is either collectively enabled or collectively disabled). If the stage 1 top level table existence check is enabled, then at step 1014 MMU 28 determines whether the associated stage 2 translation table entry specifies a stage 1 top level entry existence permission 80. As discussed above with respect to Figure 8, the stage 1 top-level entry presence permission may be coded as an alternative variant of the PRO permission (such that memory regions with stage 1 top-level entry presence permission are assumed to also have PRO permission), or may be coded as an independent attribute separate from the indication of whether PRO permission is provided. If the associated stage 2 translation table entry does not specify stage 1 top-level entry presence permission, then again in step 1010, the memory access is denied and a failure is signaled. This may be used to protect a valid and genuine L1, L2, or L3 table from being replaced with an L0 table by modifying the stage 1 top-level base address to point to the address of the L1, L2, or L3 table, since the stage 2 entry corresponding to the memory region used to hold the L1, L2, or L3 table may be defined as not having a stage 1 top-level entry presence permission.To restrict which addresses can be used as stage 1 L0 base addresses for valid memory accesses, only memory regions used to hold any valid and genuine stage 1 L0 tables can be marked as having stage 1 top level entry presence permission in the corresponding stage 2 entry.

[0129] If the stage 1 top level table existence check is disabled in step 1012, or is enabled but passes in step 1014, then in step 1016 the MMU performs any other checks required to access the memory region identified by PA_base, and if these fail, again denies the memory access in step 1010. If any other checks pass, then in step 1018 the page table walk may be performed, effectively using the stage 1 top level base address IPA_base. Thus, the address of the stage 1 top level translation table entry is obtained by applying an index offset to the determined PA_base, where the index offset is determined based on a subset of the bits of the target VA to be translated. The page table walk then continues as previously described.

[0130] Thus, as shown in FIG. 6, in an expected use defined by software (and therefore not enforced as a requirement by hardware), among the stage 1 entries accessed on a page table walk to obtain a PA mapping 64 of a memory region for which additional protection is desired, the stage 2 page / block descriptor providing the PA mapping 64 identifying a storage location of a stage 1 L0 page table specifies both PRO and stage 1 top-level presence permissions, and the stage 2 page / block descriptor providing the PA mapping 64 identifies a storage location of a stage 1 L1, L2, or L3 page table and specifies PRO permission but not stage 1 top-level presence permission. This protects against the base address substitution attack described above. An alternative to avoid the need to implement a base address check could be to trap any access to the stage 1 base address register TTBR_EL1 to a hypervisor executing at EL2, which could then check whether an update requested by operating system code executing at EL1 is valid and deny the update if necessary. However, in practice, an operating system may need to frequently switch the address in the base address register TTBR_EL1 upon context switching, and therefore trapping every update may be costly in terms of performance. By implementing the stage 1 top-level base address check shown in Figure 17, this can avoid the need for such traps on base address register updates to TTBR_EL1, improving performance.

[0131] In some examples, a single variant of stage 1 top-level presence permission may be supported, in which case the check in step 1014 of FIG. 17 may simply be a check whether that stage 1 top-level presence permission is specified.

[0132] Other examples may support two or more variants of the stage 1 top level presence permission to allow finer control over which addresses within a memory region a particular stage 1 translation table base address register can specify. For example, some implementations may support two stage 1 base address registers: Selected for stage 1 translation at EL0 or EL1 if a configurable number (number, N) of the most significant bits of the virtual address to be translated are all set to 0 (N can be defined by a control value specified in a control register), TTBR0_EL1; and • TTBR1_EL1, which is selected for stage 1 translation at EL0 or EL1 if any of the N most significant bits of the virtual address to be translated are non-zero.

[0133] Next, several variants of stage 1 top-level existence permissions can be defined, including the following: ●Toplevel0 indicates a memory area that is permitted to be used for the top-level translation table accessed via TTBR0_EL1 but is not permitted to be used for the top-level translation table accessed via TTBR1_EL1. ●Toplevel1 indicates a memory area that is permitted to be used for the top-level translation table accessed via TTBR1_EL1 but is not permitted to be used for the top-level translation table accessed via TTBR0_EL1. ●Toplevel01 indicates the memory area permitted for use for the top-level translation table accessed via either TTBR0_EL1 or TTBR1_EL1.

[0134] In this case, one implementation of the check in step 1014 may be such that a failure is signaled in step 1010 of FIG. 17 if any of the following conditions are met: TTBR0_EL1 is used to provide a base address for which the corresponding memory region has neither Toplevel0 nor Toplevel01 permissions, or ●TTBR1_EL1 is used to provide a base address where the corresponding memory region has neither Toplevel1 nor Toplevel01 permissions.

[0135] In some implementations, further controls set in a control register controlled by software in EL2 can control whether TTBR0_EL1 is prohibited from granting access to the Toplevel1 page, and whether TTBR1_EL1 is prohibited from granting access to the Toplevel0 page. In this case, the check in step 1014 can cause a failure to be signaled in step 1010 if any of the following conditions are met: TTBR0_EL1 is used to provide a base address whose corresponding memory region does not have Toplevel01 permissions or has Toplevel1 permissions if the TTBR0 / Toplevel1 failure enable control is set to trigger a failure when TTBR0_EL1 is used to access a Toplevel1 page; or ●TTBR1_EL1 is used to provide a base address whose corresponding memory region does not have Toplevel01 permissions or has Toplevel0 permissions if the TTBR1 / Toplevel0 failure enable control is set such that a failure can be triggered when TTBR1_EL1 is used to access a Toplevel0 page.

[0136] These features allow finer control over which memory address ranges can be used to provide the top-level stage 1 translation table, while the enable control allows these finer checks to be disabled if deemed acceptable for any top-level page used to provide the base addresses of both TTBR0 and TTBR1.

[0137] In some implementations, the encodings of the various top-level existence permissions Toplevel0, Toplevel1, Toplevel01 can be combined with the encoding of PRO permissions such that they are treated as Toplevel0 PRO permission, Toplevel1 PRO permission, and Toplevel01 PRO permission. In such implementations, it is not possible to define a Toplevel0, Toplevel1, or Toplevel01 memory region as having no PRO permission. Nevertheless, it is possible to define a PRO region as having none of the Toplevel0, Toplevel1, or Toplevel01 permissions, since there are separate PRO permission encodings that are not treated as having any of the stage 1 top-level table existence permissions.

[0138] In the example of Figure 8, the PRO permissions and the S1 top level entry presence permissions are shown as being specified in the S2 permissions field 68 which are specified directly as part of the encoding of the stage 2 translation table entry itself. Similarly, the stage 1 translation table entry is shown as directly encoding the stage 1 permissions in field 66 of the entry itself.

[0139] However, it is also possible for permission information to be specified indirectly by a stage 2 translation table entry in a permission indirect register, as shown in FIG. 18. In this case, the stage 2 translation table entry can specify a field identifier that identifies which field in the permission indirect register specifies the stage 2 permission for that entry, and the referenced field in the permission indirect register is encoded to indicate the permission type. This approach can be used, for example, for PRO permissions 74, S1 top-level entry presence permissions 80, the anti-aliasing properties 79 described above, or the GCS attributes described below. Indirect permission specification using registers is useful because it allows software to quickly update permissions for many translation table entries that all reference the same permission field with a single update to a register field, without having to update many different translation table entries in memory. Also, in implementations where each field of the permission indirect register has more bits than the corresponding permission field in the translation table entry, the indirection can be useful to support more types of permissions than is possible with the limited encoding space for permissions in the entry.

[0140] Guard-Controlled Stacks for Protection Against Return-Oriented Programming Attacks Figure 19 shows an example of calling a function (labeled fn1 for ease of reference) and returning from the function. A function (also known as a procedure) is a sequence of instructions that can be called from another part of a program and that, when completed, returns processing to the part of the program flow from which the function was called. Because the same function can be called from many different places in a program, the function return address is remembered when calling a function so that the function return can distinguish to which address the program flow should be returned.

[0141] For example, as shown in Figure 19, a branch-with-link instruction BLR may be executed at the time a function is called, causing the program flow to branch to an instruction at a branch target address specified using an operand of the branch-with-link instruction. The branch-with-link instruction also causes the processing circuitry to set a link register (a designated register used to track function return addresses) to the address of the next instruction after the branch-with-link instruction. After the branch is taken, a number of instructions (e.g., LD, MUL, ADD, etc.) are executed within the function code, and once the function is completed, a return branch instruction RET is executed which causes a branch to the instruction pointed to by the return address stored in the link register.

[0142] If no other functions are called from within fn1, and no exceptions occur before reaching the final return branch of fn1, then the address in the link register should still be the same as it was set to when fn1 was called.

[0143] However, since a first function fn1 called by the background code will itself often call a further function (fn2) in a nested manner, in which case the function call to fn2 will overwrite the return address stored in the link register, the function code of the first function fn1 should include instructions to save the return address from the link register to a data structure in memory (e.g. a stack structure operating in a last-in-first-out (LIFO) manner) before calling that further function, and after returning from fn2, the function code of fn1 should restore the return address to the link register before executing the return branch. The responsibility for saving and restoring function return state, such as the return address, typically lies with the software (there may not be an architecturally mandated hardware mechanism for saving the return address).

[0144] However, while the function return address is stored in memory, it may be vulnerable to an attacker modifying that data, for example, by using another thread running on another processor core, or by interrupting the called function and executing other code that in the meantime overwrites the return address stored in memory. Alternatively, an attacker may execute some instructions whose purpose is to modify the address operand of the instruction that restores the return address from memory to a register, so that the data loaded from memory is no longer the same as the return address originally saved in memory before calling the nested function. If an attacker can cause the return branch to branch at a point in the program flow other than the instruction after the function call branch (#add1+4 in the example of Figure 19), the attacker may be able to misbehave the software, potentially circumventing certain security protections or causing it to perform undesirable operations.

[0145] A function call is an example of an operation in which a processing circuit generates return state information that provides information about a state to be restored at a later time. Another scenario in which return state information may be obtained may be when an exception occurs, at which point an exception handling circuit provided in the hardware or a software exception handler may obtain exception return state information, such as an exception return address indicating the address of the instruction to be executed after returning from the exception, and / or saved processor state information indicating the mode or execution state the processor should be in after returning from the exception. For example, the saved processor state information may indicate not only from which of the exception levels EL0-EL3 the exception occurred, but also other information about the operating state of the processor at the time the exception occurred. As with function calls, exceptions may be nested, so that the exception return state obtained for one exception may be saved to memory (either automatically in hardware or by a software exception handler) when another exception occurs, and may be vulnerable to tampering by an attacker while stored in memory. These types of attacks are sometimes referred to as return-oriented programming (ROP) attacks. It is desirable to provide architectural countermeasures against such attacks.

[0146] Figures 20 and 21 show an approach to protect against ROP attacks using a protected data structure in memory called a "Guard Control Stack" (GCS). While the location of the GCS data structure in the memory address space may be selected by software, the hardware provides a number of architectural features designed to protect the GCS data structure from tampering by a malicious attacker, including tampering by an operating system (operating at exception level EL1) that has been compromised by the attacker.

[0147] As shown in FIG. 20, registers 14 include control registers 1050, which may include one or more registers that specify (among other parameters) a GCS enable parameter 1052 for specifying whether GCS mode is enabled or disabled, and a stage 1 GCS hardening check enable control parameter 1054 that controls (if GCS mode is enabled) whether a GCS memory access request undergoes a check for whether the memory region accessed by the GCS memory access request has the anti-aliasing property 79 described above set. Registers 14 also include one or more guard control stack pointer (GCS pointer) registers 1056 for storing a stack pointer that indicates an address on a GCS data structure. In some examples, GCS pointer registers 1056 may be a bank set of registers that are provided separately for at least two of the execution states (exception levels EL0-EL3), allowing software operating in different execution states to reference different GCS structures in memory without having to reprogram a shared stack pointer register after each execution state transition. In other examples, a single GCS pointer register can be used and software can update the stack pointer stored in the GCS pointer register 1054 when transitioning between execution states. Although not shown in Figure 20, the GCS enable parameter 1052 and the stage 1 GCS hardening check enable control parameter 1054 can also be specified separately for two or more different execution states.

[0148] As shown in FIG. 21, the GCS data structure 1058 is stored in a region of memory designated to be a GCS region of memory (by stage 1 permission 66 specified by the corresponding stage 1 address translation table entry). The GCS region permission may be specified directly in the encoding of the corresponding stage 1 address translation table entry or may be indirectly referenced in a permission indirect register as shown in FIG. 18. Once a memory region is identified to be a GCS region, write access to the region is restricted to write requests triggered by processing circuitry 4 when executing a particular subset of GCS access instructions. Generic store operations used by software for general store instructions not intended to access GCS structures are not considered one of the restricted subset of GCS access instructions. MMU 28 may still allow the GCS structure to be read using a generic load instruction that causes a read request to be issued that is not a GCS memory access request. If a memory access request requests access to a GCS region, and the request is a write request, and the request is not a GCS memory access request triggered by one of the restricted subset of GCS access instructions, the memory access request is denied and a failure is signaled.

[0149] 21, the subset of GCS access instructions may include at least a GCS push instruction that causes return state information (such as a function return address from the link register, or an exception return address, or saved processor state obtained at the time of an exception) to be pushed to a location on the GCS structure determined using a stack pointer indicated in a GCS pointer register 1056 that corresponds to the current execution state ELx. The GCS access instructions also include at least one form of a GCS pop instruction that pops protected return information from the GCS structure.

[0150] The GCS structure is separate from any data structures that software uses to maintain return state information saved in memory to handle nested function calls or exceptions. Thus, the GCS structure is not intended to eliminate the need for software to keep track of saving and restoring return state information itself when function calls or exceptions are nested (software-triggered saving of return state may continue in the same manner as in processors that do not support the GCS protection architectural measures described above). Instead, the GCS structure provides an area of ​​protected memory, protected from tampering by compromised code operating at exception levels EL0 or EL1, that can be used to provide information for verifying return state information that software intended to use to return from function calls or handling exceptions.

[0151] Thus, in some implementations, the GCS pop instruction that pops the protected return state information from the GCS structure may also cause processing circuitry 4 to compare the popped return state with current return state information stored in a register (e.g., a link register for a function return, or an exception return address register for an exception return, and / or a saved processor state register) and signal a failure if there is a mismatch between the return state information popped from the GCS structure 1058 and the intended return state information that the software intends to use for the function / exception return. Thus, by including instances of GCS push and GCS pop instructions in program code that executes around function calls / returns and exception entries / returns, software may be protected from tampering.

[0152] In other implementations, a separate instruction may be defined to verify whether the intended return state information is valid, apart from the instruction to pop the return state information from the GCS structure 1058.

[0153] Alternatively, the GCS pop instruction may directly pop the guard return state from the GCS into one or more registers used to specify the return state for an exception return or function return (or may be combined with an exception / function return instruction to pop the guard return state and use that state to control the exception / function return), in which case in such an implementation it is not mandatory to perform a step to verify whether the intended return state information provided by the software is valid, since the GCS guard return state is used directly to control the exception / function return.

[0154] Other types of GCS access instructions may also be supported. Some instructions that have other functionality when GCS mode is disabled using GCS enable control parameter 1052 may cause processing circuitry 4 to perform additional functionality (such as additional GCS mode specific security checks) when executed when GCS mode is enabled.

[0155] In general, by providing architectural support for defining GCS memory area types for use with GCS structure 1058 and restricting write access to GCS area types to a limited subset of GCS access instructions (which may not be permitted to access memory areas other than the GCS area type), this can reduce the attack surface available to an attacker attempting to tamper with the protected return state information stored on the GCS structure 1058.

[0156] However, because the stage 1 permission associated with a stage 1 translation table entry corresponding to a region that stores GCS structure 1058 is used to specify characteristics that indicate that the region is a GCS region, a compromised operating system may attempt to modify that stage 1 translation table entry to remove the GCS permission type, or may attempt to define an aliasing stage 1 translation table entry as shown in FIG. 15 to enable access to the same region of physical memory using a different stage 1 translation table entry that does not specify the GCS permission type.

[0157] To protect against such attacks, the translation hardening mechanism described above can be used to protect stage 1 translation table entries used to specify a GCS region for storing GCS data structure 1058. Thus, stage 1 translation table entries that specify a GCS region type can be protected from tampering by storing them in either a read-only or partially read-only region as specified by the stage 2 permission information specified (directly or indirectly) by the corresponding stage 2 translation table entry for the memory region that stores the stage 1 translation table entry. Note that because pushing return state information into a GCS region requires writing data to the GCS region, a read-only or partially read-only region type should not be specified in the stage 2 permissions for the stage 2 entry that corresponds to the GCS region itself. Also, if protected entry encoding is supported as described above, the stage 1 translation table entries that correspond to GCS regions can also be indicated as protected entries to protect them from modification by protected entry check-type RCW instructions executed in EL1 as described above. Also, anti-aliasing features 79 can be specified for stage 2 translation table entries that correspond to a GCS region to enforce that all walked stage 1 translation table entries used to find address mappings for a GCS region must be hardened stage 1 translation table entries that are stored in a read-only or partially read-only region of memory (and also required to be coded as a hardened entry if hardened entry coding is supported for stage 1 translation table entries and the translation table entry is stored in a partially read-only region). These mechanisms mean that attempts to modify a stage 1 translation table entry to remove the GCS region designation or to use an aliased stage 1 translation table entry to avoid that entry will fail.

[0158] To ensure that the translation hardening mechanism described above is used to protect stage 1 translations corresponding to GCS regions, thus providing confidence that GCS accesses are not made to an alternate GCS structure substituted for the intended GCS structure by an attacker providing aliasing stage 1 translation entries, when stage 1 GCS translation hardening enable parameter 1054 is set to an enabled state and GCS mode is enabled by GCS enable parameter 1052, a GCS memory access (including both read and write accesses) is denied (and thus causes a failure) if the stage 2 translation table entry corresponding to the target memory region attempted to be accessed by the GCS memory access does not specify anti-aliasing properties 79. This ensures that protection is in place such that a failure is generated when an access to a GCS region is attempted using a non-hardened stage 1 translation table entry that is (a) not stored as read-only in the region specified by the stage 2 translation table entry, or (b) not stored as partially read-only in the region specified by the stage 2 translation table entry and (in implementations that support protected entry encoding) is encoded as an unprotected entry. The need to check the anti-aliasing features 79 in response to GCS memory accesses can be disabled by setting the stage 1 GCS transform hardening enable parameter 1054 to a disabled state (this may be useful for legacy code written for systems that did not support the anti-aliasing features 79 or transform hardening mechanisms).

[0159] The enable control values ​​1052, 1054 for controlling the operation of the GCS mode may be restricted to being updated by instructions executing at execution levels EL2 or EL3 to prevent updating by the operating system at EL1 or applications at EL0.

[0160] 22 is a flow diagram illustrating the processing of a GCS return state push instruction, which may be a GCS specific instruction specialized to push the return state to the GCS, or a reused function call branch instruction (branch with link instruction) that also functions as a GCS return state push instruction when executed in GCS mode. In step 1100, the instruction decode circuit 10 decodes the return state push instruction while GCS mode is indicated as enabled by the GCS enable parameter 1052. If GCS mode is indicated as disabled, this type of instruction may be considered an undefined instruction and thus may cause failure, or may be treated as a no operation (NOP) instruction that has no architectural effect but does not cause failure. Assuming that the GCS mode is enabled, in response to the GCS return state push instruction, the instruction decode circuit 10 controls the execution stage 16 of the processing circuit 4 to obtain return state information based on information in a register (e.g., a link register used to store a function return address, or an exception return state register used to store exception return information such as an exception return address and a saved processor state (e.g., mode / execution state indicating value)). In step 1104, the load / store unit 26 of the processing circuit 4 issues one or more GCS memory access requests to push the return state information obtained in step 1102 to a location on the guard control stack determined based on the GCS pointer stored in the GCS pointer register 1056 for the current execution state (ELx), and the processing circuit 4 updates the stack pointer by updating the GCS pointer register 1056 to advance the stack pointer to the next location on the stack. Any known stack pointer update mechanism can be used (e.g., the stack can be an ascending stack or a descending stack, and the stack pointer can point to either the next location where information is pushed, or the last location where information was pushed).

[0161] 23 is a flow diagram illustrating the processing of a GCS return state pop instruction, which in this example also functions as a return state verification instruction, decoded in step 1120 while GCS mode is enabled. The GCS return state pop instruction may be a GCS-specific instruction specialized for popping a return state to the GCS, or may be a reused exception return instruction that also functions as a GCS return state pop instruction when executed in GCS mode. Again, if GCS mode is disabled, the instruction may be treated as an undefined or NOP instruction. In response to decoding the GCS return state pop instruction, in step 1122, the instruction decoder 10 controls the execution stage 16 (load / store unit 26) of the processing circuitry 4 to issue one or more GCS memory access requests to pop return state information from a location on the guard control stack determined based on the stack pointer stored in the GCS pointer register 1056 for the current execution state ELx, and the processing circuitry 4 updates the stack pointer to take into account the pop operation.

[0162] In step 1124, processing circuitry 4 obtains current return state information based on information in a return state register (e.g., a link register or an exception return state register, as described above). In step 1126, processing circuitry 4 compares the current return state information with the popped return state information obtained from the GCS data structure 1058 in step 1122 to determine whether the compared states match. If a mismatch is detected between the current return state information and the popped (GCS-protected) return state information, in step 1128, a failure condition is signaled since a mismatched return state may be indicative of an attempted ROP attack. If the current return state matches the popped return state obtained from the GCS structure 1058, in step 1130, the software is allowed to proceed to return from the function / exception. Note that a function return or exception return need not be directly triggered by a GCS pop / return state verify instruction, as they may be triggered by the execution of a separate instruction, such as the return branch or exception return instruction shown in FIG. 19.

[0163] 23 shows an instruction that combines both popping return state information from the GCS and verifying the current return state against the popped return state, it is also possible to separate these operations into separate instructions (one instruction to pop the return state from the GCS and a second instruction to verify the popped return state against the current return state). Also, a standalone GCS pop instruction may be provided to allow return state information to be removed from the GCS structure 1058 in scenarios where the corresponding function / exception return is no longer needed. Also, if the GCS return state pop instruction directly controls the function / exception return state used for the function / exception return (either because the GCS return state pop instruction is combined with an exception return instruction as described above, or because the GCS return state pop instruction pops the GCS protected return state directly into a register used to provide the return state for controlling the function / exception return), it may not be necessary to perform the verification steps 1126, 1128.

[0164] FIG. 24 is a flow diagram showing the access permission check performed by the MMU 28 for a memory access issued when the GCS mode is enabled by the GCS enable parameter 1052. At step 1200, a memory access request is issued specifying a target virtual address corresponding to a target memory region. The memory access request may be a GCS memory access request triggered by one of the GCS push / pop instructions shown in FIG. 22 and FIG. 23 (or by another type of GCS access instruction), or may be another type of memory access request not triggered by a GCS access type instruction. At step 1202, the MMU 28 starts address translation based on the associated stage 1 and stage 2 address mappings defined in the stage 1 and stage 2 address translation structures. At step 1203, the MMU 28 determines whether the stage 1 permission information specified directly or indirectly by the target stage 1 translation table entry that provides the address mapping for the target virtual address specifies that the target memory region is a GCS region.

[0165] If the target memory region is a GCS region, then in step 1204, MMU 28 determines whether the memory access request is a GCS memory access request triggered by one of the restricted subset of GCS access type instructions. If not, in step 1205, MMU 28 determines whether the memory access request is a write request. If the memory access request is a write request, then in step 1206, a failure is signaled to prevent other general store instruction types from writing to the GCS structure 1058 stored in the GCS region.

[0166] If the memory access request is a GCS memory access request or a read request, then in step 1208, the MMU 28 determines whether the stage 1 GCS hardening check enable parameter 1054 indicates that stage 1 GCS hardening mode is enabled. When stage 1 GCS hardening mode is enabled, in step 1210, an additional check is performed on the GCS memory access request to check whether anti-aliasing properties 79 are specified for the target memory region by the stage 2 translation table entry corresponding to the target memory region. If anti-aliasing properties 79 are not specified for the target memory region, then a failure is signaled again in step 1206.

[0167] If, at step 1208, it is determined that the stage 1 GCS hardening mode is disabled, or if, at step 1210, the target memory region has anti-aliasing properties 79 defined in the corresponding stage 2 translation table entry, then, at step 1212, the MMU 28 determines whether other access permissions are satisfied for the memory access request. For example, this may be based on other parameters specified in the stage 1 or stage 2 translation table entry corresponding to the target region, or other security conditions, such as based on the security state, exception level, or other operating mode of the processing circuitry 4. If the other access permissions are not satisfied, then a failure is again signaled at step 1206. If all other access permissions are satisfied, then the memory access request may be permitted at step 1214.

[0168] If in step 1203 the MMU 28 determines that the target memory region was not a GCS region, then in step 1220 the MMU 28 determines whether the memory access request is a GCS memory access request triggered by one of the restricted subset of GCS access type instructions. This is the same check as in step 1204, but with a different result compared to step 1204. If in step 1220 the memory access request is a GCS memory access request, then in step 1206 a failure is signaled (this failure can be triggered for both read and write requests). This ensures that a GCS memory access request cannot be used to access a non-GCS region of memory, which prevents software developers from attempting to use GCS access type instructions for non-GCS accesses that would increase the attack surface available to an attacker, and allows detection of attacks based on address operands of GCS access type instructions that are modified by an attacker to point to non-GCS regions. By restricting GCS access type instructions to those that access GCS regions and non-GCS access type instructions to those that access non-GCS regions, security can be improved.

[0169] If, in step 1220, it is determined that the memory access request is not a GCS memory access request, then in step 1222, the MMU 28 determines whether other access permissions are satisfied for the memory access request. For example, this may include checks based on the security state, exception level, or operating mode as described above, and may also include checks based on the partial read-only region type or anti-aliasing property 79 described above. Also, if the memory access request was triggered by a RCW instruction of the protection entry check type described above, whether the access is permitted may also depend on checking stale data read from the target location corresponding to the target VA. If all required access conditions are satisfied, then in step 1224 the memory access request is permitted. If any access permissions are violated, then in step 1206, a failure is signaled.

[0170] Although FIG. 24 shows a single step 1206 of signaling a failure in response to many different checks failing, it will be appreciated that some implementations may signal different failure types depending on the cause of the failure.

[0171] Also, while FIG. 24 shows an example in which a failure is not required if a non-GCS read request targets a GCS area, in other examples, step 1205 can be omitted and step 1204 can proceed to step 1206, which signals a failure if a memory access request that targets a GCS area of ​​memory is not a GCS memory access request, regardless of whether the memory access request is a read or write request.

[0172] If GCS mode is currently disabled using GCS enable parameter 1052, the GCS access instruction may trigger a failure (e.g., an undefined instruction fail) or may be treated as a no-operation (NOP) instruction. Also, for memory access requests other than GCS access requests, the checks shown in steps 1212 or 1222 of Figure 24 may be performed, but if GCS mode is disabled, the checks at steps 1203, 1204, 1208, 1210, and 1220 may be omitted.

[0173] FIG. 25 illustrates a simulator implementation that may be used. While the above embodiments implement the invention in terms of apparatus and methods for operating specific processing hardware that supports the technique, it is also possible to provide an instruction execution environment according to the embodiments described herein implemented by the use of a computer program. Such a computer program is often referred to as a simulator insofar as the computer program 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 1330, optionally running a host operating system 1320 and supporting a simulator program 1310. In some arrangements, there may be multiple layers of simulation between the hardware and the instruction execution environment provided, and / or there may be multiple different instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide a simulator implementation that runs at a reasonable speed, but such an approach may be justified in certain situations, such as when it is desired to run code native to another processor for compatibility or reuse reasons. For example, a simulator implementation may provide an instruction execution environment that has additional functionality not supported by the host processor hardware, or that is typically associated with a different hardware architecture. An overview of simulation is given in "Some Efficient Architecture Simulation Techniques", Robert Bedichek, Winter 1990 USENIX Conference, pp. 53-63.

[0174] Although embodiments have been described above with reference to particular hardware constructs or features, in the simulated embodiments, equivalent functionality may be provided by suitable software constructs or features. For example, particular circuits may be implemented as computer program logic in the simulated embodiments. Similarly, memory hardware such as registers or caches may be implemented as software data structures in the simulated embodiments. In arrangements in which one or more of the hardware elements referenced in the foregoing embodiments reside on host hardware (e.g., host processor 1330), some simulated embodiments may utilize the host hardware where suitable.

[0175] The simulator program 1310 may be stored in a computer-readable storage medium (which may be a non-transitory medium) and provides a program interface (instruction execution environment) to the target code 1300 (which may include applications, operating systems, and hypervisors) that is the same as the interface of the hardware architecture being modeled by the simulator program 1310. Thus, program instructions of the target code 1300, including the protection entry check RCW instructions and GCS access instructions described above, can be executed from within the instruction execution environment using the simulator program 1310, so that a host computer 1330 that does not actually have the hardware capabilities of the device 2 described above can emulate these capabilities. Similarly, various memory management check functions as described above, including support for PRO region types, anti-aliasing properties, and GCS memory region types, can be emulated using memory management program logic 1318 of the simulator program 1310.

[0176] Thus, the simulator program 1310 may have a processing program logic 1312 that simulates states of the processing circuitry 4 described above. For example, the processing program logic 1312 may control transitions between execution states EL0-EL3 in response to events occurring during simulated execution of the target code 1300. The instruction decode program logic 1314 decodes instructions of the target code 1300 and maps these to corresponding instructions in the native instruction set of the host device 1330. The register emulation program logic 1316 maps register accesses requested by the target code to accesses to corresponding data structures maintained on the host hardware of the host device 1330, such as by accessing registers of the host device 1330 or data in memory 1332. The memory manager logic 1318 implements address translation, page table walks, and access control checks in a manner corresponding to the MMU 28 described in the hardware implementation embodiment above, but with the additional functionality of mapping simulated physical addresses resulting from stage 2 mapping in the address translation based on the page tables defined for the target code 1300 into host virtual addresses used to access the host memory 1332. These host virtual addresses may themselves be translated into host physical addresses using standard address translation mechanisms supported by the host (the translation of host virtual addresses to host physical addresses is outside the scope of what is controlled by the simulator program 1310).

[0177] In this application, the term "configured to..." is used to mean that an element of an apparatus has a configuration that is capable of performing a defined operation. In this context, "configuration" refers to a manner of arrangement or interconnection of hardware or software. For example, an apparatus may have dedicated hardware that provides the defined operation, or a processor or other processing device may be programmed to perform the function. "Configured to" does not imply that an apparatus element needs to be modified in any way to provide the defined operation.

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

Claims

1. It is a device, A processing circuit that executes an instruction in one of multiple execution states, Address management circuit for translating a target virtual address to a target physical address in response to a memory access request specifying a target virtual address corresponding to a target memory region to be accessed, wherein the mapping from the target virtual address to the target physical address depends at least on a stage 1 address mapping specified for the target virtual address by a target stage 1 translation table entry in a stage 1 translation table structure, and the stage 1 translation table structure is accessible using a stage 1 base address that can be set by an instruction executed by the processing circuit in a first execution state, At least when the memory access request is a write request, the memory management circuit shall, under the following conditions: The stage 1 authorization information specified by the target stage 1 conversion table entry specifies that the target memory area is a guard control stack (GCS) area for storing GCS data structures for protecting return state information for returning from function calls or exceptions, and The aforementioned memory access request is a request other than a GCS memory access request, which is triggered by one of a restricted subset of GCS access type instructions. It is configured to reject the memory access request in response to a determination that both of the following conditions are met. The memory management circuit is configured to support the translation hardening mechanism for defining at least one hardening stage 1 translation table entry that is protected by the translation hardening mechanism so as not to be tampered with by instructions executed in the first execution state, based at least on translation hardening information that can be set by instructions executed by the processing circuit in a second execution state having greater privileges than the first execution state, If anti-aliasing characteristics are specified for the target memory region, the memory management circuit is configured to reject the memory access request in response to detecting that the target stage 1 translation table entry or another stage 1 translation table entry used to find the target stage 1 translation table entry is a non-hardened translation table entry not protected by the translation hardening mechanism, and In at least one operating state of the processing circuit, the memory management circuit is configured to reject the memory access request in response to determining that the memory access request is a GCS memory access request and that the anti-aliasing characteristic is not specified for the target memory region. Device.

2. The apparatus according to claim 1, wherein the memory management circuit is configured to support a two-stage address translation in which the stage 1 address mapping includes a mapping from the target virtual address to the target intermediate address, the address mapping from the target virtual address to the target physical address also depends on a stage 2 address mapping from the target intermediate address to the target physical address, which is specified for the target intermediate address by a target stage 2 translation table entry in the stage 2 translation table structure, and the stage 2 translation table structure is accessible using a stage 2 base address that can be set by an instruction executed by the processing circuit in the second execution state.

3. The apparatus according to claim 2, wherein the target stage 2 conversion table entry specifies whether the anti-aliasing characteristic is specified for the target memory area.

4. The apparatus according to claim 2 or 3, wherein, with respect to a given stage 1 translation table entry stored in a given memory area corresponding to a given intermediate address, the translation hardening information for specifying whether the given stage 1 translation table entry is a hardening stage 1 translation table entry includes stage 2 authorization information specified by the corresponding stage 2 translation table entry corresponding to the given intermediate address.

5. Each hardening stage 1 conversion table entry is stored in the given memory area that stores the stage 1 conversion table entry, according to the stage 2 authorization information of the corresponding stage 2 conversion table entry. A read-only memory area where write requests are prohibited, and A partially read-only memory region to which write requests are permitted for a restricted subset of write request types and prohibited for write request types other than the restricted subset, wherein the restricted subset of write request types includes at least metadata update write requests generated by the memory management circuit to update access tracking metadata in a translation table entry. The apparatus according to claim 4, comprising a stage 1 conversion table entry indicated as one of the following.

6. The apparatus according to claim 5, wherein the stage 2 authorization information has encoding to indicate both the read-only memory area and the partially read-only memory area.

7. The Stage 2 authorization information specifies whether the given memory region is a partially read-only memory region in which write requests to a restricted subset of write request types are permitted and prohibited for write request types other than the restricted subset, wherein the restricted subset of write request types includes at least metadata update write requests generated by the memory management circuit to update access tracking metadata in a translation table entry, and The apparatus according to claim 4, wherein the memory management circuit is configured to support each stage 1 translation table entry of the first translation table structure having a coding that specifies whether each stage 1 translation table entry of the first translation table structure is a protected entry whose updates are restricted, compared to an unprotected stage 1 translation table entry that is not designated as a protected entry, and the restricted subset of write request types includes write request types that allow updating an unprotected stage translation table entry but prohibit updating at least a subset of bits of a protected stage 1 translation table entry.

8. The processing circuit includes a protection entry check in response to a processing circuit that executes a protection entry check type read-check-write instruction to request an update to a given memory system location. Read data from the aforementioned given memory system location, The system checks whether the data read from the given memory system location has a value that matches the stage 1 conversion table entry designated as a protection entry. In response to the determination that the data read from the given memory system location has a value matching that of a stage 1 translation table entry designated as a protected entry, a subset of the update-restricted bits of the stage 1 translation table entry is prevented from being updated in response to the read-check-write instruction. The restricted subset of the write request types includes write requests issued in response to a read-check-write instruction of the protection entry check type. The apparatus according to claim 7.

9. The apparatus according to claim 7, wherein the conversion hardening information includes information indicating whether a given stage 1 conversion table entry is designated as the protected entry, and the memory management circuit is configured to treat an unprotected stage 1 conversion table entry as an unhardened stage 1 conversion table entry if the stage 2 authorization information designated by the corresponding stage 2 conversion table entry specifies that the given memory area is the partially read-only memory area.

10. Each hardening stage 1 conversion table entry is: The Stage 1 conversion table entry, indicated by the Stage 2 permission information, states that the given memory area is a read-only memory area where write requests are prohibited, and The given memory region is designated as the Stage 1 conversion table entry indicated by the Stage 2 permission information as the partially read-only memory region, The apparatus according to claim 7, comprising one of the following.

11. The apparatus according to any one of claims 1 to 3, wherein the at least one operating state of the processing circuit includes an operating state in which the GCS conversion hardening check enable control parameter is set to an enable state indicating that a GCS memory access request should be subject to a check as to whether the anti-aliasing characteristic is specified for the target memory region.

12. The apparatus according to any one of claims 1 to 3, wherein the memory management circuit is configured to reject the memory access request in response to the determination that the memory access request is a GCS memory access request and that the stage 1 authorization information does not specify that the target memory area corresponding to the target virtual address is the GCS area.

13. The apparatus according to any one of claims 1 to 3, wherein the restricted subset of GCS access type instructions includes a return state push instruction that controls the processing circuit to push return state information obtained based on information shown in one or more registers of the processing circuit to the GCS data structure.

14. The apparatus according to any one of claims 1 to 3, wherein the restricted subset of GCS access type instructions includes a return state pop instruction that controls the processing circuit to pop return state information from the GCS data structure.

15. The apparatus according to any one of claims 1 to 3, comprising at least one GCS pointer register for storing a stack pointer indicating the address of the GCS data structure.

16. The apparatus according to any one of claims 1 to 3, wherein the stage 1 authorization information specifying whether the target memory area is the GCS area is specified in a field of an authorization indirect register referenced by the target stage 1 translation table entry.

17. It is a method, The process of executing an instruction in one of several execution states, A step of translating a target virtual address to a target physical address in response to a memory access request specifying a target virtual address corresponding to a target memory region to be accessed, wherein the mapping from the target virtual address to the target physical address depends at least on a stage 1 address mapping specified for the target virtual address by a target stage 1 translation table entry in a stage 1 translation table structure, and the stage 1 translation table structure is accessible using a stage 1 base address that can be set by an instruction executed by a processing circuit in a first execution state, If the memory access request is at least a write request, the memory access request is subject to the following conditions: The stage 1 authorization information specified by the target stage 1 conversion table entry specifies that the target memory area is a guard control stack (GCS) area for storing GCS data structures for protecting return state information for returning from function calls or exceptions, and The aforementioned memory access request is a request other than a GCS memory access request, which is triggered by one of a restricted subset of GCS access type instructions. It is configured to be rejected in response to the determination that both conditions are met, The translation hardening mechanism is supported in order to define at least one hardening stage 1 translation table entry that is protected by the translation hardening mechanism so as not to be tampered with by an instruction executed in the first execution state, based at least on translation hardening information that can be set by an instruction executed in a second execution state having greater privileges than the first execution state, The aforementioned method, If anti-aliasing characteristics are specified for the target memory region, the memory access request is rejected in response to detecting that the target stage 1 translation table entry or another stage 1 translation table entry used to find the target stage 1 translation table entry is a non-hardened translation table entry not protected by the translation hardening mechanism. In at least one operating state of the processing circuit, in response to determining that the memory access request is the GCS memory access request and that the anti-aliasing characteristic is not specified for the target memory region, the process includes rejecting the memory access request, Methods that include...

18. A computer program that controls a host data processing device to provide an instruction execution environment for executing target code when executed by the host data processing device, wherein the computer program is A processing program logic that simulates the execution of the instruction of the target code in one of several execution states, Memory management program logic that translates a target virtual address corresponding to a target memory region to be accessed to a simulated target physical address in response to a memory access request specifying the target virtual address, wherein the mapping from the target virtual address to the simulated target physical address depends at least on a stage 1 address mapping specified for the target virtual address by a target stage 1 translation table entry in a stage 1 translation table structure, and the stage 1 translation table structure is accessible using a stage 1 base address that can be set by a simulated instruction executed in a first execution state, If the memory access request is at least a write request, the memory management program logic shall, under the following conditions: The stage 1 authorization information specified by the target stage 1 conversion table entry specifies that the target memory area is a guard control stack (GCS) area for storing GCS data structures for protecting return state information for returning from function calls or exceptions, and The aforementioned memory access request is a request other than a GCS memory access request, which is triggered by one of a restricted subset of GCS access type instructions. It is configured to be rejected in response to the determination that both conditions are met, The memory management program logic is configured to support a translation hardening mechanism for defining at least one hardening stage 1 translation table entry that is protected by the translation hardening mechanism so as not to be tampered with by instructions simulated to run in a first execution state, based at least on translation hardening information that can be set by instructions simulated to run in a second execution state having greater privileges than a first execution state, If anti-aliasing characteristics are specified for the target memory region, the memory management program logic is configured to reject the memory access request in response to detecting that the target stage 1 translation table entry or another stage 1 translation table entry used to find the target stage 1 translation table entry is a non-hardened translation table entry not protected by the translation hardening mechanism. In at least one operating state of the processing program logic, the memory management program logic is configured to reject the memory access request in response to determining that the memory access request is a GCS memory access request and that the anti-aliasing characteristic is not specified for the target memory region. Computer program.

19. A storage medium for storing the computer program described in claim 18.

Images