WO2024175871A1

WO2024175871A1 - Address-dependent check

Info

Publication number: WO2024175871A1
Application number: PCT/GB2024/050061
Authority: WO
Inventors: Madhusudana Reddy Vangireddy; John Michael Horley; Michael John Williams
Original assignee: ARM Ltd; Advanced Risc Machines Ltd
Current assignee: ARM Ltd
Priority date: 2023-02-24
Filing date: 2024-01-11
Publication date: 2024-08-29
Anticipated expiration: 2025-08-24
Also published as: IL322453A; GB202306066D0; TW202435061A; KR20250153235A; CN120752614A; GB2627542B; GB2627542A

Abstract

A data processing apparatus comprises processing circuitry configured to perform data processing operations in response to instructions stored in a memory system. In response to determining that an execute-instruction-from-register condition is satisfied at a point in program flow corresponding to a program counter address, the processing circuitry determines, based on instruction-defining information associated with an instruction-storing register, an alternate operation to be performed in place of an original operation represented by an instruction stored in a location in the memory system corresponding to the program counter address. The apparatus also comprises checking circuitry configured to perform an address-dependent check based on the program counter address to determine whether the processing circuitry is permitted to perform the alternate operation in place of the original operation.

Description

ADDRESS-DEPENDENT CHECK

The present technique relates to the field of data processing.

Data processing devices typically perform data processing operations based on instructions stored in a memory system. Executing instructions from memory may involve certain restrictions. For example, restrictions may limit the areas of memory from which instructions can be executed. Imposing restrictions when executing instructions from memory can improve security and reduce the likelihood of malicious code being executed.

Viewed from one aspect, the present technique provides a data processing apparatus, comprising: processing circuitry configured to perform data processing operations in response to instructions stored in a memory system, wherein in response to determining that an execute- instruction-from-register condition is satisfied at a point in program flow corresponding to a program counter address, the processing circuitry is configured to determine, based on instruction-defining information associated with an instruction-storing register, an alternate operation to be performed in place of an original operation represented by an instruction stored in a location in the memory system corresponding to the program counter address; and checking circuitry configured to perform an address-dependent check based on the program counter address to determine whether the processing circuitry is permitted to perform the alternate operation in place of the original operation

Viewed from a further aspect, the present technique provides a data processing method, comprising: performing data processing operations in response to instructions stored in a memory system; in response to determining that an execute-instruction-from-register condition is satisfied at a point in program flow corresponding to a program counter address, determining, based on instruction-defining information associated with an instruction-storing register, an alternate operation to be performed in place of an original operation represented by an instruction stored in a location in the memory system corresponding to the program counter address; and performing an address-dependent check based on the program counter address to determine whether performing the alternate operation in place of the original operation is permitted.

Viewed from a further aspect, the present technique provides a computer program for controlling a host data processing apparatus to provide an instruction execution environment for execution of target program code, the computer program comprising: processing program logic to perform data processing operations in response to instructions of the target program code identified by addresses in a simulated address space, wherein in response to determining that an execute-instruction-from-register condition is satisfied at a point in program flow corresponding to a program counter address in the simulated address space, the processing program logic is configured to determine, based on instruction-defining information associated with an instruction-storing simulated register, an alternate operation to be performed in place of an original operation represented by an instruction corresponding to the program counter address; and checking program logic to perform an address-dependent check based on the program counter address to determine whether the processing program logic is permitted to perform the alternate operation in place of the original operation.

The computer program may be stored on a computer-readable storage medium. The storage medium may be non-transitory.

Further aspects, features and advantages of the present technique will be apparent from the following description of examples, which is to be read in conjunction with the accompanying drawings, in which:

Figure 1 schematically illustrates an example of a data processing apparatus.

Figure 2 schematically illustrates the use of a translation table entry to indirectly specify permissions information.

Figure 3 schematically illustrates an example of processes which can be executed by the data processing apparatus.

Figure 4 schematically illustrates registers may be provided with the data processing apparatus.

Figure 5 illustrates a procedure for executing an instruction from an instruction-storing register in place of an instruction stored in memory.

Figure 6 illustrates conditions for determining whether the execute-instruction-from- register condition is satisfied.

Figure 7 illustrates conditions for determining whether an attempted access to an instruction-storing register should cause an exception.

Figures 8-12 provide examples of an address-dependent check.

Figure 13 illustrates a simulator implementation that may be used.

A data processing apparatus comprises processing circuitry configured to perform data processing operations in response to instructions stored in a memory system. Program flow may be controlled based on a program counter, which indicates a current point in execution of code. The program counter may be stored in a register, for example, and provides information identifying a program counter address which identifies a next instruction to be fetched from the memory system, the fetched instruction identifying an operation to be performed by the processing circuitry. The program counter may be provided in different ways, for example the program counter may directly indicate the program counter address or may identify an offset which is combined with a base address to provide the program counter address. The program counter may be updated in response to instruction fetches from memory or in response to branch operations, to indicate the next instruction in the program. The memory system from which an instruction can be fetched may not be limited to main memory, and may include one or more levels of caches storing data corresponding to addresses in the main memory.

Whilst a program may be conventionally performed by executing instructions from memory, there may be certain cases where it would instead be preferable to perform an alternate operation other than an operation associated with an instruction indicated by the program counter. For example, as will be discussed in further detail below, after reaching a software breakpoint in a program it may be desired to perform an alternate operation instead of performing an operation based on the instruction associated with the program counter address (for example, the instruction at the program counter address may be a breakpoint instruction and the alternate operation may be based on a replaced instruction that was replaced with the breakpoint instruction). The alternate operation may be determined based on instruction-defining information stored in an instruction-storing register rather than an instruction stored in the memory system at the program counter address. Hence, the performing the alternate operation may comprise executing an instruction from the instructionstoring register rather than executing an instruction from memory. The instruction-defining information could include, for example, an opcode identifying the alternate operation and information specifying operands for the alternate operation.

To determine when to perform the alternate operation based on the instruction-storing register in place of an operation based on an instruction in memory, the processing circuitry may check whether an execute-instruction-from-register condition is satisfied. The processing circuitry may then execute the instruction stored in the instruction-storing register rather than the instruction stored at the program counter address when the execute-instruction-from- register condition is satisfied. Performing alternate operations based on an instruction stored in a register in place of operations based on instructions stored in the memory system can provide a flexible technique for modifying a program (e.g. for debugging purposes) without requiring new instructions to be written to the memory system. This can avoid overhead, such as enforcing a coherency protocol, which may be associated with writing a new instruction to memory when it is desired to modify code. In addition, modification of the program by executing a particular instruction from a register instead of memory can be specific to a particular thread in a particular processing unit, with other processing units having access to the memory seeing the original code and not the modified code. However, the inventors have realised that performing the alternate operation based on an instruction stored in a register may mean that certain restrictions that would be enforced when executing an instruction from memory are bypassed. When executing the instruction from the instruction-storing register, the instruction is not fetched from memory and therefore the restrictions that may normally be performed when fetching an instruction may not take place. The restrictions imposed when executing an instruction from memory may reduce the likelihood of malicious code being executed or a processor being tricked into performing operations that should not be allowed. Therefore, bypassing the restrictions whilst performing the alternate operation in place of an original operation may present a mechanism by which incorrect instructions may be executed.

The inventors have realised that it may only be valid to perform the alternate operation in place of the original operation at certain points in a program where this behaviour is expected and/or where the risk of this behaviour being used to attack the processor is reduced. The inventors have therefore realised that the potential risk associated with performing an alternate operation in place of an original operation can be reduced by performing a check based on the point in program flow where it is attempted to perform the alternate operation. Therefore, the data processing apparatus also comprises checking circuitry configured to perform an address-dependent check based on the program counter address to determine whether the processing circuitry is permitted to perform the alternate operation in place of the original operation. Performing an address-dependent check dependent on the address of the instruction for which operation is replaced with the alternate operation means that the alternate operation is only allowed at certain points in a program. The address-dependent check is not particularly limited, with several examples of address-dependent checks discussed below. In addition, the address-dependent check may include one or more separate checks depending on the program counter address, where in some examples the address-dependent check fails unless each separate check is passed. The address-dependent check for determining whether an alternate operation should be allowed in place of an original operation may appear to be unusual because it is a check based on an address in memory associated with the operation that is being replaced, and not a check based on the actual alternate operation that is to be performed. However, the inventors have determined that this check can protect against certain abuses of the mechanism for executing an instruction from the instruction-storing register.

To perform the address-dependent check, the checking circuitry may check the state of permissions information associated with the program counter address. Permissions information may indicate whether a particular access to memory, such as a read or write, should be allowed. Permissions information may include permissions flags, for example, where each flag has a state which indicates that a certain permission is provided and a state indicating that the certain permission is not provided. Permissions information may be also provided in alternative ways. For example, the combination of a number of permissions bits may indicate that certain permissions are provided whilst others are not provided, without a particular permission being associated with a particular bit. The permissions information may be associated with regions of memory, so that certain permissions can be provided for certain regions of memory. The permissions may include an execute permission and a write permission which may be used to check whether a given address is within an executable or writeable region of memory, for example, although further permissions such as a read permission may also be provided. Checking the state of permissions information associated with the program counter address provides a simple technique for performing the addressdependent check. Permissions information may be quick to access and the checks may be determined by checking the state of the permissions information without requiring further calculations or comparisons to be made to determine if the check is satisfied.

