Address Dependency Check

Abstract

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

Description

[Technical Field]

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

[0002]

[0003] 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, the restrictions may limit the area of ​​memory in which the instructions may be executed. Imposing restrictions on executing instructions from memory can improve security and reduce the likelihood of malicious code being executed.

[0003] Viewed from one aspect, the present technique provides a data processing apparatus, the data processing apparatus comprising: a processing circuit configured to perform data processing operations in response to instructions stored in a memory system, the processing circuit being configured, in response to determining that an instruction execution condition from a register is satisfied at a point in a program flow corresponding to a program counter address, to determine, based on instruction definition information associated with an instruction storage register, an alternative operation to be performed in place of an original operation represented by the instruction stored at a location in the memory system corresponding to the program counter address; and a check circuit configured to perform an address dependency check based on the program counter address to determine whether the processing circuit is permitted to perform the alternative operation instead of the original operation.

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

[0005] 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 executing target program code, the computer program comprising: processing program logic for performing data processing operations in response to instructions of target program code identified by addresses in the simulated address space, wherein, in response to determining that an instruction execution condition from the register is satisfied at a point in the program flow corresponding to a program counter address in the simulated address space, determining, based on instruction definition information associated with the instruction storage simulated register, an alternative operation to be performed in place of the original operation represented by the instruction corresponding to the program counter address; The processing program logic is configured to perform an address dependency check based on a program counter address to check the processing program logic to determine whether the processing program logic is permitted to perform an alternative operation instead of the original operation.

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

[0007] Further aspects, features, and advantages of the present technique will become apparent from the following description of examples, read in conjunction with the accompanying drawings. [Figure 1] 1 illustrates a schematic diagram of an example of a data processing device; [Figure 2] 10 illustrates schematically the use of translation table entries to indirectly specify permission information. [Figure 3] 1 illustrates schematically an example of a process that may be performed by a data processing apparatus. [Figure 4] 2 illustrates schematically registers that may be provided in a data processing apparatus; [Figure 5] 1 illustrates a procedure for executing instructions from an instruction storage register instead of instructions stored in memory. [Figure 6] Indicates the condition for determining whether the instruction execution condition from the register is met. [Figure 7] Indicates the conditions for determining whether an attempted access to an instruction storage register should cause an exception. [Figure 8] Provides an example of address dependency checking. [Figure 9] Provides an example of address dependency checking. [Figure 10] Provides an example of address dependency checking. [Figure 11] Provides an example of address dependency checking. [Figure 12] Provides an example of address dependency checking. [Figure 13] Illustrates a simulator implementation that may be used.

[0008] A data processing apparatus includes a processing circuit 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 that indicates a current point in the execution of the code. The program counter may be stored, for example, in a register and provides information identifying a program counter address that identifies the next instruction to be fetched from the memory system, and the fetched instruction identifies the operation to be performed by the processing circuit. The program counter may be provided in different ways; for example, the program counter may directly indicate a program counter address or may identify an offset that, combined with a base address, provides the program counter address. The program counter may be updated in response to an instruction fetch from memory or in response to a branch operation to indicate the next instruction in the program. The memory system from which instructions may be fetched may not be limited to main memory, but may also include one or more levels of cache that store data corresponding to addresses in main memory.

[0009] Although a program may traditionally be executed by executing instructions from memory, there may be certain cases in which it is instead preferable to perform an alternative operation other than the operation associated with the instruction indicated by the program counter. For example, as described in further detail below, after a software breakpoint in a program is reached, it may be desirable to perform an alternative operation instead of performing an operation based on the instruction associated with the program counter address (e.g., the instruction at the program counter address may be a breakpoint instruction, and the alternative operation may be based on a replaced instruction that has been replaced by the breakpoint instruction). The alternative operation may be determined based on instruction definition information stored in an instruction storage register rather than an instruction stored in a memory system at the program counter address. Thus, performing the alternative operation may include executing an instruction from the instruction storage register rather than executing an instruction from memory. The instruction definition information may include, for example, an opcode that identifies the alternative operation and information specifying operands for the alternative operation.

[0010] To determine when to perform an alternative operation based on an instruction storage register instead of an operation based on an instruction in memory, the processing circuit may check whether an instruction-from-register execution condition is met. The processing circuit may then execute the instruction stored in the instruction storage register instead of the instruction stored at the program counter address when the instruction-from-register execution condition is met. Performing an alternative operation based on instructions stored in a register instead of an operation based on instructions stored in a memory system can provide a flexible technique for modifying a program (e.g., for debugging purposes) without having to write new instructions to the memory system. This can avoid overhead, such as implementing coherency protocols, that may be associated with writing new instructions to memory when it is desired to modify code. Furthermore, modifying a program by executing particular instructions from a register instead of memory may be specific to a particular thread within a particular processing unit, and other processing units with access to the memory will see the original code rather than the modified code.

[0011] However, the inventors have recognized that performing an alternative operation based on an instruction stored in a register may mean that certain restrictions that are in place when executing instructions from memory are bypassed. When executing instructions from an instruction storage register, the instructions are not fetched from memory, and therefore restrictions that may normally be in place when fetching instructions may not be in place. Restrictions imposed when executing instructions from memory may reduce the possibility of malicious code being executed or of a processor being tricked into performing an operation that should not be permitted. Thus, bypassing restrictions while performing an alternative operation instead of the original operation may present a mechanism by which erroneous instructions may be executed.

[0012] The inventors have recognized that it may only be effective to perform an alternative operation in place of an original operation at certain points in a program where this behavior is expected and / or where the risk that this behavior will be used to attack the processor is reduced. Accordingly, the inventors have recognized that the potential risk associated with performing an alternative operation in place of an original operation can be reduced by performing a check based on the point in the program flow at which the alternative operation is attempted to be performed. Accordingly, the data processing apparatus also includes a check circuit configured to perform an address-dependent check based on a program counter address to determine whether the processing circuit is permitted to perform the alternative operation in place of the original operation. Performing the address-dependent check in dependence on the address of the instruction whose operation is replaced by the alternative operation means that the alternative operation is only permitted at certain points in the program. The address-dependent check is not particularly limited, and some examples of address-dependent checks are described below. Furthermore, the address-dependent check may include one or more separate checks depending on the program counter address, and in some examples, the address-dependent check fails unless each separate check passes. The address-dependent check to determine whether an alternative operation should be allowed in place of the original operation may appear unusual because it is a check based on the address in memory associated with the operation being replaced, and not on the actual alternative operation to be performed. However, the inventors have determined that this check can protect against certain exploits of the mechanism for executing instructions from instruction storage registers.

[0013] To perform an address-dependent check, the check circuitry may check the state of permission information associated with the program counter address. The permission information may indicate whether a particular access to memory, such as a read or write, should be permitted. The permission information may include, for example, permission flags, each having a state indicating that a particular permission is provided and a state indicating that a particular permission is not provided. The permission information may be provided in alternative ways. For example, some permission bit combinations may indicate that certain permissions are provided while other permissions are not provided, without certain permissions being associated with specific bits. The permission information may also be associated with a region of memory, such that certain permissions may be provided for a particular region of memory. The permissions may include execute permission and write permission, which may be used to check whether a given address is within an executable or writable region of memory, although additional permissions, such as read permission, may also be provided. Checking the state of permission information associated with the program counter address provides a simple technique for performing address-dependent checks. The permission information can be quickly accessed, and the check can be determined by checking the state of the permission information without having to perform further calculations or comparisons to determine whether the check is satisfied.

[0014] In one example, an address dependency check may involve determining whether a processing circuit is permitted to execute an instruction associated with a program counter address. If the instruction identified by the program counter address is not within an executable region of memory in which the processing circuit is permitted to execute instructions, this may indicate that something unexpected occurred during processing. For example, a branch may have been executed to update the program counter address to the address of a memory region containing data rather than instructions. Because instructions are not permitted to execute from memory with a program counter address outside the executable region, one way to prevent abuse of the mechanism for performing an alternative operation in place of the original operation may be to prevent instructions from being executed from an instruction storage register while the program counter address is outside the executable region. Thus, in one example, an address dependency check includes checking whether the program counter address is within an executable memory region in which the processing circuit is permitted to execute instructions. This may provide a simple determination that an alternative operation should not be permitted to proceed based on the program counter address.

