Address-related check

Abstract

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

Description

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

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

[0003] From one aspect, the present technology provides a data processing device, the data processing device comprising:

[0004] processing circuitry configured to perform data processing operations in response to instructions stored in a memory system, wherein in response to determining that an execute instruction from register condition is satisfied at a point in program flow corresponding to a program counter address, the processing circuitry is configured to determine, based on instruction definition information associated with an instruction storage register, an alternate operation to be performed in place of an original operation represented by the instruction stored in the location in the memory system corresponding to the program counter address; and

[0005] Check circuitry is configured to perform an address-dependent check based on the program counter address to determine whether the processing circuitry is permitted to perform the substitute operation in place of the original operation.

[0006] From another aspect, the present technology provides a data processing method, which includes:

[0007] performing data processing operations in response to instructions stored in a memory system;

[0008] In response to determining that an execute instruction from register condition is satisfied at a point in program flow corresponding to a program counter address, determining, based on instruction definition information associated with an instruction storage register, an alternate operation to be performed in place of an original operation represented by an instruction stored in a location in the memory system corresponding to the program counter address; and

[0009] An address dependency check is performed based on the program counter address to determine whether execution of the substitute operation is permitted in place of the original operation.

[0010] Viewed from another aspect, the present technology provides a computer program for controlling a host data processing device to provide an instruction execution environment for executing target program code, the computer program comprising:

[0011] processing program logic to perform a data processing operation in response to an instruction of the target program code identified by an address in the emulated address space, wherein, in response to determining that an execute instruction from register condition is satisfied at a point in program flow corresponding to a program counter address in the emulated address space, the processing program logic is configured to determine, based on instruction definition information associated with an instruction storage emulation register, an alternate operation to be performed in place of an original operation represented by the instruction corresponding to the program counter address; and

[0012] A check program logic is configured to perform an address-related check based on the program counter address to determine whether the processing program logic is allowed to perform the substitute operation in place of the original operation.

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

[0014] Further aspects, features and advantages of the present technology will be apparent from the following description of examples read in conjunction with the accompanying drawings, in which:

[0015] Figure 1 An example of a data processing apparatus is schematically illustrated.

[0016] Figure 2 The example schematically illustrates the use of translation table entries to indirectly specify permission information.

[0017] Figure 3 Examples of processes that may be performed by a data processing apparatus are schematically illustrated.

[0018] Figure 4 Schematically illustrates registers that may be provided with a data processing apparatus.

[0019] Figure 5 A process for executing instructions from an instruction storage register in place of instructions stored in memory is illustrated.

[0020] Figure 6 The conditions for determining whether the conditions for executing an instruction from a register are satisfied are illustrated.

[0021] Figure 7 Illustrate the conditions for determining whether an attempted access to the instruction storage register should cause an exception.

[0022] Figures 8 to 12 Provides examples of address-related checks.

[0023] Figure 13 Examples of simulator implementations that can be used.

[0024] A data processing apparatus includes processing circuitry configured to perform data processing operations in response to instructions stored in a memory system. Program flow may be controlled based on a program counter indicating a current point in code execution. For example, the program counter may be stored in a register and provide information identifying a program counter address, the program counter address identifying the next instruction to be fetched from the memory system, the fetched instruction identifying an operation to be performed by the processing circuitry. The program counter may be provided in different ways, for example, the program counter may directly indicate the program counter address, or may identify an offset that is combined with a base address to provide a 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, and may include one or more levels of cache that store data corresponding to addresses in main memory.

[0025] Although a program can conventionally be executed by executing instructions from memory, in some cases, it may be more appropriate to execute an alternative operation (rather than an operation associated with the instruction indicated by the program counter). For example, as will be discussed in further detail below, after reaching a software breakpoint in a program, it may be desirable to execute an alternative operation rather than an operation based on an instruction associated with a 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 replaced with the breakpoint instruction). The alternative operation may be determined based on instruction definition information stored in an instruction storage register rather than the instruction at the program counter address stored in the memory system. Thus, executing the alternative operation may include executing an instruction from an instruction storage register rather than executing an instruction from memory. The instruction definition information may include, for example, an opcode identifying the alternative operation and information specifying operands for the alternative operation.

[0026] To determine when to execute an alternative operation based on an instruction storage register instead of an operation based on an instruction in memory, the processing circuitry may check whether an execute instruction from register condition is satisfied. When the execute instruction from register condition is satisfied, the processing circuitry may then execute the instruction stored in the instruction storage register instead of the instruction stored at the program counter address. Executing an alternative operation based on an instruction stored in a register instead of an operation based on an instruction stored in a memory system may provide a flexible technique for modifying a program (e.g., for debugging purposes) without having to write new instructions to the memory system. This may avoid the overhead that may be associated with writing new instructions to memory when it is desired to modify code, such as enforcing coherence agreements. Additionally, modifying a program by executing specific instructions from registers instead of memory may be specific to a specific thread in a specific processing unit, where other processing units have access to memory that sees the original code instead of the modified code.

[0027] However, the inventors have realized that executing an alternative operation based on an instruction stored in a register can mean bypassing certain restrictions that would be enforced when executing instructions from memory. When executing an instruction from an instruction storage register, the instruction is not fetched from memory, and therefore the restrictions that are normally enforced when fetching instructions may not occur. The restrictions imposed when executing instructions from memory can reduce the likelihood of malicious code being executed or the processor being tricked into executing an operation that should not be allowed. Therefore, bypassing restrictions while executing an alternative operation in place of the original operation can provide a mechanism by which incorrect instructions can be executed.

[0028] The inventors have learned that executing an alternate operation in place of the original operation may only be effective at certain points in the program where such behavior is expected and / or where the risk of such behavior presenting a processor attack is reduced. The inventors have therefore learned that the potential risks associated with executing an alternate operation in place of the original operation can be reduced by performing checks based on the point in the program flow at which the alternate operation is attempted. Therefore, the data processing apparatus further includes a check circuit configured to perform an address-dependent check based on a program counter address to determine whether the processing circuitry is permitted to execute the alternate operation in place of the original operation. Performing an address-dependent check based on the address of the instruction whose operation is to be replaced by the alternate operation means that the alternate operation is only permitted at certain points in the program. The address-dependent check is not particularly limited, and several examples of address-dependent checks are discussed below. Furthermore, the address-dependent check may include one or more separate checks based on the program counter address, wherein in some examples, the address-dependent check fails unless each separate check passes. The address-dependent check used to determine whether the alternate operation should be permitted in place of the original operation may appear unusual because it is based on a check of the address in memory associated with the replaced operation, rather than a check of the actual alternate operation to be executed. However, the inventors have determined that this check may protect the mechanism used to execute instructions from the instruction storage register from certain abuses.

[0029] To perform address-related checks, the checking circuitry may check the state of permission information associated with the program counter address. The permission information may indicate whether a particular access to the memory, such as reading or writing, should be allowed. The permission information may include permission flags, for example, each flag having a state indicating that a certain permission is granted and a state indicating that a certain permission is not granted. The permission information may also be provided in alternative ways. For example, a combination of multiple permission bits may indicate that certain permissions are granted while others are not granted, while no specific permissions are associated with specific bits. The permission information may be associated with regions of the memory, so that certain permissions may be granted for certain regions of the memory. For example, permissions may include execute and write permissions, which can be used to check whether a given address is within an executable or writable region of the memory, but further permissions, such as read permissions, may also be provided. Checking the state of permission information associated with the program counter address provides a simple technique for performing address-related checks. The permission information is quickly accessible, and checks can be determined by checking the state of the permission information without requiring further calculations or comparisons to determine whether the check is satisfied.

