Exception return state lock parameter

Abstract

The apparatus includes an exception return state register storage device and a processing circuit. The processing circuit is responsive to a protection control stack (GCS) exception return state push instruction to retrieve exception return state information from the exception return state register storage device and push the state information to a GCS data structure. The processing circuit is responsive to a GCS exception return state pop instruction to retrieve GCS protection exception return state information from the GCS data structure. The processing circuit is responsive to an attempt to modify the exception return state information stored in the exception return state register storage device in at least one operating state to detect whether an exception return state lock parameter is in a locked or unlocked state and to signal a fault when in the locked state.

Description

[Technical field]

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

[0002] The data processing apparatus may save exception return state information in response to taking an exception, the exception return state information indicating the state of the processor when the exception was taken, such that once exception handling has been completed the processor may return to processing that was occurring before the exception was taken.

[0003] At least some examples provide an apparatus that includes an exception return state register storage device for storing exception return state information, and a processing circuit for performing processing operations in response to instructions, the processing circuit comprising a guarded control stack. and a processing circuit configured to retrieve GCS protected exception return state information from the exception return state register storage device in response to a GCS exception return state push instruction and to push the exception return state information to the GCS data structure; and a processing circuit configured to retrieve GCS protected exception return state information from the GCS data structure in response to a GCS exception return state pop instruction. The apparatus comprises a memory management circuit for rejecting a write request specifying the target address in response to determining that a memory region corresponding to the target address is designated as a GCS region for storing the GCS data structure and the write request is a request other than a GCS memory access request triggered by one of a restricted subset of GCS access type instructions, the restricted subset of GCS access type instructions including at least a GCS exception return state push instruction. The processing circuit is configured to detect whether an exception return state lock parameter is in a locked or unlocked state in response to an attempt to modify the exception return state information stored in the exception return state register storage device in at least one operating state of the processing circuit, and to signal a fault if it detects that the exception return state lock parameter is in a locked state.

[0004] At least some examples include storing exception return state information in an exception return state register storage device and performing a processing operation in response to an instruction using a processing circuit; retrieving the exception return state information from the exception return state register storage device in response to a protection control stack (GCS) exception return state push instruction and pushing the exception return state information into a GCS data structure; retrieving the GCS protection exception return state information from the GCS data structure in response to a GCS exception return state pop instruction; a memory region corresponding to the target address is designated as a GCS region for storing the GCS data structure; the write request is a limited subset of instructions of the GCS access type, and the GCS access type is a limited subset of instructions of the GCS access type. the restricted subset of GCS access type instructions including at least a GCS exception return state push instruction, in response to determining that the request is other than a GCS memory access request triggered by one of the restricted subset of GCS access type instructions, the restricted subset including at least a GCS exception return state push instruction, rejecting a write request specifying a target address, and in at least one operating state of the processing circuit, in response to an attempt to modify the exception return state information stored in the exception return state register storage device, detecting whether an exception return state lock parameter is in a locked or unlocked state and signaling a fault if detecting that the exception return state lock parameter is in a locked state.

[0005] At least some examples provide a computer program including instructions that, when executed by a host data processing apparatus, control the host data processing apparatus to provide an instruction execution environment for executing target code, the computer program including: register emulation program logic that controls the host data processing apparatus to simulate an exception return state register storage for storing exception return state information; and processing program logic that controls the host data processing apparatus to simulate execution of instructions of the target code, the processing program logic being configured to, in response to a protected control stack (GCS) exception return state push instruction of the target code, retrieve the exception return state information from the simulated exception return state register storage and push the exception return state information into a GCS data structure; and the processing program logic being configured to, in response to a GCS exception return state pop instruction of the target code, retrieve the GCS protected exception return state information from the GCS data structure; the memory manager program includes memory manager logic for rejecting a write request specifying the target address in response to determining that the memory region corresponding to the target address is designated as a GCS region for storing a GCS data structure, and the write request is a request other than a GCS memory access request triggered by one of a restricted subset of GCS access type instructions, the restricted subset of GCS access type instructions including at least a GCS exception return state push instruction; and the processing program logic is configured to detect whether an exception return state lock parameter is in a locked or unlocked state in response to an attempt to modify the exception return state information stored in the simulated exception return state register storage device in at least one simulated operating state of the processing program logic, and to signal a fault if it detects that the exception return state lock parameter is in a locked state.

[0006] The computer program may be stored in a 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] 1 illustrates an example of a register of a processing circuit. [Diagram 5] 1 shows an example of instructions that are executed on entry to and return from a taken exception. [Figure 6] 1 illustrates the use of a protected control stack (GCS) structure to protect return state information obtained in response to an exception entry. [Figure 7] Here is an example of instructions that are executed on entry to and return from a taken exception when using the GCS structure: [Figure 8] FIG. 1 is a flow diagram illustrating a method for checking whether a memory access request is granted. [Figure 9] FIG. 11 is a flow diagram showing steps performed upon exception entry. [Figure 10] FIG. 11 is a flow diagram showing steps performed in response to a GCS exception return state push instruction. [Figure 11] FIG. 2 is a flow diagram showing steps performed in response to a GCS exception return state pop instruction. [Figure 12] FIG. 2 is a flow diagram showing steps performed in response to an exception return instruction. [Figure 13] FIG. 11 is a flow diagram illustrating two alternative examples of steps performed in response to an instruction requesting modification of exception return state information stored in an exception return state register storage device. [Figure 14]FIG. 11 is a flow diagram illustrating two alternative examples of steps performed in response to an instruction requesting modification of exception return state information stored in an exception return state register storage device. [Figure 15] 1 shows an implementation of a simulator.

[0008] The apparatus has an exception return state register storage device for storing exception return state information, and processing circuitry for performing processing operations in response to instructions.

[0009] Return-oriented-programming (ROP) based attacks are a common class of attacks against data processing systems. ROP attacks attempt to cause a program to behave in an unexpected way by corrupting the return state information used to return from a function call or exception. Often, software stores return state information in memory, for example to facilitate nesting of function calls or exceptions, and the return state information of an outer function call or exception (of a set of nested function calls or exceptions) is saved to memory for preservation before it can be overwritten in a register with the return state information of an inner function call or exception. A successful ROP attack may cause a function return or exception return to return program flow to an instruction other than the next instruction at the time the function was called or the exception was taken, allowing an attacker to control the processing circuit to perform any sequence of operations other than the sequence of operations intended by the programmer.

[0010] To protect against ROP-based attacks that tamper with exception return state information, it may be useful to provide a protected control stack (GCS) data structure used to protect return state information for returning from an exception. The processing circuitry retrieves exception return state information from an exception return state register storage device in response to a protected control stack (GCS) exception return state push instruction, and pushes the exception return state information to the GCS data structure. The processing circuitry retrieves the GCS protected exception return state from the GCS data structure in response to a GCS exception return state pop instruction. Protection of the GCS data structure may be provided by a memory management circuitry that supports designating a memory region as a GCS region intended to store the GCS data structure. The memory management circuitry rejects a write request that specifies a target address in response to determining that a memory region corresponding to the target address is designated as a GCS region when the write request is a request other than a GCS memory access request triggered by one of a restricted subset of GCS access type instructions (the restricted subset of GCS access type instructions includes at least a GCS exception return state push instruction). Thus, one can define protected regions of memory that cannot be written to by any type of write request (e.g., general-purpose (non-GCS-specific) store instructions can be excluded from the restricted subset of GCS access type instructions). This limits the attack surface available to an attacker to attempt to subvert the GCS-protected exception return state stored in the GCS data structures. Thus, one can provide stronger protection for the exception return state than is possible using a general-purpose stack maintained by software in a standard readable / writeable memory region.

[0011] However, the inventors have recognized that there may be a window between exception entry (when the exception return state is captured in the exception return state register storage) and execution of the GCS exception return state push instruction, and another window between execution of the GCS exception return state pop instruction and exception return, when the exception return state information may be vulnerable to tampering in the registers that, if successful, may circumvent checks based on the protected exception return state information stored in the GCS data structure. If an attacker is able to modify the exception return state in the exception return state register storage between the exception entry and execution of the GCS exception return state push instruction, an incorrect exception return state may be pushed into the GCS data structure and thus erroneously considered as trusted in the GCS data structure. Similarly, some attacks may be based on modifying the exception return state in the exception return state register storage after execution of the GCS exception return state pop instruction but before execution of the exception return.