[0015] Additionally or alternatively, the address-dependent check may include checking whether the program counter address is within a writable memory region to which the processing circuit is permitted to write data. If the instruction at the program counter address is within a region of memory that can be written to, the processing circuit may be able to write data to that address, causing the instruction at the program counter address to be modified. Debug code is an example of a particular technique that may be expected to replace instructions in memory (e.g., with a breakpoint instruction), and therefore write permission may be expected to be set during debugging for regions of memory that store instructions. Debug code may also be a particular scenario in which performing alternative operations based on instruction storage registers is expected to occur (described in more detail below). Thus, checking write permission may help distinguish debug scenarios in which execution from instruction storage registers is expected and may be permitted from normal code execution in which it may be desirable to prevent execution from instruction storage registers. If the processing circuit is prevented from modifying the instruction at the program counter address, the processing circuit may also be prevented from performing alternative operations based on instruction definition information in the instruction storage registers.

[0016] However, the permission information may be specified in several other ways. For example, a memory protection unit (MPU) may be associated with the processing circuit. The MPU may store entries that each identify a range of memory addresses and the permissions associated with the identified range of memory addresses. Alternatively, the permission information may be specified using a page table structure. A page table includes page table entries that correspond to specific ranges of addresses and provides translation between virtual addresses used by the processor and physical addresses in the memory system. Specifying the permission information using page table entries may be particularly efficient because page table entries are typically associated with regions of memory and instructions are often provided together in memory. Thus, an instruction corresponding to a preceding value taken by the program counter address in a previous cycle may correspond to the same page table entry as the program counter address, and therefore, the page table entry may already be cached in a translation lookaside buffer (TLB) due to access to an earlier instruction. Thus, the permission value is already cached in the processing circuit and can be quickly accessed for address-dependent checking. If the page table entry is not yet cached, the processing circuit may provide an existing page table walk mechanism for accessing the permission.

[0017] Permission information for a memory region that includes a program counter address may be specified directly in the page table entry that corresponds to that address. However, the number of available bits in the format for a page table entry may be limited, and therefore, if there are several different permissions that may or may not each be provided, there may not be enough bits in the permission field of the page table entry to directly represent all of the permissions. Thus, in some examples, at least some of the permission information may be indirectly specified by a page table entry. In this case, the permission information may be provided in a permission register, and the page table entry may specify a field identifier that identifies which field of the permission register specifies at least some of the permissions for that entry, and the referenced field of the permission register is encoded to indicate the permission type. In addition to allowing more permissions to be specified than can be directly encoded in a page table entry, this may allow a processing circuit to quickly update the permissions for many page table entries that all reference the same permission field by performing a single update to the permission field, without having to update each page table entry separately. Furthermore, if different processing environments have access to different permission registers but share a page table, this may allow the same page table entry to be used across different processing environments while providing different permissions for the different processing environments, since the different processing environments may have different instances of the permission register referenced by the page table entry, and the different instances of the permission register may be set to different permission encodings for the different processing environments.

[0018] A more flexible address-dependent check may be provided if the current exception level of the processing circuit is taken into account when the check is performed. This may be useful because lower-privilege software associated with a lower-privilege exception level may not be trusted to perform an alternative operation instead of the original operation, but higher-privilege software, which may have a higher level of trust, may be trusted to perform the alternative operation at the same program counter address. Rather than prohibiting or allowing the alternative operation for all exception levels, the address-dependent check may depend on the current exception level of the processing circuit. To provide additional flexibility when the address-dependent check includes checking permission information, the check circuit may be configured to select which permission information is used to perform the address-dependent check based on the current exception level of the processing circuit. For example, there may be an item of permission information for exception levels of privilege less than a threshold level and a separate item of permission information for exception levels of privilege greater than the threshold level.

[0019] The use of executable and write permissions is described above as an option for implementing address-dependent checks. However, executable and write permissions may be associated with other aspects of controlling access to memory, and thus the flexibility to modify executable and write privileges for a particular region of memory may be reduced. For example, a region may be implicitly designated as executable and / or writable even if software does not want to allow execution from registers for that region. Thus, in addition to, or instead of, performing a check based on executable and write permissions, an address-dependent check may include checking whether the permission information indicates that instruction execution permission from registers is provided for the program counter address. The check circuitry may be configured to determine that the processing circuitry is not authorized to perform an alternative operation in place of the original operation in response to determining that the permission information indicates that instruction execution permission from registers is not provided for the program counter address, even if the permission information indicates that execute permission or write permission is provided for the program counter address. Thus, a permission indicating whether instructions in the region can replace their operation with an alternative operation may be checked, independent of execute and write permissions. In some examples, the permission may be a new permission that is not used for other permission checks.

[0020] In some examples, an address may only be associated with instruction execution permission from a single register. However, as described above, it may be useful to provide different permissions for different exception levels. In one particular example, code executing at a least-privileged exception level may include applications that are not necessarily trusted, while higher exception levels may be used for trusted code, such as an operating system, a hypervisor, etc. Thus, it may be appropriate to implement different permissions for the least-privileged exception level and other exception levels. Accordingly, in some examples, the permission information may indicate whether instruction execution permission from a first register is provided and whether instruction execution permission from a second register is provided. In response to determining that the processing circuit is currently executing at the least-privileged exception level, the check circuit is configured to perform an address-dependent check depending on whether instruction execution permission from the first register is provided, and in response to determining that the processing circuit is currently executing at an exception level other than the least-privileged exception level, the check circuit is configured to perform an address-dependent check depending on whether instruction execution permission from the second register is provided. Thus, the address-dependent check may be more flexible because it can take into account the current exception level of the processing circuit and is independent of restrictions imposed on permissions other than instruction execution permission from a register.

[0021] An address dependency check need not include checking permissions associated with the program counter address. Alternatively, or additionally, an address dependency 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, the address dependency check may fail. This may be because the normal behavior of using an instruction storage register is to perform an alternative operation based on the instruction storage register instead of the original operation based on the instruction at the program counter address. However, if there is no valid instruction at the program counter address, an incorrect use of the mechanism may be identified. For example, an address dependency check may fail if the value stored at the program counter address corresponds to an undefined instruction encoding.

[0022] Furthermore, the address dependency check may include checking whether the instruction stored at the location in the memory system corresponding to the program counter address is an expected type of instruction. Use of the instruction storage register to execute instructions may be restricted to certain points in the program. These points may be identified based on permissions associated with the program counter address, but these points may 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 dependency check may fail. The expected type of instruction may include a broad category of instructions (e.g., the instruction may be an expected type of instruction if it does not write to memory) or may include a specific instruction, such as an individual opcode. The expected type of instruction may be dynamically adjustable based on some information stored in a register, for example, but in some examples, there are a limited number of expected type instructions predefined in the hardware of the processing unit such that use of the instruction storage register to execute instructions is restricted to only replacing the operation of certain limited instructions. The process of checking whether the instruction at the program counter address is an instruction of the expected type may involve loading the instruction from memory (optionally performing additional permission checks during the memory access) and comparing the fetched instruction with instructions of the expected type.

[0023] The types of instructions that may be considered to be expected type instructions are not particularly limited and may vary for different implementations. However, a particular example in which execution from a register is useful is during a software breakpoint. In a software breakpoint, a particular instruction in code may be replaced in memory by a breakpoint instruction. The breakpoint instruction generates an exception so that a debugger can analyze the processing circuitry for diagnostic purposes, such as debugging the code. In some examples, in scenarios where a breakpoint has not been established, execution from an instruction storage register may be considered unlikely to be used, and therefore, an instruction at a program counter address that is an instruction other than a breakpoint instruction may be a sign that the mechanism for execution from an instruction storage register is being used improperly. Therefore, in some examples, an expected type of instruction includes at least a breakpoint instruction. If an instruction execution from a register condition is met while the instruction at the program counter address is not a breakpoint instruction, this may indicate that the mechanism is being used improperly, and the address dependency check may fail.

[0024] The alternative operation is selectively executed by the processing circuit depending on the result of the address dependency check when the instruction execution from register condition is satisfied. The decision to execute the alternative operation based on the instruction storage register may be made by software at a particular point in the program and may require instructing the processing circuit's hardware to execute the alternative operation. Thus, in some examples, the processing circuit may be configured to determine whether the instruction execution from register condition is satisfied based on at least one enable value stored in at least one control register. Because software may be permitted to write to the control register, this provides a simple mechanism by which software can instruct hardware to execute the alternative operation, which may add little overhead to the processing circuit. Because control may be established over whether software with a particular level of privilege is permitted to update the control register, this may also be an efficient way to impose control over whether a particular portion of software should be allowed to satisfy the instruction execution from register condition. It will be appreciated that while one aspect of the instruction execution from register condition may include checking at least one enable value, the instruction execution from register condition may also include additional conditions, and thus setting an enable value may not necessarily cause the instruction execution from register condition to be satisfied. For example, the conditions for executing an instruction from a register may include checking that the processing circuitry is executing in a particular mode of operation.