In one example, the address-dependent check may involve determining whether the processing circuitry would be permitted to execute the instruction associated with the program counter address. If the instruction identified by the program counter address is not in an executable region of memory from which the processing circuitry is permitted to execute instructions, then this may indicate that something unexpected has occurred in processing. For example, a branch could have been performed to update the program counter address to an address in a memory region containing data rather than instructions. Since instructions would not be allowed to execute from memory with the program counter address outside of an executable region, one method of preventing abuse of the mechanism for performing the alternate operation in place of an original operation may be to prevent instructions being executed from the instruction-storing register whilst the program counter address is outside of an executable region. Therefore, in an example the address-dependent check comprises checking whether the program counter address is within an executable memory region from which the processing circuitry is permitted to execute instructions. This can provide a simple determination that an alternate operation should not be allowed to proceed based on the program counter address.

In addition to or instead of the above, the address-dependent check may comprise checking whether the program counter address is within a writeable memory region to which the processing circuitry is permitted to write data. If the instruction at the program counter address is within a region of memory that may be written to, then it may be possible for the processing circuitry to write data to that address and cause the instruction at the program counter address to be modified. Debugging code is an example of a particular technique where it may be expected to replace instructions in memory (for example, with breakpoint instructions), and therefore a write permission may be expected to be set during debugging for regions of memory storing instructions. Debugging code may also be a particular scenario where performing the alternate operation based on the instruction-storing register is expected to occur (as will be discussed below in greater detail). Therefore, checking for the write permission may help to distinguish debugging scenarios where execution from the instructionstoring register may be expected and permitted, from regular code execution where it may be desired to prevent execution from the instruction-storing register. If the processing circuitry is prevented from modifying the instruction at the program counter address, then the processing circuitry may also be prevented from performing an alternate operation based on the instruction-defining information in the instruction-storing register.

The permissions information may be specified in a number of ways. For example, a memory protection unit (MPU) could be provided in association with the processing circuitry. The MPU may store entries each identifying a range of memory addresses and permissions associated with the identified range of memory addresses. Alternatively, permissions information may be specified using a page table structure. Page tables contain page table entries corresponding to a particular range of addresses, providing a translation between virtual addresses as used by a processor and physical addresses in the memory system. Specifying the permissions information using the page table entry may be particularly efficient, since page table entries are typically associated with a region of memory and instructions are often provided together in memory. The instructions corresponding to preceding values taken by the program counter address in previous cycles may therefore correspond to the same page table entry as the program counter address, and the page table entry may have therefore already been cached in a translation lookaside buffer (TLB) due to accesses to the earlier instructions. Therefore, the permissions values may already be cached in the processing circuitry and be quick to access for the address-dependent check. If the page table entry has not already been cached, then the processing circuitry may provide existing page table walk mechanisms for accessing the permissions.

The permissions information for the memory region containing the program counter address may be specified directly in a page table entry corresponding to that address. However, the number of available bits in a format for a page table entry may be limited, and therefore if there are several different permissions which may each be provided or not provided, there may not be sufficient bits in the permissions field of the page table entry to directly represent all of the permissions. Therefore, in some examples at least a portion of the permissions information may be specified indirectly by a page table entry. In this case, permissions information may be provided in a permissions register, and a page table entry could specify a field identifier identifying which field of the permissions register specifies at least a portion of the permissions for that entry, with the referenced field of the permissions register encoded to indicate the permission type. In addition to allowing more permissions to be specified than can be encoded directly in a page table entry, this may allow processing circuitry to quickly update permissions for many page table entries that all reference the same permissions field by performing a single update to the permissions field rather than needing to update each page table entry separately. Furthermore, if different processing environments have access to different permissions registers but share page tables, then this may allow the same page table entries to be used across the different processing environments whilst providing different permissions for different processing environments since different processing environments may have different instances of the permissions register referenced by a page table entry, with the different instances of the permissions register being able to be set to different permission encodings for the different processing environments.

A more flexible address-dependent check may be provided if the check takes into account a current exception level of the processing circuitry when the check is performed. This might be useful since less privileged software associated with a less privileged exception level might not be trusted to perform the alternate operation in place of the original operation, but more privileged software which may have a greater level of trust may be trusted to perform the alternate operation at the same program counter address. Rather than prohibiting or permitting the alternate operation for all exception levels, the address-dependent check may depend on a current exception level of the processing circuitry. To provide the additional flexibility when the address-dependent check comprises checking permissions information, the checking circuitry could be configured to select which permissions information is used to perform the address-dependent check based on a current exception level of the processing circuitry. For example, there may be an item of permissions information for exception levels less privileged than a threshold level and a separate item of permissions information for exception levels at or more privileged than the threshold level.

The use of an executable and a write permission have been discussed above as options for implementing the address-dependent check. However, the executable and write permissions may be associated with other aspects of controlling access to memory, and therefore there may be reduced freedom to modify the executable and write privileges for certain regions of memory. For example, a region could be incidentally specified as executable and/or writeable even when software may not wish to allow execution from a register for that region. Therefore in addition to, or instead of, performing checks based on the executable and write permissions, the address-dependent check may comprise checking whether the permissions information indicates that an execute-instruction-from-register permission is provided for the program counter address. The checking circuitry may be configured to determine that the processing circuitry is not permitted to perform the alternate operation in place of the original operation, in response to determining that the permissions information indicates that the execute-instruction-from-register permission is not provided for the program counter address, even if the permissions information indicates that an execute permission or a write permission is provided for the program counter address. Hence, a permission could be checked that is independent from the execute and write permissions and indicates whether an instruction in that region can have its operation replaced with an alternate operation. In some examples, the permission may be a new permission not used for any other permissions checks.

In some examples, an address may only be associated with a single execute- instruction-from-register permission. However, as discussed above, it can be useful to provide different permissions for different exception levels. In one particular example, code executing at the least privileged exception level may include applications, which are not necessarily trusted, whereas higher exception levels may be used for trusted code such as operating systems, hypervisors and so on. It may therefore be appropriate to enforce different permissions for the least privileged exception level and other exception levels. Therefore in some examples, the permissions information may indicate whether a first execute-instruction- from-register permission is provided and whether a second execute-instruction-from-register permission is provided. In response to determining that the processing circuitry is currently executing at a least privileged exception level, the checking circuitry is configured to perform the address-dependent check depending on whether the first execute-instruction-from-register permission is provided, and in response to determining that the processing circuitry is currently executing at an exception level other than the least privileged exception level, the checking circuitry is configured to perform the address-dependent check depending on whether the second execute-instruction-from-register permission is provided. Hence, the addressdependent check may be more flexible as it can take into account the current exception level of the processing circuitry, as well as being independent from restrictions imposed on permissions other than execute-instruction-from-register permissions.

The address-dependent check is not required to include checking the permissions associated with the program counter address. Alternatively, or additionally, the addressdependent check may include checking what is stored at the program counter address. For example, if there is no valid instruction stored at the program counter address then the address-dependent check may fail. This may be because the usual behaviour using the instruction-storing register is to perform an alternate operation based on the instruction-storing register in place of an original operation based on an instruction at the program counter address. However, if there is no valid instruction at the program counter address then incorrect use of the mechanism may be identified. For example, if the value stored at the program counter address corresponds to an undefined instruction encoding then the addressdependent check may fail.

In addition, the address-dependent check may comprise checking whether the instruction stored in the location in the memory system corresponding to the program counter address is an expected type of instruction. Use of the instruction-storing register for executing instructions may be restricted to certain points in a program. Whilst these points may be identified based on the permissions associated with the program counter address, they can also or alternatively be identified by checking the type of instruction at the program counter address. If the instruction at the program counter address is not an expected type of instruction, the address-dependent check may fail. An expected type of instruction may include broad categories of instructions (e.g., an instruction could be an expected type of instruction if it does not write to memory), or may include specific instructions such as individual opcodes. Whilst the expected type of instruction may be dynamically adjustable, for example based on some information stored in a register, in some examples there are a limited number of expected types of instruction predefined in the hardware of the processing apparatus such that use of the instruction-storing register for executing instructions is restricted to only replacing the operation of certain limited instructions. The process of checking whether an instruction at the program counter address is an expected type of instruction may include loading the instruction from memory (optionally performing additional permissions checks during the memory access) and comparing the retrieved instruction to an expected type of instruction.