[0030] In one example, an address-dependent check may involve determining whether the processing circuitry will be allowed 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 from which the processing circuitry is allowed to execute instructions, this may indicate that something unexpected has occurred during processing. For example, a branch may have been executed to update the program counter address to an address in a memory region containing data rather than instructions. Because execution of an instruction from memory where the program counter address is outside the executable region is not allowed, one method of preventing abuse of a mechanism for executing an alternate operation in place of the original operation may be to prevent execution of an instruction from an instruction storage register when the program counter address is outside the executable region. Thus, in one example, the address-dependent check includes checking whether the program counter address is within an executable memory region from which the processing circuitry is allowed to execute instructions. This may provide a simple determination based on the program counter address that the alternate operation should not be allowed to proceed.

[0031] As a supplement or alternative to the above, the address-related check may include checking whether the program counter address is within a writable memory area in which the processing circuit is allowed to write data. If the instruction at the program counter address is within a writable memory area, it may be possible for the processing circuit to write data to the address and cause the instruction at the program counter address to be modified. Debug code is an example of a specific technology in which it is expected that instructions in the memory will be replaced (e.g., with a breakpoint instruction), and therefore it is expected that write permissions will be set during debugging for an area of ​​the memory storing instructions. Debug code can also be a specific scenario in which it is expected that an alternative operation based on an instruction storage register will be performed (as will be discussed in more detail below). Therefore, the check for write permissions can help distinguish debug scenarios in which execution from the instruction storage register is expected and allowed from regular code execution in which it may be expected to prevent execution from the instruction storage register. If the processing circuit is prevented from modifying the instruction at the program counter address, it is also possible to prevent the processing circuit from performing the alternative operation based on the instruction definition information in the instruction storage register.

[0032] Permission information can be specified in a variety of ways. For example, a memory protection unit (MPU) associated with the processing circuitry can be provided. The MPU can store entries, each of which identifies a memory address range and the permissions associated with the identified memory address range. Alternatively, permission information can be specified using a page table structure. A page table contains page table entries corresponding to a specific address range, providing a translation between virtual addresses used by the processor and physical addresses in the memory system. Using page table entries to specify permission information can be particularly efficient because page table entries are generally associated with regions of memory, and instructions are often provided together in memory. The instruction corresponding to the leading value obtained by the program counter address in the previous cycle can therefore correspond to the same page table entry as the program counter address, and the page table entry can therefore be cached in the translation lookaside buffer (TLB) due to access to the earlier instruction. Therefore, the permission value can be cached in the processing circuitry and can be quickly accessed for address-related checks. If the page table entry is not already cached, the processing circuitry can use an existing page table traversal mechanism to access the permissions.

[0033] Permission information for a memory region containing a program counter address may be specified directly in a page table entry corresponding 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 be provided, there may not be enough bits in the permission field of the page table entry to directly represent all of the permissions. Therefore, in some examples, at least a portion of the permission information may be specified indirectly by the 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 a portion of the permissions for that entry, wherein 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 encoded directly in a page table entry, this may allow processing circuitry to quickly update the permissions of a page table entry by performing a single update for that permission across many page table entries that all reference the same permission field, without having to update each page table entry separately. Furthermore, if different processing environments have access to different permission registers but share page tables, this may allow the same page table entry to be used across the different processing environments while providing different permissions to the different processing environments because the different processing environments may have different instances of the permission register referenced by the page table entry, where the different instances of the permission register can be set to different permission encodings for the different processing environments.

[0034] When performing the check, if the check takes into account the current exception level of the processing circuitry, a more flexible address-dependent check may be provided. This may be useful because lower privilege software associated with a lower privilege exception level may not be trusted to perform an alternative operation in place of the original operation, but higher privilege software with a higher trust level may be trusted to perform an alternative operation at the same program counter address. The address-dependent check may depend on the current exception level of the processing circuitry, rather than prohibiting or allowing the alternative operation for all exception levels. To provide additional flexibility when the address-dependent check includes checking permission information, the checking circuitry may be configured to select which permission information to use to perform the address-dependent check based on the current exception level of the processing circuitry. For example, there may be permission information items for exception levels that are less privileged than a threshold level, and separate permission information items for exception levels that are at or above the threshold level.

[0035] The use of executable and write permissions as an option for implementing address-dependent checks has been discussed above. However, executable and write permissions can be associated with other aspects of controlling access to memory, and thus the freedom to modify executable and write privileges for certain regions of memory can be reduced. For example, a region may be inadvertently designated as executable and / or writable even when software may not intend to allow execution from registers for that region. Therefore, in addition to or in lieu of these checks based on executable and write permissions, address-dependent checks can include checking whether permission information indicates that execute instruction permission from registers is provided for a program counter address. The checking circuitry can be configured to determine that the processing circuit is not permitted to perform an alternative operation in place of the original operation in response to determining that permission information indicates that execute instruction 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. Therefore, permissions can be checked independently of execute and write permissions and indicate whether instructions in the region can have their operations replaced with alternative operations. In some examples, the permissions can be new permissions that are not used in any other permission checks.

[0036] In some examples, an address may be associated with only a single execute-from-register instruction permission. However, as discussed above, providing different permissions for different exception levels can be useful. In one specific example, code executing at the lowest privilege 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. Enforcing different permissions for the lowest privilege exception level and other exception levels may therefore be appropriate. Therefore, in some examples, the permission information may indicate whether a first execute-from-register instruction permission is provided and whether a second execute-from-register instruction permission is provided. In response to determining that the processing circuit is currently executing at the lowest privilege exception level, the checking circuitry is configured to perform an address-related check depending on whether the first execute-from-register instruction permission is provided, and in response to determining that the processing circuit is currently executing at an exception level other than the lowest privilege exception level, the checking circuitry is configured to perform an address-related check depending on whether the second execute-from-register instruction permission is provided. Therefore, the address-related check can 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 the execute-from-register instruction permission.

[0037] The address-dependent check need not include checking the permissions associated with the program counter address. Alternatively or additionally, the address-dependent check may include checking what is stored at the program counter address. For example, if no valid instruction is stored at the program counter address, the address-dependent check may fail. This may be because the typical behavior of using the 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, if the value stored at the program counter address corresponds to an undefined instruction encoding, the address-dependent check may fail.

[0038] Additionally, the address-dependent check may include checking whether the instruction stored in the location corresponding to the program counter address in the memory system is an instruction of the expected type. Execution of instructions using the instruction storage register may be restricted to certain points in the program. While these points may be identified based on permissions associated with the program counter address, 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 instruction of the expected type, the address-dependent check may fail. Instructions of the expected type may include a broad category of instructions (e.g., if the instruction is not written to memory, it may be an instruction of the expected type) or may include specific instructions, such as individual opcodes. While the expected type of instruction may be dynamically adjustable, for example, based on information stored in a register, in some examples, there is a finite number of expected instruction types predefined in the hardware of the processing device, such that execution of instructions using the instruction storage register is restricted to operations that replace only certain limited instructions. Checking whether the instruction at the program counter address is an instruction of the expected type may include loading the instruction from memory (optionally performing additional permission checks during the memory access) and comparing the retrieved instruction with instructions of the expected type.

[0039] The type of instruction that can be considered to be an instruction of the expected type is not subject to specific restrictions and may vary for different specific implementations. However, a specific example in which self-register execution is useful is during software breakpoint setting. In software breakpoint setting, certain instructions in the code can be replaced in memory by breakpoint instructions. Breakpoint instructions cause exceptions to be triggered so that a debugger can analyze the processing circuit for diagnostic purposes (such as for debugging code). In some examples, it can be considered that self-instruction storage register execution is unlikely to be used in a situation where its breakpoints have not yet been established, and therefore, the fact that the instruction at the program counter address is an instruction other than a breakpoint instruction can be a sign that the mechanism for self-instruction storage register execution is being improperly used. Therefore, in some examples, the expected type of instruction includes at least a breakpoint instruction. If the self-register execution instruction condition is met while the instruction at the program counter address is not a breakpoint instruction, this can indicate that the mechanism is being improperly used and the address-related check may fail.