[0025] While we discussed above how security can be improved by performing address-dependent checks when an instruction execution from a register condition is met, this can prevent malicious code from executing from an instruction storage register. Security can be further improved by controlling when the instruction execution from a register condition is allowed to be met. In particular, if the instruction execution from a register condition is indicated by an enable value in a control register, setting the enable value can be prohibited in certain cases to prevent scammers or malicious software from erroneously setting the instruction execution from the register condition. A particularly effective technique for controlling the setting of the enable value can be based on the execution environment of the software. For example, the software can be handled by a processing circuit at one of multiple exception levels. A lower-privilege exception level can have reduced register access rights compared to a higher-privilege exception level. A mechanism for switching between exception levels can include notifying the processing circuit of the exception and performing an exception return. At lower exception levels, less trusted software can be executed, while at higher exception levels, more trusted software, such as an operating system or hypervisor, can be executed. To prevent less trusted software from mistakenly setting an instruction execution condition from a register (and thereby potentially causing an alternate operation to be performed based on the register instead of the original operation), the processing circuitry may be configured to prohibit writing to at least one control register containing an enable value when executing at a privilege exception level lower than the threshold exception level. Thus, less privileged software may not be able to set the instruction execution condition from the register. Mechanisms for preventing particular exception levels from accessing particular registers may already be provided in some hardware implementations, and therefore the additional overhead associated with imposing the further requirement that writing to an enable value control register be prevented for particular exception levels may be low.This therefore provides an effective and efficient technique for reducing the ability of less trustworthy software to exploit the use of instruction storage registers.

[0026] In some examples, a single enable value may be provided that is permitted to be set by software executing at or above the threshold privilege level. However, in some architectures, there may be two or more privilege levels that are equal to or greater than the threshold privilege level. In these examples, there may be a disagreement between software that is both permitted to set the enable value regarding whether the instruction execution from register condition can be satisfied. For example, there may still be a possibility that lower-privilege software may be tricked into setting the instruction execution from register condition or may be malicious, or higher-privilege software may wish to disable execution from the instruction storage register for other reasons, and therefore the higher-privilege software may wish to prevent the lower-privilege software from setting the instruction execution from register condition. A further value may be provided in the further control register to allow the higher-privilege level to exercise control over the lower level when both are equal to or greater than the threshold privilege level. The processing circuit may determine whether the instruction execution from register condition is satisfied based on both the enable value and the further value. A processing circuit executing at the threshold exception level (or a lower privilege exception level) may not be permitted to write to the further control register. Thus, software at the threshold privilege level is permitted to write to the control register that stores the enable value, but is not permitted to write to the further control register that stores the further value. Thus, software executing at a privilege level higher than the threshold privilege level can override software at the threshold privilege level and prevent the instruction execution from register condition from being satisfied. Providing the further control register can increase the granularity of control that different privilege levels can have over whether the instruction execution from register condition is set.

[0027] While security may be provided by performing address-dependent checks and optionally restricting when instruction-execution-from-register conditions may be set, both of these restrictions may still allow free access to instruction storage registers. While this may not be an issue in some implementations, in other instances, allowing free access to instruction storage registers may be undesirable because instructions are executed from instruction storage registers only at specific points in the code, such as after specific settings have been defined for enable values ​​used to determine whether instruction-execution-from-register conditions are met and for permission information used to define whether address-dependent checks are met. For example, if malicious software were able to cause a malicious instruction to be written to an instruction storage register before an alternative operation was executed, this could allow the malicious instruction to be executed. Furthermore, because instruction storage registers may be private to higher-privilege software, it may be desirable to prevent lower-privilege software from reading instructions in the instruction storage registers. Thus, further security may be provided by providing a trap condition in which the access check circuitry is configured to cause the processing circuitry to trap to the higher-privilege exception level in response to detecting an attempt to read from or write to an instruction storage register by a processing circuitry executing at a given exception level. Software executing at the higher privilege exception level can then handle the attempted read or write appropriately. Whether a trap condition is met may depend on trap configuration information, so that implementations that support traps are not required to always trap (which may depend on control state information). Providing a trap condition further enhances the security associated with providing an instruction storage register and reduces the potential for exploitation by performing an alternate operation instead of the original operation.

[0028] As described above, the check circuit is configured to perform an address-dependency check based on the program counter address to determine whether the processing circuit is permitted to execute an alternative operation instead of the original operation. If the check fails, it is determined that the processing circuit is not permitted to execute the alternative operation. In some examples, the processing circuit may execute the alternative operation anyway, but is then prevented from proceeding further with processing. Values ​​generated as a result of the alternative or subsequent operation may not be committed, as if they had not been generated in the first place. However, in some examples, the processing circuit may be prevented from executing the alternative operation when the address-dependency check fails. This may reduce the opportunity for side-channel attacks associated with executing an alternative operation that should not be executed.

[0029] In some examples, the check circuitry may be configured to raise an exception in response to determining that an address dependency check has failed, which may trigger a transfer to a higher privileged exception level that can handle the exception. This may allow attack attempts and / or errors that lead to the address dependency check failing to be identified and addressed.

[0030] In some cases, when an instruction execution condition from a register is satisfied, an exception may occur during an attempt to execute the alternative operation. One reason for this may be that an address dependency check failed. Another reason may be that the address dependency check passed, but execution of the instruction stored in the instruction storage register may have caused a different failure, such as a memory access failure, or the instruction may have been an undefined instruction. It may be advantageous to provide some information identifying why the exception occurred so that an exception handler can identify and address the problem. Thus, in some examples, the processing circuit is configured to maintain exception identification information in an exception identification register. In response to a failure of the address dependency check, the processing circuit is configured to set the exception identification information to indicate a first exception cause. In response to detecting that the instruction execution condition from the register was satisfied and the address dependency check was successful, but a failure occurred due to the attempt to execute the alternative operation, the processing circuit is configured to set the exception identification information to indicate a second exception cause.

[0031] A specific example will now be described with reference to the figures.

[0032] 1 schematically illustrates an example of a data processing apparatus 2. The data processing apparatus has a processing pipeline 4 (e.g., an example of processing circuitry that may form part of a CPU (Central Processing Unit)). The processing circuitry 4 is for executing instructions defined in an instruction set architecture (ISA) to perform data processing operations represented by the instructions. The processing pipeline 4 includes several pipeline stages. In this example, the pipeline stages include a fetch stage 6 for fetching instructions from an instruction cache 8, a decode stage 10 for decoding the fetched program instructions to generate micro-operations (decoded instructions) that are processed by the remaining stages of the pipeline, an issue stage 12 for checking whether operands required for the micro-operation are available in a register file 14 and for issuing the micro-operation for execution once the operands required for a given micro-operation are available, an execute stage 16 for performing the data processing operation corresponding to the micro-operation by processing operands read from the register file 14 to generate a result value, and a writeback stage 18 for writing the results of the processing back to the register file 14. It will be understood that this is just one example of a possible pipeline architecture, and other systems may have additional stages or different configurations of stages. For example, an out-of-order processor may include a register renaming stage for mapping architectural registers specified by a program instruction or micro-operation to physical register specifiers that identify physical registers in register file 14. In some examples, there may be a one-to-one relationship between the ISA-defined program instructions decoded by decode stage 10 and the corresponding micro-operations processed by the execute stage.There may also be a one-to-many or many-to-one relationship between program instructions and micro-operations; for example, a single program instruction may be split into two or more micro-operations, or two or more program instructions may be fused together to be processed as a single micro-operation.

[0033] Execution stage 16 includes several processing units for performing different classes of processing operations. For example, the execution units may include a scalar arithmetic / logic unit (ALU) 20 for performing arithmetic or logical operations on scalar operands read from registers 14, a floating-point unit 22 for performing operations on floating-point values, a branch unit 24 for evaluating the results of branch operations and adjusting a program counter representing the current execution point accordingly, and a load / store unit 26 for performing load / store operations that access data in memory systems 8, 30, 32, 34.