[0012] One approach to address this issue may be to require that the operation of the GCS exception return state push instruction is instead executed in hardware in response to the exception entry itself, and that the operation of the GCS exception return state pop instruction is executed in response to the same instruction that triggers the exception return, in order to eliminate these time windows. However, this approach may increase the number of operations that require triggering by a single event (exception entry and return). Such an overload of actions required in response to a single triggering event may make it much more complicated for processor microarchitecture designers to implement circuit hardware to support these operations while meeting circuit timing requirements. Also, separating the GCS exception return state push instruction from the exception entry and the GCS exception return state pop instruction from the exception return also has the advantage that software has more flexibility to decide which exception entry / return events to protect or not protect, and therefore it may not be desirable to combine these operations.

[0013] In the examples described below, an exception return state lock parameter is provided that can be set to a locked or unlocked state. In at least one operating state of the processing circuit, the processing circuit detects whether the exception return state lock parameter is in a locked or unlocked state in response to an attempt to modify the exception return state information stored in the exception return state register storage device, and signals a fault if it detects that the exception return state lock parameter is in a locked state. By providing an architectural mechanism to lock and prevent modification of the exception return state information, the security provided by the GCS-based checking of the exception return state information can be improved by preventing tampering with the exception return state information within the window between the exception entry and the push of the exception return state to the GCS data structure, and between the pop of the GCS-protected exception return state information and the subsequent exception return.

[0014] The processing circuit may support execution of instructions at one of several exception levels associated with different privilege levels. In at least one operating state of the processing circuit, the processing circuit may set an exception return state lock parameter to a locked state in response to an exception being taken where the exception is to be taken at the same exception level as the current exception level before the exception was taken. Thus, for an exception to be taken at the same exception level as the processing executed before the exception was taken, the exception entry may cause the processing circuit to lock the exception return state information against modification before the obtained exception return state information may be pushed to the GCS data structure to protect the exception return state information obtained in response to the exception entry from tampering. Setting the exception return state lock parameter to the locked state may be done automatically in response to the exception being taken without requiring an explicit software instruction executed after the exception entry that sets the exception return state lock parameter to the locked state.

[0015] It is not mandatory to set the exception return state lock parameter to a locked state in response to an exception entry where an exception is to be taken for an exception level having higher privileges than the exception level that was current before the exception was taken. If an exception is taken for a higher privileged level, the higher privileged exception handling code can be trusted to properly manage the exception return. Attacks are more likely when exceptions are taken for the same exception level. Nevertheless, other implementations may also choose to lock the exception return state information when an exception is taken for a higher privileged exception level.

[0016] In at least one operating state of the processing circuit, the processing circuit may set an exception return state lock parameter to an unlocked state in response to a GCS exception return state push instruction. Thus, once the exception return state information has been pushed into the GCS data structure, there is no longer a need to prevent modification of the exception return state information in the exception return state register storage, and thus switching the lock parameter to an unlocked state allows subsequent operations that may need to effectively modify the information in the exception return state register storage to proceed. Unlocking the exception return state lock parameter in response to a GCS exception return state push instruction also helps improve security by enabling detection of cases where an instruction (e.g., an exception return instruction) that is executed when modification of the exception return state should be locked is executed in an incorrect sequence of program flow when modification of the exception return state is currently unlocked.

[0017] In at least one operating state of the processing circuit, the processing circuit may set an exception return state lock parameter to a locked state in response to a GCS exception return state pop instruction. The GCS exception return state pop instruction may mark the beginning of a window during which the exception return state popped from the GCS data structure is vulnerable to tampering, and thus locking the exception return state in response to a GCS exception return state pop instruction helps provide confidence that, on subsequent exception returns, the exception return state information used for the exception return is still the same as the information obtained from the GCS data structure.

[0018] In at least one operating state of the processing circuit, the processing circuit checks whether the exception return state lock parameter is set to a locked state in response to an exception return instruction for triggering an exception return based on exception return state information stored in the exception return state register storage device, where the exception return is a return to processing at the same exception level as the current exception level before the exception return, and signals a fault in response to detecting that the exception return state lock parameter is set to an unlocked state. This may help protect against attacks that may attempt to control program flow to cause an exception return instruction to be executed without first obtaining GCS-protected exception return state information using a GCS exception return state pop instruction.

[0019] When an instruction is executed that may cause information in the exception return status register storage to be modified while the exception return status lock parameter is set to the locked state, different approaches can be taken to determine whether or not a fault should be signaled.

[0020] In one example, in at least one operating state of the processing circuit, the processing circuit may signal a fault in response to an attempt to execute an instruction that requests a modification to information in the exception return state register storage device when the exception return state lock parameter is set to a locked state, regardless of whether a new value to be written to the exception return state register storage device is the same as or different from an old value previously stored in the exception return state register storage device. Thus, in this case, if an instruction attempts to modify information in the exception return state register storage device and such modifications are locked, a fault is signaled even if the new value to be written by the instruction is the same as the old value previously stored in the exception return state register storage device. Although there is no modification of the exception return state information if the new value is the same as the old value, signaling a fault regardless of any comparison between the old and new values ​​may be simpler (from the perspective of a hardware designer attempting to implement control circuit logic for controlling the signaling of a fault in response to the exception return state lock parameter), since there is no need to read the value currently stored in the exception return state register storage device to determine whether to trigger a fault or not.

[0021] In another example, in at least one operating state of the processing circuit, when the exception return state lock parameter is set to the locked state, the processing circuit, in response to an attempt to execute an instruction that requires a modification to information in the exception return state register storage device, can check whether a new value to be written to the exception return state register storage device is the same as or different from an old value previously stored in the exception return state register storage device, and signal a fault if it determines that the new value is different from the old value. This approach can be useful for speeding up the processing of some fast exception code paths where the exception handler is so short that it does not need to save / restore the exception return state to / from a stack in memory. In this case, the exception handler may prefer not to execute any GCS exception return state push / pop instructions, since the exception return state initially obtained may remain in the exception return state register storage device throughout the execution of the exception handler. This may mean that the exception return state lock parameter may remain in the locked state across the exception handler. Nevertheless, there may be some valid reasons why the exception handler may attempt to modify the exception return state register storage device. Thus, while a fault should be triggered if there is an attempt to modify the exception return state information stored in the exception return state register storage device while the lock parameter is in the locked state, sometimes the attempted modification may actually write the same value already stored in the exception return state register storage device, in which case there is no risk of the exception return state being corrupted. For example, this may occur if, as described above, there was no intention to modify the exception return state information because it is in a fast exception code path, but the exception handler code includes a common code path shared with other use cases that require modification of the exception return state information, and it is preferable anyway to execute an instruction that writes to the exception return state register (e.g., to speed up performance by avoiding conditional branches), but sets an operand of that instruction to write the same value previously stored in the exception return state register when the instruction is used with the fast exception code path.Therefore, by not signaling a fault if the modifying instruction does not change the value in the exception return status register storage, performance can be improved by eliminating the latency added by signaling a fault (which would otherwise interrupt current processing and allow a different exception handler to run).

[0022] The GCS exception return state pop instruction can be implemented in different ways.

[0023] In some examples, the GCS exception return state pop instruction can simply pop the GCS protection exception return state information into the register storage (either directly into the exception return state register storage, or into a general-purpose register where a subsequent instruction can move the GCS protection exception return state information into the exception return state register storage). The GCS protection exception return state information can then be used directly to control exception return upon execution of a subsequent exception return instruction. In this case, software does not need to manage the saving / restoring of exception return state information into a software-managed stack structure, typically in memory. This is because execution of the GCS exception return state push / pop instruction means that the GCS data structure is sufficient to track the exception return state, even if a nested exception causes the exception return state in the exception return state register storage to be overwritten.

[0024] In another example, rather than using the GCS protected exception return state to control the exception return directly, it can be used to verify whether the intended exception return state information stored in the exception return state register storage is safe to use for a subsequent exception return. In this case, software can use its normal mechanisms to manage the exception return state information in the exception return state register storage (e.g., if exceptions are nested, the software saves / restores the exception return state to a stack data structure maintained in non-GCS memory). The GCS exception return state push / pop instructions further save / restore the exception return state to a GCS data structure, allowing the intended exception return state information obtained by the software to be checked before being used to control the exception return.

[0025] Thus, in such an example, in addition to popping the GCS protection exception return state information from the GCS data structure in response to a GCS exception return state pop instruction, the processing circuitry also signals a fault upon detecting a mismatch between the intended exception return state information obtained from the exception return state register storage and the GCS protection exception return state information obtained from the GCS data structure. Thus, the GCS protection exception return state information is not used to directly control exception return, but rather is used to verify the intended exception return state information.