[0040] When the execute-from-register instruction condition is met, an alternative operation is selectively performed by the processing circuitry depending on the results of an address-related check. The decision to perform an alternative operation based on the instruction storage register may be made by software at certain points in the program, which may require instructing the hardware of the processing circuitry to perform the alternative operation. Therefore, in some examples, the processing circuitry may be configured to determine whether the execute-from-register instruction condition is met based on at least one enable value stored in at least one control register. Because software may be allowed to write to the control register, this provides a simple mechanism by which software can instruct the hardware to perform the alternative operation, which may impose only minimal overhead on the processing circuitry. Because controls may already be established for whether software with a certain privilege level is allowed to update the control register, this may also be an efficient method for imposing control over whether specific portions of software should be allowed to satisfy the execute-from-register instruction condition. While one aspect of the execute-from-register instruction condition may involve checking at least one enable value, it should be understood that the execute-from-register instruction condition may also include further conditions, and thus, setting an enable value may not necessarily result in the execute-from-register instruction condition being met. For example, the execute-from-register instruction condition may also include checking that the processing circuitry is executing in a specific operating mode.

[0041] As discussed above, security can be improved by performing address-dependent checks when an execute-from-register condition is met, which can prevent malicious code from being executed from the instruction storage register. Security can be further improved by controlling when the execute-from-register condition is allowed to be met. Specifically, when the execute-from-register condition is indicated by an enable value in a control register, setting the enable value can be disabled in certain circumstances to prevent spoofed or malicious software from incorrectly setting the execute-from-register condition. A particularly effective technique for controlling the setting of the enable value can be based on the software's execution environment. For example, the software may be processed by processing circuitry in one of multiple exception levels. A lower-privileged exception level may have reduced register access permissions compared to a higher-privileged exception level. Mechanisms for switching between exception levels may include signaling an exception to the processing circuitry and performing an exception return. Less trusted software may execute at a lower exception level, while more trusted software (such as an operating system or hypervisor) may execute at a higher exception level. To prevent less-trusted software from incorrectly setting the execute-from-register instruction conditional (and thereby potentially causing a register-based alternative operation to be executed in place 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 an exception level less privileged than a threshold exception level. Consequently, less-privileged software may be unable to set the execute-from-register instruction conditional. Mechanisms for preventing certain exception levels from accessing certain registers may already be provided in some hardware implementations, and thus imposing a further requirement for preventing writes to the enable value control register for certain exception levels may have low associated overhead. Thus, this provides an effective and efficient technique for reducing the ability of less-trusted software to abuse instruction storage registers.

[0042] In some examples, a single enable value may be provided that is allowed to be set by software executing at or above a threshold privilege level. However, in some architectures, there may be two or more privilege levels at or above the threshold privilege level. In these examples, there may be inconsistencies between software that is both allowed to set an enable value related to whether the execute-from-register instruction condition is allowed to be satisfied. For example, there may still be the possibility that the lower-privileged software may be tricked into setting the execute-from-register instruction condition or may be malicious, or that the higher-privileged software may wish to disable execution from the instruction storage register for other reasons and, therefore, may wish to prevent the lower-privileged software from setting the execute-from-register instruction condition. To enable the higher-privileged level to enforce control over the lower-privileged level when both are at or above the threshold privilege level, another value may be provided in another control register. The processing circuitry may determine whether the execute-from-register instruction condition is satisfied based on both the enable value and the other value. Processing circuitry executing at the threshold exception level (or in an exception level less privileged than the threshold exception level) may not be allowed to write to the other control register. Thus, software at a threshold privilege level is allowed to write to a control register that stores an enable value, but is not allowed to write to another control register that stores another value. Thus, software executing at a higher privilege level than the threshold privilege level can override software at the threshold privilege level and prevent the execute-from-register instruction condition from being satisfied. Providing another control register increases the granularity of control that different privilege levels can have over whether the execute-from-register instruction condition is set.

[0043] While security can be provided by performing address-dependent checks and optionally limiting when the execute-from-register instruction condition can be set, both of these restrictions can still allow unfettered access to the instruction storage register. While this may not be a problem in some implementations, for example, because instructions from the instruction storage register are only executed at certain points in the code (such as after a certain setting has been defined for an enable value used to determine whether the execute-from-register instruction condition is satisfied and for permission information used to define whether the address-dependent check is satisfied), in other examples, allowing unfettered access to the instruction storage register may be undesirable. For example, if malware is able to cause malicious instructions to be written to the instruction storage register before executing an alternative operation, this may allow the malicious instructions to be executed. Additionally, it may be desirable to prevent lower-privilege software from being able to read instructions in the instruction storage register, as these may be reserved for higher-privilege software. Therefore, further security can be provided by providing a trap condition, wherein the access checking circuitry is configured to cause the processing circuitry to trap to a higher-privilege exception level in response to detecting that processing circuitry executing at a given exception level attempts to read from or write to the instruction storage register. Software executing at a higher privilege exception level can then handle the attempted read or write in an appropriate manner. Whether a trap condition is satisfied can depend on trap configuration information, so that in implementations that support setting traps, it is not necessary to always set the trap (which can depend on control state information). Providing a trap condition further increases the security associated with providing an instruction storage register and reduces the potential for abuse by executing an alternate operation in place of the original operation.

[0044] As discussed above, the checking circuitry is configured to perform an address-dependent check based on the program counter address to determine whether the processing circuitry is permitted to execute an alternate operation in place of the original operation. If the check fails, the processing circuitry is determined not to be permitted to execute the alternate operation. In some examples, the processing circuitry may execute the alternate operation anyway, but then be later prevented from further processing. Values ​​resulting from the alternate operation or the later operation may not be submitted, as if those results had not been generated in the first place. However, in some examples, the processing circuitry may be prevented from executing the alternate operation if the address-dependent check fails. This can reduce the chances of side-channel attacks associated with executing an alternate operation that should not be executed.

[0045] In some examples, the check circuitry can be configured to raise an exception in response to determining that an address-related check has failed. This can trigger a transition to a higher privileged exception level that can handle the exception. This can enable attempted attacks and / or errors that cause address-related checks to fail to be identified and addressed.

[0046] In some cases, when the execute instruction from register condition is met, an exception may be raised during an attempt to perform an alternative operation. One reason for this is that an address-related check may have failed. Another reason is that the address-related check may have passed, but executing the instruction stored in the instruction storage register may have resulted in a different fault (such as a memory access fault), or the instruction may have been an undefined instruction. It may be advantageous to provide some information identifying why the exception was raised so that the exception handler can identify and address the problem. Therefore, 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-related check, the processing circuit is configured to set the exception identification information to indicate a first exception cause. In response to detecting that the execute instruction from register condition is met and the address-related check is successful, but a fault occurs due to the attempt to perform the alternative operation, the processing circuit is configured to set the exception identification information to indicate a second exception cause.

[0047] Specific examples will now be described with reference to the accompanying drawings.

[0048] Figure 1 An example of a data processing device 2 is schematically illustrated. The data processing device has a processing pipeline 4 (an example of processing circuitry, which may, for example, form part of a CPU (central processing unit)). The processing circuitry 4 is configured to execute instructions defined in an instruction set architecture (ISA) to perform the data processing operations represented by the instructions. The processing pipeline 4 includes a plurality of pipeline stages. In this example, the pipeline stages include a fetch stage 6 for fetching instructions from an instruction cache 8; a decode stage 10 for decoding the fetched program instructions to produce micro-operations (decoded instructions) to be 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, once the operands required to execute the micro-operation are available, issuing the micro-operation for execution; an execute stage 16 for executing the data processing operation corresponding to the micro-operation by processing operands read from the register file 14 to produce a result value; and a writeback stage 18 for writing the processed results back to the register file 14. It will be appreciated that this is only one example of a possible pipeline architecture, and that other systems may have additional stages or different stage configurations. For example, in an out-of-order processor, a register renaming stage may be included for mapping architectural registers specified by program instructions or micro-operations to physical register descriptors that identify physical registers in register file 14. In some examples, there may be a one-to-one relationship between program instructions defined in the ISA decoded by decode stage 10 and corresponding micro-operations processed by the execute stage. There may also be a one-to-many or many-to-one relationship between program instructions and micro-operations, such that, for example, a single program instruction may be split into two or more micro-operations, or two or more program instructions may be fused to be processed as a single micro-operation.