[0034] A memory management unit (MMU) 28 is provided to control memory access permission checks and perform address translation between a virtual address specified by the load / store unit 26 based on the operands of a data access instruction and a physical address that identifies the storage location of the data within 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, whose page table entries define address translation mappings and may also specify access permissions that 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 for instruction fetches triggered by the fetch stage 6. As shown in FIG. 1 , the MMU 28 may be implemented using an instruction-side MMU (I-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 which case both MMUs may cache information from a shared set of page tables in their respective TLBs 29. It will be appreciated that in other examples, the same MMU and / or TLB may be shared between instruction side accesses from fetch stage 6 and data side accesses from load / store unit 26.

[0035] In this example, the memory system includes a level 1 data cache 30, a level 1 instruction cache 8, a shared level 2 cache 32, and a main system memory 34. It will be understood that this is only one example of a possible memory hierarchy and that other arrangements of caches may be provided. The particular types of processing units 20-26 shown in execution stage 16 are merely an example; other implementations may have different sets of processing units or may include multiple instances of the same type of processing unit so as to be able to handle multiple micro-operations of the same type in parallel. It will be understood that FIG. 1 is only a simplified representation of some components of a possible processor pipeline implementation and that a processor may include many other elements that are not illustrated for the sake of brevity.

[0036] The data processing apparatus includes a program counter that indicates the current point of execution. The program counter may be provided in a program counter register in register file 14, which may directly store the program counter address or a program counter address offset by a fixed amount. The program counter address may be used to identify the next instruction to be fetched by fetch stage 6 and may be incremented by an amount depending on the size of the instruction as it is fetched, in addition to being updated for taken branch instructions by any amount specified by the branch. In this way, the program counter address indicates the next instruction in the program and causes the processing circuitry to step through the program.

[0037] Register file 14 includes instruction storage registers configured to store instruction definition information, such as values ​​identifying opcodes and operands. When an instruction execution condition from the registers is satisfied, processing circuitry may execute an alternative operation based on the instruction storage registers instead of the original operation represented by the instruction stored at a location in memory corresponding to the program counter address (the original operation being the operation that would be executed corresponding to the program counter address if the instruction execution condition from the registers was not satisfied). For example, the instruction identified by the program counter address may not be fetched from memory, and instruction definition information may instead be provided from the instruction storage registers. In this case, execution in execution stage 16 is based on the instruction definition information rather than the information stored at the program counter address.

[0038] There may be no restrictions on where data written to an instruction storage register can be written from, and therefore, the instruction storage register could theoretically store instructions that could cause behavior that could compromise the data processing apparatus. Execution from an instruction storage register bypasses permission checks that may be performed on memory accesses when the fetch circuitry 6 reads instructions from the memory systems 8, 32, 34, which normally prevent the execution of instructions that are not authorized to be executed. Thus, the instruction storage register presents a route by which instructions can be executed when they should not be authorized. An adversary could, for example, store an instruction in an instruction storage register and trick the code into executing that instruction. Acceptable use of the instruction storage register to execute instructions may be provided only at specific points in the code where use of the instruction storage register is expected.

[0039] Therefore, the data processing apparatus also includes a check circuit 36. If it is determined that the instruction execution conditions from the register are satisfied, the check circuit performs an address-dependent check based on the program counter address to determine whether an alternative operation is permitted to be performed in place of the original operation. If the alternative operation is not permitted, the check circuit 36 ​​generates an exception, preventing the alternative operation from being executed.

[0040] The address dependent checks performed by check circuitry 36 may vary and may include several different checks. The address dependent checks may include one or more of the following: Check that the program counter address is within an executable region of memory. Substitution operations may typically be used to replace the action of an instruction. However, if the program counter address does not point to an executable region of memory, this may indicate that it is not an instruction, or at least not an instruction that can be executed. Therefore, this may indicate a point in processing where execution from a register may not be allowed. Check that the program counter address is within a writable area of ​​memory. If the memory instruction that is replaced by an instruction stored in an instruction storage register can be written to, this may indicate that it can be freely modified. Therefore, it may not be necessary to prevent this operation from being replaced by a register-based operation. Furthermore, code may be in a writable area of ​​memory when it is being debugged. Since debugging may be a situation in which execution from the instruction storage register is expected to occur, checking for write permission may be a way of indirectly checking whether the current situation is a debug situation in which execution from the instruction storage register is expected. Check that the program counter address is within a writable and executable memory region. This combination of the above two checks can more accurately identify the regions of code being debugged, since these are regions that can be provided with both execute and write permissions and where execution from the instruction storage registers can be expected. ●Checking that the program counter address is within a memory region explicitly allows execution from the instruction storage register instead of instructions within that region of memory for the current exception level, independent of execute and write permissions. • Check that the instruction in memory at the program counter address is an expected type of instruction, such as a breakpoint instruction that is expected to replace the operation of the memory instruction with an alternative operation.

[0041] If one or more of the above conditions are not met, it may indicate that there is an attempt to execute an instruction based on an instruction storage register at an unexpected point in the code.

[0042] Some of the above checks may be performed by referencing access permissions associated with the program counter address in memory. The permissions may be specified in page table entries in a page table stored in memory, which may be cached in a TLB 29 associated with the instruction-side MMU (I-MMU). The permissions may include a flag corresponding to each permission, or a combination of bits may be associated with a particular set of permissions. The permissions may include execute permission, write permission, and / or instruction execution permission from at least one register independent of execute permission and write permission. Instruction execution permission from different registers may be provided for different exception levels of the processing circuit. Additional permissions, such as a read permission indicating that a region of memory is readable, may also be provided. In some examples, the permissions may be specified directly in page table entries stored in memory. However, in other examples, the page table entries specify the permissions indirectly, as shown in FIG. 2.

[0043] FIG. 2 illustrates the use of a page table entry (translation table entry) 40 to indirectly specify permissions for a region of memory corresponding to a page table entry. The page table entry 40 is part of a page table stored in memory and may be cached in the TLB 29. A permission field 42 in the page table entry 40 provides a field identifier (the permission field 42 indicates the permission itself when the permission is specified directly). The field identifier identifies a field in a permission register 44 (permission indirect register) used to specify the permission. The permission may be specified in any manner within the identified field of the permission register 44, such as the encoding used to represent the permission directly within the page table entry. Providing the permission in the permission register 44 rather than in the page table entry 42 means that the permission for several regions of memory can be updated at once by writing updated values ​​to fields in the permission register referenced by several page table entries. Furthermore, there may be more encoding space available in the identified field of the register 44 than in the permission field of the page table entry 40, allowing a greater number of different permissions to be provided. Furthermore, if different processing environments access the same memory but different registers (e.g., if they are different cores of a processing unit), the same page table entry 40 may reference fields in different permission registers, allowing different permissions to be specified by the same page table entry. Each of the write, execute, and instruction execution permissions from each register may be provided in the page table entry as a direct permission or in a field of a permission register.

[0044] Executing instructions from an instruction storage register instead of instructions in memory may be used in several situations. For example, during debugging, it may be desirable to run a slightly modified version of a program to enable performance comparison against another thread executing the original program. For this purpose, it may be useful to run the modified program by executing the modified instructions from a register and leaving the original program in memory for the comparison thread to execute. Another example is improving the use of software breakpoints, which may be used to debug code. With software breakpoints, specific instructions in a portion of software stored in memory are replaced with breakpoint instructions, which, when executed, cause an exception to be generated. When the breakpoint instruction causes the exception, higher-privilege code can take appropriate debugging action. However, with instructions in the code replaced with breakpoint instructions, the software is no longer complete and cannot be easily executed from memory; otherwise, debugging would be inaccurate because instructions are missing. One technique for dealing with missing instructions is to temporarily replace the breakpoint instruction in memory with the original instruction, execute the original instruction, and then replace it again with the breakpoint instruction. This procedure may include the following: 1. The user, via the debugger, requests a breakpoint at a given program counter address (PC). 2. The debugger replaces the instruction at the given program counter address with a breakpoint (BRK) instruction. 3. The original instructions are saved by the debugger into debugger memory. 4. Upon receiving a software breakpoint exception, the processing circuitry records the PC in a register and the debugger takes appropriate debug action. 5. To return to the original thread, 5.1. All other running threads that may share the breakpoint are suspended. 5.2 The debugger replaces the BRK at the given PC in memory with the original instruction stored in the debugger memory. 5.3 The debugger sets an enable bit to enable software stepping. 5.4 The debugger executes an exception return (ERET) instruction. 6. The processing circuitry executes the original instruction in the PC, then takes a software step exception and returns control to the debugger. 7. The debugger replaces the original instruction with a BRK, resumes other threads if necessary, and then executes another ERET.

[0045] This procedure is relatively inefficient. First, if multiple threads are executing the process being debugged, the other threads must be paused to avoid missing the BRK instruction while the BRK instruction is temporarily replaced in memory with the original instruction. This delays other threads of execution. Furthermore, this procedure requires two writes to memory (one to write the original instruction to memory, and one to then write the BRK to memory again). Writing to memory can involve certain overhead, especially if coherency needs to be enforced in addition to the usual permission checks, which may also involve sending coherency messages to invalidate cached copies of the instructions.

[0046] An instruction storage register can be used to alleviate these problems. Rather than replacing the BRK in memory, the original instruction can instead be written to the instruction storage register (e.g., from debugger memory). A software step can then include executing the original instruction from the instruction storage register instead of the operation defined by the BRK instruction remaining in memory. This eliminates the need to suspend other threads and may also eliminate two writes to memory.

[0047] However, as mentioned above, execution from a register presents a possible route for instructions to be executed when they should not be, and therefore, checking circuitry may perform address-dependent checks to ensure that the program counter address is at a point in the code where execution from an instruction storage register is expected. For example, if 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 a BRK instruction.

[0048] Further details regarding the execution of instructions from instruction storage registers are described below with reference to exception levels (privilege levels). FIG. 3 provides an overview of the use of exception levels in a processing device. FIG. 3 schematically illustrates an example of a process that may be performed by a data processing device. A hypervisor 50 may manage several virtual machines (VMs, also known as guest operating systems or guest OSs) 52. Each VM 52 may manage one or more applications 54. For example, the hypervisor 50 may control which regions of 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 resources between the respective virtual machines 52). Similarly, each VM 52 may control which regions of address space are allocated to each application 54 running under that VM 52 and control switching between applications as needed.