The types of instruction which may be considered to be an expected type of instruction are not particularly limited and may vary for different implementations. However, a particular example where execution from a register is useful is during software breakpointing. In software breakpointing, certain instructions in code may be replaced in memory by breakpoint instructions. A breakpoint instruction causes an exception to be raised so that a debugger may analyse the processing circuitry for diagnostic purposes, such as for debugging the code. In some examples, it may be considered unlikely that the execution from the instruction-storing register would be used in scenarios where a breakpoint has not been established, and so the instruction at the program counter address being an instruction other than a breakpoint instruction may be a sign that the mechanism for execution from the instruction-storing register is being used improperly. Hence, in some examples the expected type of instruction includes at least a breakpoint instruction. If the execute-instruction-from-register condition is satisfied whilst the instruction at the program counter address is not a breakpoint instruction, then this may indicate that the mechanism is being used improperly, and the address-dependent check may fail.

The alternate operation is selectively performed by the processing circuitry, depending on the outcome of the address-dependent check, when the execute-instruction-from-register condition is satisfied. The decision to perform an alternate operation based on the instructionstoring register may be made by software at certain points in a program, which may need to instruct the hardware of the processing circuitry to perform the alternate operation. Therefore in some examples the processing circuitry may be configured to determine whether the execute-instruction-from-register condition is satisfied based on at least one enable value stored in at least one control register. As software may be permitted to write to the control register, this provides a simple mechanism by which the software can instruct hardware to perform the alternate operation which may add little overhead to the processing circuitry. Since there may be established controls over whether software having a certain level of privilege is permitted to update control registers, this may also be an efficient method for imposing controls over whether particular parts of software should be permitted to cause the execute- instruction-from-register condition to be satisfied. Whilst one aspect of the execute-instruction- from-register condition may involve checking the at least one enable value, it will be appreciated that the execute-instruction-from-register condition may also include further conditions and therefore setting the enable value may not necessarily cause the execute- instruction-from-register condition to be satisfied. For example, the execute-instruction-from- register condition may also comprise checking that the processing circuitry is executing in a particular mode of operation.

It has been discussed above how security may be improved by performing an addressdependent check when the execute-instruction-from-register condition is satisfied, which may prevent malicious code from being executed from the instruction-storing register. Security may be further improved by controlling when the execute-instruction-from-register condition is allowed to be satisfied. In particular, when the execute-instruction-from-register condition is indicated by an enable value in a control register, setting of the enable value may be prohibited in certain cases to prevent tricked or malicious software from incorrectly setting the execute- instruction-from-register condition. A particularly effective technique for controlling setting of the enable value may be based on execution environments of software. For example, software may be processed by the processing circuitry in one of a plurality of exception levels. Less privileged exception levels may have reduced register access rights compared to more privileged exception levels. The mechanisms for switching between exception levels may include signalling an exception to the processing circuitry and performing an exception return. Less trusted software may be executed at a lower exception level, whereas more trusted software such as an operating system or a hypervisor may be executed at higher exception levels. To prevent less trusted software from incorrectly setting the execute-instruction-from- register condition (and thereby potentially causing an alternate operation to be performed based on a register in place of an original operation) the processing circuitry may be configured to prohibit writes to the at least one control register containing the enable value when executing at an exception level less privileged than a threshold exception level. Hence, less privileged software may be unable to set the execute-instruction-from-register condition. Mechanisms for preventing certain exception levels from accessing certain registers may already be provided in some hardware implementations, and therefore there may be low additional overhead associated with imposing the further requirement that writes to the enable value control register are prevented for certain exception levels. Hence, this provides an effective and efficient technique for reducing the ability of less trusted software to abuse use of the instruction-storing register.

In some examples a single enable value may be provided which is allowed to be set by software executing at or above a threshold privilege level. However, in some architectures, there may be two or more privilege levels at or above the threshold privilege level. In these examples, there may be disagreement among pieces of software which are both permitted to set the enable value about whether the execute-instruction-from-register condition is allowed to be satisfied. For example, there may still be a possibility that the less privileged software may be tricked into setting the execute-instruction-from-register condition or may be malicious, or the more privileged software may wish to disable execution from the instruction-storing register for other reasons, and therefore the more privileged software may wish to prevent the less privileged software from setting the execute-instruction-from-register condition. In order to enable higher privilege levels to enforce controls over lower levels when both are at or above the threshold privilege level, a further value may be provided in a further control register. The processing circuitry may determine whether the execute-instruction-from-register condition is satisfied based on both the enable value and the further value. Processing circuitry executing at (or in a less privileged exception level than) the threshold exception level may not be permitted to write to the further control register. Hence, software at the threshold privilege level is permitted to write to the control register storing the enable value, but not to the further control register storing the further value. Therefore, software executing at a more privileged level than the threshold privilege level may override software at the threshold privilege level and prevent the execute-instruction-from-register condition from being satisfied. Providing the further control register can increase the granularity of control that different privilege levels may have over whether the execute-instruction-from-register condition is set.

Whilst security may be provided by performing the address-dependent check and optionally restricting when the execute-instruction-from-register condition may be set, both of these restrictions may still allow free access to the instruction-storing register. Whilst this may not be a problem in some implementations, for example because instructions are only executed from the instruction-storing register at certain points in code, such as after a certain setting has been defined for the enable value used to decide whether the execute-instruction- from-register condition is satisfied and for the permissions information used to define whether the address-dependent check is satisfied, in other examples allowing free access to the instruction-storing register may be undesirable. For example, if malicious software has been able to cause a malicious instruction to be written to the instruction-storing register before the alternate operation is performed, then this may allow malicious instructions to be executed. In addition, it may be desirable to prevent less privileged software from being able to read the instruction in the instruction-storing register, as this may be private to the more privileged software. Therefore, further security may be provided by providing a trap condition in which access checking circuitry is configured to cause the processing circuitry to trap to a more privileged exception level in response to detecting an attempt by the processing circuitry executing at a given exception level to read from or write to the instruction-storing register. Software executing at the more privileged exception level may then be able to handle the attempted read or write as appropriate. Whether or not the trap condition is satisfied may depend on trap configuration information, such that in implementations supporting trapping it is not essential to always trap (it could depend on control state information). Providing the trap condition further increases the security associated with providing the instruction-storing register and reduces the potential for abuse of performing an alternate operation in place of an original operation.

As discussed above, the checking circuitry is configured to perform an addressdependent check based on the program counter address to determine whether the processing circuitry is permitted to perform the alternate operation in place of the original operation. When the check is failed, it is determined that the processing circuitry is not permitted to perform the alternate operation. In some examples, the processing circuitry may perform the alternate operation anyway butthen be later prevented from progressing further with processing. Values generated as a result of the alternate operation or later operations may not be committed, as if they were not generated in the first place. However, in some examples, the processing circuitry may be prevented from performing the alternate operation when the addressdependent check is failed. This may reduce the chance of side channel attacks associated with performing an alternate operation that should not be performed.

In some examples, the checking circuitry may be configured to raise an exception in response to determining failure of the address-dependent check. This may trigger a transfer to a more privileged exception level which can handle the exception. This may enable attempted attacks and/or errors leading to the address-dependent check failing to be identified and addressed.

In some cases, when the execute-instruction-from-register condition is satisfied, an exception may be raised during an attempt to perform the alternate operation. One reason for this is that the address-dependent check may have failed. Another reason is that the addressdependent check may have passed, but execution of the instruction stored in the instructionstoring register may have caused a different fault, such as a memory access fault or the instruction may have been an undefined instruction. It can be advantageous to provide some information identifying why the exception was raised so that an exception handler may identify and address the problem. Hence, in some examples the processing circuitry is configured to maintain exception-identifying information in an exception-identifying register. In response to failure of the address-dependent check, the processing circuitry is configured to set the exception-identifying information to indicate a first exception cause. In response to detecting that the execute-instruction-from-register condition is satisfied and the address-dependent check is successful, but a fault arises due to an attempt to perform the alternate operation, the processing circuitry is configured to set the exception-identifying information to indicate a second exception cause.

Particular examples will now be described with reference to the Figures.

Figure 1 schematically illustrates an example of a data processing apparatus 2. The data processing apparatus has a processing pipeline 4 (an example of processing circuitry, which could for example form part of a CPU (Central Processing Unit)). The processing circuitry 4 is for executing instructions defined in an instruction set architecture (ISA) to carry out data processing operations represented by the instructions. The processing pipeline 4 includes a number of 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) to be processed by remaining stages of the pipeline; an issue stage 12 for checking whether operands required for the micro-operations are available in a register file 14 and issuing microoperations for execution once the required operands for a given micro-operation are available; an execute stage 16 for executing data processing operations corresponding to the microoperations, by processing operands read from the register file 14 to generate result values; and a writeback stage 18 for writing the results of the processing back to the register file 14. It will be appreciated that this is merely one example of possible pipeline architecture, and other systems may have additional stages or a different configuration of stages. For example in an out-of-order processor a register renaming stage could be included for mapping architectural registers specified by program instructions or micro-operations to physical register specifiers identifying physical registers in the register file 14. In some examples, there may be a one-to-one relationship between program instructions defined in the ISA that are decoded by the decode stage 10 and the corresponding micro-operations processed by the execute stage. It is also possible for there to be a one-to-many or many-to-one relationship between program instructions and micro-operations, so that, for example, a single program instruction may be split into two or more micro-operations, or two or more program instructions may be fused to be processed as a single micro-operation.