[0026] In another example, the GCS protection exception return state information may be used to verify whether the intended exception return state information is correct, but this verification may not be performed in response to the GCS exception return state pop instruction itself; instead, a subsequent GCS exception return state verify instruction may verify whether the intended exception return state information in the exception return state register storage matches the previously popped GCS exception return state information obtained by the GCS exception return state pop instruction.

[0027] The exception return state information stored in the exception return state register storage may be in a variety of forms. In general, the exception return state register storage may comprise one or more registers that store the exception return state information. For example, the exception return state register storage may comprise an exception return address register for storing the exception return address of the instruction to be executed after returning from the exception, and / or a saved processor state register for storing the processor state to be restored upon return from the exception. The information stored in one or both of these registers may be stored in the GCS structure in response to a GCS exception return state push instruction.

[0028] The saved processor state register may be a register in which the current processor state of the processing circuit is copied from the processor state register to the saved processor state register in response to taking an exception. Since taking an exception may cause the current processor state to change, the current processor state may be captured by copying it to the saved processor state register, so that the processing circuit is free to update the current processor state according to the state in which the exception is taken. An exception handler executed in software may then read the saved processor state register and save the captured state to memory to ensure that the saved processor state is preserved even if a further exception occurs that preempts the handling of the previous exception. A GCS exception state push instruction may also be used to push the saved processor state into the GCS data structure to enable verification of the exception return state information upon the corresponding exception return.

[0029] The exception return state lock parameter may usefully be a parameter specified in a processor state register. This means that the exception return state lock parameter itself is automatically saved when an exception is taken, since, along with other contents of the processor state register, it may be copied to the saved processor state register in response to the exception being taken. Similarly, in response to an exception return instruction, the previous value of the exception return state lock parameter is restored by copying the saved processor state from the saved processor state register to the processor state register. This approach therefore means that if a new exception is taken during the window between the exception entry and the GCS exception return state push instruction, or during the window between the GCS exception return state pop instruction and the exception return, the current state of the exception return state lock parameter (which should be in a locked state during these windows) is captured and therefore restored on return from the new exception as part of the normal restoration of the saved processor state, allowing it to be restored to its previous state at the time the new exception was taken. Thus, an attacker cannot use triggering a new exception as a mechanism to attempt to circumvent the protection provided by the exception return state lock parameter.

[0030] Monitoring of modifications to the exception return state register storage based on the exception return state lock parameter is not necessarily required in all operating states of the processing circuit. For example, some control state information stored in one or more control registers may be used to determine whether or not various checks of the exception return state lock parameter described above should be performed. Disabling these checks may be useful for backward compatibility with software written for legacy systems that did not support the exception return state lock parameter. Such legacy software may require greater vigilance on the part of the software developer in ensuring that there are no loopholes that an attacker can exploit to perform an ROP attack.

[0031] Thus, in one example, at least one operating state of the processing circuit includes an operating state in which the exception recovery state lock enable control parameter is set to a valid state indicating that locking of the exception recovery state information using the exception recovery state lock parameter is valid, and if the exception recovery state lock enable control parameter is set to a invalid state, there is no need to update or check the exception recovery state lock parameter as described above.

[0032] In some examples, architectural features supporting the use of GCS data structures (such as GCS exception return state push / pop instructions, other instructions that interact with GCS data structures, and various faults triggered to protect GCS data structures from unauthorized access) may be completely disabled depending on the state of the GCS enable parameter. Again, support may be provided for software written for legacy systems that did not support these GCS-based architectural features. Thus, at least one operational state of the processing circuit (in which the various measures described above in conjunction with the exception return state lock parameter are taken) may include an operational state in which the exception return state lock enable control parameter is set to an enabled state indicating that locking of exception return state information is enabled using the exception return state lock parameter, and the GCS enable parameter is set to an enabled state indicating that a GCS mode for supporting the use of GCS data structures is enabled.

[0033] As described above, the memory management circuitry may reject a write request that specifies a target address in response to determining that the memory region corresponding to the target address is designated as a GCS region and that the write request is other than a GCS memory access request triggered by one of a restricted subset of GCS access type instructions that are permitted to access GCS regions. The memory management circuitry may also reject a memory access request in response to determining that the memory access request is a GCS memory access request and that the memory region corresponding to the target address is not 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 a normal memory region that is used to store other data. This means that if the address operand of a GCS access type instruction is modified by an attacker (e.g., made incorrect by an attacker forcing an incorrect sequence of program flow) to cause the GCS memory access request to access a non-GCS region, this is detected as an error and the request to access memory is rejected. This improves security by preventing an attacker from forging the GCS-protected exception return state by substituting another region of memory for the GCS data structures.

[0034] Although the GCS data structure is described above as being used to protect exception return state information from ROP attacks, the same data structure may also be used to protect function return state information, such as function return addresses. A mechanism may be provided to detect whether information obtained from the GCS data structure is exception return state information or function return state information (e.g., by distinguishing and enabling the encoding of valid exception return state records and valid function return state records to be distinguishable), so that a GCS exception return state verification instruction may cause the processing circuitry to check whether a obtained GCS record used as GCS protected exception return state information corresponds to a valid exception return state record, and thus monitor for attempts to produce erroneous behavior by verifying the exception return state information for an exception return using the function return state record.

[0035] In other examples, GCS data structures may be used to protect exception return state information but not to protect function return state information (e.g., a different mechanism may be used to protect function return state from ROP attacks, or architectural level protection from ROP attacks may not be provided for function return state information (instead, the responsibility for defending against ROP attacks on function returns may fall on the software developer)). Thus, GCS data structures are not necessarily shared between exception return state and function return state.

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

[0037] 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 the 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, register emulation program logic, and memory management program logic that emulate the functionality of the processing circuitry, exception return state register storage, and memory management circuitry described above, such as the support of the GCS exception return state push instruction and the GCS exception return state pop instruction, and the exception return state lock parameter, 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.

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

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

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

[0041] The device also comprises an exception handling circuit 40 for controlling the handling of exceptions. In response to an exception signal 42, the exception handling circuit 40 interrupts the processing being performed by the pipeline 4 and controls the pipeline 4 to switch to the processing of an exception handler corresponding to the type of exception indicated by the exception signal 42. For example, the exception may be an interrupt triggered by an external event not directly caused by the software being executed by the processing pipeline 4, such as an interrupt signaling an external event, such as a user pressing a button on an electronic device comprising the processing device, a processor reset being asserted, receipt of a message from a network interface or other input / output device, etc. Also, the exception may be a software-triggered exception, which is directly caused by the software being executed by the pipeline 4. A software-triggered exception may be voluntarily triggered by the software, for example by executing an instruction that causes a "supervisor call" interrupt to be taken, triggering a switch to a more privileged execution state. Alternatively, a software-triggered exception may be an exception involuntarily triggered by the software, which occurs due to an error occurring in at least one instruction executed by the software, such as an undefined instruction error or an address fault.

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

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

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

[0045] If an exception is taken during processing at the current exception level ELx, the exception may be executed at the same exception level ELx or at a more privileged exception level ELy, where y>x. A property associated with the exception type may indicate the target exception level of the exception.

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

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

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

[0049] 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) (the virtual machine corresponding to the 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). 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.

[0050] 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 for stage 1 and stage 2, respectively. 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).

[0051] 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. In the case of a non-secure EL1&0 translation regime, this set includes both stage 1 and stage 2 translation lookups. 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 of the target memory region that provide information about how to control access to the 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.

[0052] 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 final entry of the traversal of the stage 1 or stage 2 structures and provides the address mapping being explored. 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 final 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 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 translation failure.

[0053] Register Status 4 shows an example of a subset of the registers 14 of a data processing apparatus, including registers for storing architectural state used to handle exception returns and registers for protecting the exception return state from tampering. The registers 14 include a set of general purpose registers (GPRs) 50 for storing general purpose operands and results of data processing instructions and load / store instructions. A program counter (PC) register 52 is provided for storing a program counter value indicating the address of an instruction representing the current point in the program flow. Processor state (PSTATE) registers 54 store one or more values ​​indicative of the current state of the processing circuitry 4. For example, the PSTATE register 54 includes an indication 56 of the current exception level EL. PSTATE register 54 may also include an indication of the current instruction set to be set to be used for decoding instructions in decode stage 10, the current security state, other indications of the processor mode in which processing circuitry 4 is operating, as well as condition code flags used to indicate the results of previous processing instructions that may be used to evaluate whether a test condition is satisfied for a subsequent conditional instruction (which conditional instruction controls the processing circuitry to perform a function that is conditional on the test condition being satisfied). In addition, as described further below, PSTATE register 54 includes an exception return state lock parameter (EXLOCK) 58 for locking the exception return state information to prevent updates.