[0049] 3, each process is associated with a given privilege level EL0, EL1, EL2, or EL3. In this example, higher-numbered privilege levels are more privileged than lower-numbered privilege levels, although in other examples the numbering may be reversed. In this example, application 54 runs at privilege level EL0, VM 52 runs at privilege level EL1, and hypervisor 50 runs at privilege level EL2. Typically, processes running at higher privilege levels have rights that are not available to processes running at lower privilege levels.

[0050] As shown in FIG. 3 , the hypervisor 50, VM 52, and device 54 may operate in a normal domain. Furthermore, the device may support a secure domain separated from the normal domain so that processes running in the normal domain cannot access data or instructions associated with the secure domain. Thus, there may also be processes running in the secure domain, such as a secure operating system (OS) 56 and a trusted application 58 running in the secure domain under the control of the secure OS 56. The secure OS 56 and the trusted application 58 run at privilege levels S-EL1 and S-EL0, respectively. To manage transitions between the normal and secure domains, a secure monitor process 60 is also provided at privilege level EL3. The secure monitor process 60 may, for example, manage which regions of the address space are associated with the secure or non-secure domain, and some protection hardware is provided to prevent non-secure processes in the normal domain from accessing data or instructions in the secure domain. One example of a technique for separating normal and secure domains is the Trustzone® technique offered by ARM® Limited of Cambridge, UK, although other examples may also be used. Providing a secure domain as shown in FIG. 3 is optional, and other embodiments may not support, for example, secure monitor 60, secure OS 56, and trusted applications 58.

[0051] Each of the processes 50, 52, 54, 56, 58, and 60 uses a virtual address (VA) to identify a location to be accessed in a data store, such as memory. The VA is translated into a physical address (PA), which directly identifies the corresponding storage location. In the case of an application 54 or virtual machine 52, the VA is first translated into an intermediate physical address (IPA), and then the IPA is translated into a PA. By providing two levels of address translation, for example, the virtual machine 52 may control page tables for the VA-to-IPA translation to control which portion of the address space is allocated to each application 54, and the hypervisor 50 may control page tables for the IPA-to-PA translation to control which portion of the address space is allocated to each virtual machine 52. For other processes, the VA is directly translated into a PA, for example, using the hypervisor 50 (in the normal domain) or secure OS 56 (in the secure domain) to control page tables that control the portion of the address space each process can access.

[0052] Further details will also refer to several registers, as shown in FIG. 4, that may be provided in register file 14. Registers are provided in the format NAME_ELy, where ELy indicates the lowest privileged exception level that can access a given register. Accesses below ELy may raise an exception to be handled by higher-privilege software. For example, writing to MDSCR_EL1 by software running at EL0 may be prohibited. The format ESR_ELx indicates banked registers, i.e., multiple copies of the ESR register, named ESR_EL1, ESR_EL2, and ESR_EL3, for storing exception information for exceptions made to EL1, EL2, and EL3, respectively. Register fields are referenced in the format NAME_ELy.FIELD and are shown within the registers in FIG. 4. The particular layout of information within the registers shown in the example of FIG. 4 is merely an example; other examples may combine register fields in other ways (e.g., with different assignments of which fields are in the same register or in different registers). Furthermore, some of the register control information may be omitted from particular examples of the present technique. Certain descriptions refer to the value in a register being "set" or set to "1." It will be understood that there are different equivalent values ​​that can be stored in a register field to indicate a set state, and that 1 (0b1) is merely an example. The following registers and register fields are shown in FIG. 4:

[0053] MDSCR_EL1 is a control register for debug. MDSCR_EL1.EnSTEPOP is a register field that stores an enable value that can be set by EL1 and higher privilege exception levels. Software running at EL1 can set the enable value to indicate that it wants the instruction execution condition from the register to be met for the next value of the program counter address corresponding to the instruction after the enable value is set.

[0054] MDSTEPOP_EL1 is an instruction storage register that can be written by EL1 and higher privileged exception levels. Access to MDSTEPOP_EL1 can be further controlled with trap conditions shown in Figure 7. Instructions can be executed from MDSTEPOP_EL1 once the instruction execution from register conditions are met and address dependency checks pass.

[0055] ESR_ELx is a set of banked exception syndrome registers ESR_EL1, ESR_EL2, ESR_EL3 that store information about exceptions taken for the corresponding exception level. For example, ESR_EL1 stores information about exceptions taken for EL1. Field ESR_ELx.STEPOP may be used to indicate that an exception occurred due to execution of the instruction stored in MDSTEPOP_EL1. Field ESR_ELx.EC may be used to indicate that an exception was made to a higher exception level than the exception level at which it was generated. Field ESR_ELx.ISS.FAILED may be used to indicate that the generated exception is a software step failure exception due to a failed address-dependent check. Field ESR_ELx.ISS.IFSC may be used to indicate that the software step failure exception is due to the instruction at the PC address not being the expected (e.g., BRK) instruction.

[0056] MDCR_EL2 is a control register that provides configuration information for debug and can be set by EL2 or EL3. Field MDCR_EL2.EnSTEPOP is a field that can store an additional value that can be used to determine if the instruction execution from register condition is met. MDCR_EL2.EnSTEPOP can be set by more privileged code than MDCR_EL1.EnSTEPOP and can therefore be used to override EL1 when EL1 wants to set the instruction execution from register condition. Field MDCR_EL2.TDA provides control over access to debug registers in EL1 and, if set, indicates that accesses to certain debug registers in EL1, including the instruction storage register MDSTEPOP_EL1, will trap to EL2 (unless there is a higher priority exception pending).

[0057] HDFGRTR2_EL2 is a control register that can be set by EL2 or EL3 to control access to the MDSTEPOP_EL1 register. Register field HDFGRTR2_EL2.nMDSTEPOP_EL1 can be set by EL2 to control whether software at EL1 is allowed to directly read the value stored in MDSTEPOP_EL1, or whether an attempted read should trap to a higher exception level. Register field HDFGWTR2_EL2.nMDSTEPOP_EL1 can be set by EL2 to control whether software at EL1 is allowed to directly write to MDSTEPOP_EL1, or whether an attempted write should trap to a higher exception level. Thus, using these registers EL2 (e.g., a hypervisor) can impose control over how EL1 (e.g., an operating system) is allowed to access instruction storage registers.