[0049] Execution stage 16 includes a plurality of processing units for performing different types 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 the program counter indicating the current execution point accordingly; and a load / store unit 26 for performing load / store operations to access data in memory systems 8, 30, 32, 34.

[0050] A memory management unit (MMU) 28 is provided for controlling memory access permission checks and performing address translation between a virtual address specified by the load / store unit 26 based on an operand of a data access instruction and a physical address identifying a storage location of the data in the memory system. The MMU has at least one translation lookaside buffer (TLB) 29 for caching address translation data from a page table stored in the memory system, wherein the page table entries of the page table define an address translation image and may also specify access permissions that govern whether a given process executing in the pipeline is allowed to read, write or execute instructions from a given memory region. The MMU 28 may also lookup at instruction fetches triggered by the fetch stage 6. As Figure 1 As shown, the MMU 28 may be implemented using an instruction-side MMU (I-MMU) for performing MMU functions for instruction fetching (which is separate from the 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 the fetch stage 6 and data-side accesses from the load / store unit 26.

[0051] 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 other arrangements of caches may be provided. The specific type of processing units 20 through 26 shown in the execution stage 16 is only one example, and other implementations may have different groups of processing units or may include multiple instances of the same type of processing unit so that multiple micro-operations of the same type can be processed in parallel. It will be understood that Figure 1 This is only a simplified representation of some components of a possible processor pipeline implementation, and the processor may include many other elements that are not illustrated for the sake of brevity.

[0052] The data processing apparatus includes a program counter that indicates the current execution point. The program counter may be provided in a program counter register within register file 14, which may store the program counter address directly or a fixed offset from the program counter address. 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 dependent on the size of the instruction when an instruction is fetched, in addition to being updated by an arbitrary amount specified by the branch when the branch instruction is taken. In this way, the program counter address indicates the next instruction in the program and enables the processing circuitry to step through the program.

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

[0054] There may be no restrictions on where data written to the instruction storage register can be written from, so in theory the instruction storage register could store instructions that could cause behavior that could harm the data processing apparatus. Execution from the instruction storage register bypasses permission checks that may be performed on memory accesses when the fetch circuit 6 reads instructions from the memory system 8, 32, 34, which would normally prevent the execution of instructions that are not allowed to be executed. Thus, the instruction storage register presents a route through which instructions can be executed when they should not be allowed to be executed. For example, an attacker could trick the code into storing an instruction in the instruction storage register and then executing that instruction. Permission to execute instructions using the instruction storage register may only be provided at certain points in the code where the instruction storage register is expected to be used.

[0055] Therefore, the data processing apparatus further includes a check circuit 36. When it is determined that the instruction execution condition from the register is satisfied, the check circuit performs an address-related check based on the program counter address to determine whether an alternate operation is permitted to be executed in place of the original operation. If the alternate operation is not permitted, the check circuit 36 ​​raises an exception and prevents the alternate operation from being executed.

[0056] The address-related checks performed by the check circuit 36 ​​may vary and may include several different checks. The address-related checks may include one or more of the following:

[0057] Check that the program counter address is within the executable area of ​​memory. Substitute operations can generally be used to replace the actions of an instruction. However, if the program counter address does not point to an executable area of ​​memory, this may indicate that it is not an instruction, or at least not an executable instruction. Therefore, this may indicate a point in the process where execution from registers may not be allowed.

[0058] Check that the program counter address is within a writable area of ​​memory. If the memory instruction replaced by the instruction stored in the instruction storage register can be written, this may indicate that it is freely modifiable. Therefore, there may be no need to prevent this operation from being replaced by a register-based operation. In addition, when debugging code, the code may be in a writable area of ​​memory. Since debugging can be a situation where execution from the instruction storage register is expected, checking for write permission can be an indirect way to check whether the current situation is a debugging situation where execution from the instruction storage register is expected.

[0059] Check that the program counter address is within a writable and executable area of ​​memory. This combination of the two checks above can more accurately identify areas of code being debugged, as these are areas where both execute and write permissions can be provided and where execution from the instruction storage registers can be expected.

[0060] • Check that the program counter address is within a region of memory for which execution from the instruction storage registers is explicitly allowed to replace instructions in that region of memory for the current exception level, regardless of execute and write permissions.

[0061] • Checking that the instruction in memory at the program counter address is an expected type of instruction, such as a breakpoint instruction, where an operation that replaces the memory instruction with an alternative operation would be expected.

[0062] If one or more of the above conditions are not met, it may indicate that an attempt to execute an instruction storage register based instruction occurred at a point in the code where this was not expected.

[0063] Some of the checks described above may be performed by reference to access permissions associated with a program counter address in memory. The permissions may be specified in a page table entry in a page table stored in memory, which may be cached in a TLB 29 associated with an instruction side MMU (I-MMU). The permissions may include flags corresponding to each permission, or combinations of bits may be associated with certain groups of permissions. The permissions may include execute permission, write permission and / or at least one self-register execute instruction permission that is independent of the execute permission and the write permission. Different self-register execute instruction permissions may be provided for different exception levels of the processing circuit. Further permissions may also be provided, such as a read permission to indicate that a region of memory is readable. In some examples, the permissions may be specified directly in the page table entry when it is stored in memory. However, in other examples, such as Figure 2 For example, page table entries indirectly specify permissions.

[0064] Figure 2 The example uses a page table entry (translation table entry) 40 to indirectly specify permissions for a region of memory corresponding to the page table entry. The page table entry 40 is part of a page table stored in memory and may also be cached in the TLB 29. A permission field 42 provided in the page table entry 40 provides a field identifier (whereas if permissions were specified directly, the permission field 42 would indicate the permission itself). The field identifier identifies a field in a permission register 44 (a permission indirect register) that specifies permissions. Permissions may be specified in any manner in the identified field of the permission register 44, such as an encoding that directly represents the permissions in the page table entry. Providing permissions in the permission register 44 rather than in the page table entry 42 means that permissions for several regions of memory can be updated at once by writing updated values ​​to fields of the permission register referenced by several page table entries. In addition, there may be more available encoding space in the identified field of the register 44 than in the permission field of the page table entry 40, allowing a larger number of different permissions to be provided. Furthermore, if different processing environments have access to the same memory but to different registers (e.g., if they are different cores of a processing device), the same page table entry 40 may represent fields in different permission registers, allowing different permissions to be specified through the same page table entry. Each of the write permission, execute permission, and respective register execute instruction permission may be provided as direct permissions in the page table entry or in fields of the permission register.

[0065] Executing instructions from an instruction storage register instead of instructions in memory can be used in several situations. For example, during debugging, it may be desirable to execute a slightly modified version of a program to allow performance comparison with another thread executing the original program. For this purpose, it may be useful to execute the modified program by executing the modified instructions from the register, while leaving the original program in memory for execution by the corresponding thread. Another example is to improve the use of software breakpoints that can be used to debug code. When a software breakpoint is set, certain instructions in a piece of software stored in memory are replaced with breakpoint instructions, which cause an exception to be triggered when executed. When a breakpoint instruction causes an exception, the higher privileged code can take appropriate debugging actions. However, because the instructions in the code have been replaced with breakpoint instructions, the software is no longer complete and cannot be simply executed from memory, otherwise debugging will be inaccurate due to missing instructions. One method 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. The process may involve the following process:

[0066] 1. The user requests a breakpoint at a given program counter address (PC) through the debugger.

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

[0068] 3. The original instructions are saved by the debugger to the debugger memory.

[0069] 4. After receiving a software breakpoint exception, the processing circuit records the PC in a register and the debugger takes appropriate debugging actions.

[0070] 5. Return to the original thread:

[0071] 5.1. Pause all other executing threads that may share the breakpoint.

[0072] 5.2 The debugger replaces the BRK for the given PC in memory with the original instruction stored in the debugger memory.

[0073] 5.3 Debugger Set the enable bit to enable the software step-by-step execution process.

[0074] 5.4 The debugger executes the exception return (ERET) instruction.

[0075] 6. The processing circuitry executes the original instruction at the PC and then takes a software step-through exception to return control to the debugger.

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

[0077] This process is relatively inefficient. First, if more than one thread is executing the debugged process, the other threads need to be paused so that they do not miss the BRK instruction in memory while it is temporarily replaced with the original instruction. This delays the other threads. In addition, this process requires two writes to memory (one to write the original instruction to memory, and one to write the BRK to memory again later). Writing to memory can involve certain overheads, specifically, in addition to the usual permission checks, if coherence needs to be enforced, this can also involve sending consistency messages to invalidate cached copies of instructions.

[0078] Instruction storage registers can be used to alleviate these problems. Instead of replacing the BRK in memory, the original instruction can be written to the instruction storage register (e.g., from debugger memory). Subsequently, software stepping can involve executing the original instruction from the instruction storage register instead of the operation defined by the BRK instruction retained in memory. This can avoid the need to pause other threads and also avoid two writes to memory.

[0079] However, as discussed above, execution from registers presents a possible route for executing instructions when they should not be executed, and therefore the checking circuitry can perform address-dependent checks to ensure that the program counter address is a point in the code where execution from the instruction storage registers is expected. For example, when the address-dependent check involves checking whether the instruction at the program counter address is an expected type of instruction, the check may pass when the instruction at the program counter address is a BRK instruction.

[0080] Further details of executing instructions from the instruction storage register are described below with reference to exception levels (privilege levels). Figure 3 Provides an overview of the use of exception levels in processing devices. Figure 3 The following schematically illustrates an example of a process that can be performed by a data processing device. A hypervisor 50 can manage multiple virtual machines (VMs, also referred to as client operating systems or client OSs) 52. Each VM 52 can manage one or more applications 54. For example, the hypervisor 50 can control which regions of the address space are allocated to each virtual machine 52 and control switching between virtual machines 52, such as scheduling interrupts to time-share processing resources between the corresponding virtual machines 52. Similarly, each VM 52 can control which regions of the address space are allocated to each application 54 executing under that VM 52 and can control switching between applications as needed.

[0081] like Figure 3As shown, each process is associated with a given privilege level, EL0, EL1, EL2, or EL3. In this example, higher-numbered privilege levels have greater privileges than lower-numbered privilege levels, although the numbering may be reversed in other examples. In this example, application 54 executes at privilege level EL0, VM 52 executes at privilege level EL1, and hypervisor 50 executes at privilege level EL2. Generally speaking, processes executing at higher privilege levels have permissions that processes executing at lower privilege levels do not have.

[0082] like Figure 3 As shown, the hypervisor 50, VM 52 and device 54 can operate in the normal domain. In addition, the device can support isolating the secure domain from the normal domain so that processes executed in the normal domain cannot access data or instructions associated with the secure domain. Therefore, there can also be processes running in the secure domain, such as a secure operating system (OS) 56 and a trusted application 58 executed in the secure domain under the control of the secure OS 56. The secure OS 56 and the trusted application 58 are executed at privilege levels S-EL1 and S-EL0, respectively. A security monitoring process 60 at privilege level EL3 is also provided to manage transitions between the normal domain and the secure domain. For example, the security monitoring process 60 can manage which areas of the address space are associated with the secure domain or the non-secure domain, with some protection hardware provided to prevent non-secure processes in the normal domain from accessing data or instructions within the secure domain. An example of a technique for isolating the normal domain from the secure domain is provided by Provided by Cambridge Limited, UK technology, although other examples may also be used. For example, providing Figure 3 The security domains shown are optional, and other embodiments may not support the security monitor 60 , the secure OS 56 , and the trusted applications 58 .

[0083] 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) that directly identifies the corresponding memory location. For an application 54 or a virtual machine 52, the VA is first translated into an intermediate physical address (IPA), and then the IPA is translated into a PA. For example, by providing a two-level address translation, the virtual machine 52 can control the page tables used for VA-to-IPA translation to control which portions of the address space are allocated to each application 54, and the hypervisor 50 can control the page tables used for IPA-to-PA translation to control which portions of the address space are allocated to each virtual machine 52. For other processes, the VA is translated directly into a PA, with the hypervisor 50 (in the normal domain) or the secure OS 56 (in the secure domain) controlling the page tables that control which portions of the address space each process can access.