[0054] The registers 14 include several exception return registers, such as a saved processor state register (SPSR) 60 and an exception link register (ELR) 62 in this example. In this example, the SPSR 60 and the ELR 62 are banked registers, meaning that several separate instances of these registers are provided corresponding to different exception levels EL1-EL3. When an exception is taken to be handled at a given exception level ELx (ELx being one of EL1, EL2, and EL3), the current program counter stored in the program counter register 52 is copied to the ELR_ELx 62 and the current processor state stored in the PSTATE register 54 is copied to the SPSR_ELx 60 (i.e., copied to several versions of the ELR 62 and the SPSR 60 corresponding to the given exception level ELx). The copied value of the program counter may be referred to as an exception return address. The copied value of the current processor state may be referred to as a saved processor state. The exception return address and the saved processor state may be collectively referred to as exception return state information. Upon exception return from an exception handled at a given exception level ELx, the saved processor state is copied from SPSR_ELx 60 to the PSTATE register 54 and the exception return address is copied from ELR_ELx 62 to the program counter register 52 to restore the processor to the state it was in when the exception was taken. The register suffix ELx indicates that exception ELx is the lowest privileged exception level that allows instructions to write to these registers. Thus, for example, SPSR_EL2 can be written to EL2 or EL3, but not to EL0 or EL1.

[0055] The registers 14 also include a protection control stack pointer register (GCSPR) 64, which is again banked per exception level such that there is a version of GCSPR_ELx associated with each of the exception levels EL1, EL2, EL3. The GCS pointer register 64 is used to store a stack pointer that points to a data structure in memory called the protection control stack (GCS) that is used to protect the exception return state saved in the SPSR 60 and ELR 62 upon an exception. This is discussed in more detail below. The registers also include a GCS control register (GCSCR) 66, which is also banked per exception level to provide versions of GCSCR_ELx that correspond to the exception levels EL1, EL2, EL3. When the processing circuit 4 is operating at a given exception level ELx, the corresponding stack pointer as well as the GCS control registers GCSPR_Elx and GCSCR_ELx provide the stack pointer and control state for controlling the use of the GCS data structure. The GCS control registers 66 include at least a GCS enable parameter 68 for controlling whether architectural measures for protecting use of the GCS data structures are enabled or disabled, and an exception return state lock enable parameter (EXLOCKEN) 69 for controlling whether use of the exception return state lock parameter (EXLOCK) 58 for preventing modification of the exception return registers 60, 62 is enabled or disabled. It will be appreciated that the GCS control registers 66 may also store other state information for controlling the behavior of the processing circuit when in a GCS mode in which use of the GCS data structures is enabled as indicated by the enable parameter 68.

[0056] 4 shows an example in which registers 60, 62, 64, 66 are banked to provide multiple versions of these registers corresponding to different exception states of processing circuit 4, this is not required and in other examples a single version of any of these registers may be provided and shared between exception states. Software may then switch the values ​​stored in the shared registers when switching between exception states, such that the values ​​stored in the shared registers in a given exception state may differ from the values ​​stored in the shared registers in a different exception state. It is also possible that a subset of registers 60, 62, 64, 66 are banked and another subset of registers 60, 62, 64, 66 are shared between exception states.

[0057] FIG. 5 shows an example of instructions executed at exception entry and return in a system that does not support the use of the GCS. The left side of FIG. 5 shows an exception entry sequence. In response to an exception being taken by the exception handling circuit 40, the exception handling circuit 40 triggers the handling circuit 4 to copy the current program counter value and the current processor state from the program counter register 52 and the PSTATE register 54, respectively, to the exception link register 62 and the SPSR 60 associated with the exception state ELx in which the exception is to be taken. This copying of the exception return state of the exception is hardware triggered. Thus, no specific instruction needs to be executed to cause the exception return state to be copied. The exception handling circuit 40 then controls the handling circuit to execute an exception handling routine. For example, the exception handling routine that is first executed in response to an exception entry may be a generic exception wrapper handler that performs some generic control functions before branching to a more specific handler for handling the specific cause of the exception. Thus, to ensure that the saved exception return state is preserved, even if a further exception occurs and the new exception return state is copied to registers 60, 62 before branching to the individual handler, the exception handling routine executes instruction 72 to push the register state information (including at least the exception return state information from SPSR 60 and ELR 62) into a software maintained data structure in memory, such as a stack. The particular manner in which the data structure used to save the exception return state is organized can be selected in a software specific manner, and there may be no architectural definition of how this exception return state is saved. Having saved the exception return state to memory, the exception handling software code executes a function call branch instruction 74 which branches to the individual handler code for handling the cause of the exception.

[0058] Upon returning from the exception, the exception handling software code executes an instruction 76 to read the previously saved register state from a data structure in memory (e.g., pop the register state from a stack data structure), an instruction 77 to restore the register state to the exception return registers 60, 62 (e.g., this could be a system register modification instruction permitted to write to a system control register), and an exception return instruction 78 to trigger an exception return based on the exception return state stored in the registers 60, 62. Thus, the exception return instruction 78 causes the previously saved processor state to be copied from SPSR_ELx 60 to the PSTATE register 54 and the previously saved exception return address to be copied from ELR_ELx 62 to the program counter register 52. This causes a branch to the instruction indicated by the previously saved exception return address, which is executed in the processor state indicated by the previously saved processor state value in SPSR_ELx.

[0059] An attacker may attempt to implement a return-oriented programming (ROP) attack by tampering with the exception return state information while it is held in memory between the time it is written by instruction 72 and the time it is read by instruction 76. If an attacker can successfully corrupt the exception return state, this may allow the exception return to return to a different point in the program from the point at which the exception was taken, or to return the processor state represented by PSTATE register 54 to a different state (e.g., a more privileged state) than when the exception was taken, either of which may result in undesirable behavior that could potentially pose a risk of leaking secure information or software code.

[0060] 6 illustrates a technique for protecting against such ROP attacks on the exception return state. Upon exception entry, an additional instruction is executed to push the exception return state captured for the exception in registers 60, 62 to a protected data structure called the protection control stack (GCS) data structure 80. The address to which the exception return state is pushed is determined based on the GCS stack pointer register 64 associated with the current exception state ELx. The access permissions specified by the page table (used by the MMU 28 to control address translation) define the address region used to store the GCS data structure 80 as a special "GCS" memory type that is restricted to be accessed only by a restricted subset of GCS access instructions and cannot be accessed using other types of instructions that are not in that restricted subset. Thus, an attacker who tampers with the address operand of a generic load / store instruction of a running program may not be able to cause that instruction to access the GCS data structure 80 if that instruction is not one of the special GCS access instructions. For example, the GCS memory type may be indicated within a stage 1 access permission that is specified directly or indirectly by a corresponding stage 1 translation table entry used to provide the mapping between the virtual address space and the intermediate address space (e.g., the GCS memory type permission may be indicated in the encoding of the stage 1 translation table entry itself or in a register referenced by the stage 1 translation table entry). Conversely, if a GCS access instruction attempts to access a region of memory that is not specified as a GCS memory type, a fault may be signaled to prevent an attacker from tricking the GCS access instruction into accessing a region other than GCS data structure 80.

[0061] Upon exception return, apart from any software-controlled restoration of the exception return state from a software-specific data structure in memory as described in FIG. 5 (intended to be used later by the exception return state instruction 78 to control the exception return), an additional GCS pop instruction is executed to pop the protection exception return state from a location on the GCS data structure 80 determined based on the GCS stack pointer in GCSPR_ELx64, compare the protection exception return state with the intended exception return state, and signal a fault if a mismatch is detected. This provides a means of detecting whether the intended return state has been tampered with in memory before being popped by instruction 76. If the intended exception return state matches the protection exception return state obtained from the GCS data structure 80, the exception return instruction 78 can proceed to trigger an exception return based on the intended exception return state.