[0058] MDCR_EL3 is a control register that provides configuration information for debugging and can be set by EL3. Field MDCR_EL3.EnSTEPOP can store an additional value that can be used to determine whether an instruction execution from register condition is met. If MDCR_EL3.EnSTEPOP is 0, an instruction execution from register condition can be prevented even if other enable bits indicate that the condition should be met, thus allowing EL3 to override lower exception levels. Because MDCR_EL3.EnSTEPOP cannot be set by code executing at EL1 or EL2, it can be used to override the control provided by code executing at EL1 and EL2 based on MDSCR_EL1.EnSTEPOP and MDCR_EL2.EnSTEPOP. Field MDCR_EL3.TDA provides control over access to debug registers in EL0, EL1, and EL2, and, when set, indicates that accesses to certain debug registers in EL0-EL2, including the instruction storage register MDSTEPOP_EL1, will trap to EL3.

[0059] HCR_EL2 is a hypervisor (EL2) configuration register that provides control for virtualization. HCR_EL2.E2H indicates whether a configuration running a host operating system (a type 2 hypervisor) is supported at EL2, which can affect exception handling at lower levels such as EL0. (If a type 2 hypervisor is supported, some exceptions that would otherwise be handled at EL1 may be handled at EL2 instead.) When HCR_EL2.E2H is set to 1, facilities for supporting the host operating system at EL2 are enabled. HCR_EL2.TGE is an example of trap control and indicates whether to trap general exceptions to EL2. When HCR_EL2.TGE = 1, exceptions that would normally be routed from EL0 to EL1 are instead routed to EL2, effectively disabling EL1 from being available for exception taking. If HCR_EL2.E2H is also enabled (HCR_EL2.{E2H,TGE} = {1,1}), EL1 is completely disabled and EL0 is run by the host operating system.

[0060] EDHSR holds syndrome information for debug events. EDHSR.STEPOP is a register field that can be set when execution of the instruction in the MDSTEPOP_EL1 register causes an exception and enters debug state.

[0061] Although some of the following description refers to the use of the present technique to implement software breakpoints, it will be understood that the concepts described are not so limited: the concepts may be extended to the use of instruction storage registers for other operations, and specific references are merely used to describe at least one way of actually implementing the present technique.

[0062] FIG. 5 illustrates a procedure for executing an instruction from an instruction storage register instead of an instruction stored in memory. In step 500, processing is at a point in the program flow where the next instruction to be fetched is indicated by the program counter address. In step 502, it is determined whether an instruction-from-register execution condition is met, which indicates to the processing circuitry that, if permitted, the next operation should be performed based on information stored in the instruction storage register instead of the instruction stored at the program counter address. The determination of whether the instruction-from-register execution condition is met may be made according to FIG. 6. While FIG. 6 illustrates several conditions for determining whether the instruction-from-register execution condition is met, it will be understood that one or more of the conditions may not be provided in all implementations of the present technique.

[0063] In step 600 of Figure 6, it is determined whether the enable value is set, i.e., whether MDSCR_EL1.EnSTEPOP=1. If not, then software at EL1 or above has not set the enable bit, indicating that it wants to execute the next instruction from a register. Therefore, in this case, the instruction execution condition from a register is not met (step 616).

[0064] In step 602 of Figure 6, it is determined whether EL3 is implemented. If so, then in step 604 it is determined whether the enable bit settable only by EL3 is set by determining whether MDCR_EL3.EnSTEPOP=1. If not, then EL3 is preventing instructions from executing from the instruction storage register, and therefore the instruction execution from register condition is not met. If EL3 is not implemented or does not override EL1, then in step 606 it is determined whether EL2 is implemented.

[0065] If EL2 is implemented and not disabled (step 608), then in step 610 it is determined whether the processing circuit is currently executing at EL0 or EL1 (i.e., below EL2). If not, then there is no need to perform a check to see if EL2 has overridden the instruction execution condition from a register, and the condition is considered met. However, if processing is at EL0 or EL1, then in step 612 the process optionally determines whether the register field HCR_EL2.{E2H.TGE}={1,1}. If so, then EL1 is overridden, and a separate check to determine whether EL2 has overridden the instruction execution condition from a register may not be necessary. Otherwise, in step 614 it is determined whether EL2 has overridden the execution of an alternative operation from an instruction storage register by checking the state of MDCR_EL2.EnSTEPOP. If not, then the instruction execution condition from a register is met (step 618). However, if EL2 has overridden the instruction execution condition from a register, then the condition is not met (step 616).

[0066] Thus, even though EL1 requires that an instruction execution condition from a register be met by setting an enable bit, it can be seen that this is overridden by both EL2 and EL3 (depending on the implementation). For example, if EL2 or EL3 is not provided in a particular implementation, it will be understood that one or more of the steps shown in Figure 6 can be omitted. 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 shown.

[0067] 5, if it is determined that the instruction execution condition from the register is not met, then the processing circuitry does not perform an alternative operation in place of the original operation in step 504. The processing circuitry may continue processing normally, for example, by fetching an instruction from the memory system at the program counter address.

[0068] However, if the instruction execution condition from the register is met, then in step 506 check circuitry 36 performs an address dependency check. The address dependency check may include one or more of the checks shown in Figures 8-12, as described below. It will be appreciated that the address dependency check may include further checks whose results depend on the program counter address.

[0069] 8, the address dependency check may be a permission check based on a permission associated with the program counter address. In step 800, it may be determined whether execute permission is provided for the program counter address, allowing the instruction stored at the program counter address to be executed by the processing circuit. If so, that aspect of the address dependency check may be satisfied, and the result of the overall address dependency check depends on whether other checks failed (step 804). If execute permission is not provided, the address dependency check fails (step 802).

[0070] 9, the address-dependent check may be a permission check based on a permission associated with the program counter address. In step 900, it may be determined whether 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 circuit. The results of steps 902 and 904 are the same as steps 802 and 804, respectively.

[0071] As shown in FIG. 10 , the address-dependent check may be a permission check based on a permission associated with a program counter address. In step 1000, instruction execution permission from a dedicated register may be provided for the program counter address, independent of other permissions, including write permission and execute permission, to determine whether instructions in the memory region indicated by the program counter address are allowed to be replaced by alternative operations performed based on the instruction storage register. If the check based on instruction execution permission from the register fails in step 1002, a check based on execute permission and write permission is performed, and even if it passes, the address-dependent check fails. If the check based on instruction execution permission from the register passes in step 1004, whether the address-dependent check passes overall depends on the results of the other checks in the address-dependent check.

[0072] While the check in FIG. 10 may be performed based on instruction execution permission from a single register, the check may also be performed as shown in FIG. 11. FIG. 11 illustrates a process for selecting instruction execution permission from a register based on the current exception level. If the current exception level is the lowest privileged exception level EL0, the instruction execution permission value from a first register may be selected to be used in the check in FIG. 10. However, if the processing circuit is executing at a higher exception level EL1-EL3, the instruction execution permission value from a second register may be selected. This allows different permissions to be set for the lowest exception level (which may be the lowest trusted exception level) and other exception levels. Thus, in some cases, execution of instructions from memory may be prevented only for the lowest exception level.

[0073] 12, the address dependency check may be based on the type of instruction stored at the program counter address. If the instruction at the PC address is an expected type of instruction, such as a breakpoint instruction, the check may pass (step 1204). If not (step 1202), the address dependency check may fail.

[0074] Returning again to FIG. 5 , if the address dependency check fails, in step 510, the check circuit 36 ​​may signal an exception to the processing circuit, which may prevent the execution of an alternative operation instead of the original operation. A failure of the address dependency check when executing a software step operation may be signaled using a software step failure exception. The exception level at which the software step failure exception is taken is the exception level indicated by ELx in the following references. A value may be set in register field ESR_ELx.EC to indicate whether the exception is taken for an EL higher than the current EL or for the current EL. Field ESR_ELx.ISS.FAILED may be set to indicate that the generated exception is a software step failure exception due to a failed address dependency check. If the check is as shown in FIG. 12 , checking whether the PC address has an instruction of the expected type, field ESR_ELx.ISS.IFSC may be set to indicate that the software step failure exception is due to the instruction at the PC address not being the expected (e.g., BRK) instruction. If ESR_ELx.ISS.FAILED is set but ESR_ELx.ISS.IFSC is not set, it can be determined that the address dependent check failure was due to a permission (execute, write, or execute instruction from register) failure.