The execute stage 16 includes a number of processing units, for executing different classes of processing operation. 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 outcome of branch operations and adjusting the program counter which represents the current point of execution accordingly; and a load/store unit 26 for performing load/store operations to access data in a memory system 8, 30, 32, 34.

A memory management unit (MMU) 28 is provided for controlling memory access permission checks and performing address translations between virtual addresses specified by the load/store unit 26 based on operands of data access instructions and physical addresses identifying storage locations of data in the memory system. The MMU has at least one translation lookaside buffer (TLB) 29 for caching address translation data from page tables stored in the memory system, where the page table entries of the page tables define the address translation mappings and may also specify access permissions which govern whether a given process executing on the pipeline is allowed to read, write or execute instructions from a given memory region. The MMU 28 may also be looked up on instruction fetches triggered by the fetch stage 6. As shown in Figure 1 , the MMU 28 may be implemented using an instruction-side MMU (l-MMU) for performing MMU functions for instruction fetches, separate from a data-side MMU (D-MMU) used by the load/store unit 26 for data accesses - in this case both MMUs can cache in their respective TLBs 29 information from a shared set of page tables. It will be appreciated that in other examples, a same MMU and/or TLB may be shared between instruction-side accesses from the fetch stage 6 and data-side accesses from the load/store unit 26.

In this example, the memory system includes a level one data cache 30, the level one instruction cache 8, a shared level two cache 32 and main system memory 34. It will be appreciated that this is just one example of a possible memory hierarchy and other arrangements of caches can be provided. The specific types of processing unit 20 to 26 shown in the execute stage 16 are just one example, and other implementations may have a different set of processing units or could include multiple instances of the same type of processing unit so that multiple micro-operations of the same type can be handled in parallel. It will be appreciated that Figure 1 is merely a simplified representation of some components of a possible processor pipeline implementation, and the processor may include many other elements not illustrated for conciseness.

The data processing apparatus comprises a program counter indicating the current point of execution. The program counter may be provided in a program counter register within the register file 14, which may directly store a program counter address or a program counter address offset by a fixed amount. The program counter address can be used to identify a next instruction to be fetched by the fetch stage 6, and can be incremented by an amount depending on the size of the instruction when an instruction is fetched, in addition to being updated on a taken branch instruction by an arbitrary amount specified by the branch. In this way, the program counter address indicates a next instruction in a program, and causes the processing circuitry to step through a program.

The register file 14 comprises an instruction-storing register configured to store instruction-defining information such as an opcode and values identifying operands. When an execute-instruction-from-register condition is satisfied, the processing circuitry may perform an alternate operation based on the instruction-storing register in place of an original operation represented by an instruction stored in a location in memory corresponding to the program counter address (the original operation is the operation which would be performed corresponding to the program counter address if the execute-instruction-from-register condition is not satisfied). For example, the instruction identified by the program counter address may not be fetched from memory, and the instruction-defining information may be provided from the instruction-storing register in its place. In this case, execution in the execute stage 16 is based on the instruction-defining information and not on information stored at the program counter address.

There may be no restrictions on where data written to the instruction-storing register may be written from, so the instruction-storing register may in theory store instructions which could cause behaviour that may compromise the data processing apparatus. Executing from the instruction-storing register bypasses permissions checks that may be performed on the memory access when the fetch circuitry 6 reads instructions from the memory system 8, 32, 34, which would usually prevent execution of instructions that are not allowed to be performed. Hence, the instruction-storing register presents a route by which instructions may be caused to execute when they should not be permitted. An adversary may trick code into storing an instruction in the instruction-storing register and executing that instruction, for example. Allowable uses of the instruction-storing register for executing instructions may only be provided at certain points in code where use of the instruction-storing register is expected.

Therefore, the data processing apparatus also comprises checking circuitry 36. When it is determined that the execute-instruction-from-register condition is satisfied, the checking circuitry performs an address-dependent check based on the program counter address to determine whether the alternate operation is allowed to be performed in place of the original operation. If the alternate operation is not permitted, the checking circuitry 36 raises an exception and prevents performance of the alternate operation.

The address-dependent check performed by the checking circuitry 36 may vary, and may include several different checks. The address-dependent check may comprise one or more of:

Checking that the program counter address is within an executable region of memory. The alternate operation may be typically used to replace the action of an instruction. However, if the program counter address does not point to an executable region of memory then this may indicate that it is not an instruction, or at least not an instruction which may be executed. Hence, this might indicate a point in processing where execution from a register may not be permitted.

• Checking that the program counter address is within a writeable region of memory. If the memory instruction being replaced by the instruction stored in the instruction-storing register may be written to, then this may indicate that it can be modified freely. Hence, there may be no need to prevent this operation being replaced with an operation based on a register. In addition, code may be in a writeable region of memory when it is being debugged. As debugging may be a situation where execution from the instruction-storing register is expected to occur, checking for the write permission may be a way of indirectly checking whether the current situation is a debugging situation where execution from the instruction-storing register is expected.

• Checking that the program counter address is within a region of memory that is both writeable and executable. This combination of the above two checks may more accurately identify areas of code that are being debugged, since these are regions where both the execute and write permissions may be provided, and where execution from the instruction-storing register may be expected.

• Checking that the program counter address is within a region of memory explicitly permitting, independent from the execute and write permissions, execution from the instruction-storing register in place of instructions in that region of memory for the current exception level.

• Checking that the instruction in memory at the program counter address is an expected type of instruction, such as a breakpoint instruction, where it would be expected to replace the operation of the memory instruction with an alternate operation.

If one of more of the above conditions are not satisfied, it may indicate that there is an attempt to execute an instruction based on the instruction-storing register at a point where this is not expected in code.

Certain of the checks described above may be performed by referring to access permissions associated with the program counter address in memory. The permissions may be specified in page table entries in page tables stored in memory, which may be cached at the TLB 29 associated with the instruction-side MMU (l-MMLI). The permissions may include flags corresponding to each permission, or combinations of bits may be associated with certain sets of permissions. The permissions may include an execute permission, a write permission, and/or at least one execute-instruction-from-register permission which is independent from the execute and write permissions. Different execute-instruction-from-register permissions may be provided for different exception levels of the processing circuitry. Further permissions may also be provided, such as a read permission indicating that the region of memory is readable. In some examples, the permissions may be directly specified in the page table entries as stored in memory. However, in other examples page table entries specify permissions indirectly as illustrated in Figure 2.

Figure 2 illustrates the use of a page table entry (translation table entry) 40 to indirectly specify permissions for a region of memory corresponding to the page table entry. The page table entry 40 is part of a page table stored in memory, and may also be cached in the TLB 29. A permissions field 42 provided in the page table entry 40 provides a field identifier (whereas the permissions field 42 would indicate permissions themselves if the permissions were specified directly). The field identifier identifies a field in a permissions register 44 (permission indirection register) used to specify the permissions. The permissions may be specified in any way in the identified field of the permissions register 44, such as the encodings used to represent permissions directly in the page table entry. Providing permissions in a permissions register 44 rather than in a page table entry 42 means that permissions for several regions of memory can be updated at once, by writing an updated value to a field of the permissions register referred to by several page table entries. In addition, there may be more encoding space available in the identified field of the register 44 than in the permissions field of the page table entry 40, allowing a greater number of distinct permissions to be provided. Further, if different processing environments have access to the same memory but different registers (for example, if they are different cores of a processing apparatus) then the same page table entry 40 may refer to fields in different permissions registers, allowing different permissions to be specified by the same page table entry. Each of the write, execute, and each execute-instruction-from-register permission may be provided in a page table entry as a direct permission or in a field of a permissions register.

Executing an instruction from the instruction-storing register in place of an instruction in memory may be used in several situations. For example, during debugging, it may be desired to execute a slightly modified version of a program to allow for comparison of performance against another thread executing the original program. For this purpose, it may be useful to execute the modified program by executing modified instructions from a register, leaving the original program in memory for the comparative thread to execute. Another example is to improve the use of software breakpoints, which may be used to debug code. In software breakpointing, certain instructions in a piece of software stored in memory are replaced with breakpoint instructions, which cause exceptions to be raised when performed. When a breakpoint instruction causes an exception, more privileged code may take an appropriate debug action. However, since instructions in the code have been replaced with breakpoint instructions, the software is no longer complete and cannot simply be executed from memory, or else debugging will not be accurate since instructions are missing. One approach for addressing the missing instructions is to temporarily replace the breakpoint instructions in memory with the original instructions, perform the original instruction, then replace it once again with a breakpoint instruction. The procedure may involve the following:

1. A user requests a breakpoint at a given program counter address (PC) through a debugger.

2. The debugger replaces the instruction at the given program counter address with a breakpoint (BRK) instruction.

3. The original instruction is saved to debugger memory by the debugger.

4. Upon receiving the Software Breakpoint exception, the processing circuitry records the PC in a register and the debugger takes the appropriate debug action.