[0084] Further details will also refer to Figure 4 As shown, a plurality of registers may be provided in register file 14. Registers are provided in the format NAME_ELy, where ELy indicates the lowest privilege exception level at which a given register may be accessed. Accesses below ELy may cause an exception to be raised for handling by higher privileged software. For example, writing to MDSCR_EL1 by software executing at EL0 may be prohibited. The format ESR_ELx indicates a banked register, i.e., multiple copies of an ESR register, which are named ESR_EL1, ESR_EL2, ESR_EL3, for storing exception information relating to exceptions taken to EL1, EL2, EL3, respectively. Register fields are represented in the format NAME_ELy.FIELD and are displayed in Figure 4 In the registers shown in Figure 4 The particular layout of information in the registers in the example of is only one example, and other examples may combine register fields in other ways (e.g., to allocate differently which fields go into the same register or in different registers). Additionally, some information in the register control information may be omitted from certain examples of the present technology. Certain descriptions refer to values ​​in registers that are "set" or set to "1." It should 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 only one example. The following registers and register fields are illustrated in Figure 4 middle:

[0085] MDSCR_EL1 is a control register used for debugging. MDSCR_EL1.EnSTEPOP is a register field that stores an enable value that can be set by EL1 and higher privileged exception levels. Software operating at EL1 can set the enable value to indicate that it wishes to satisfy the execute instruction from register condition for the next value of the program counter address corresponding to the instruction after the enable value has been set.

[0086] MDSTEPOP_EL1 is an instruction storage register that can be written to by EL1 and higher privileged exception levels. Access to MDSTEPOP_EL1 can be illustrated in Figure 7 When the conditions for executing instructions from registers are met and the address-related checks pass, the instruction from MDSTEPOP_EL1 can be executed.

[0087] ESR_ELx is a group of exception syndrome registers (ESR_EL1, ESR_EL2, and ESR_EL3) that store information related to exceptions taken to corresponding exception levels. For example, ESR_EL1 stores information related to exceptions taken to EL1. The ESR_ELx.STEPOP field can be used to indicate that the exception was caused by executing the instruction stored in MDSTEPOP_EL1. The ESR_ELx.EC field can be used to indicate that the exception was taken to a higher exception level than the exception level at which the exception was generated. The ESR_ELx.ISS.FAILED field can be used to indicate that the exception generated was a software step-through failure exception due to an address-dependent check failure. The ESR_ELx.ISS.IFSC field can be used to indicate that the software step-through failure exception was due to the instruction at the PC address not being the expected (e.g., BRK) instruction.

[0088] MDCR_EL2 is a control register that provides configuration information for debugging and can be set by either EL2 or EL3. The MDCR_EL2.EnSTEPOP field can store another value that can be used to determine whether the execute-from-register instruction condition is satisfied. Because MDCR_EL2.EnSTEPOP can be set by higher-privileged code than MDCR_EL1.EnSTEPOP, it can be used to override EL1 when EL1 wishes to set the execute-from-register instruction condition. The MDCR_EL2.TDA field provides control over access to debug registers in EL1 and, when set, directs access to certain debug registers in EL1 (including the instruction storage register MDSTEPOP_EL1) to trap to EL2 (if no higher-priority exception is pending).

[0089] HDFGRTR2_EL2 is a control register that can be set by either EL2 or EL3 to control access to the MDSTEPOP_EL1 register. The 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. The 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., the hypervisor) can impose control on how EL1 (e.g., the operating system) is allowed to access the instruction storage registers.