[0075] However, if the address dependency check passes, then in step 512, check circuit 36 ​​enables the processing circuit to execute an alternative operation based on the instruction storage register to be executed instead of the original operation executed based on the instruction stored at the location corresponding to the PC address. In the case of a breakpoint instruction, this enables the replaced instruction to be executed from the instruction storage register instead of the breakpoint instruction as it remains stored in the code in memory. If the instruction executed from the instruction storage register reads from or writes to the program counter, this is the current program counter (associated with the BRK instruction in memory), since the program counter has not been modified to enable the execution of the alternative operation. If instruction execution from MDSTEPOP_EL1 completes without generating an exception, the current program counter value is incremented by the size of the instruction, and code execution proceeds. If an exception is generated during execution of an instruction from the instruction storage register, the return address of the exception may be based on the current PC value. Following execution of the operation represented by the instruction in the instruction storage register, a debug exception is triggered (EDHSR.STEPOP is set to indicate the cause of the debug exception). A debug exception triggers a transition to debug mode, in which further execution of the program code being debugged is halted and instead instructions are executed from debug memory, which may be either a dedicated storage unit or a designated area within memory system 30, 32, 34. This allows the debugger to execute debug instructions that are not part of the program code being debugged, for example to examine register contents or data in memory or to read performance counter values. Once debug operations performed in 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 may then resume at the next address following the program counter value from the register at which the alternative operation was executed.

[0076] The use of the instruction memory register MDSTEPOP_EL1 to implement software breakpoints may proceed according to the following exemplary description (this is merely one exemplary example of a software use case, and it will be understood that the operations shown in the pseudocode are not required features of the hardware device).

[0077] 0 BRK at EL0 10 <Software breakpoint exception handler starts at EL1> 20 <Enable software stepping> 30 MSR MDSCR_EL1,x0 / / Write 0b1 to MDSCR_EL1.EnSTEPOP 40 MSR MDSTEPOP_EL1,x1 / / Write the replaced instruction to the instruction memory register Instruction memory register 50 ERET / / Return to EL0 60 <Execute from MDSTEPOP_EL1> 70 <Software step exception for EL1>

[0078] Address dependency checking may be performed by the hardware when it is determined to execute from MDSTEPOP_EL1.

[0079] In some examples, the instruction memory register may have restricted access. For example, the register may be accessible at EL1 and above, but not at EL0. An exemplary instruction memory register is MDSTEPOP_EL1 as shown in FIG. 4. Access to the register MDSTEPOP_EL1 may be controlled as shown in FIG. 7, which shows several checks for determining whether an attempted access to the instruction memory register should cause an exception, and if so, at which exception level the exception should be handled, although it will be understood that one or more of the steps shown in FIG. 7 may be excluded.

[0080] In step 700, an attempt to read from or write to register MDSTEPOP_EL1 is detected. In step 702, it is determined whether the current exception level is EL0. If the current exception level is EL0 and there is an attempt to access an EL1 instruction storage register, this is not allowed and in step 704 there is a trap to a higher exception level to handle the security violation. If the current EL is not EL0, in step 704 it is determined whether the current EL is EL1 or EL2 (i.e., not EL3). If the EL is EL3, in step 708 there is no trap to a higher EL because there may not be a higher exception level.

[0081] If EL is EL1 or EL2, and either (step 710) MDCR_EL3.TDA=1 or (step 712) MDCR_EL3.EnSTEPOP=0 (i.e., EL3 prevents the instruction execution from register condition from being met, disabling execution from the instruction storage register), then the attempted access traps to EL3 in step 714. If neither of these are true and the current exception level is EL2 (step 716), there is no trap to a higher EL.

[0082] If the current exception level is EL1, then in step 718 it is determined whether MDCR_EL2.TDA=1, and if this is true, the attempted access traps to EL2. Otherwise, if the attempted access is a read, it is determined whether HDFGRTR2_EL2.nMDSTEPOP_EL1=0 (a control bit settable by EL2 that controls reads from MDSTEPOP_EL1 at EL1), and if the attempted access is a write, it is determined whether HDFGWTR2_EL2.nMDSTEPOP_EL1=0 (a control bit settable by EL2 that controls writes to MDSTEPOP_EL1 at EL1). If either of these is true, the access is blocked by EL2, and in step 724 the attempted access is trapped to EL2.

[0083] Thus, it can be seen that both EL2 and EL3 can independently control whether or not to allow access from EL1 to the instruction storage register MDSTEPOP_EL1. Furthermore, EL2 can be read and written independently of each other, further increasing flexibility in controlling the instruction storage register. It will be understood that not all of the steps shown in FIG. 7 are required, and the technique can be implemented without one or more of the trap conditions being implemented. For example, in some examples, EL3 may not be implemented, and therefore, there may be no EL3 step. Similarly, some implementations may support the option to disable the use of EL2. In that case, the test in step 716 would be, “The current EL is EL1, and is EL2 enabled?” Thus, if EL2 is not implemented or is currently disabled, the method would proceed from step 716 to step 708, and steps 718-724 would be omitted. It will also be understood that the specific order of steps in the above flowchart is merely exemplary, and that the same results can be achieved with a different order of steps or by performing some steps in parallel.

[0084] When executing an instruction from an instruction storage register, an exception may be generated indicating that there was a fault during execution. For example, if the instruction in MDSTEPOP_EL1 is an undefined instruction, or if it is a load / store instruction that attempts to access an address that fails an MMU check, an exception may be generated indicating that execution of that instruction caused a fault. In this case, the fault is due to the instruction in the instruction storage register, not the instruction at the PC address. Therefore, exception handling software may not be able to identify the fault if it uses only the PC address to find the instruction. To identify that the exception was caused by an instruction in a register, the field ESR_ELx.STEPOP may be set in the ESR register to indicate that the exception was generated from executing the instruction in the MDSTEPOP_EL1 register.

[0085] There are (at least) two independent reasons why an exception may occur when attempting to execute an instruction from a register due to the instruction execution condition from the register being met. First, the address dependency check may fail. Second, the address dependency check may pass, but the execution of the instruction stored in the instruction storage register may cause a fault. These two cases may be distinguished using the registers mentioned above. ESR_ELx.EC may indicate the primary exception cause (e.g., undefined instruction, data abort (fault), or software step exception), where ELx indicates the exception level at which the exception is taken. If the address dependency check fails, the register field ESR_ELx.ISS.FAILED may be set. If the address dependency check failure is due to the instruction at the program counter address not being an instruction of the expected type, ESR_ELx.ISS.IFSC may also be set. If the execution of the instruction in the instruction storage register fails, ESR_ELx.STEPOP may be set, but ESR_ELx.ISS.FAILED remains unset. Thus, by checking the state of ESR_ELx.EC, ESR_ELx.ISS.FAILED, and ESR_ELx.ISS.STEPOP, software handling the exception can determine whether the exception was generated due to a failure of an address dependency check, due to execution of an instruction in an instruction storage register, or for some other reason. Some of the fields in ESR_ELx may also have other purposes when used for other types of exceptions (e.g., ESR_ELx.IFSC may be used for a different purpose during a data abort compared to its use described above for a software step exception).

[0086] Register field EDHSR.STEPOP may also be set to indicate that debug state was entered by execution of the instruction in the MDSTEPOP_EL1 register.

[0087] FIG. 13 illustrates a simulator implementation that may be used. While the above embodiments implement the invention in terms of apparatus and methods for operating specific processing hardware that supports the techniques, it is also possible to provide an instruction execution environment according to the embodiments described herein implemented 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. Various simulator computer programs include emulators, virtual machines, models, and binary translators, including dynamic binary translators. Typically, a simulator implementation may run on a host processor 1306, optionally running a host operating system 1304 and supporting a simulator program 1302. In some arrangements, there may be multiple layers of simulation between the hardware and the provided instruction execution environment, and / or there may be multiple different instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations that run at reasonable speeds, but such an approach may be justified in certain situations, such as when it is desirable to execute code native to another processor for compatibility or reuse reasons. For example, a simulator implementation may provide an instruction execution environment with additional functionality not supported by the host processor hardware, or may provide an instruction execution environment typically associated with a different hardware architecture. An overview of simulation is given in "Some Efficient Architecture Simulation Techniques," Robert Bedichek, Winter 1990 USENIX Conference, pp. 53-63.

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