5. To return to the original thread:

5.1. All other threads that are executing that might share the breakpoint are paused.

5.2 The debugger replaces the BRK at the given PC in memory with the original instruction stored in debugger memory

5.3 The debugger sets an enable bit to enable a Software Step procedure.

5.4 The debugger executes an exception return (ERET) instruction.

6. The processing circuitry executes the original instruction at the PC, and then takes a Software Step exception to return control to the debugger.

7. The debugger replaces the original instruction with a BRK, restarts other threads if necessary, and then executes another ERET.

This procedure is relatively inefficient. First, if more than one thread is executing the process being debugged then the other threads need to be paused so that they do not miss the BRK instruction whilst it is temporarily replaced in memory with the original instruction. This delays other threads of execution. In addition, this procedure requires two writes to memory (one to write the original instruction to memory and one to write the BRK to memory again afterwards). Writes to memory may involve certain overhead, particularly if coherency needs to be enforced as in addition to the usual permissions checks this may also involve sending coherency messages to invalidate cached copies of instructions.

The instruction-storing register may be used to alleviate these issues. Rather than replacing the BRK in memory, the original instruction may instead be written to the instructionstoring register (e.g. from the debugger memory). Then, the Software Step may involve executing the original instruction from the instruction-storing register in place of the operation defined by the BRK instruction which remains in memory. This may remove the need to pause other threads, and also removes the two writes to memory.

However, as discussed above executing from a register presents possible routes for instructions to be executed when they should not be, and therefore the checking circuitry may perform address-dependent checks to ensure that the program counter address is a point in code where execution from the instruction-storing register is expected. For example, when the address-dependent check involves checking whether the instruction at the program counter address is an expected type of instruction, this check may be passed when the instruction at the PC address is the BRK instruction.

Further details for execution of an instruction from the instruction-storing register will be described below with reference to exception levels (privilege levels). Figure 3 provides an outline of the use of exception levels in the processing apparatus. Figure 3 schematically illustrates an example of processes which can be executed by the data processing apparatus. A hypervisor 50 may manage a number of virtual machines (VMs, also known as guest operating systems or guest OS) 52. Each VM 52 may manage one or more applications 54. For example the hypervisor 50 may control which regions of an address space are allocated to each virtual machine 52 and control switching between the virtual machines 52, e.g. scheduling interrupts to time share processing resource between the respective virtual machines 52. Similarly, each VM 52 may control which regions of the address space are allocated to each application 54 executing under that VM 52, and may control switching between the applications as required.

As shown in Figure 3, each process is associated with a given privilege level ELO, EL1 , EL2, EL3. In this example higher numbered privilege levels are more privileged than lower numbered privilege levels, although it could be numbered the other way round in other examples. In this example, the applications 54 execute at privilege level ELO, the VMs 52 execute at privilege level EL1 and the hypervisor 50 executes at privilege level EL2. Typically, a process executing at a higher privilege level has rights not available to a process executing at a lower privilege level.

As shown in Figure 3, the hypervisor 50, VMs 52 and apparatus 54 may operate in a normal domain. In addition, the apparatus may support a secure domain which is partitioned from the normal domain so that processes executing in the normal domain cannot access data or instructions associated with the secure domain. Hence, there may also be processes running in the secure domain, such as a secure operating system (OS) 56 and trusted applications 58 executing in the secure domain under control of the secure OS 56. The secure OS 56 and trusted applications 58 execute at privilege levels S-EL1 , S-EL0 respectively. A secure monitor process 60 is also provided at privilege level EL3 to manage transitions between the normal domain and the secure domain. The secure monitor process 60 may for example manage which regions of the address space are associated with the secure or nonsecure domains, with some protection hardware being provided to prevent non-secure processes in the normal domain accessing data or instructions within the secure regions. An example of a technique for partitioning the normal and secure domains is the Trustzone® technique provided by ARM® Limited of Cambridge, UK, although other examples could also be used. The provision of a secure domain as shown in Figure 3 is optional and other embodiments may not support the secure monitor 60, secure OS 56 and trusted applications 58 for example.

The processes 50, 52, 54, 56, 58, 60 each use virtual addresses (VAs) to identify locations to be accessed in a data store such as memory. The VAs are translated into physical addresses (PAs) directly identifying corresponding storage locations. For an application 54 or a virtual machine 52, the VAs are first translated into intermediate physical addresses (I PAs), and then the IPAs are translated into PAs. By providing two levels of address translation, the virtual machine 52 may control page tables for the VA to I PA translation to control which portions of the address space are allocated to each application 54, and the hypervisor 50 may control page tables for the I PA to PA translation to control which portions of the address space are allocated to each virtual machine 52, for example. For the other processes the VAs are translated directly into PAs with the hypervisor 50 (in the normal domain) or the secure OS 56 (in the secure domain) for example controlling the page tables which control which portions of the address space each process can access.

Further details shall also reference a number of registers as shown in Figure 4 which may be provided in the register file 14. The registers are provided in a format NAME_ELy, where ELy indicates the least privileged exception level which may access a given register. Accesses below ELy may cause an exception to be raised to be handled by more privileged software. For example, writes to MDSCR_EL1 by software executing at EL0 may be prohibited. The format ESR_ELx indicates banked registers - multiple copies of the ESR register, named ESR_EL1 , ESR_EL2, ESR_EL3, for storing exception information about exceptions taken to EL1 , EL2, EL3 respectively. Register fields are referred to in the format NAME_ELy.FIELD and are shown within the registers in Figure 4. The specific layout of information in the registers shown in the example of Figure 4 is just one example, and other examples could combine the register fields in other ways (e.g., with a different allocation of which fields go in the same register or are in different registers). In addition, some of the register control information may be omitted from certain examples of the present technique. Certain descriptions refer to values in registers being “set” or set to “1”. It will be appreciated that there are different equivalent values that may be stored in a register field to indicate the set state, and that 1 (0b1) is merely an example. The following registers and register fields are illustrated in Figure 4:

MDSCR_EL1 is a control register for debugging. MDSCR_EL1.EnSTEPOP is a register field storing an enable value settable by EL1 and more privileged exception levels. Software operating at EL1 may set the enable value to indicate that it wishes the execute- instruction-from-register condition to be satisfied for the next value of the program counter address corresponding to the instruction after the enable value has been set.

MDSTEPOP_EL1 is an instruction-storing register which can be written to by EL1 and more privileged exception levels. Access to MDSTEPOP_EL1 may be further controlled with the trap conditions illustrated in Figure 7. When the execute-instruction-from-register condition is satisfied and the address-dependent check passes, then an instruction may be executed from MDSTEPOP_EL1.

ESR_ELx are a set of banked exception syndrome registers ESR_EL1 , ESR_EL2, ESR_EL3 which store information relating to exceptions taken to the corresponding exception level. For example, ESR_EL1 stores information relating to exceptions taken to EL1. The field ESR_ELx.STEPOP may be used to indicate that an exception was caused due to execution of the instruction stored in MDSTEPOP_EL1. The field ESR_ELx.EC may be used to indicate that an exception has been taken to a higher exception level than an exception level in which it was generated. The field ESR_ELx.lSS. FAILED may be used to indicate that the exception that has been generated is the Software Step Failed exception due to a failed addressdependent check. The field ESR_ELx.ISS.IFSC may be used to indicate that the Software Step Failed exception is due to an instruction at the PC address not being an expected (e.g., BRK) instruction.

MDCR_EL2 is a control register which provides configuration information for debugging and can be set by EL2 or EL3. The field MDCR_EL2.EnSTEPOP is a field which may store a further value which may be used to determine whether the execute-instruction- from-register condition is satisfied. Since MDCR_EL2.EnSTEPOP may be set by more privileged code than MDCR_EL1.EnSTEPOP, it may be used to override EL1 when EL1 wishes to set the execute-instruction-from-register condition. The field MDCR_EL2.TDA provides control over access to debug registers in EL1 , and when set indicates that accesses to certain debug registers in EL1 , including the instruction-storing register MDSTEPOP_EL1 , are trapped to EL2 (if there is no higher priority exception pending).

HDFGRTR2_EL2 is a control register which can be set by EL2 or EL3 to control access to the MDSTEPOP_EL1 register. The register field HDFGRTR2_EL2.nMDSTEPOP_EL1 may be set by EL2 to control whether software at EL1 is permitted to directly read the value stored in MDSTEPOP_EL1 , or whether an attempted read should trap to a higher exception level. The register field HDFGWTR2_EL2.nMDSTEPOP_EL1 may be set by EL2 to control whether software at EL1 is permitted to directly write to MDSTEPOP_EL1 or whether an attempted write should trap to a higher exception level. Hence, using these registers EL2 (e.g., the hypervisor) may impose controls over how EL1 (e.g., an operating system) is permitted to access the instruction-storing register.