[0090] MDCR_EL3 is a control register that provides configuration information for debugging and can be set by EL3. The field MDCR_EL3.EnSTEPOP can store another value that can be used to determine whether the execute-from-register instruction condition is met. If MDCR_EL3.EnSTEPOP is 0, the execute-from-register instruction condition is prevented even if the other enable bits indicate that the execute-from-register instruction condition should be met, and thus EL3 can 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 controls provided by code executing at EL1 and EL2 based on MDSCR_EL1.EnSTEPOP and MDCR_EL2.EnSTEPOP. The field MDCR_EL3.TDA provides control over access to debug registers in EL0, EL1, and EL2, and when set, indicates that access to certain debug registers in EL0 through EL2 (including the instruction storage register MDSTEPOP_EL1) is trapped to EL3.

[0091] HCR_EL2 is a hypervisor (EL2) configuration register that provides controls for virtualization. HCR_EL2.E2H indicates whether the configuration of the host operating system (type 2 hypervisor) is supported in EL2, which can affect exception handling at lower levels (such as EL0) (if the type 2 hypervisor is supported, some exceptions can be handled in EL2 instead, otherwise they would be handled in EL1). When HCR_EL2.E2H is set to 1, facilities that support the host operating system in EL2 are enabled. HCR_EL2.TGE is an example of a trap control that indicates whether general exceptions are trapped in EL2. When HCR_EL2.TGE=1, exceptions that are normally routed from EL0 to EL1 are instead routed to EL2, effectively disabling EL1 and making it unavailable for taking exceptions. If HCR_EL2.E2H is also enabled (HCR_EL2.{E2H,TGE}={1,1}), EL1 is completely disabled and EL0 runs in the host operating system.

[0092] EDHSR holds symptom group information for debug events. EDHSR.STEPOP is a register field that may be set when executing the instruction in the MDSTEPOP_EL1 register causes an exception and enters debug state.

[0093] Although some of the following description will refer to using the present technology to perform software breakpoint setting, it should be understood that the concepts described are not so limited. The concepts can be extended to use instruction storage registers for other operations, and specific references are only used to explain at least one way to actually implement the present technology.

[0094] Figure 5 The process for executing an instruction from an instruction storage register in place of an instruction stored in memory is illustrated. At step 500, processing occurs at a point in the program flow where the next instruction to be fetched is indicated by the program counter address. At step 502, a determination is made as to whether an execute instruction from register condition is satisfied, which indicates to the processing circuit that the next operation should be performed based on information stored in the instruction storage register rather than the instruction stored at the program counter address, if permitted. The determination as to whether the execute instruction from register condition is satisfied may be based on Figure 6 occur. Figure 6 A plurality of conditions for determining whether the condition for executing an instruction from a register is satisfied are illustrated, but it should be understood that one or more of the conditions may not be provided in every specific implementation of the present technology.

[0095] exist Figure 6At step 600, a determination is made as to whether the enable value is set, i.e., whether MDSCR_EL1.EnSTEPOP = 1. If not, software at EL1 or higher has not set the enable bit indicating that it wishes the next instruction to be executed from registers. Therefore, in this case, the execute instruction from register condition is not met (step 616).

[0096] exist Figure 6 At step 602, it is determined whether EL3 is enabled. If so, then at step 604, it is determined whether the enable bit, which can only be set by EL3, is set by determining whether MDCR_EL3.EnSTEPOP = 1. If not, EL3 has been prevented from executing instructions from the instruction storage register, and therefore the execute instruction from register condition is not met. If EL3 is not enabled or has not yet overwritten EL1, then at step 606, it is determined whether EL2 is enabled.

[0097] If EL2 is implemented and not disabled (step 608), then at step 610, a determination is made as to whether the processing circuit is currently executing at EL0 or EL1 (i.e., below EL2). If not, no check is performed to see if EL2 has already overridden the execute-from-register instruction condition, and the condition is deemed satisfied. However, if processing is at EL0 or EL1, then at step 612, the process optionally determines if register field HCR_EL2.{E2H.TGE} = {1,1}. If so, EL1 is disabled, and a separate check to determine if EL2 has already overridden the execute-from-register instruction condition may not be necessary. If not, then at step 614, a determination is made as to whether EL2 has already overridden the execute-from-instruction storage register alternative operation by checking the state of MDCR_EL2.EnSTEPOP. If not, the execute-from-register instruction condition is satisfied (step 618). However, if EL2 has already overridden the execute-from-register instruction condition, the condition is not satisfied (step 616).

[0098] Thus, it will be seen that even if EL1 has requested that the execute instruction from register condition be satisfied by setting the enable bit, this is also subject to being overridden by both EL2 and EL3 (depending on the specific implementation). It will be understood that, for example, if EL2 or EL3 are not provided in a particular implementation, then this may be excluded. Figure 6 For example, the check at step 612 may not be included, and the process may move directly from step 610 to step 614. Similar considerations apply to the other steps illustrated.

[0099] return Figure 5If the execute instruction from register condition is determined not to be satisfied, then the processing circuit does not perform the alternate operation in place of the original operation at step 504. The processing circuit may, for example, continue processing as usual by fetching the instruction at the program counter address from the memory system.

[0100] However, if the execute instruction from register condition is met, then at step 506, the check circuit 36 ​​performs an address-dependent check. As will now be discussed, the address-dependent check may include the example shown in FIG. Figures 8 to 12 It should be understood that the address-related check may also include further checks, the results of which depend on the program counter address.

[0101] like Figure 8 As illustrated, the address-dependent check may be a permission check based on permissions associated with the program counter address. At step 800, it may be determined whether execute permission is provided for the program counter address, thereby allowing the processing circuit to execute the instruction stored at the program counter address. If so, that aspect of the address-dependent check may be satisfied, and the outcome of the overall address-dependent check depends on whether any other checks have failed (step 804). If execute permission is not provided, the address-dependent check fails (step 802).

[0102] like Figure 9 As illustrated, the address-related check can be a permission check based on the permissions associated with the program counter address. At step 900, it can be determined whether write permission is provided for the program counter address, thereby allowing the processing circuit to write to the memory area indicated by the program counter address. The results at steps 902 and 904 are the same as the results of steps 802 and 804, respectively.

[0103] like Figure 10 As illustrated, the address-related check may be a permission check based on permissions associated with the program counter address. At step 1000, it may be determined whether a dedicated execute-from-register instruction permission is provided for the program counter address, which allows instructions in the memory area indicated by the program counter address to be replaced by alternative operations executed based on the instruction storage register, regardless of other permissions including write permissions and execute permissions. At step 1002, if the check based on the execute-from-register instruction permission fails, the address-related check fails, even if the checks based on execute permissions and write permissions have been performed and passed. At step 1004, if the check based on the execute-from-register instruction permission passes, whether the address-related check as a whole passes depends on the results of the other checks in the address-related check.

[0104] although Figure 10 The check in can occur based on a single self-register execution instruction permission, and the check can also be as follows Figure 11occurs as illustrated in . Figure 11 The process of selecting the execution instruction permission from the register based on the current exception level is illustrated. If the current exception level is the lowest privilege exception level EL0, the first execution instruction permission value from the register may be selected for use Figure 10 However, if the processing circuit is executing at a higher exception level EL1 to EL3, a second self-register execution instruction permission value may be selected. This allows different permissions to be set for the lowest exception level (which may be the least trusted exception level) and other exception levels. Thus, in some cases, execution of instructions from memory may be prevented only for the lowest exception level.

[0105] like Figure 12 As illustrated, the address dependency check may be based on the type of instruction stored at the program counter address. If the instruction at the program counter address is an instruction of the expected type (such as a breakpoint instruction), the check may pass (step 1204). Otherwise (step 1202), the address dependency check may fail.