[0089] The simulator program 1302, which may be stored on a computer-readable storage medium (which may be a non-transitory medium), provides a program interface (an instruction execution environment) to the target code 1300 (which may include applications, an operating system, and a hypervisor) that is the same as the interface of the hardware architecture being modeled 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, thereby enabling a host computer 1306 that does not actually have the hardware features of the device 2 described above to emulate those features.

[0090] For example, simulator program 1302 may provide processing program logic 1308 that simulates characteristics of processing circuit 2 and check program logic 1310 that simulates characteristics of check circuit 36. Simulator program 1302 may provide a simulated address space 1312, where storage is actually within a physical memory system provided by host hardware 1306, and simulator program 1302 maps addresses in the simulated address space to addresses in the physical memory system, so that target code 1300 may reference addresses in the simulated address space. Simulator program 1302 may also provide simulated registers 1314 that can be treated as registers by target code 1300, whereby storage may again be provided within the physical memory system of host hardware 1306.

[0091] The concepts described herein may be embodied in computer-readable code for the fabrication of devices embodying the described concepts. For example, the computer-readable code may be used in one or more stages of a semiconductor design and fabrication process, including Electronic Design Automation (EDA) stages, to fabricate integrated circuits comprising devices embodying the concepts. Such computer-readable code may additionally or alternatively enable the definition, modeling, simulation, verification, and / or testing of devices embodying the concepts described herein.

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

[0093] Additionally or alternatively, the computer-readable code may define a low-level description of integrated circuit components embodying the concepts described herein, such as one or more netlists or integrated circuit layout definitions, including representations such as GDSII. One or more netlists or other computer-readable representations of the integrated circuit components may be generated by applying one or more logic synthesis processes to the RTL representations to generate definitions used to fabricate devices embodying the invention. Alternatively or additionally, the one or more logic synthesis processes may generate a bitstream from the computer-readable code that is loaded into a Field Programmable Gate Array (FPGA) to configure the FPGA to embody the described concepts. The FPGA may be deployed for concept verification and testing purposes prior to fabrication in an integrated circuit, or the FPGA may be deployed directly into a product.

[0094] The computer readable code may include a mixture of code representations for fabricating a device, including, for example, a mixture of one or more of an RTL representation, a netlist representation, or another computer readable definition used in a semiconductor design and fabrication process to fabricate a device embodying the invention. Alternatively or additionally, a concept may be defined in a combination of a computer readable definition used in a semiconductor design and fabrication process to fabricate a device and computer readable code that defines instructions to be executed by the defined device once fabricated.

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

[0096] In this application, the term "configured to" is used to mean that elements of a device have a configuration that allows them to perform a defined operation. In this context, "configuration" refers to the arrangement or interconnection of hardware or software. For example, a device may have dedicated hardware that provides the defined operation, or a processor or other processing device may be programmed to perform the function. "Configured to" does not imply that the device elements need to be modified in any way to provide the defined operation.

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

Claims

1. 1. A data processing device, comprising: a processing circuit configured to perform data processing operations in response to instructions stored in a memory system, wherein in response to determining that an instruction execution condition from a register is satisfied at a point in a program flow corresponding to a program counter address, the processing circuit is configured to determine, based on instruction definition information associated with an instruction storage register, an alternative operation to be performed in place of an original operation represented by an instruction stored at a location in the memory system corresponding to the program counter address; and a check circuit configured to perform an address dependency check based on the program counter address to determine whether the processing circuitry is authorized to perform the alternative operation instead of the original operation.

2. the address dependency check includes checking the state of permission information associated with the program counter address; 2. The data processing apparatus of claim 1, comprising:

3. the address dependency check includes checking whether the program counter address is within an executable memory region in which the processing circuitry is permitted to execute instructions; 3. The data processing apparatus of claim 2, comprising:

4. the address dependency check includes checking whether the program counter address is within a writable memory region to which the processing circuitry is permitted to write data; 4. A data processing apparatus according to claim 2 or 3, comprising:

5. 5. A data processing apparatus according to claim 2, wherein the permission information is specified directly or indirectly in a page table entry corresponding to the program counter address.

6. 6. A data processing apparatus as claimed in claim 5, wherein the page table entry corresponding to the program counter address indirectly specifies at least part of the permission information used to perform the address dependency check by identifying a register location for storing the permission information.

7. 7. A data processing apparatus as claimed in claim 4, wherein the check circuitry is configured to select which permission information is used to perform the address dependency check based on a current exception level of the processing circuitry.

8. the address dependency check includes checking whether the permission information indicates that instruction execution permission from a register is provided for the program counter address; the checking circuitry is configured to determine that the processing circuitry is not authorized to perform the alternative operation in place of the original operation in response to determining that the permission information indicates that the program counter address is not provided with instruction execution permission from the register, even if the permission information indicates that execution permission or write permission is provided for the program counter address. A data processing device according to any one of claims 4 to 7.

9. the permission information indicates whether instruction execution permission is provided from a first register and whether instruction execution permission is provided from a second register; In response to determining that the processing circuitry is currently executing at a least privileged exception level, the check circuitry is configured to perform the address dependency check depending on whether instruction execution permission is provided from the first register; 9. A data processing apparatus as claimed in claim 8, wherein in response to determining that the processing circuitry is currently executing at an exception level other than the least privileged exception level, the check circuitry is configured to perform the address dependency check depending on whether instruction execution permission is provided from the second register.

10. the address dependency check includes checking whether the instruction stored at the location in the memory system corresponding to the program counter address is an instruction of an expected type; 10. A data processing apparatus according to any one of claims 1 to 9, comprising:

11. 11. A data processing apparatus as claimed in claim 10, wherein said expected type of instruction includes at least a breakpoint instruction.

12. the processing circuitry is configured to determine whether an instruction execution condition from the register is satisfied based on at least one enable value stored in at least one control register; 12. A data processing device according to any one of claims 1 to 11.

13. the processing circuitry is configured to inhibit writing to the at least one control register when executing at a privileged exception level lower than a threshold exception level.

13. A data processing apparatus according to claim 12.

14. 14. A data processing apparatus as claimed in claim 13, wherein the processing circuitry is also configured to determine whether an instruction execution condition from said register is satisfied based on a further value stored in a further control register, and wherein processing circuitry executing below said threshold exception level is not permitted to write to said further control register.

15. In response to determining that a trap condition is met, the access check circuitry is configured to cause the processing circuitry to trap to a higher 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 an instruction storage register.

15. A data processing device according to any one of claims 1 to 14.

16. 16. A data processing apparatus as claimed in any preceding claim, wherein said processing circuitry is prevented from performing said alternative operation in place of said original operation in response to said checking circuitry determining that said address dependency check has failed.

17. 17. A data processing apparatus as claimed in any preceding claim, wherein the check circuitry is configured to generate an exception in response to determining that the address dependency check has failed.

18. the processing circuitry is configured to maintain exception identification information in an exception identification register; In response to the address dependency check failing, the processing circuitry is configured to set the exception identification information to indicate a first exception cause; 18. A data processing apparatus as claimed in any one of claims 1 to 17, wherein in response to detecting that an instruction execution condition from the register is satisfied and the address dependency check is successful but a fault has occurred due to an attempt to perform the alternative operation, the processing circuitry is configured to set the exception identification information to indicate a second exception cause.

19. A computer readable medium storing computer readable code for producing a data processing apparatus according to any one of claims 1 to 18.

20. 1. A data processing method comprising: performing data processing operations in response to instructions stored in the memory system; responsive to determining that an instruction execution condition from a register is satisfied at a point in the program flow corresponding to the program counter address, determining, based on instruction definition information associated with an instruction storage register, an alternative operation to be performed in place of an original operation represented by an instruction stored at a location in the memory system corresponding to said program counter address; performing an address dependency check based on the program counter address to determine whether the alternative operation is permitted to be performed in place of the original operation.

21. 1. A computer program for controlling a host data processing apparatus to provide an instruction execution environment for executing target program code, comprising: processing program logic for performing 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 instruction execution condition from a register is satisfied at a point in a program flow corresponding to a program counter address in the simulated address space, the processing program logic determines, based on instruction definition information associated with simulated registers that store instructions, an alternative operation to be performed in place of an original operation represented by an instruction stored at a location in the simulated memory system corresponding to the program counter address; 1. A computer program product comprising: processing program logic configured to perform an address dependency check based on the program counter address to check program logic to determine whether the processing program logic is authorized to perform the alternative operation instead of the original operation.

Images