MDCR_EL3 is a control register which provides configuration information for debugging and can be set by EL3. The field MDCR_EL3.EnSTEPOP may store a further value which can be used to determine whether the execute-instruction-from-register condition is satisfied. If MDCR_EL3.EnSTEPOP is 0 then the execute-instruction-from-register condition may be prevented, even if other enable bits indicate that the execute-instruction-from-register condition should be satisfied, and hence EL3 can override lower exception levels. Since MDCR_EL3.EnSTEPOP cannot be set by code executing at EL1 or EL2, it may be used to override the control provided based on MDSCR_EL1.EnSTEPOP and MDCR_EL2.EnSTEPOP by code executing at EL1 and EL2. The field MDCR_EL3.TDA provides control over access to debug registers in ELO, EL1 , and EL2 and when set indicates that accesses to certain debug registers in EL0-EL2, including the instruction-storing register MDSTEPOP_EL1 , are trapped to EL3.

HCR_EL2 is a hypervisor (EL2) configuration register providing controls for virtualisation. HCR_EL2.E2H indicates whether a configuration running a host operating system (type 2 hypervisor) is supported at EL2, which can affect exception handling at lower levels such as ELO (if a type 2 hypervisor is supported, some exceptions which would otherwise be handled at EL1 may be handled at EL2 instead). When HCR_EL2.E2H is set to 1 , the facilities to support a host operating system at EL2 are enabled. HCR_EL2.TGE is an example of a trap control, which indicates whether to trap general exceptions to EL2. When HCR_EL2.TGE=1. exceptions that would ordinarily be routed from ELO to EL1 are instead routed to EL2, effectively disabling EL1 from being available for taking exceptions. If HCR_EL2.E2H is also enabled (HCR_EL2.{E2H, TGE}={1 ,1}) then EL1 is fully disabled and ELO runs in the host operating system.

EDHSR holds syndrome information for a debug event. EDHSR. STEPOP is a register field which may be set when execution of the instruction in the MDSTEPOP_EL1 register caused an exception and entry into the debug state.

Whilst some of the following description will make reference to the use of the present technique for performing software breakpointing, it will be appreciated that the concepts described are not so limited. The concepts may be extended to use of the instruction-storing register for other operations, and the specific references are merely used to explain at least one way of performing the present technique in practice.

Figure 5 illustrates a procedure for executing an instruction from an instruction-storing register in place of an instruction stored in memory. At step 500, processing is at a point in program flow where the next instruction to be fetched is indicated by the program counter address. At step 502 it is determined whether an execute-instruction-from-register condition is satisfied, which indicates to the processing circuitry that if permitted the next operation should be performed based on the information stored in the instruction-storing register instead of the instruction stored at the program counter address. Determining whether the execute- instruction-from-register condition is satisfied may take place according to Figure 6. Figure 6 illustrates a number of conditions for determining whether the execute-instruction-from- register condition is satisfied, but it will be appreciated that one or more of the conditions may not be provided in every implementation of the technique.

At step 600 of Figure 6 it is determined whether the enable value is set, i.e., is MDSCR_EL1.EnSTEPOP=1. If not, then software at EL1 or higher has not set the enable bit to indicate that it wishes the next instruction to be executed from a register. Hence, in this case the execute-instruction-from-register condition is not satisfied (step 616).

At step 602 of Figure 6 it is determined whether EL3 is implemented. If so, it is determined at step 604 whether an enable bit only settable by EL3 is set by determining whether MDCR_EL3.EnSTEPOP=1. If not, then EL3 has prevented instructions from being executed from the instruction-storing register, and therefore the execute-instruction-from- register condition is not satisfied. If EL3 is not implemented or has not overridden EL1 , then it is determined whether EL2 is implemented at step 606.

If EL2 is implemented and not disabled (step 608) then at step 610 it is determined whether the processing circuitry is currently executing at EL0 or EL1 (i.e., below EL2). If not, there is no need to perform a check to see if EL2 has overridden the execute-instruction-from- register condition, and it is considered that the condition is satisfied. However, if processing is at EL0 or EL1 then the process optionally determines whether the register fields HCR_EL2.{E2H.TGE}={1 ,1} at step 612. If so, then EL1 is disabled and a separate check to determine whether EL2 overrides the execute-instruction-from-register condition may be unnecessary. If not, it is determined at step 614 whether EL2 has overridden performance of the alternate operation from the instruction-storing register by checking the state of MDCR_EL2.EnSTEPOP. If not, then the execute-instruction-from-register condition is satisfied (step 618). However, if EL2 has overridden the execute-instruction-from-register condition then the condition is not satisfied (step 616).

Hence, it will be seen that even though EL1 has requested that the execute-instruction- from-register condition be satisfied by setting the enable bit, this is subject to overrides by both EL2 and EL3 (depending on implementation). It will be appreciated that one or more of the steps shown in Figure 6 may be excluded, for example if EL2 or EL3 are not provided in a particular implementation. For example, the check at step 612 may not be included, and the process may move directly from step 610 to step 614. Similar considerations apply to the other steps illustrated.

Returning to Figure 5, if it is determined that the execute-instruction-from-register condition is not satisfied, then at step 504 the processing circuitry does not perform the alternate operation in place of the original operation. The processing circuitry may, for example, continue with processing as usual by fetching the instruction from the memory system at the program counter address.

However, if the execute-instruction-from-register condition is satisfied, then at step 506 the checking circuitry 36 performs an address-dependent check. The address-dependent check may comprise one or more of the checks illustrated in Figures 8-12, as will now be discussed. It will be appreciated that the address-dependent check may also include further checks for which the outcome of the check is dependent on the program counter address.

As illustrated in Figure 8, the address-dependent check may be a permissions check based on permissions associated with the program counter address. It may be determined at step 800 if an execute permission is provided for the program counter address, allowing instructions stored at the program counter address to be executed by the processing circuitry. If so, then that aspect of the address-dependent check may be satisfied and the result of the overall address-dependent check depends on whether any other check has failed (step 804). If the execute permission is not provided, then the address-dependent check fails (step 802).

As illustrated in Figure 9, the address-dependent check may be a permissions check based on permissions associated with the program counter address. It may be determined at step 900 if a write permission is provided for the program counter address, allowing the memory region indicated by the program counter address to be written to by the processing circuitry. The outcomes at step 902 and 904 are the same as steps 802 and 804 respectively.

As illustrated in Figure 10, the address-dependent check may be a permissions check based on permissions associated with the program counter address. It may be determined at step 1000 if a dedicated execute-instruction-from-register permission is provided for the program counter address, independently from other permissions including the write and execute permissions, allowing instructions in the memory region indicated by the program counter address to have their operations replaced by alternate operations executed based on the instruction-storing register. At step 1002, if the check based on the execute-instruction- from-register permission fails, then the address-dependent check fails even if checks are performed and pass based on the execute and write permissions. At step 1004, if the check based on the execute-instruction-from-register permission passes, then whether the addressdependent check passes overall is dependent on the result of other checks in the addressdependent check. Whilst the check in Figure 10 may take place on the basis of a single execute- instruction-from-register permission, the check may also take place as illustrated in Figure 11 . Figure 11 illustrates a process of selecting an execute-instruction-from-register permission on the basis of the current exception level. If the current exception level is the least privileged exception level, ELO, then a first execute-instruction-from-register permission value may be selected to be used in the check of Figure 10. However, if the processing circuitry is executing at a higher exception level, EL1-EL3, then a second execute-instruction-from-register permission value may be selected. This allows different permissions to be set for the lowest exception level, which may be the least trusted exception level, and the other exception levels. Hence, in some cases executing an instruction from memory may only be prevented for the lowest exception level.

As illustrated in Figure 12, the address-dependent check may be based on the type of instruction stored at the program counter address. The check may pass (step 1204) if the instruction at the PC address is an expected type of instruction such as a breakpoint instruction. Otherwise (step 1202), the address-dependent check may fail.

Returning again to Figure 5, if the address-dependent check fails, then at step 510 the checking circuitry 36 may signal an exception to the processing circuitry, and performing the alternate operation in place of the original operation may be prevented. Failure of the addressdependent check when performing a Software Step operation may be signalled using a Software Step Failed exception. The exception level at which the Software Step Failed exception is taken will be the exception level indicated by ELx in the following references. A value may be set in a register field ESR_ELx.EC to indicate whether the exception is taken to a higher EL than the current EL or whether it is taken to the current EL. A field ESR_ELx.lSS. FAILED may be set to indicate that the exception that has been generated is the Software Step Failed exception due to a failed address-dependent check. When the check is as illustrated in Figure 12, checking whether there is an expected type of instruction at the PC address, a field ESR_ELx.ISS.IFSC may be set to indicate that the Software Step Failed exception is due to an instruction at the PC address not being an expected (e.g., BRK) instruction. If ESR_ELx.lSS. FAILED is set but ESR_ELx.ISS.IFSC is not, then it may be determined that failure of the address-dependent checks was due to a permission (execute, write, or execute-instruction-from-register) failure.