[0062] Thus, as shown in Figure 7, the exception entry and return codes have been extended to include an additional GCS exception state push instruction 81 on exception entry and a GCS exception state verify (pop and compare) instruction 82 on exception return to provide additional protection against pushing the exception return state to memory by instruction 72 and reading it back by instruction 76. Although Figure 7 shows a single instruction 82 to both pop the protection exception return state from the GCS data structure 80 and verify the intended exception return state in registers 60, 62 against the protection exception return state, other examples could break this into two separate instructions, one to pop the protection exception return state from memory and one to verify whether the intended exception return state matches the popped exception return state. Also, in some examples, the GCS exception return state pop instruction 82 may simply pop the exception return state from the GCS data structure 80 without verifying against the exception return state in the exception return state registers 60, 62 (e.g., the GCS exception return state pop instruction 82 may pop the GCS protected exception return state directly into the exception return state registers 60, 62, from where it can be used by the exception return instruction 78 to directly control the exception return. In this case, there is no need for software to execute instructions 72, 76 to push / pop the exception return state to a separate software-managed stack in normal non-GCS memory).

[0063] The instructions 81, 82 provided for pushing the exception return state into the GCS structure 80 and popping the exception return state from the GCS structure are considered to be GCS access instructions that are permitted to access memory areas specified in the stage 1 access permissions as being GCS regions of memory.

[0064] It will be appreciated that the various GCS-related functions described above may be performed when the GCS enable parameter 68 is set to a valid state indicating that GCS mode is enabled. When the GCS enable parameter 68 is set to a disabled state indicating that GCS mode is disabled (which may be useful, for example, for compatibility with legacy code not designed for use in GCS mode), GCS access instructions may be treated as no-operation instructions with no architectural function or may be treated as undefined instructions (causing a fault to be signaled when the GCS access instruction is executed), and additional checks that may be performed for certain non-GCS access instructions when GCS mode is enabled may be omitted (see example flow diagrams described below).

[0065] GCS mode may be useful to support a protected area in memory that is used to maintain a copy of the valid exception return state obtained for a given exception, which may be used to directly control the exception return or may be used to verify the "intended" exception return state used to control the exception return.

[0066] However, because the GCS exception state push instruction 80 is separate from the hardware-triggered capture of the exception return state in response to the exception entry 70, there exists a window of time 90 (labeled "Window A" in FIG. 7) in which an attacker might attempt to modify the contents of the exception return state registers 60, 62, such that the exception return state pushed into the GCS data structure 80 in response to instruction 81 is not the same as the exception return state captured in response to the exception being taken. Similarly, if the exception return state information could be modified in the registers 60, 62, there exists a window of time 92 (labeled "Window B") in an exception return between execution of the GCS exception return state pop instruction 82 and execution of the exception return instruction 78, which could allow an exception return to be triggered for a program counter value and processor state that has not been obtained from the GCS 80 or that has not been verified against state obtained from the GCS 80.

[0067] To address this issue, an exception return state lock parameter (EXLOCK) 58 is provided in PSTATE register 54. EXLOCK 58 can be set to a locked state and an unlocked state. In one example, in a locked state EXLOCK=1 and in an unlocked state EXLOCK=0. In other examples, the reverse mapping can be used, or EXLOCK 58 can be a multi-bit parameter that encodes both the exception return state lock parameter and other information, in which case a first subset of the states of EXLOCK 58 can be considered locked states and a second subset of the states of EXLOCK 58 can be considered unlocked states. Thus, there are various ways in which EXLOCK 58 can be encoded to indicate locked and unlocked states.

[0068] When EXLOCK is in the unlocked state, modifications to the exception return state registers may be permitted (provided any other checks are met, such as the current exception level 56 being privileged enough to update the particular banked version of the exception return state register 60, 62 for which the modification is being attempted). When EXLOCK 58 is in the locked state, modifications to the information stored in the exception return state in the registers 60, 62 are prohibited, even if an attempt is made using an instruction that, if executed while EXLOCK 58 is in the unlocked state, would otherwise be permitted to modify the exception return state information. For at least exceptions taken at the same exception level that was current before the exception was taken, the EXLOCK parameter 58 may be set to lock the exception return state registers 60, 62 against modifications during windows A 90 and B 92 shown in FIG. 7 to prevent tampering with the exception return state information while it is retrieved and pushed into the GCS data structure 80 upon exception entry, and while it is verified against the protected exception return state restored from the GCS data structure 80 and used for the exception return 78. Exceptions taken at an exception level that is more privileged than the current exception level may be considered not to require the setting of lock parameters when the exception is taken, because more privileged code that executes after the exception is taken can be trusted to properly manage its return state.

[0069] Therefore, architectural mechanisms are provided to prevent modification of the exception return state before it is saved to the GCS data structures 80 and after it is restored from the GCS data structures 80. When an exception is taken, the state is locked and cannot be modified. PSTATE.EXLOCK 58 can lock write access to the ELR 62 and SPSR 60 (at least against writes that would attempt to change the values ​​stored in registers 60 or 62) and is set when an exception is taken. Executing a push procedure 81 to save the exception return state to the GCS buffer 80 unlocks PSTATE.EXLOCK, allowing future writes to registers 60, 62. Executing a pop procedure 82 to restore the exception return state from the GCS buffer 80 relocks PSTATE.EXLOCK, preventing future writes and ensuring that the state restored from the GCS is immutable. Once locked, any attempt to write to the state (ELR / SPSR) will signal a fault (which may cause further exceptions to be taken). Alternatively, the fault may only occur if the value being written to one or both of registers 60, 62 is different from the current value in that register. This allows for a fast code path for scenarios where the return state is not changed.

[0070] An additional check of the EXLOCK parameter 85 can be performed to trigger a fault if any of the following occur: Exception entry 70 when EXLOCK parameter 85 is currently in the locked state, · GCS exception state push procedure 81 when EXLOCK parameter 85 is currently in the unlocked state, · GCS exception state pop procedure 82 when EXLOCK parameter 85 is currently in the locked state, · Exception return 78 when EXLOCK parameter 85 is currently in an unlocked state.

[0071] Any of these events may indicate that an attacker has corrupted the control flow, causing one of the GCS protection instructions to be overlooked or causing code to execute in a different order than intended, which may suggest an ROP attack has been attempted.

[0072] The exception return state lock enable control parameter EXLOCKEN 69 can be set to a valid or invalid state (which again can be coded in a variety of ways similar to those described above for EXLOCK 58), with a valid state indicating that the exception return state lock features described above are enabled using the exception return state lock parameter 58, and a invalid state indicating that these exception return state lock features are disabled. As described below, when the GCS mode is disabled using the GCS enable parameter 68 set to a invalid state, or when EXLOCKEN 69 is set to a invalid state, various checks based on the EXLOCK parameter 58 (and the action of setting the EXLOCK parameter 58 to a locked or unlocked state) can be disabled.

[0073] FIG. 8 is a flow diagram illustrating the access permission checks performed by the MMU 28 for memory accesses issued when GCS mode is enabled by the GCS enable parameter 68 stored in the GCS control register 66 for the current exception level ELx. In step 100, a memory access request is issued specifying a target virtual address corresponding to a target memory region. In step 102, the MMU 28 initiates an address translation based on the associated stage 1 (and stage 2, if necessary) address mappings defined in the stage 1 address translation structure and the stage 2 address translation structure as shown in FIG. 3. Any known address translation technique may be used to define the address mappings for the translation. In step 104, 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. For example, the stage 1 permission information may be encoded in the target stage 1 translation table entry itself or may be stored in a register field referenced by the target stage 1 translation table entry. Another example could be to define a GCS region using stage 2 permission information specified (directly or indirectly via a reference to a register) by a stage 2 translation table entry that corresponds to an intermediate address mapped to a target VA by a target stage 1 translation table entry. It is also possible for a separate data structure (separate from the translation table structure) to define a memory region that is a GCS region.

[0074] If the target memory region is a GCS region, then in step 106, the MMU 28 determines whether the memory access request is a GCS memory access request triggered by one of a restricted subset of GCS access type instructions that are permitted to access GCS regions. Otherwise, in step 107, the MMU 28 determines whether the memory access request is a write request. If the memory access request is a write request, then in step 108, a fault is signaled to prevent other generic load / store instruction types from accessing the GCS structure 80. If the memory access request is a read request, then there is no need to signal a fault and the method proceeds to step 110 (other examples may choose to signal a fault for a non-GCS read request to a GCS memory region, but this is optional since read requests do not destroy GCS protection exception return state information).