[0106] Return again Figure 5 , if the address related check fails, then at step 510, the checking circuit 36 ​​may signal an exception to the processing circuit and may prevent the execution of the alternative operation in place of the original operation. When performing a software step-by-step operation, the failure of the address related check may be signaled using a software step-by-step failure exception. The exception level at which the software step-by-step failure exception is taken will be the exception level indicated by ELx in the following references. A value may be set in the register field ESR_ELx.EC to indicate whether the exception is taken to an EL higher than the current EL or whether it is taken to the current EL. The field ESR_ELx.ISS.FAILED may be set to indicate that the exception that has been generated is a software step-by-step failure exception due to a failed address related check. When checking such Figure 12 As illustrated in FIG, a check is made to see if an instruction of the expected type exists at the PC address. The field ESR_ELx.ISS.IFSC may be set to indicate that the software step-through 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 may be determined that the failure of the address-related check is due to a permission failure (execute, write, or execute from register instruction).

[0107] However, if the address dependency check passes, then at step 512, the check circuitry 36 allows the processing circuitry to execute an alternate operation to be executed based on the instruction storage register in place of the original operation that would have been executed based on the instruction stored in the location corresponding to the PC address. In the case of a breakpoint instruction, this allows the alternate instruction to be executed from the instruction storage register in place of the breakpoint instruction in the code stored in memory. If the instruction executed from the instruction storage register reads from or writes to the program counter, then since the program counter has not yet been modified to allow the alternate operation to be executed, this will be the current program counter (associated with the BRK instruction in memory). If the MDSTEPOP_EL1 instruction completes without generating an exception, the current program counter value is incremented by the size of the instruction to allow code execution to proceed. If the exception occurs during the execution of an instruction from the instruction storage register, the return address for the exception can be based on the current PC value. After executing the operation represented by the instruction in the instruction storage register, a debug exception is triggered (where 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 debugged program code is suspended and instructions from debug memory, which may be a dedicated memory location or a designated area within the memory systems 30, 32, 34, are executed instead. This allows the debugger to execute debug instructions that are not part of the debugged program code, for example, to investigate register contents or data in memory or to read an execution counter value. Once the debug operation to be executed in debug mode is complete, additional debug instructions may be executed to clear the enable value MDSCR_EL1.EnSTEPOP, after which an exception return instruction is used to return execution to the debugged program, which may then continue from the next address following the program counter value executed from the register by the alternate operation.

[0108] Implementing software breakpoints using instruction storage register MDSTEPOP_EL1 may proceed according to the following example description (it will be understood that this is merely an illustrative example of a software use case and the operations shown in pseudocode are not required features of a hardware device).

[0109] 0BRK at EL0

[0110] 10<Exception handler for software breakpoints starts at EL1>

[0111] 20<Enable software step-by-step execution>

[0112] 30MSR MDSCR_EL1,x0 / / Write 0b1 to MDSCR_EL1.EnSTEPOP 40MSR MDSTEPOP_EL1,x1 / / Write the replaced instruction to the instruction storage register

[0113] 50ERET / / Return to EL0

[0114] 60<Executed from MDSTEPOP_EL1>

[0115] 70<Software step-by-step execution exception to EL1>

[0116] When determined to be executed from MDSTEPOP_EL1, address correlation checking can be performed by hardware.

[0117] In some examples, the instruction storage register may have restricted access. For example, the register may be accessible to EL1 or higher but not to EL0. An example instruction storage register is Figure 4 MDSTEPOP_EL1 is shown in the MDSTEPOP_EL1 register. The access to the MDSTEPOP_EL1 register can be as follows: Figure 7 The control is illustrated as illustrating a number of checks to determine whether an attempted access to an instruction storage register should result in an exception, and if so, at which exception level the exception should be handled, although it should be understood that the exception may be handled at any level. Figure 7 One or more of the steps shown are excluded.

[0118] At step 700, an attempt is detected to read from or write to register MDSTEPOP_EL1. At 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 the EL1 instruction storage register, this is not allowed, and at step 704, there is a trap to a higher exception level to handle the security violation. If the current EL is not EL0, at step 704, it is determined that the current EL is EL1 or EL2 (i.e., not EL3). If the EL is EL3, then at step 708, since there may not be a higher exception level, there is no trap to a higher EL.

[0119] If the EL is EL1 or EL2 and (step 710) MDCR_EL3.TDA = 1 or (step 712) MDCR_EL3.EnSTEPOP = 0 (i.e., EL3 has prevented execution from registers from the instruction storage register from the instruction storage register from which the instruction is stored), then an access trap is attempted to EL3 at step 714. If neither of these conditions are true and the current exception level is EL2 (step 716), then there is no trap to a higher EL.

[0120] If the current exception level is EL1, then at step 718, it is determined whether MDCR_EL2.TDA = 1, and if this is true, the attempted access is trapped to EL2. Otherwise, when the attempted access is a read, it is determined whether HDFGRTR2_EL2.nMDSTEPOP_EL1 = 0 (a control bit that can be set by EL2 to control reading from MDSTEPOP_EL1 at EL1), and when the attempted access is a write, it is determined whether HDFGWTR2_EL2.nMDSTEPOP_EL1 = 0 (a control bit that can be set by EL2 to control writing to MDSTEPOP_EL1 at EL1). If either of these is true, the access has been prevented by EL2, and at step 724, the attempted access is trapped to EL2.

[0121] Thus, it will be seen that both EL2 and EL3 can independently control whether access to the instruction storage register MDSTEPOP_EL1 is allowed from EL1. In addition, EL2 can allow reads and writes independently of each other, further increasing the flexibility of control over the instruction storage register. It should be understood that not all Figure 7 All steps shown are required, and the present technique can be implemented even when one or more of the trap conditions are not implemented. For example, in some examples, EL3 may not be implemented, so the EL3 steps may not be present. Similarly, some implementations may support the option of disabling the use of EL2. In this case, the test of step 716 becomes "Is the current EL EL 1, and is EL2 enabled?", so if EL2 is not implemented or is currently disabled, the method proceeds from step 716 to step 708, and steps 718 through 724 are omitted. It should also be understood that the specific order of steps in the flowcharts described above is merely an example, and the same result can be achieved with steps in a different order or with some steps performed in parallel.

[0122] When executing an instruction from the instruction storage register, an exception may be generated indicating that a fault has occurred 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 has not passed the MMU check, an exception may be generated indicating that the execution of the instruction caused a fault. In this case, the fault will not be a fault caused by the instruction at the PC address, but a fault caused by the instruction in the instruction storage register. Therefore, if the exception handling software only uses the PC address to locate the instruction, it may not be able to identify the fault. To identify that the exception was caused by the instruction in the register, the field ESR_ELx.STEPOP in the ESR register can be set to indicate that the exception was caused by the execution of the instruction in the MDSTEPOP_EL1 register.

[0123] When an attempt is made to execute an instruction from a register because the execute-from-register instruction condition is met, there are (at least) two independent reasons why an exception may be raised. First, the address-related check may fail. Second, the address-related check may pass, but executing the instruction stored in the instruction storage register may result in a fault. These two situations can be distinguished using the registers described above. ESR_ELx.EC may indicate the primary exception cause (e.g., undefined instruction, data abort (fault), or software step-through exception), where ELx indicates the exception level to which the exception is taken. When the address-related check fails, the register field ESR_ELx.ISS.FAILED may be set. If the failure of the address-related check is due to the instruction at the program counter address not being of the expected type, ESR_ELx.ISS.IFSC may also be set. When execution of the instruction in the instruction storage register fails, ESR_ELx.STEPOP may be set while ESR_ELx.ISS.FAILED remains unset. Thus, by checking the status of ESR_ELx.EC, ESR_ELx.ISS.FAILED, and ESR_ELx.ISS.STEPOP, software handling the exception can determine whether the exception occurred due to a failure of an address-related check, due to executing an instruction in the instruction storage register, or for some other reason. Some of the fields of 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 than for the software step-through exception described above).

[0124] Register field EDHSR.STEPOP may also be set to indicate that the debug state has been entered as a result of executing the instruction in the MDSTEPOP_EL1 register.