However, if the address-dependent check passes, then at step 512 the checking circuitry 36 allows the processing circuitry to perform the alternate operation based on the instruction-storing register to be performed in place of the original operation which would be performed based on the instruction stored in the location corresponding to the PC address. In the case of the breakpoint instruction, this allows the replaced instruction to be executed from the instruction-storing register in place of the breakpoint instruction which remains stored in the code in memory. If the instruction executed from the instruction-storing register reads from or writes to the program counter, this will be the current program counter (associated with the BRK instruction in memory) because the program counter has not been modified to allow execution of the alternate operation. If the instruction execution from MDSTEPOP_EL1 completes without generating an exception, then the current program counter value is incremented by the size of the instruction to allow execution of the code to progress. If an exception is generated during execution of the instruction from the instruction-storing register, the return address for the exception may be based on the current PC value. Following execution of the operation represented by the instruction in the instruction-storing register, a debug exception is triggered (with EDHSR. STEPOP being set to indicate the cause of the debug exception). The debug exception triggers a transition to a debug mode in which further execution of the program code being debugged is halted and instructions are instead executed from a debug memory which could either be a dedicated storage unit or a designated region within the memory system 30, 32, 34. This can allow the debugger to execute debug instructions not part of the program code being debugged, e.g. to investigate register contents or data in memory or read out performance counter values. Once the debug operations to be carried out in the debug mode are completed, an additional debug instruction may be executed to clear the enable value MDSCR_EL1.EnSTEPOP followed by an exception return instruction to return execution to the program being debugged which can then resume from the next address following the program counter value for which the alternate operation was performed from the register.

The use of the instruction-storing register MDSTEPOP_EL1 for implementing a software breakpoint may proceed according to the following example description (it will be appreciated this is just one illustrative example of a software use case and the operations shown in the pseudocode are not required features of the hardware apparatus).

0 BRK at ELO

10 <Exception handler for Software Breakpoint starts at EL1> 20 <Enable Software step>

30 MSR MDSCR_EL1 , xO / /Write Obi to MDSCR_EL1 . EnSTEPOP

40 MSR MDSTEPOP ELI , xl / /Write replaced instruction to instruction-storing register

50 ERET / /Return to ELO

60 <Execute from MDSTEPOP_EL1>

70 <Software Step exception to EL1>

The address-dependent check may be performed by the hardware when it is determined to execute from MDSTEPOP_EL1. In some examples, the instruction-storing register may have restricted access. For example, the register may be accessible to EL1 or higher but not ELO. An example instructionstoring register is MDSTEPOP_EL1 as shown in Figure 4. Access to the register MDSTEPOP_EL1 may be controlled as illustrated in Figure 7, which illustrates a number of checks to determine if an attempted access to the instruction-storing register should cause an exception, and if so which exception level the exception should be handled in, although it will be appreciated that one or more of the steps shown in Figure 7 may be excluded.

At step 700 an attempted read from or write to the register MDSTEPOP_EL1 is detected. At step 702 it is determined whether the current exception level is ELO. If the current exception level is ELO and there is an attempt to access the EL1 instruction-storing register, then this is not permitted and at step 704 there is a trap to a higher exception level to handle the security violation. If the current EL is not ELO, it is determined at step 704 whether the current EL is EL1 or EL2 (i.e. , not EL3). If the EL is EL3, then at step 708 there is no trap to a higher EL as there may be no higher exception level.

If the EL is EL1 or EL2 and either (step 710) MDCR_EL3.TDA=1 or (step 712) MDCR_EL3.EnSTEPOP=0 (i.e., EL3 has prevented the execute-instruction-from-register condition from being satisfied, disabling execution from the instruction-storing register) then the attempted access traps to EL3 at step 714. If neither of these is true, and the current exception level is EL2 (step 716) then there is no trap to a higher EL.

If the current exception level is EL1 , then it is determined whether MDCR_EL2.TDA=1 at step 718 and if this is true then the attempted access traps to EL2. Otherwise, when the attempted access is a read it is determined whether HDFGRTR2_EL2.nMDSTEPOP_EL1=0 (a control bit settable by EL2 controlling reads from MDSTEPOP_EL1 at EL1) and when the attempted access is a write it is determined whether HDFGWTR2_EL2.nMDSTEPOP_EL1=0 (a control bit settable by EL2 controlling writes to MDSTEPOP_EL1 at EL1). If either of these is satisfied then the access has been prevented by EL2, and the attempted access traps to EL2 at step 724.

Hence, it will be seen that EL2 and EL3 can both independently control whether an access from EL1 to the instruction-storing register MDSTEPOP_EL1 is permitted. In addition, EL2 can permit read and writes independently from each other, further increasing the flexibility of control over the instruction-storing register. It will be appreciated that not all of the steps shown in Figure 7 are required, and that the present technique may be implemented without one or more of the trap conditions being implemented. For example only, in some examples EL3 may not be implemented, so the EL3 steps may not be present. Similarly, some implementations could support the option of disabling use of EL2. In that case, the test at step 716 becomes “Current EL is EL1 and EL2 is enabled?”, so if EL2 is not implemented or is currently disabled, then the method proceeds from step 716 to step 708 and steps 718-724 would be omitted. It will also be appreciated that the particular order of the steps in the flowcharts described above is just one example, and the same outcomes may be achieved with steps in a different order, or with some steps performed in parallel.

When executing an instruction from the instruction-storing register, an exception may be generated indicating that there has been a fault during execution. For example, if the instruction in MDSTEPOP_EL1 is an undefined instruction, or if it is a load/store instruction attempting to access an address which fails an MMU check, then an exception may be generated indicating that execution of that instruction caused a fault. In this case, the fault will not be a fault caused by the instruction at the PC address but a fault caused by the instruction in the instruction-storing register. Hence, exception handling software may be unable to identify the fault if it only uses the PC address to locate the instruction. To identify that the exception was caused by the instruction in the register, the field ESR_ELx.STEPOP may be set in an ESR register to indicate that the exception was generated from the execution of the instruction in the MDSTEPOP_EL1 register.

There are (at least) two independent reasons that an exception may be raised when attempting to execute an instruction from a register due to the execute-instruction-from- register condition being satisfied. First, the address-dependent check may fail. Second, the address-dependent check may pass but execution of the instruction stored in the instructionstoring register may cause a fault. These two cases may be distinguished using the registers described above. ESR_ELx.EC may indicate a primary exception cause (e.g. undefined instruction, data abort (fault), or software step exception), where ELx indicates the exception level that the exception is taken to. When the address-dependent check fails, the register field ESR_ELx.lSS. FAILED may be set. If failure of the address-dependent check was due to the instruction at the program counter address not being an expected type of instruction then ESR_ELx.ISS.IFSC may also be set. When execution of the instruction in the instructionstoring register fails, ESR_ELx.STEPOP may be set whilst ESR_ELx.lSS. FAILED remains not set. Hence, by checking the state of ESR_ELx.EC, ESR_ELx.lSS. FAILED and ESR_ELx.lSS. STEPOP, software handling the exception can determine whether the exception was generated due to failure of the address-dependent check, due to execution of the instruction in the instruction-storing register, or for some other reason. Some of the fields of ESR_ELx may also have other purposes when used for other types of exception (e.g. ESR_ELx.lFSC may be used for a different purpose on a data abort compared to the use described above for a software step exception).

The register field EDHSR. STEPOP may also be set to indicate that the debug state has been entered due to execution of the instruction in the MDSTEPOP_EL1 register.

Figure 13 illustrates a simulator implementation that may be used. Whilst the earlier described embodiments implement the present invention in terms of apparatus and methods for operating specific processing hardware supporting the techniques concerned, it is also possible to provide an instruction execution environment in accordance with the embodiments described herein which is implemented through 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. Varieties of 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 1306, optionally running a host operating system 1304, supporting the simulator program 1302. In some arrangements, there may be multiple layers of simulation between the hardware and the provided instruction execution environment, and/or multiple distinct instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations which execute at a reasonable speed, but such an approach may be justified in certain circumstances, such as when there is a desire to run code native to another processor for compatibility or re-use reasons. For example, the simulator implementation may provide an instruction execution environment with additional functionality which is not supported by the host processor hardware, or provide an instruction execution environment typically associated with a different hardware architecture. An overview of simulation is given in “Some Efficient Architecture Simulation T echniques”, Robert Bedichek, Winter 1990 IISENIX Conference, Pages 53 - 63.

To the extent that embodiments have previously been described with reference to particular hardware constructs or features, in a simulated embodiment, equivalent functionality may be provided by suitable software constructs or features. For example, particular circuitry may be implemented in a simulated embodiment as computer program logic. Similarly, memory hardware, such as a register or cache, may be implemented in a simulated embodiment as a software data structure. In arrangements where one or more of the hardware elements referenced in the previously described embodiments are present on the host hardware (for example, host processor 1306), some simulated embodiments may make use of the host hardware, where suitable.