[0075] If the memory access request is a GCS memory access request, then in step 110, MMU 28 determines whether any other access permissions have been satisfied for the memory access request. For example, this may be based on other parameters specified in the stage 1 translation table entry or stage 2 translation table entry corresponding to the target region, or may be based on other security checks, for example based on the security state, exception level, or other operating mode of processing circuit 4. If any other required access permissions are not satisfied, then a fault is again signaled in step 108. If it is determined that any other access permissions that need to be satisfied for the memory access request are satisfied, then in step 112, the memory access request may be permitted.

[0076] If in step 104 the MMU 28 determines that the target memory region was not a GCS region, then in step 114 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 as the check in step 106, but with the opposite result compared to step 106. If in step 114 the memory access request is a GCS memory access request, then a fault is signaled in step 108. This ensures that a GCS memory access request cannot be used to access a non-GCS region of memory, prevents software developers from being tempted to use GCS access type instructions for non-GCS accesses that would increase the attack surface available to an attacker, and allows detection of address operands of GCS access type instructions that have been modified by an attacker to point to a non-GCS region. By restricting GCS access type instructions to accesses to GCS regions and non-GCS access type instructions to accesses to non-GCS regions, security can be improved.

[0077] If, at step 114, it is determined that the memory access request is not a GCS memory access request, then, at step 116, MMU 28 determines whether any other access permissions are satisfied for the memory access request. For example, this may include checks based on security state, exception level, or operating mode, as described above. If all requested access conditions are satisfied, then, at step 118, the memory access request is granted. If any access permissions are violated, then a fault is signaled at step 108.

[0078] Although FIG. 8 shows a single step 108 of signaling a fault in response to several different checks failing, it will be appreciated that some implementations may signal different fault types depending on the cause of the fault.

[0079] 8 shows the checks that are performed if a memory access request is received while GCS mode is enabled by the GCS mode enable parameter 68 in the GCS control register 66 for the current exception level ELx. If GCS mode is currently disabled, steps 104, 106, 107, 114 may be omitted and the checks that are performed may be checks based on other access permissions unrelated to the use of the GCS data structure 80, as described in steps 110, 116.

[0080] As shown in Figure 8, protection of GCS data structure 80 is provided at the architectural level by MMU 28 supporting the definition of dedicated GCS memory region types (e.g., using a translation table) that indicate that addresses within the region receive special protection when required to be accessed by a limited subset of GCS access type instructions and not by other load / store instructions. GCS access type instructions may include at least a GCS exception return state push instruction 81 and a GCS exception return state pop / verify instruction 82, described above in Figure 7. Other types of GCS access type instructions may also be provided, for example, a standalone GCS exception return state pop instruction that pops the exception return state from GCS data structure 80 without verifying against the intended exception return state. Other GCS access type instructions may be provided to push and restore function return state, for example, to protect the return address used for function return.

[0081] 9 is a flow diagram showing the steps performed in response to an exception entry. In step 120, the exception handling circuit 40 detects that an exception should be taken based on the exception signal 42 and triggers the exception entry procedure. In response to the exception entry, in step 122, the program counter and the current processor state are copied from the registers 52, 54 to the versions of the exception link register 62 and the saved processor state register 60, respectively, that correspond to the exception level ELx at which the exception should be executed. In step 124, the handling circuit 4 or the exception handling circuit 40 updates the program counter register 52 to indicate the address of the first instruction to be executed from the exception entry program code and updates the PSTATE register 54 to indicate the processor state in which the exception should be taken, causing a branch to the exception entry code to be executed in the new state indicated by the PSTATE register 54. In step 126, the processing circuit 4 determines whether the GCS mode is currently enabled (based on the GCS enable parameter 68) and whether the lock of the exception return status is enabled (based on the GCS exception return state lock enable parameter EXLOCKEN 69) (the version of the parameters 68, 69 used is the version stored in one of the banked versions of the GCS control register 66 corresponding to the current exception level ELx). The processing circuit 4 also determines whether the exception should be taken at the same exception level (ELx) as the current exception level before the exception was taken. If the GCS mode is enabled, the lock of the exception return state is enabled, and the exception is taken at the same exception level as the current exception level before the exception was taken, in step 128 the processing circuit 4 sets the exception return state lock parameter EXLOCK 58 to the locked state. Otherwise, EXLOCK 58 is set to the unlocked state in step 129. Although FIG. 9 shows an example in which EXLOCK 58 is set to a locked state only for exceptions taken at the same exception level EL, other examples may set EXLOCK 58 to a locked state for exceptions taken at an exception level having a higher privilege.

[0082] Figure 10 is a flow diagram showing an exception return state push procedure for pushing the protected exception return state to the GCS data structure 80. In step 130, the instruction decoder 10 decodes a GCS exception return state push instruction while the GCS enable parameter 68 is in a valid state indicating that the GCS mode is enabled (if the GCS mode is disabled, the GCS exception return state push instruction may be interpreted as a no-operation or undefined instruction and the remaining steps of Figure 10 are not executed). In step 132, the processing circuit 4 is controlled by the instruction decoder 10 to check whether EXLOCKEN 69 indicates that the lock of the exception return state is enabled (if banked versions of the GCS control register 66 are provided for different exception levels, the version of the parameter 69 used for the check in step 132 is the version corresponding to the current exception level). If so, in step 134 the processing circuit 4 is controlled to check whether the exception return state lock parameter (EXLOCK 58) is currently in an unlocked state. If EXLOCK 58 is in an unlocked state, then a fault is signaled in step 136. This is because, as shown in Figure 7, for exception entry sequences that are valid when the exception return state lock is enabled, the exception return state lock parameter 58 should currently be locked when the exception return state is being pushed into the GCS data structure 80. (As shown in Figure 9, for exceptions taken to more privileged exception levels where EXLOCK 58 is not locked when the exception is taken, more privileged exception handlers can be trusted to manage the exception return state, and therefore the requirement for EXLOCK 58 to be locked when the GCS exception return state push instruction is executed does not pose a problem for these more privileged exception handlers, and so there is no need to execute the GCS exception return state push instruction at all.) Signaling a fault if EXLOCK 58 is currently unlocked provides a countermeasure against attacks based on tampering with the program flow to cause the GCS push procedure to be executed other than after an exception entry.Thus, the check at step 134 reduces the risk that any attacker-controlled exception return state (as opposed to the exception return state obtained in response to an exception entry) will be pushed into GCS data structure 80 .

[0083] If in step 132 the exception return state lock is found to be disabled (EXLOCKEN 69 is set to the disabled state) or if in step 134 EXLOCK 58 is in the locked state, in step 138 the processing circuit 4 obtains exception return state information from the exception return state registers 60, 62, and in step 140 the processing circuit 4 issues one or more memory access requests to push the obtained exception return state information to a location on the GCS data structure 80 determined based on the current stack pointer stored in the GCS pointer register GCSPR_ELx 64 corresponding to the current exception level ELx.

[0084] In step 140, the processing circuit 4 checks whether EXLOCKEN 69 indicates that the lock on the exception return state is enabled, and if the lock on the exception return state is enabled, proceeds to step 144 (alternatively, the same check performed in step 132 may cause step 144 to be performed conditionally depending on whether the lock on the exception return state is enabled or disabled, and thus it may not be necessary to check the EXLOCKEN parameter 69 again). If the lock on the exception return state is enabled, in step 144 the lock on the exception return state parameter 58 is set to an unlocked state (if the lock on the exception return state is disabled, this step is skipped). Regardless of whether the lock on the exception return state is enabled or disabled, in step 146 the processing circuit 4 updates the stack pointer in the GCS pointer register 64 corresponding to the current execution state (exception level) ELx to account for the push of the exception return state onto the stack (e.g., the stack pointer may be decremented or incremented by an amount corresponding to the size of the exception return state record formed based on the contents of the registers 60, 62).

[0085] Figure 11 is a flow diagram showing the steps performed to pop the exception return state from the GCS data structure 80. In step 150, the instruction decoder 10 decodes a GCS exception return state pop instruction while GCS mode is indicated as enabled by the GCS enable parameter 68. (Again, if GCS mode is disabled, the GCS exception return state pop instruction may be treated as a NOP (no operation) or undefined instruction, and the remaining steps of Figure 11 may not be performed.)