[0125] Figure 13The simulator that can be used is specifically implemented. Although the embodiment described a little before is used to implement the present invention with the device and method for operating the specific processing hardware of supporting relevant technology, it is also possible to provide the instruction execution environment implemented by using a computer program according to the embodiment described herein. Such computer programs are often called simulators because they provide the specific implementation based on software of hardware architecture. The types of simulator computer programs include emulators, virtual machines, models and binary translators (including dynamic binary translators). Generally speaking, the simulator is specifically implemented and can be run on the host processor 1306 that optionally runs the host operating system 1304 and supports the simulator program 1302. In some arrangements, there can be multiple layers of simulation between the hardware and the instruction execution environment provided and / or the multiple different instruction execution environments provided on the same host processor. Historically, powerful processors have been needed to provide a simulator specifically implemented with reasonable speed, but this method can be justified in some cases, such as when it is desired to run the code native to another processor because of compatibility or reuse reasons. For example, the simulator can be specifically implemented to provide an instruction execution environment with additional functionality that is not supported by the host processor hardware, or to provide an instruction execution environment generally associated with different hardware architectures. A review of simulation is given in "Some Efficient Architecture Simulation Techniques" (Robert Bedichek, Winter 1990 USENIX Conference, pp. 53-63).

[0126] Where embodiments have been previously described with reference to specific hardware architectures or features, in an analog embodiment, equivalent functionality may be provided by suitable software architectures or features. For example, specific circuits may be implemented as computer program logic in an analog embodiment. Similarly, memory hardware (such as registers or caches) may be implemented as software data structures in an analog embodiment. Where one or more of the hardware elements mentioned in the previously described embodiments are present in an arrangement on host hardware (e.g., host processor 1306), some analog embodiments may utilize host hardware where appropriate.

[0127] The simulator program 1302 may be stored on a computer-readable storage medium (which may be a non-transitory medium) and provides a program interface (an instruction execution environment) to the target code 1300 (which may include an application program, an operating system, and a hypervisor) that is the same as the interface of the hardware architecture modeled by the simulator program 1302. Thus, program instructions of the target code 1300 can be executed from within the instruction execution environment using the simulator program 1302, so that a host computer 1306 that does not actually have the hardware features of the device 2 discussed above can emulate these features.

[0128] For example, the simulator program 1302 may provide processing program logic 1308 that simulates the characteristics of the processing circuit 2 and checker logic 1310 that simulates the characteristics of the checker circuit 36. The simulator program 1302 may provide a simulated address space 1312, in which memory is actually in the physical memory system provided by the host hardware 1306, and the simulator program 1302 maps addresses in the simulated address space to addresses in the physical memory system so that the target code 1300 can represent addresses in the simulated address space. The simulator program 1302 may also provide simulated registers 1314 that can be viewed as registers by the target code 1300, but the memory for them may again be provided in the physical memory system of the host hardware 1306.

[0129] The concepts described herein may be embodied in computer-readable code for fabricating 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 an electronic design automation (EDA) stage, to fabricate integrated circuits that include devices embodying the concepts. The computer-readable code may additionally or alternatively facilitate the definition, modeling, simulation, verification, and / or testing of devices embodying the concepts described herein.

[0130] For example, computer-readable code for fabricating an apparatus that implements the concepts described herein may define a code implementation of a hardware description language (HDL) that represents the concept. For example, the code may define a register transfer level (RTL) abstraction that defines one or more logic circuits that implement the apparatus. The code may define an HDL that represents one or more logic circuits that implement the apparatus in Verilog, SystemVerilog, Chisel, or VHDL (Very High Speed ​​Integrated Circuit Hardware Description Language), as well as intermediate representations such as FIRRTL. The computer-readable code may provide a definition of the implementation concept using a system-level modeling language, such as SystemC and SystemVerilog, or other behavioral representations of the concept that can be interpreted by a computer to facilitate simulation, functional and / or formal verification, and testing of the concept.

[0131] Additionally or alternatively, the computer-readable code may define a low-level description of an integrated circuit component that implements the concepts described herein, such as one or more wiring lookup tables or integrated circuit layout definitions, including representations such as GDSII. The one or more wiring lookup tables or other computer-readable representations of the integrated circuit component may be generated by applying one or more logic synthesis processes to the RTL representation to generate definitions for manufacturing devices that implement the present 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 implement the concepts. The FPGA may be deployed for the purpose of validating and testing concepts prior to manufacturing in an integrated circuit, or the FPGA may be deployed directly in a product.

[0132] The computer-readable code may include a mixture of code representations for fabricating a device, such as a mixture comprising one or more of an RTL representation, a wiring diagram representation, or another computer-readable definition for a semiconductor design and fabrication process to fabricate a device embodying the invention. Alternatively or additionally, concepts may be defined in a combination of a computer-readable definition to be used in a semiconductor design and fabrication process to fabricate a device, and computer-readable code defining instructions to be executed by the defined device once fabricated.

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

[0134] In this application, the phrase "configured to..." is used to mean that the elements of a device have a configuration capable of performing the defined operation. In this context, "configuration" refers to the arrangement or manner in which hardware or software are interconnected. For example, the 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 mean that the device elements need to be changed in any way to provide the defined operation.

[0135] Although exemplary embodiments of the present invention have been described herein in detail with reference to the accompanying drawings, it should be understood that the invention is not limited to such precise embodiments and that various changes and modifications may be implemented therein by those skilled in the art without departing from the scope of the invention as defined in the appended claims.

Claims

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

2. The data processing apparatus according to claim 1, wherein The address-dependent checking includes checking a status of permission information associated with the program counter address.

3. The data processing apparatus according to claim 2, wherein The address dependency check includes checking whether the program counter address is within an executable memory area that allows the processing circuit to execute instructions.

4. The data processing apparatus according to claim 2 , wherein The address dependency check includes checking whether the program counter address is within a writable memory area where the processing circuit is allowed to write data. 5 . The data processing apparatus according to claim 2 , wherein the permission information is directly or indirectly specified in a page table entry corresponding to the program counter address.

6. The data processing apparatus according to claim 5, wherein the page table entry corresponding to the program counter address indirectly specifies at least a portion of the permission information used to perform the address-related check by identifying a register location for storing the permission information. 7 . The data processing apparatus according to claim 4 , wherein the checking circuit is configured to select which permission information to use to perform the address-related checking based on a current exception level of the processing circuit.

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

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

10. A data processing apparatus according to any preceding claim, wherein The address dependency check includes checking whether the instruction stored in the location in the memory system corresponding to the program counter address is an expected type of instruction. The data processing apparatus according to claim 10 , wherein the expected type of instruction comprises at least a breakpoint instruction.

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

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

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

15. A data processing apparatus according to any preceding claim, wherein In response to determining that a trap condition is satisfied, the access checking circuitry is configured to cause the processing circuitry to trap to a higher privileged exception level in response to detecting that the processing circuitry executing at a given exception level attempts to read from or write to the instruction storage register.

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

17. A data processing apparatus as claimed in any preceding claim, wherein the checking circuitry is configured to raise an exception in response to determining that the address-related check fails.

18. A data processing apparatus according to any preceding claim, wherein the processing circuitry is configured to maintain exception identification information in an exception identification register, wherein: In response to a failure of the address-related check, the processing circuit is configured to set the exception identification information to indicate a first exception cause; and In response to detecting that the execute-from-register instruction condition is satisfied and the address dependency check succeeds, but a failure occurs due to attempting to execute the alternative operation, the processing circuit is configured to set the exception identification information to indicate a second exception cause.

19. A computer-readable medium for storing computer-readable code for producing a data processing apparatus according to any preceding claim.

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

21. 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 to perform a data processing operation in response to an instruction of the target program code identified by an address in the emulated address space, wherein, in response to determining that an execute instruction from register condition is satisfied at a point in program flow corresponding to a program counter address in the emulated address space, the processing program logic is configured to determine, based on instruction definition information associated with an instruction storage emulation register, an alternate operation to be performed in place of an original operation represented by the instruction stored in the location in the emulated memory system corresponding to the program counter address; and Check program logic is configured to perform an address-dependent check based on the program counter address to determine whether the processing program logic is permitted to perform the substitute operation in place of the original operation.

Images