The simulator program 1302 may be stored on a computer-readable storage medium (which may be a non-transitory medium), and provides a program interface (instruction execution environment) to the target code 1300 (which may include applications, operating systems and a hypervisor) which is the same as the interface of the hardware architecture being modelled by the simulator program 1302. Thus, the program instructions of the target code 1300 may be executed from within the instruction execution environment using the simulator program 1302, so that a host computer 1306 which does not actually have the hardware features of the apparatus 2 discussed above can emulate these features. For example, the simulator program 1302 may provide processing program logic 1308 simulating the features of the processing circuitry 2 and checking program logic 1310 simulating the features of the checking circuitry 36. The simulator program 1302 may provide a simulated address space 1312, where the storage is actually in a physical memory system provided by the host hardware 1306 and the simulator program 1302 maps addresses in the simulated address space onto addresses in the physical memory system so that the target code 1300 may refer to addresses in the simulated address space. The simulator program 1302 may also provide simulated registers 1314 which may be treated as registers by the target code 1300, but for which the storage may again be provided in the physical memory system of the host hardware 1306.

Concepts described herein may be embodied in computer-readable code for fabrication of an apparatus that embodies the described concepts. For example, the computer-readable code can be used at one or more stages of a semiconductor design and fabrication process, including an electronic design automation (EDA) stage, to fabricate an integrated circuit comprising the apparatus embodying the concepts. The above computer- readable code may additionally or alternatively enable the definition, modelling, simulation, verification and/or testing of an apparatus embodying the concepts described herein.

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

Additionally or alternatively, the computer-readable code may define a low-level description of integrated circuit components that embody concepts described herein, such as one or more netlists or integrated circuit layout definitions, including representations such as GDSII. The one or more netlists or other computer-readable representation of integrated circuit components may be generated by applying one or more logic synthesis processes to an RTL representation to generate definitions for use in fabrication of an apparatus embodying the invention. Alternatively or additionally, the one or more logic synthesis processes can generate from the computer-readable code a bitstream to be loaded into a field programmable gate array (FPGA) to configure the FPGA to embody the described concepts. The FPGA may be deployed for the purposes of verification and test of the concepts prior to fabrication in an integrated circuit or the FPGA may be deployed in a product directly.

The computer-readable code may comprise a mix of code representations for fabrication of an apparatus, for example including a mix of one or more of an RTL representation, a netlist representation, or another computer-readable definition to be used in a semiconductor design and fabrication process to fabricate an apparatus embodying the invention. Alternatively or additionally, the concept may be defined in a combination of a computer-readable definition to be used in a semiconductor design and fabrication process to fabricate an apparatus and computer-readable code defining instructions which are to be executed by the defined apparatus once fabricated.

Such computer-readable code can be disposed in any known transitory computer- readable medium (such as wired or wireless transmission of code over a network) or non- transitory computer-readable medium such as semiconductor, magnetic disk, or optical disc. An integrated circuit fabricated using the computer-readable code may comprise components such as one or more of a central processing unit, graphics processing unit, neural processing unit, digital signal processor or other components that individually or collectively embody the concept.

In the present application, the words “configured to...” are used to mean that an element of an apparatus has a configuration able to carry out the defined operation. In this context, a “configuration” means an arrangement or manner of interconnection of hardware or software. For example, the apparatus may have dedicated hardware which provides the defined operation, or a processor or other processing device may be programmed to perform the function. “Configured to” does not imply that the apparatus element needs to be changed in any way in order to provide the defined operation.

Although illustrative embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various changes and modifications can be effected therein by one skilled in the art without departing from the scope of the invention as defined by the appended claims.

Claims

1. A data processing apparatus, comprising: processing circuitry configured to perform data processing operations in response to instructions stored in a memory system, wherein in response to determining that an execute- instruction-from-register condition is satisfied at a point in program flow corresponding to a program counter address, the processing circuitry is configured to determine, based on instruction-defining information associated with an instruction-storing register, an alternate operation to be performed in place of an original operation represented by an instruction stored in a location in the memory system corresponding to the program counter address; and checking circuitry configured to perform an address-dependent check based on the program counter address to determine whether the processing circuitry is permitted to perform the alternate operation in place of the original operation.

2. The data processing apparatus according to claim 1 , wherein the address-dependent check comprises checking the state of permissions information associated with the program counter address.

3. The data processing apparatus according to claim 2, wherein the address-dependent check comprises checking whether the program counter address is within an executable memory region from which the processing circuitry is permitted to execute instructions.

4. The data processing apparatus according to any of claims 2 and 3, wherein the address-dependent check comprises checking whether the program counter address is within a writeable memory region to which the processing circuitry is permitted to write data.

5. The data processing apparatus according to any of claims 2 to 4, wherein the permissions information is specified directly or indirectly in a page table entry corresponding to the program counter address.

6. The data processing apparatus according to claim 5, wherein the page table entry corresponding to the program counter address indirectly specifies at least a portion of the permissions information used to perform the address-dependent check by identifying a register location for storing the permissions information.

7. The data processing apparatus according to any of claims 4 to 6, wherein the checking circuitry is configured to select which permissions information is used to perform the addressdependent check based on a current exception level of the processing circuitry.

8. The data processing apparatus according to any of claims 4 to 7, wherein the address-dependent check comprises checking whether the permissions information indicates that an execute-instruction-from-register permission is provided for the program counter address, wherein the checking circuitry is configured to determine that the processing circuitry is not permitted to perform the alternate operation in place of the original operation, in response to determining that the permissions information indicates that the execute- instruction-from-register permission is not provided for the program counter address, even if the permissions information indicates that an execute permission or a write permission is provided for the program counter address.

9. The data processing apparatus according to claim 8, wherein the permissions information indicates whether a first execute-instruction-from-register permission is provided and whether a second execute-instruction-from-register permission is provided; in response to determining that the processing circuitry is currently executing at a least privileged exception level, the checking circuitry is configured to perform the addressdependent check depending on whether the first execute-instruction-from-register permission is provided, and in response to determining that the processing circuitry is currently executing at an exception level other than the least privileged exception level, the checking circuitry is configured to perform the address-dependent check depending on whether the second execute-instruction-from-register permission is provided.

10. The data processing apparatus according to any preceding claim, wherein the address-dependent check comprises checking whether the instruction stored in the location in the memory system corresponding to the program counter address is an expected type of instruction.

11. The data processing apparatus according to claim 10, wherein the expected type of instruction includes at least a breakpoint instruction.

12. The data processing apparatus according to any preceding claim, wherein the processing circuitry is configured to determine whether the execute-instruction- from-register condition is satisfied based on at least one enable value stored in at least one control register.

13. The data processing apparatus according to claim 12, wherein the processing circuitry is configured to prohibit writes to the at least one control register when executing at an exception level less privileged than a threshold exception level.

14. The data processing apparatus according to claim 13 wherein the processing circuitry is also configured to determine whether the execute-instruction-from-register condition is satisfied based on a further value stored in a further control register, wherein processing circuitry executing at or below the threshold exception level is not permitted to write to the further control register.

15. The data processing apparatus according to any preceding claim, wherein in response to determining that a trap condition is satisfied, access checking circuitry is configured to cause the processing circuitry to trap to a more privileged exception level in response to detecting an attempt by the processing circuitry executing at a given exception level to read from or write to the instruction-storing register.

16. The data processing apparatus according to any preceding claim, wherein the processing circuitry is prevented from performing the alternate operation in place of the original operation in response to the checking circuitry determining failure of the address-dependent check.

17. The data processing apparatus according to any preceding claim, wherein the checking circuitry is configured to raise an exception in response to determining failure of the address-dependent check.

18. The data processing apparatus according to any preceding claim, wherein the processing circuitry is configured to maintain exception-identifying information in an exceptionidentifying register, wherein: in response to failure of the address-dependent check, the processing circuitry is configured to set the exception-identifying information to indicate a first exception cause; and in response to detecting that the execute-instruction-from-register condition is satisfied and the address-dependent check is successful, but a fault arises due to an attempt to perform the alternate operation, the processing circuitry is configured to set the exception-identifying information to indicate a second exception cause.

19. A computer-readable medium to store computer-readable code for fabrication of the data processing apparatus of any preceding claim.

20. A data processing method, comprising: performing data processing operations in response to instructions stored in a memory system; in response to determining that an execute-instruction-from-register condition is satisfied at a point in program flow corresponding to a program counter address, determining, based on instruction-defining information associated with an instruction-storing register, an alternate operation to be performed in place of an original operation represented by an instruction stored in a location in the memory system corresponding to the program counter address; and performing an address-dependent check based on the program counter address to determine whether performing the alternate operation in place of the original operation is permitted.

21. A computer program for controlling a host data processing apparatus to provide an instruction execution environment for execution of target program code, the computer program comprising: processing program logic to perform data processing operations in response to instructions of the target program code identified by addresses in a simulated address space, wherein in response to determining that an execute-instruction-from-register condition is satisfied at a point in program flow corresponding to a program counter address in the simulated address space, the processing program logic is configured to determine, based on instruction-defining information associated with an instruction-storing simulated register, an alternate operation to be performed in place of an original operation represented by an instruction stored in a location in the simulated memory system corresponding to the program counter address; and checking program logic to perform an address-dependent check based on the program counter address to determine whether the processing program logic is permitted to perform the alternate operation in place of the original operation.