[0086] In response to the GCS exception return state pop instruction, in step 152, processing circuit 4 checks whether EXLOCKEN 69 is set to a valid state indicating that locking of the exception return state is valid (if banked versions of GCS control register 66 are provided for different exception levels, the version of parameter 69 used for the check in step 152 is the version corresponding to the current exception level). If locking of the exception return state is valid, in step 154, processing circuit 4 checks whether EXLOCK parameter 58 is set to a locked state. If EXLOCK 58 is currently in a locked state, a fault is signaled in step 156. This is because an exception return state pop instruction should not be executed when EXLOCK is locked, indicating a deviation from expected usage. This fault can signal a potential attack attempting to disrupt program flow and cause incorrect validation of the protected exception return state from GCS data structure 80.

[0087] If the lock on the exception return state is determined to be invalid in step 152 or if EXLOCK 58 is currently in an unlocked state in step 154, then in step 158 processing circuit 4 issues one or more memory access requests to pop GCS protection return state information from a location on GCS data structure 80 determined based on the stack pointer in GCS pointer register 66 that corresponds to the current exception level ELx. In step 160, the GCS stack pointer in register GCSPR_ELx 66 is updated to account for the popping of the exception return state from GCS data structure 80 (e.g., the stack pointer is incremented or decremented in the opposite direction (but by a corresponding amount) to the update made in step 146 of FIG. 10).

[0088] Steps 162, 164, and 166 are steps that may be optionally executed in response to a GCS exception return state pop instruction in implementations in which the GCS exception return state pop instruction also controls the processing circuitry 4 to verify whether the intended exception return state information currently stored in the exception return registers 60, 62 matches the GCS protection exception return state information popped from the GCS data structure 80 in step 158. In step 162, the processing circuitry 4 reads the intended exception return state information represented by the current values ​​in the exception link register 62 and SPSR 60 corresponding to the current exception level ELx. The term "intended" exception return state information is used to refer to the current values ​​of the exception return states in the registers 62, 60 at the time of execution of the GCS exception return state pop instruction (which may or may not be the same as the values ​​written to those registers when the corresponding exception entry was made). In step 164, the processing circuit 4 determines whether the intended exception return state information obtained from the registers 60, 62 matches the GCS protection exception return state information read from the GCS data structure 80 stored in the protected GCS area of ​​memory, and if there is a mismatch a fault is signaled in step 166.

[0089] If, in step 164, the intended exception return state information matches the GCS protected exception return state information, or if steps 162, 164, 166 are not performed because the GCS exception return state pop instruction does not trigger a verification (but instead, for example, pops the GCS protected return state information directly into the exception return state registers 60, 62), then in step 168 the processing circuit 4 checks whether EXLOCKEN 69 indicates that the lock on the exception return state is enabled, and if the lock on the exception return state is enabled, proceeds to step 170 (alternatively, the same check performed in step 152 may cause step 170 to be performed conditionally depending on whether the lock on the exception return state is enabled or disabled). If the lock on the exception return state is enabled, then in step 170 the lock on the exception return state parameter 58 is set to the locked state (if the lock on the exception return state is disabled, this step is skipped).

[0090] 12 is a flow diagram illustrating the steps performed in response to an exception return instruction. In step 180, the instruction decoder 10 decodes the exception return instruction and in response generates control signals for controlling the processing circuitry 4 (specifically the execution stage 16) to perform the subsequent steps. In step 182, the processing circuitry 4 determines whether the GCS enable parameter 68 indicates that the GCS mode is currently enabled, whether the EXLOCKEN parameter 69 indicates that the lock on exception return state is also enabled (again, if a banked version of the GCS control register 66 is provided for a different exception level, the version of the parameters 68, 69 used to check in step 182 is the version corresponding to the current exception level), and whether the exception return is a return to processing at the same exception level as the current exception level. If both the GCS mode and the lock on exception return state are enabled and the exception return is to return to processing executed at the current exception level, in step 184 the processing circuitry 4 checks whether the EXLOCK parameter 58 is currently in an unlocked state. If EXLOCK 58 is currently in the unlocked state, a fault is signaled in step 186 to indicate that the exception return may not have followed the preceding exception return state pop instruction 82, and therefore it may be unsafe to perform the exception return using the potentially unsafe exception return state specified in registers 60, 62.

[0091] If the GCS mode is currently disabled, or the EXLOCKEN parameter 69 is set to disable locking of the exception return state, or the exception return is for an exception level with a lower privilege than the current exception level, or the EXLOCK parameter 58 is currently in a locked state, then the exception return is allowed to proceed, and then in step 188 the exception return address is copied from ELR_ELx 62 to the program counter register 52 and the saved processor state is copied from SPSR_ELx 60 to the PSTATE register 54. Note that because the EXLOCK parameter 58 is part of the processor state that is saved at the time of the exception and restored at the time of the exception return, step 188 may change the exception return state lock parameter 58 to the same state indicated by EXLOCK 58 when the corresponding exception is taken. Thus, whether EXLOCK 58 is in a locked or unlocked state after the exception return depends on the state of EXLOCK when the corresponding exception was taken.

[0092] 13 is a flow diagram showing steps for controlling whether modification of exception return state information in the registers 60, 62 may be permitted. In step 200, the instruction decoder 10 decodes an instruction that requests modification of exception return state information (e.g., exception return address or saved processor state) in one or both of the exception link register 62 or the saved processor state register 60 associated with a target exception level (which may or may not be the current exception level 56, since instructions executed at a higher privileged exception level may modify the exception return state associated with a lower privileged exception level). In step 202, the processing circuit 4 determines whether the GCS mode, as indicated as valid by the enable parameter 68 and the EXLOCKEN parameter 69, indicates that locking of the exception return state is enabled. If the GCS mode is disabled or locking of the exception return status is disabled, in step 204, modification to the exception return state information may be permitted if any other checks (such as whether the current exception level has sufficient privileges to allow modification of the specified register) are also satisfied. If in step 202 it is determined that both the GCS mode and the exception recovery state lock are valid, then in step 206 the processing circuit 4 determines whether the exception recovery state lock parameter EXLOCK 58 is currently in a locked state. If EXLOCK 58 is in an unlocked state, then again in step 204 modification may be allowed if any other checks are satisfied. If in step 206 the EXLOCK parameter 58 is in a locked state then in step 208 a fault is signalled to prevent modification of the exception recovery state information (thus monitoring for any attempt to tamper with the exception recovery state in window A 90 or window B 92 as shown in FIG. 7).

[0093] 13, the signaling of a fault in step 208 is independent of whether the value to be written to the exception return state information in one of the registers 60, 62 is the same as or different from the previous value stored in that register. Thus, a fault is signaled even if execution of the instruction encountered in step 200 did not actually change the exception return state. This approach may be easier to implement in hardware, since it does not require circuit logic to rely on reading the registers 60, 62 and comparing with the new value to be written to signal a fault.

[0094] An alternative example is shown in Figure 14. Steps 200, 202, 204, 206 and 208 in Figure 14 are the same as the corresponding steps in Figure 13. Figure 14 includes an additional check in step 210 to check whether the new value to be written to one of the registers 60, 62 is different from the old value of the exception return state information in that register. If the new value is different from the old value, a fault is signaled in step 208. If the new value is the same as the old value, then in step 204 the attempted "fix" may be allowed since it does not change the exception return state information. This approach can speed up some code paths, e.g. fast exception paths that use very short exception handling routines (returning from the exception almost immediately after taking the exception), thus eliminating the need to save / restore the exception return state to memory, reducing the risk of tampering by an attacker. For such fast exception code paths, the GCS exception return state push / pop instructions may not be used, and therefore EXLOCK may remain set throughout the exception routine. Nevertheless, if an exception handling routine executes a system register modifying instruction that attempts to modify the exception return state in registers 60, 62 (unlikely, but possible), the corresponding fault that would be triggered while EXLOCK is locked can be avoided if the new value written by the system register modifying instruction is indeed the same as the old value, and therefore there is no risk of corrupting the exception return state. This can help improve the performance of such code paths.

[0095] Although the flow diagrams described above depict steps being performed in a particular order, it will be appreciated that the same functions may be performed in different orders, or at least partially in parallel.

[0096] FIG. 15 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 techniques, 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 computer programs are often referred to as simulators insofar as they provide 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 330, which optionally runs a host operating system 320 and supports a simulator program 310. 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.

[0097] 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 in host hardware (e.g., host processor 330), some simulated embodiments may use the host hardware where suitable.

[0098] The simulator program 310 may be stored in a computer-readable storage medium (which may be a non-transitory medium) and provides a program interface (an instruction execution environment) to the target code 300 (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 310. Thus, program instructions of the target code 300, including the GCS access instructions described above, may be executed from within an instruction execution environment using the simulator program 310, thereby allowing a host computer 330 that does not actually have the hardware capabilities of the device 2 described above to emulate these capabilities. Similarly, checks based on the EXLOCK parameter 58 may be emulated using the simulator program 310 (e.g., using a portion of the processing program logic 312 or the instruction decode program logic 314).

[0099] Thus, the simulator program 310 may have a processing program logic 312 that simulates the states of the processing circuit 4 described above. For example, the processing program logic 312 may control transitions of the execution states EL0-EL3 in response to events occurring during the simulated execution of the target code 300. The instruction decode program logic 314 decodes instructions of the target code 300 and maps them to corresponding instruction sets in the native instruction set of the host device 330. The register emulate program logic 316 maps register accesses requested by the target code to accesses to corresponding data structures maintained on the host hardware of the host device 330, such as by accessing data in registers or memory 332 of the host device 330. The memory management program logic 318 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 obtained by stage 2 mapping in the address translation based on the page table defined for the target code 300 to host virtual addresses used to access the host memory 332. These host virtual addresses may themselves be translated to 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 control by simulator program 310). Exception handling program logic 320 controls the handling of simulated exceptions that occur during execution of target code 300 (such as faults triggered by the EXLOCK-based checks described above).

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

[0101] 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, An exception recovery state register memory device for storing exception recovery state information, It comprises a processing circuit for executing processing operations in response to commands, The processing circuit is configured to receive a protection control stack (GCS) exception return state push instruction, retrieve the exception return state information from the exception return state register storage device, and push the exception return state information to the GCS data structure. The processing circuit is configured to acquire GCS protection exception return state information from the GCS data structure in response to a GCS exception return state pop command. The device includes a memory management circuit for rejecting a write request specifying a target address in response to determining that the memory area corresponding to the target address is designated as a GCS area for storing the GCS data structure, and that the write request is a restricted subset of GCS access type instructions, and that the restricted subset of GCS access type instructions is a request other than a GCS memory access request triggered by one of the restricted subset of GCS access type instructions, which includes at least the GCS exception return state push instruction. The processing circuit is configured to, in at least one operating state of the processing circuit, in response to an attempt to modify the exception return state information stored in the exception return state register storage device, detect whether the exception return state lock parameter is in a locked state or an unlocked state, and if it is detected that the exception return state lock parameter is in the locked state, signal a fault.

2. The processing circuit is configured to perform the processing operation in one of a plurality of exception levels associated with different privilege levels. The apparatus according to claim 1, wherein the processing circuit is configured to set the exception return state lock parameter to the locked state in response to the taking of an exception at the same exception level as the current exception level before the exception was taken, in at least one operating state of the processing circuit.

3. The apparatus according to any one of claims 1 to 2, wherein the processing circuit is configured to set the exception return state lock parameter to the unlocked state in response to the GCS exception return state push command in at least one operating state of the processing circuit.

4. The apparatus according to any one of claims 1 to 2, wherein the processing circuit is configured to set the exception return state lock parameter to the locked state in response to the GCS exception return state pop command in at least one operating state of the processing circuit.

5. The apparatus according to any one of claims 1 to 2, wherein the processing circuit is configured to, in at least one operating state of the processing circuit, check whether the exception return state lock parameter is set to the locked state in response to an exception return command for triggering an exception return in which the exception return is a return to processing at the same exception level as the current exception level before the exception return, based on the exception return state information stored in the exception return state register storage device, and to signal a fault in response to detecting that the exception return state lock parameter is set to the unlocked state.

6. The apparatus according to any one of claims 1 to 2, wherein the processing circuit is configured to signal a fault in response to an attempt to execute an instruction requesting modification to information in the exception return state register storage device, when the exception return state lock parameter is set to the locked state in at least one operating state of the processing circuit, regardless of whether the new value to be written to the exception return state register storage device is the same as or different from an old value previously stored in the exception return state register storage device.

7. The apparatus according to any one of claims 1 to 2, wherein the processing circuit is configured to, in at least one operating state of the processing circuit, when the exception return state lock parameter is set to the locked state, in response to an attempt to execute an instruction requesting modification of information in the exception return state register storage device, check whether a new value to be written to the exception return state register storage device is the same as or different from an old value previously stored in the exception return state register storage device, and if it is determined that the new value is different from the old value, signal the fault.

8. The apparatus according to any one of claims 1 to 2, wherein the processing circuit is configured to signal a fault when, in response to the GCS exception return state pop instruction, a mismatch is detected between the intended exception return state information obtained from the exception return state register storage device and the GCS protection exception return state information obtained from the GCS data structure.

9. The apparatus according to any one of claims 1 to 2, wherein the exception return state register storage device includes an exception return address register for storing the exception return address of an instruction to be executed after returning from an exception.

10. The apparatus according to any one of claims 1 to 2, wherein the exception recovery state register storage device includes a saved processor state register for storing the processor state to be restored after recovery from an exception.

11. The processing circuit is configured to copy the processor state from the processor state register to the stored processor state register in response to an exception being taken. The apparatus according to claim 10, wherein the exception recovery state lock parameter is a parameter specified in the processor state register.

12. The apparatus according to claim 11, wherein the processing circuit is configured to, in response to an exception return instruction, copy a saved processor state including a saved exception return state lock parameter from the saved processor state register to the processor state register, and restore the exception return state lock parameter to the value indicated by the saved exception return state lock parameter.

13. The apparatus according to any one of claims 1 to 2, wherein the at least one operating state of the processing circuit includes an operating state in which the exception return state lock activation control parameter is set to an enabled state indicating that the lock of exception return state information is enabled using the exception return state lock parameter.

14. The at least one operating state of the processing circuit is, The exception return state lock enable control parameter is set to an enabled state, indicating that the lock on the exception return state information is enabled using the exception return state lock parameter, and The apparatus according to any one of claims 1 to 2, wherein the GCS activation parameter is set to an enabled state indicating that a GCS mode for supporting the use of the GCS data structure is enabled.

15. The apparatus according to any one of claims 1 to 2, wherein the memory management circuit is configured to reject a GCS memory access request specifying a given target address in response to determining that the memory area corresponding to the given target address is not designated as the GCS area.

16. It is a method, The exception recovery status information is stored in the exception recovery status register memory, Using a processing circuit to execute processing operations in response to instructions, In response to a protection control stack (GCS) exception return state push instruction, the exception return state information is retrieved from the exception return state register storage device and the exception return state information is pushed to the GCS data structure. In response to the GCS exception return status pop command, the GCS protection exception return status information is obtained from the GCS data structure, A write request specifying a target address is rejected in response to the determination that the memory area corresponding to the target address is designated as a GCS area for storing the GCS data structure, and that the write request is a restricted subset of GCS access type instructions, and that the restricted subset of GCS access type instructions is a request other than a GCS memory access request triggered by one of the restricted subset of GCS access type instructions, which includes at least the GCS exception return state push instruction. A method comprising: detecting whether an exception return state lock parameter is locked or unlocked in response to an attempt to modify the exception return state information stored in the exception return state register storage device in at least one operating state of the processing circuit; and signaling a fault if it is detected that the exception return state lock parameter is locked.

17. A computer program, which, when executed by a host data processing device, includes instructions for controlling the host data processing device and providing an instruction execution environment for executing target code, wherein the computer program is A register emulation program logic that controls the host data processing device and simulates an exception return state register storage device for storing exception return state information, The system includes a processing program logic that controls the host data processing device to simulate the execution of instructions in the target code, The processing program logic is configured to control the host data processing device in response to a protection control stack (GCS) exception return state push instruction of the target code, to obtain the exception return state information from the simulated exception return state register storage device, and to push the exception return state information to the GCS data structure. The processing program logic is configured to obtain GCS protection exception return state information obtained from the GCS data structure in response to the GCS exception return state pop instruction of the target code. The computer program includes memory management program logic for rejecting a write request specifying a target address in response to determining that the memory area corresponding to the target address is a GCS area for storing the GCS data structure, and that the write request is a restricted subset of GCS access type instructions, and that the restricted subset of GCS access type instructions is a request other than a GCS memory access request triggered by one of the GCS access type instructions, which includes at least the GCS exception return state push instruction. A computer program wherein the processing program logic is configured to, in at least one simulated operating state of the processing program logic, control the host data processing device to detect whether an exception return state lock parameter is locked or unlocked in response to an attempt to modify the exception return state information stored in the simulated exception return state register storage device, and, if it detects that the exception return state lock parameter is locked, signal a fault.

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

Images