Speculative execution following state transition instructions

Abstract

The present disclosure relates to speculative execution following a state transition instruction. An apparatus and a method are described, the apparatus comprising: processing circuitry adapted to execute instructions from an instruction stream, the instruction stream comprising a state transition instruction followed by further instructions, wherein the processing circuitry changes a security state of the processing circuitry in response to the state transition instruction; issue circuitry adapted to issue the further instructions for speculative execution prior to the state transition instruction being completed, the further instructions having a requirement in relation to the security state; and completion circuitry adapted to perform a completion operation on the further instructions, comprising checking whether the requirement in relation to the security state is met.

Description

Technical Field

[0001] This technology relates to the field of data processing systems. Background Technology

[0002] Some data processing systems are capable of operating in any of multiple security states, where access to certain data is restricted to instructions executed in some of these security states. This allows the selected data to remain secure by preventing operations executed in different security states from accessing it.

[0003] In such a system, instructions have specific requirements regarding a security state, indicating a particular security state in which they are permitted to execute. Therefore, when switching between security states of the processing system, it is necessary to prevent instructions halfway through the execution pipeline from being executed in an unauthorized state at the time of the security state change. One way to achieve this is to assume that the security requirements of any instruction halfway through the pipeline at the time of the security state change do not match the updated security state, and to flush the pipeline each time the security state of the data processing system changes. However, this approach can have a significant performance impact on the system. Specifically, performance impacts are known to be associated with execution flushing—for example, due to the fact that any flushed instructions may need to be reissued and re-executed.

[0004] This would be beneficial in improving the performance of the data processing system after a change in security status. Summary of the Invention

[0005] As one example, the present technology provides an apparatus comprising: processing circuitry adapted to execute instructions from an instruction stream, the instruction stream including a state transition instruction and subsequent further instructions, wherein the processing circuitry changes a security state in response to the state transition instruction; issuing circuitry adapted to issue the further instructions for speculative execution prior to the completion of the state transition instruction, the further instructions having a requirement regarding the security state; and completion circuitry adapted to perform a completion operation on the further instructions, including checking whether the requirement regarding the security state is met.

[0006] In another example, the present technology provides a method comprising: executing instructions from an instruction stream, the instruction stream including a state transition instruction and subsequent further instructions; changing the security state of the processing circuit in response to the state transition instruction; issuing the further instructions to be speculatively executed before the state transition instruction is completed, the further instructions having a requirement regarding the security state; and performing a completion operation on the further instructions, including checking whether the requirement regarding the security state is met.

[0007] In another example, the present technology provides an apparatus comprising: means for executing instructions from an instruction stream, the instruction stream including a state transition instruction and subsequent further instructions; means for changing a security state of the processing circuit in response to the state transition instruction; means for issuing the further instructions to be speculatively executed before the state transition instruction is completed, the further instructions having a requirement regarding the security state; and means for performing a completion operation on the further instructions, including checking whether the requirement regarding the security state is met.

[0008] In another example, the present technology provides an apparatus comprising: processing circuitry for executing instructions; prediction circuitry for generating predictions of one or more required supplementary operations in the instructions; and injection circuitry for injecting microcode corresponding to the supplementary operation into the processing circuitry in response to the predictions.

[0009] In another example, a method is provided that includes: executing instructions; generating a prediction of one or more required supplementary operations in the instructions; and injecting microcode corresponding to the supplementary operations into processing circuitry in response to the prediction.

[0010] In another example, an apparatus is provided, comprising: means for executing instructions; means for generating a prediction of one or more required supplementary operations in the instructions; and means for injecting microcode corresponding to the supplementary operations into processing circuitry in response to the prediction.

[0011] Further aspects, features, and advantages of this technology will become clear from the following description of the examples, which is read in conjunction with the accompanying drawings. Attached Figure Description

[0012] Figure 1 The diagram illustrates a data processing system in which this technology can be applied;

[0013] Figure 2 The diagram illustrates the processing circuitry accessing data stored in a memory with a secure area;

[0014] Figure 3 The diagram illustrates the transition between safe and unsafe operating states.

[0015] Figure 4 The diagram illustrates how instructions executed in various security states access data in memory.

[0016] Figures 5A to 5C This is a flowchart illustrating the execution of state transition instructions;

[0017] Figure 6This technical diagram illustrates a portion of a data processing pipeline;

[0018] Figure 7 This is a flowchart illustrating the execution of state transition instructions;

[0019] Figure 8 The diagram illustrates a portion of the data processing pipeline, including a microcode predictor and injection circuitry.

[0020] Figure 9A and 9B This is a flowchart illustrating the prediction and insertion of the supplementary operation;

[0021] Figure 10A and 10B This is a flowchart illustrating the microcode that predicts whether a state transition initialization operation will be needed;

[0022] Figure 11 The illustration shows a technique for predicting whether microcode representing state transition initialization operations will be needed based on the safety requirements of the instructions.

[0023] Figure 12 The diagram illustrates a series of data access commands for accessing data in the array; and

[0024] Figure 13 The illustration shows a technique used to determine whether the processing circuitry requires array boundary checks. Detailed Implementation

[0025] According to one example configuration, an apparatus is provided, comprising: processing circuitry adapted to execute instructions from an instruction stream, the instruction stream including a state transition instruction and subsequent further instructions, wherein the processing circuitry changes a security state in response to the state transition instruction; issuing circuitry adapted to issue the further instructions for speculative execution prior to the completion of the state transition instruction, the further instructions having a requirement regarding the security state; and completion circuitry adapted to perform a completion operation on the further instructions, including checking whether the requirement regarding the security state is met.

[0026] According to this technology, a subsequent instruction (further instruction) following a state transition instruction is issued regardless of whether its security state requirements match the current security state of the operating system, and a check is performed on whether the security requirements of the instruction are met when the completion circuit completes the instruction (e.g., before or during completion). This avoids the need for the processing circuit to assume that the requirements of any instruction midway through execution do not match the updated security state of the operating system, thus eliminating the need to trigger a flush in response to every change in the security state. This allows for improved system performance by reducing the likelihood of pipeline flushing, thereby avoiding the performance impact associated with flushing. Furthermore, this technology does not rely on delaying the insertion of instructions into the pipeline until it can be determined whether the appropriate security state requirements are met, which would also be inefficient. This may be counterintuitive to those skilled in the art, as it allows instructions to be executed even when the security state of the processing circuit does not meet the security state requirements associated with the instruction at the time the instruction is issued. Those skilled in the art will anticipate that this poses a risk to the security of the operation associated with the issued instruction. However, by providing a completion circuit to perform a check on whether the security state requirements are met as part of the completion operation, security in the system can be maintained.

[0027] In some examples, the security state is one of a first security state and a second security state; the processing circuit transitions from the first security state to the second security state in response to a state transition instruction; and the requirement regarding the security state indicates the required security state, and the operation includes checking whether the required security state matches the second security state.

[0028] In this example, the requirement regarding the safety state (also known as the safety requirement) is the safety state of the processing circuit in which further instructions are expected to be executed. However, according to these examples, further instructions can still be issued by the issuing circuit, regardless of whether the safety state requirement is met at the time the further instructions are issued, because the safety requirement is not checked until the completion circuit performs the completion operation. Specifically, since the state transition instruction in this example causes the processing circuit to transition from a first safety state to a second safety state, the completion circuit checks whether the safety state requirement of the further instructions matches the second safety state. However, this check is not performed until the completion phase, meaning that further instructions can still be issued and speculatively executed before the state transition is executed. This improves system performance by avoiding the need to trigger a flush after the state change.

[0029] In some examples, the completion operation includes: completing further instructions when the completion circuit determines that the required security state matches the second security state; and triggering flushing when the completion circuit determines that there is a mismatch between the required security state and the second security state.

[0030] Triggering a flush before a further instruction completes, when a mismatch exists between the required security state and the second security state, protects data that would otherwise be accessed by that instruction from being accessed in the wrong security state. This improves system security. There are performance effects associated with flushing, and those skilled in the art may worry that this will offset the performance benefits of speculatively executing further instructions as in this art. However, it is possible that the further instruction will have a security state that matches the second security state, especially upon completion, so that the probability of flushing being triggered by the completion operation is small enough that the performance gain still outweighs the negative effects of flushing.

[0031] In some examples, further instructions specify a target address, which has security attributes indicating requirements regarding the security status.

[0032] There are many ways to indicate a security requirement for a further instruction, but in this example, the further instruction indicates a target address, which itself has security attributes indicating a security requirement. The target address can therefore be used to identify this requirement. This is a simple and effective way to identify the security requirement of a further instruction without requiring the instruction itself to be marked with any additional information.

[0033] In some examples, during speculative execution of further instructions, the processing circuitry is adapted to delay state updates regarding the further instructions.

[0034] State updates can be implicit in the sense that a structure (e.g., memory or cache) is updated due to a non-write operation. During this delay, any updates to the structure that would otherwise occur are instead written to local storage. For example, a read from memory causes a state update in the cache if the read data is stored in the cache (cache line fill). In these embodiments, such (implicit) state updates are deferred. For example, taking a cache update as an example, after data is retrieved from memory, it is stored in local storage, and after the delay has occurred, it is stored in the cache. Another example of (implicit) state updates is updates to branch predictors. Adding a delay in this way helps avoid updates with security state requirements that are not satisfied by the security state of the processing circuitry. This delay allows the security state to be switched to the correct state before the update occurs, which maintains the security of the system. In some examples, a further instruction is part of a block of instructions, where each instruction has the same requirement regarding the security state; and the state update updates at least one data value that is visible to instructions outside the block of instructions.

[0035] In this example, the state update is an update to the location visible to instructions outside the current block of the executed instruction. Since it is not yet confirmed whether further instructions are allowed to complete (due to their security state requirements), there is no guarantee that any state updates made by further instructions are correct. Therefore, delaying state updates such as these improves system security by preventing instructions outside the current block from accessing potentially incorrect data. In some examples, the delayed state update is still visible to instructions within the instruction block. For example, instructions within the instruction block may be allowed to access local memory within the processing circuitry, while instructions outside the instruction block may be prevented from accessing local memory.

[0036] In some examples, the state update updates at least one data value of at least one of the following: cache; register file; and memory.

[0037] Caches, register files, and memory can be visible to instructions outside the current instruction block. Therefore, delaying updates to the state of these structures while speculatively executing further instructions improves the safety of updates.

[0038] In some examples, the completion operation includes issuing a state update when the completion circuit determines that the requirements regarding the safety state have been met.

[0039] Once the security requirements for further instructions have been met after the operation is completed, the state update generated in response to the further instructions can be trusted. Thus, a deferred state update can be completed (e.g., structures such as caches, registers, and memory can be updated as indicated by the deferred state update).

[0040] In some examples, a security state is one of a safe state and an unsafe state.

[0041] Data processing systems can operate in any number of security states, but in some examples, a security state is one of two states—a secure state and an insecure state. In such systems, processes can be marked as secure or insecure depending on whether they are considered trustworthy. Certain memory regions and other critical resources available to the processing circuitry can therefore be identified as secure, making access to these resources dependent on the processing circuitry operating in a secure state, under the control of a program considered trustworthy.

[0042] In some examples, the requirement regarding the security state indicates the required security state; and the completion of the operation includes, when the required security state is an unsafe state, completing further instructions.

[0043] In this example, when the processing circuitry is in a safe state, the execution of both safe and unsafe instructions is permitted. Therefore, if the safety state requirement of a further instruction indicates an unsafe state, the completion operation includes completing the further instruction regardless of whether the safety state requirement is met. This is acceptable because instructions whose safety state requirement indicates an unsafe state do not require trust (e.g., they are not expected to trigger access to resources marked as safe). Therefore, executing these instructions can be considered safe regardless of the current safety state of the processing circuitry. This allows for improved system performance because the processing circuitry does not need to wait for the safety state of the further instruction to match the safety state of the processing circuitry before completing the further instruction when the required safety state is unsafe.

[0044] In some examples, the processing circuitry transitions from a safe state to a non-safe state in response to a state transition instruction; a requirement for a safe state indicates the required safe state; and the operation includes checking whether the required safe state is a non-safe state.

[0045] As described above, when the processing circuitry executes in an insecure state, critical resources marked as secure cannot be accessed, thus protecting these resources from access by programs not deemed sufficiently trustworthy to be allowed to operate in a secure state. When the processing circuitry executes in an insecure state, instructions indicating a secure state should not be allowed to complete because they could trigger access to resources marked as secure, which is not permitted when the processing circuitry executes in an insecure state. Therefore, when the processing circuitry operates in an insecure state (after a state transition instruction that changes the state of the processing system from secure to insecure), instructions with security requirements indicating an insecure state are allowed to complete. Thus, completing the operation includes checking whether the required security state is insecure. This improves system security by protecting any secure data from access by insecure instructions.

[0046] In a data processing system, some operations performed by the processing circuitry may also require the execution of one or more supplementary operations. These supplementary operations can be injected into the processing pipeline as microcode when it is determined that they are needed. Typically, when it is determined that an operation requires a supplementary operation, the pipeline is flushed out of all instructions following that operation before the microcode corresponding to the supplementary operation is injected. This allows the supplementary operation to be executed together with the operation that requires it (e.g., simultaneously or immediately after). Therefore, it would be advantageous to provide an improved method for injecting microcode.

[0047] According to an example configuration, a processing circuit is provided to execute instructions; a prediction circuit to generate a prediction of one or more required supplementary operations in the instructions; and an injection circuit to inject microcode corresponding to the supplementary operation into the processing circuit in response to the prediction.

[0048] One or more instructions require supplementary operations that enable or support the execution of those instructions when executed. By using predictive circuitry to predict the supplementary operations required by the processing circuitry during the execution of one or more operations, it is possible to predetermine whether the corresponding microcode should be injected into the pipeline. This allows microcode to be injected earlier (e.g., before the operation requiring the supplementary operation reaches the execution phase of the processing pipeline), reducing the number of instructions that need to be flushed from the pipeline (e.g., because fewer instructions will be injected between the issuance of the operation requiring the supplementary operation and the injection of the microcode). This is advantageous because it reduces the performance impact associated with execution flushing—which is caused, for example, by the fact that any flushed instruction may need to be reissued and re-executed. The prediction can take any of several forms. For example, the prediction can be simply a prediction of whether a supplementary operation is required, while in other examples it can be a prediction of which supplementary operations are required.

[0049] In some examples, the prediction circuit is adapted to generate predictions based on one or more of the instructions.

[0050] In this example, the predictive circuitry observes the characteristics of one or more instructions and bases its prediction of whether additional operations are needed on these characteristics. Examples of the characteristics observed by the predictive circuitry include the type of operation to be performed in response to the instruction, and the memory location identified by the instruction (if the instruction is a data access instruction such as a load or store instruction).

[0051] In some examples, a branch prediction circuit is provided to generate the prediction direction of a branch instruction; wherein the prediction circuit is adapted to generate a prediction based on the prediction direction.

[0052] The result of a branch instruction determines which of several different instruction sequences will be executed next. If one or more instructions in the selected instruction sequence will require supplementary operations, the result of the branch instruction indicates whether these supplementary operations need to be injected into the processing circuitry. Therefore, in this example, the result of a branch prediction made by the branch prediction circuit is used to predict whether the processing circuitry needs supplementary operations—for example, if the branch prediction predicts that processing will branch into an instruction stream that includes one or more instructions requiring supplementary operations, the prediction circuitry will predict the need for supplementary instructions and inject them into the processing circuitry. Thus, the prediction circuitry according to this technique can base its predictions on information provided by existing architecture within the data processing system. This allows the technique to be implemented with minimal adaptive modifications to the design of existing data processing systems, as it utilizes existing architectures such as branch prediction circuitry.

[0053] In some examples, in response to this prediction, the processing circuitry is adapted to postpone the execution of instructions until microcode is injected into the processing circuitry.

[0054] In this example, when the predictive circuitry predicts that one or more instructions will require a supplementary operation, the processing circuitry suspends the execution of any further instructions until the microcode is inserted. This improves system performance by reducing the number of instructions issued between the issuance of the supplementary operation request and the insertion of the microcode. This, in turn, reduces the number of instructions that need to be flushed from the pipeline when the microcode is injected. If processing is suspended immediately after the supplementary operation request is issued, the microcode can be inserted without flushing the pipeline with intervening instructions because no further instructions are issued. Furthermore, even if processing is not suspended immediately after the supplementary operation request is issued, suspending the pipeline still has performance benefits because doing so reduces the number of intervening instructions that need to be flushed (e.g., if the pipeline is flushed three cycles after the supplementary operation request is issued, only three cycles' worth of instructions will need to be flushed when the microcode is injected).

[0055] In some examples, the processing circuitry is adapted to determine whether an additional operation is required in response to one or more of the instructions; and when it is determined that an additional operation is required, the injection circuitry is adapted to inject microcode into the processing circuitry, and the processing circuitry is adapted to continue execution of the instructions.

[0056] By delaying the injection of microcode until it is determined that it is actually needed, the microcode does not need to be injected immediately after the prediction is made—instead, processing can be deferred until the actual need for the operation is determined (e.g., processing can be deferred until the instruction requesting supplementary operations reaches the execution phase). This avoids the need to flush the microcode out of the pipeline if it is later found that the prediction was incorrect, thus avoiding the negative performance impact associated with flushing.

[0057] In some examples, a flushing circuit is provided to generate a flush in response to an incorrect prediction.

[0058] In these examples, if the prediction is later found to be incorrect, the flushing circuit removes the microcode from the pipeline by performing a flush. This approach can be beneficial for implementing this technique because the performance gain from speculatively injecting microcode when the prediction is correct outweighs the impact of flushing the pipeline in the few cases where the prediction is incorrect.

[0059] In some examples, the processing circuitry is adapted to suppress the execution of supplementary operations in response to incorrect predictions.

[0060] In these examples, incorrect predictions are addressed by suppressing the execution of supplementary operations. This prevents the execution of incorrectly injected supplementary operations due to incorrect predictions without flushing the supplementary operations out of the pipeline. Thus, the negative performance impact of flushing can be avoided.

[0061] In some examples, a masking circuit is provided to suppress the execution of the complement operation by applying a predicate to mask the complement operation.

[0062] In some situations, it may be appropriate to keep the microcode in the pipeline even when the prediction is determined to be incorrect. One situation where this might be appropriate is when the microcode has a limited impact on the system (e.g., if the microcode does not change anything architecturally, such as the program counter). Instead, in these examples, the execution of the supplementary operation (if the prediction is incorrect) can be suppressed by applying a predicate (e.g., a condition) to the microcode. The masking circuit can thus be arranged to apply a predicate to the microcode before it is inserted into the processing circuitry, where the predicate is a condition indicating that either the microcode should not be executed, or the result of the microcode's execution should be discarded, if the prediction is incorrect. As a result, the pipeline does not need to be flushed in response to incorrect predictions, and the negative performance effects of flushing can be avoided.

[0063] In some examples, the processing circuitry is adapted to execute instructions in a safe state; the supplementary operation is a state transition initialization operation, and the prediction circuitry generates a prediction based on the required change of the safe state; and the processing circuitry is adapted to respond to the state transition initialization operation by initializing the processing circuitry in response to the required change of the safe state.

[0064] One advantageous application of this technique, which inserts and supplements microcode corresponding to operations, is when transitioning from one security state to another within a processing circuit. In such a system, processes can be associated with specific security states (in some examples, this could be "safe" or "unsafe"), indicating in which security state the processing circuit needs to operate in order to execute those processes. For example, the security state of a particular process might be set based on whether it is considered trustworthy. Certain memory regions and other critical resources available to the processing circuit can thus be identified as accessible to the processing circuit when it executes in a specific security state, thereby restricting access to these resources to the time when the processing circuit operates in that security state.

[0065] Specifically, changes in the state of the security circuit may require supplementary operations, such as state transition initialization operations, to initialize the processing circuitry in response to the required changes in the security state. Therefore, in some examples, the predictive circuitry predicts whether a state transition initialization operation is needed based on the required changes in the security state and injects the appropriate microcode when necessary.

[0066] In some examples, each of the subset of instructions indicates an address with security attributes that indicate requirements regarding the security state; and the prediction circuitry is adapted to generate a prediction based on the security attributes of each of the subset of instructions.

[0067] There are several ways in which predictive circuitry can be adapted to predict whether a state transition initialization operation is needed for processing circuitry, but in this example, the predictive circuitry is suitable for making predictions based on the security attributes of addresses identified by the instructions to be executed. For example, the predictive circuitry can identify changes in the security attributes between instructions within a subset of instructions, which can indicate that a state transition is imminent or even necessary.

[0068] In some examples, a subset of the instructions is memory access instructions; and the address is a memory access address.

[0069] As described above, certain memory regions can be identified as accessible to the processing circuitry when it executes in a specific security state, thus restricting access to these resources to the time when the processing circuitry operates in that security state. In these examples, specific memory addresses have security attributes indicating whether they are addresses in secure or insecure memory. Memory locations with security attributes indicating a security state are generally not accessible unless the processing circuitry operates in a secure state under the control of a trusted program. Indicating the security attributes of memory access instructions based on memory access addresses is therefore a particularly simple technique for indicating security attributes, requiring no additional labels or information in the instructions.

[0070] In some examples, the address of each instruction in a subset of instructions identifies the storage location in the memory circuit where the instruction is stored.

[0071] Another way to identify the security attributes of an instruction is based on its storage location within the memory circuitry. For example, this could indicate whether the instruction itself is stored in secure or insecure memory.

[0072] In some examples, the instructions include branch instructions; the device includes branch prediction circuitry to generate a predicted direction for the branch instructions; and the prediction circuitry is adapted to generate a prediction when the predicted direction indicates a required change in the safety status.

[0073] Another way to adapt the predictive circuit for predicting whether a state transition initialization operation is needed is based on a prediction generated by a branch predictive circuit. A branch instruction executed by the processing circuit causes a stream of instructions to be executed that requires the processing circuit to be in a different safety state than the processing circuit was in when the branch instruction was executed. Therefore, in some examples, the predicted direction of the branch instruction is used to detect whether a state transition initialization operation is needed. This example of the technique can therefore be implemented using existing structures such as branch predictive circuits.

[0074] In some examples, the prediction direction indicates the branch target address of the branch instruction; and the branch target address has a security attribute that indicates the requirements regarding the security state.

[0075] The prediction direction of branch instructions can take any of several forms. In some examples, the prediction direction indicates whether the expected branch is to be "taken" or "not taken." However, in these examples, the prediction direction takes the form of predicting the branch target address. In this example, since the security attributes of the predicted branch target address indicate the security state in which the processing circuitry needs to operate in order to execute the associated instruction, it can be used to predict whether a state transition initialization operation will be required. This is a particularly efficient implementation of the technique because it uses existing branch prediction structures and information readily available from the target address (e.g., security attributes).

[0076] In some examples, one or more of the instructions correspond to an array access operation, which identifies the location and index of the array; the supplementary operation is an array boundary check operation; and the processing circuitry is adapted to respond to the array boundary check operation by comparing the index with the array size and returning an error indication when the index is outside the array size.

[0077] Processing circuitry may require supplementary operations to perform array boundary checks. Array boundary checks involve checking whether the element identified by the array access operation is a valid element within the array (e.g., whether the index identified by the array access falls within the array boundary). Specifically, if the array access operation is executed by the processing circuitry, array boundary checks may be required depending on the attributes of the array access operation and the array itself. Therefore, in these examples, prediction circuitry is arranged to predict whether the array access operation to be executed requires the injection of microcode corresponding to the array boundary check. The examination mechanism used to predict whether an array boundary check is required can vary, but in some examples, the prediction is based on determining whether a previous array access operation identifying the same target address required an array boundary check. Predicting whether an array boundary check will be required before the array access operation reaches the execution phase reduces the likelihood that pipeline flushing will be required if it is later determined that an array boundary check will be required, thereby reducing the negative performance impact associated with flushing.

[0078] In some examples, a decoding circuit is provided to decode the instruction; wherein an injection circuit injects microcode into the decoding circuit.

[0079] This is a simple implementation of the technique that can utilize existing structures such as decoding circuits, and is particularly advantageous because it does not require the injected microcode to be decoded before being injected into the processing circuitry. However, it should be noted that the microcode may also be injected into different parts of the processing circuitry. For example, the microcode may also be injected after the decoding circuitry, if it has already been decoded.

[0080] Specific embodiments will now be described with reference to the accompanying drawings.

[0081] Figure 1 An example of a data processing apparatus 100 having a processing pipeline comprising several pipeline stages is illustrated. The pipeline includes a branch predictor 102 for performing predictions related to branch instructions. For example, the branch predictor can predict the direction in which a branch instruction will take, and / or the target address of its predictable branch instruction.

[0082] The pipeline also includes a fetch unit / stage 104, which fetches instructions from instruction cache 106 or other memory structures 108, 110. The fetch stage 104 fetches the instruction identified by the fetch address, and the decode stage 112 decodes the fetched instruction to generate control signals for subsequent stages of the pipeline. The instruction fetched by the fetch unit 104 may be subject to branch predictions provided by the branch predictor 102. Specifically, if the branch predictor 102 predicts that a branch will be taken, the fetched instruction will be at the location indicated by that branch.

[0083] The renaming phase 114 performs register renaming to map the architecture register designator recognized by the instruction to the physical register designator that identifies the register 118 provided in the hardware. The issuing phase 120 includes an issuing queue that queues instructions awaiting execution until the operands required to process these instructions are available in register 118, and includes selection circuitry to select instructions for execution phase 122 to execute. Execution phase 122 executes the instructions to implement the corresponding processing operations, and the results of the executed instructions are written back to register 118. Execution phase 122 includes several execution units, such as a branch unit 124 for evaluating whether a branch instruction has been correctly predicted, an ALU (Arithmetic Logic Unit) 126 for performing arithmetic or logical operations, an FPU (Floating Point Unit) 128 for performing operations using floating-point operands, and a load / store unit 130 for performing load operations to load data from memory into register 118 or store operations to store data from register 118 into the memory system. In this example, the memory system includes a Level 1 instruction cache 106, a Level 1 data cache 132, a Level 2 cache 108 shared between data and instructions, and main memory 110. However, it will be understood that this is only one example of a possible memory hierarchy, and other implementations may have additional levels of cache or different arrangements. Access to memory can be controlled using a memory management unit (MMU) for controlling address translation and / or memory prediction.

[0084] The pipeline also includes a completion phase 134. Once instructions have been executed by execution unit 122, they are completed in completion operations performed by completion circuitry 134. Instruction completion includes, for example, writing back to any register 118, writing to the memory system, and performing any other necessary status updates. Completion operations performed by completion circuitry 134 may also include checking the safety status requirements of the executed instructions, which will be discussed in more detail below.

[0085] A flushing circuit 136 is also provided, which generates a flush in response to certain triggers to clear all unfinished instructions from the pipeline. For example... Figure 1 As shown by the dashed lines, the flushing circuit 136 can operate on the acquisition stage 104, the decoding stage 112, the renaming stage 114, the sending stage 120, and / or the execution stage 122.

[0086] Figure 1 The data processing system 100 described herein is configured to operate in one of several security states. For example, Figure 1The data processing system 100 executes in one of a secure state and an insecure state, and the instructions executed by the processing circuitry indicate which of the secure and insecure states is the secure state required for the execution of the instruction. Similarly, the memory 110 can be partitioned into secure memory regions and insecure memory regions, and instructions executed by the processing circuitry in an insecure state can be prohibited from accessing data stored in the secure region of the memory. The data processing system 100 can transition from one secure state to another—for example, in response to a state transition instruction.

[0087] As will be discussed in more detail below, instructions following a state transition instruction can be executed speculatively without first checking that any security requirements they identify are satisfied by the system's current security state. Completion circuit 134 is configured to check during completion operation whether the security state requirements of the executed instructions are satisfied by the system's current security state. If it is determined at this stage that the security attributes of the executed instructions do not match the system's current security state, a flushing circuit is triggered to flush the pipeline.

[0088] The data processing system 100 also includes a microcode predictor 138 for predicting whether the operations performed in the execution phase 132 will require one or more supplementary operations. The microcode predictor may make predictions, for example, based on instructions obtained through branch predictions made by the fetching unit 104 or the branch predictor 102, or based on the security attributes of the instructions obtained by the fetching unit 104. If the execution phase 122 requires supplementary operations, the injection circuit 140 injects microcode corresponding to these supplementary operations into the decoding phase 112. This process will be described in more detail below.

[0089] You will understand, Figure 1 The pipeline shown is just one example, and other examples may have different sets of pipeline stages for execution units. For example, an ordered processor may not have a renaming stage 118.

[0090] Figure 2 The diagram illustrates the access of the processing circuit (execution circuit) 122 to the memory. As described above, the memory 100 can be partitioned into a secure region 202, where the remaining portion of the memory 110 is a non-secure region. Data in the secure region 202 is protected from access by the processing circuit 122 when operating in a non-secure state—the processing circuit is allowed to access memory items stored in the non-secure region of the memory, but is not allowed to access memory items in the secure region of the memory when operating in a non-secure state. On the other hand, when the processing circuit is executing in a secure state, the processing circuit 122 can access data within or outside the secure region 202.

[0091] Figure 3 The diagram illustrates a processing circuit 122 that can transition between a safe state 302 and an unsafe state 304. The processing circuit can be triggered to change the safety state based on instructions. For example, as... Figure 3 As shown, specialized state transition instructions, such as the Branch with Link and Exchange Non-secure (BLXNS) instruction, can be executed to transition the processing circuit from secure state 302 to insecure state 304. The BLXNS instruction also causes the processing circuit to retain contextual information indicating the state of the system prior to the state change. It will be understood that although the instruction shown in the figure is the BLXNS instruction, any specialized state transition instruction that changes the state of the processing circuit can be used.

[0092] Subsequently, in response to a return targeting a specific address, the processing circuitry can be triggered to return from the unsafe state 304 to the safe state 302. For example, this could be an address value reserved to identify a state transition requiring a change from unsafe state 304 to safe state 302. Upon identifying such an address, the processing circuitry retrieves the context information saved in response to the BLXNS instruction and changes the state of the processing circuitry to safe state 302. It will become clear that... Figure 3 The state transition process described is just one example, and other processes are possible. For example, different triggers can cause a state transition to occur, replacing the BLXNS instruction and instructions targeting specific addresses.

[0093] Figure 4 The illustration shows how data access to addresses in memory can be controlled based on the security attributes of their target addresses. Figure 4 This illustrates a first memory access instruction (0) that accesses data in the secure region 202 of memory when the processing circuitry is operating in a secure (S) state. This instruction is allowed to execute because the security state of the processing circuitry matches the security attribute of the memory access address.

[0094] The diagram also illustrates a second memory access instruction (1) for accessing data in secure region 202, but this instruction is executed when the processing circuitry is operating in a non-secure (NS) state. This instruction is therefore not permitted to execute because the attributes of the memory access address do not match the current security state of the processing circuitry.

[0095] Finally, a third instruction (2) is shown, which is a data access instruction to access data in the non-secure region 402. This instruction is executed when the processing circuit is in a secure state (S). However, this instruction will still be allowed to execute even though the security attributes of the memory access address do not match the current state of the processing circuit—in this example, when executed in a secure state, the processing circuit is allowed to access any data in memory. However, it should be noted that this is only an example implementation; it is possible that the processing circuit may be restricted to accessing data with security attributes that match its security state.

[0096] Figures 5A to 5C This is a flowchart illustrating the problem that this technology aims to solve. Specifically, Figures 5A to 5C The diagram illustrates the transition between security states in response to a state transition command from the processing circuit 122.

[0097] Figure 5A The diagram illustrates the response of a typical data processing system to state transition commands. Figure 5A In the method described, a state transition instruction is issued S502, and a further instruction is issued after the state transition instruction S504. The state transition instruction is executed by the processing circuit 122 S506 to transition the processing circuit from one security state to another. In a typical data processing system, a flushing of any incomplete instructions S508 follows the state change so that any instructions identifying an incorrect security state can be removed from the pipeline. Any instructions following the state transition instruction (including previously issued further instructions) are then reissued S510. This arrangement allows the system's security to be maintained by ensuring that any issued instructions match the system's security state. Pipeline flushing thus prevents any instructions issued under the assumption that the security state is the previous security state from being incorrectly executed. However, requiring flushing to be implemented every time a state change is executed has a significant impact on system performance.

[0098] Figure 5B An alternative method for executing state transition instructions is shown. This method also begins by issuing a state transition instruction S502. However, in this example, the next step S512 includes suspending execution until it is determined that the state transition S514 is complete. Once the state transition is determined to be complete, a further instruction S516 is issued. According to this scheme, the performance impact associated with flushing is avoided, therefore when... Figure 5A Compared to the scheme shown, this improves the overall performance of the system. However, the deferred execution still impacts system performance due to the interruption in execution between state transition instructions and further instructions.

[0099] Figure 5CThe diagram illustrates another scheme for executing a state transition instruction. This method also begins at step S502, issuing the state transition instruction. Next, it is determined in S518 whether a further instruction needs to be issued, and this step is repeated until it is determined that a further instruction needs to be issued. When it is determined that a further instruction needs to be issued, the security requirements of the further instruction (e.g., the security attributes of the memory access address indicated by the instruction) are checked in S520. Specifically, it is determined whether the security requirements of the further instruction are satisfied by the security state of the processing circuitry. If it is determined in S522 that the security requirements of the further instruction are not satisfied by the processor state, a deferral or flush is triggered in S524. If the security requirements of the further instruction are satisfied, the further instruction is issued in S526. This technique reduces the probability of needing a flush or deferral by checking the security requirements of the further instruction before issuance, thus improving system performance. However, since the check is performed when the instruction is issued, it does not consider whether the state transition has been completed. Therefore, the security state of the processing circuitry at the time the further instruction is issued may not match the state of the processing circuitry at the time the further instruction is issued. If further instructions are allowed to be executed even when the system’s security state changes between issuing and executing them, this can compromise the security of the system.

[0100] Therefore, it would be advantageous to provide an alternative solution to ensure the security of the processing system without significantly affecting its performance.

[0101] Figure 6 The diagram illustrates the arrangement according to this technology. Figure 1 Part of the processor pipeline described in [the document / document]. Figure 6 The diagram shows the output queue 602 and the selection circuit 604, which are... Figure 1 This is a portion of the issuing circuit 120 shown. The selection circuit 604 selects instructions from the issuing queue 602 for execution by the processing circuit 122. The processing circuit then executes the selected instructions before the completion circuit 134 performs a completion operation, which may include, for example, writing back to any register 118 or the first-level data buffer 132, and may include triggering the flushing circuit 136 to perform a flush.

[0102] As shown in the figure, the instructions in the issue queue can indicate a security state (e.g., secure or insecure). For example, the instructions may be marked with a security state requirement, or they may identify a memory access address with a specific security attribute. In this example, instructions 0 and 1 in issue queue 602 indicate an insecure state, and instructions 3 and 4 indicate a secure state. A secure gateway instruction (SG) is also illustrated in the issue queue, which is an example of an instruction that causes the processing circuit 122 to transition from an insecure state to a secure state.

[0103] When an instruction is issued from the dispatch queue 602 to the processing circuit 122, the processing circuit 122 speculatively executes the instruction, regardless of whether the security state indicated by the instruction matches the system's security state. Then, during the completion operation executed by the completion circuit 134, a check is performed to determine whether the security state requirement indicated by the instruction is satisfied by the processing circuit's current security state. If the required security state indicated by the instruction is satisfied by the processing circuit 122's current security state, the instruction is completed; otherwise, if the required security state is not satisfied by the processing circuit 122's current security state, the flushing circuit 136 flushes the pipeline. It should be noted that the security state requirements of instructions 0 and 1, indicating a non-safe state, can be satisfied even if the system is currently operating in a safe state (as described above, see reference). Figure 4 Using this arrangement, instructions are speculatively issued from the issuance queue 602 without first checking whether their requirements regarding the system's security state are met. Since instructions issued after a state transition (e.g., a security gateway instruction SG) typically have security state requirements that match the state into which the processing circuitry will transition, this reduces the likelihood that pipelines will be deferred during or after state transitions and avoids the security risks of issuing instructions based on the security state of the processing circuitry 122 at the time of issuance rather than at the time the instruction is executed.

[0104] Figure 7 The diagram illustrates a method for executing state transition instructions according to this technology. Figure 7 In this method, a state transition instruction is issued in S502, and a further instruction is subsequently issued in S702, regardless of whether the security state requirement of the further instruction is satisfied by the security state of the processed system. The state transition instruction is executed in S704 to change the security state of the system, and the further instruction is executed in S706, again regardless of whether the security state requirement of the further instruction indicated by its security attribute is satisfied by the security state of the system. Then, after the execution of the further instruction, as part of the completion operation performed by the completion circuit 134, a check in S708 is performed to determine whether the security requirement of the further instruction is satisfied by the current security state of the processed circuit. If it is determined in S710 that the security requirement of the further instruction is not satisfied, the pipeline is flushed in S712. However, it should be noted that the security state requirement of an instruction indicating a non-safe state may be satisfied in some examples even if the processed circuit is in a safe state. Returning to step S710, if it is determined that the security requirement of the further instruction is satisfied by the security state of the processed circuit, the further instruction is completed in S714.

[0105] According to the technique described above, system performance can be improved by speculatively executing further instructions regardless of whether the requirements of the further instructions regarding the security state of processing circuit 122 are met at the time the further instructions are issued. Specifically, this avoids the need to perform flushing or deferred execution every time the processor's security state changes. Thus, the performance impact associated with flushing and deferred execution can be avoided.

[0106] Some operations performed by processing circuitry 122 also require the execution of supplementary operations. Therefore, such operations can be injected into the processing pipeline as microcode when it is determined that they are needed. In a typical system, when processing circuitry 122 determines that a supplementary operation is needed, any unfinished instructions issued after the operation requiring the supplementary operation are flushed from the pipeline, allowing microcode associated with the supplementary operation to be injected into the pipeline. However, this approach—due to flushing—has a significant performance impact.

[0107] Figure 8 The diagram shows... Figure 1 This is part of the processing pipeline described herein, which is adapted to predict when processing circuitry 122 will require supplemental operation. Specifically, Figure 8 A microcode predictor 138 is shown, which provides a prediction of whether the processing circuitry 122 will require supplementary operations, and based on this prediction, causes the injection circuitry 140 to inject the corresponding microcode into the pipeline via multiplexer 802. Multiplexer 802 selects between the injected microcode and instructions acquired by the acquisition circuitry 104, and outputs its selection to the decoding circuitry 112. The decoding circuitry 112 decodes the received instructions and passes them to the processing circuitry 122 for execution, possibly via a renaming stage 114 and an issuing stage 120 (not shown).

[0108] By predicting whether the processing circuit 122 might need a supplementary operation before knowing definitively whether such an operation is required (e.g., before the instruction requesting the supplementary operation arrives at the execution phase 122 of the pipeline), and by injecting the corresponding microcode into the pipeline in response to that prediction, this technique reduces the likelihood of needing a flush, thereby improving system performance.

[0109] Figure 9A and 9B These are two examples of predicting whether the processing circuit 122 needs additional operations and injecting the corresponding microcode into the pipeline in response.

[0110] exist Figure 9AIn the example illustrated, microcode predictor 138 predicts whether processing circuit 122 in step S902 will require a supplementary operation. When it is determined that a supplementary operation is required in step S904, microcode corresponding to the supplementary operation is injected into the processing circuit in step S906. Optionally, the microcode inserted into the processing circuit can be tagged with a predicate (condition) that corresponds to the prediction. Thus, if the prediction / predicate is determined to be incorrect, the instruction is not executed by the processing circuit. If the prediction does not require a supplementary operation, step S906 is skipped.

[0111] In step S908, it is determined whether the prediction made in step S904 is correct. If the prediction is correct, processing continues to S910; however, if the prediction is incorrect, in step S912, either a predicate is used to mask the supplementary operation to prevent the processing circuit from performing the supplementary operation, or the pipeline is flushed. More specifically, if the microcode is marked with a predicate in step S906, then flushing the pipeline is not required in step S912 when the prediction is determined to be incorrect. Instead, the processing circuit responds to the predicate by either not executing the microcode or by discarding the execution result of the microcode.

[0112] Figure 9B The diagram illustrates a method for predicting whether the processing circuit 122 needs an additional operation and, in response, suspending the processor pipeline. The method begins with a prediction, S902, of whether an additional operation is needed. If it is predicted that an additional operation will be needed in S904, processing is suspended in S914 until the processing circuit determines whether an additional operation is actually needed—in other words, whether the prediction is correct. If the processing circuit determines that an additional operation is needed in S916, the associated microcode is injected into the processing circuit in S906, and processing continues in S918. On the other hand, if it is predicted that no additional operation is needed, step S906 is skipped, and processing continues in S918. Returning to step S904, after determining that the processing circuit 122 does not need an additional operation, it is later determined whether an additional operation is actually needed in S920. When it is determined that an additional operation is needed, if it is determined that the prediction in S922 is correct, processing continues in S918. On the other hand, if it is determined that the prediction is incorrect, a flush in S924 is triggered.

[0113] One example of supplementary operations that processing circuitry 122 might require is a state transition initialization operation, used to initialize processing circuitry 122 in preparation for changes in the processor's safe state. In this example, there are several ways to arrange microcode predictor 138 to predict whether a state transition initialization operation will be needed. Figure 10A and 10B Two examples of how this prediction can be generated are provided.

[0114] exist Figure 10AIn the example, the microcode predictor receives a branch prediction (S1002) from the branch prediction circuit 102. Based on this prediction, the microcode predictor determines (S1004) whether the prediction direction requires a change in the safety state of the processing circuit 122. If the prediction direction does not require a change in the safety state, the microcode predictor predicts that no supplementary operation will be needed, and processing continues (S1006). On the other hand, if the microcode predictor predicts a change in the safety state based on the branch prediction, the microcode for the state transition initialization operation is inserted into the processing pipeline (S1008). Thus, this technique can be implemented using existing branch prediction structures.

[0115] Figure 10B The illustration shows an example of predicting whether a state transition initialization operation will be needed based on the safety requirements of the instructions in observation acquisition phase 104. Figure 10B In this method, the microcode predictor observes the security requirements of the instructions obtained by the acquisition circuit 104 in S1010. If the microcode predictor observes a change in the security requirements in S1012, the injection circuit 140 injects microcode for the state transition initialization operation into the decoding stage S1014. On the other hand, if no change in the security attributes is observed, the process continues in S1016.

[0116] Figure 11 The diagram illustrates how the security requirements of the acquired instructions can be used to predict whether the processing circuit 122 needs a state transition initialization operation. Figure 11 The acquisition stage 104 is shown, in which several instructions have been acquired. Some instructions indicate the requirements of the processing circuit 122 regarding the security state—instructions 0, 1, and 2 indicate the non-secure (NS) state as the required security state, and instruction 4 indicates the secure (S) state. Instruction 3 is a security gateway (SG) instruction used to transition the security state of the processing circuit from the non-secure state to the secure state. Figure 11 In some examples, the microcode predictor 138 observes a change in the security requirement from an insecure state to a secure state between instructions 2 and 4. In some examples, this observation includes the microcode predictor 138 observing that a security gateway (SG) instruction has been retrieved, thus predicting that a change in security state is imminent. In other examples, the microcode predictor 138 observes the security attributes of the retrieved instructions. Specifically, the microcode predictor 138 observes that the security attribute (secure) of instruction 4 differs from the security attribute (insecure) of instruction 2, thus using this observed change in security requirement to predict that a state transition initialization operation will be required.

[0117] The microcode predictor 138 and injection circuit 140 can also be used to detect whether the processing circuit 122 needs supplementary operations corresponding to array boundary checks when executing memory access instructions to access data in the array.

[0118] Figure 12 The diagram illustrates accessing data within the array. Figure 12 In the diagram, instruction 0 is a data access request to write data to element 1 of the array. However, element 1 is not present in the array shown, so this access is invalid. Similarly, instruction 2—a request to write a data value to element 11 of the array—is also invalid because the array contains only 8 elements. On the other hand, instruction 1—a request to read data stored at element 5 of the array—is valid. In some cases, allowing such access could grant the application access to arbitrary areas of memory or cause memory errors. Therefore, it would be advantageous to perform an array boundary check that would identify instructions 0 and 1 as invalid. It would also be beneficial for the microcode predictor 138 to be able to predict in advance whether supplementary operations corresponding to the array boundary check will be needed.

[0119] The microcode predictor 138 can predict in many ways whether the processing circuit 122 needs supplementary operations corresponding to the array boundary check. Figure 13 An example is shown.

[0120] The microcode predictor 138 is useful because it can predict whether an array access operation will require the insertion of microcode corresponding to an array boundary check. Figure 13 In this process, the microcode predictor 138 predicts whether an array access instruction acquired by the fetching circuit 104 will require microcode corresponding to an array boundary check by observing the quality of the fetched instructions. Specifically, the microcode predictor 138 includes an array access information storage unit 1102 that stores information about previous array access operations. Specifically, the array access information storage unit 1102 may store an indication of whether an array boundary check was required for a previous array access operation to a specific target address. The microcode predictor 138 can thus predict whether an array boundary check will be required for instructions in the fetch queue 104 based on previously executed array access operations.

[0121] The exact mechanism used for this prediction can vary, but in some examples, the microcode predictor 138 can predict the need for an array boundary check whenever it determines that a previous array access operation specifying the same target address has required an array boundary check. When the array boundary check passes for a particular target address and index, the array access information storage unit 1102 can record this fact so that future accesses for the same target address and index (or smaller non-negative indexes) are not required. In other examples, the microcode predictor 138 can record boundaries calculated from previous array boundary checks for the same target address and determine the rate at which upcoming array access operations approach these boundaries. For example, the microcode predictor 138 can record... Figure 12The previous array boundary checks for the array access described in the diagram are 0 and 7, and it can be observed that the index of the performed array access operation increments by 6 each time. Based on this, the microcode predictor 138 can predict that the index of instruction 2 will be 11, and thus an array boundary check may be required.

[0122] However, it will become clear that the exact method used to generate predictions about whether array boundary checks are needed can differ from the reference method. Figure 13 The example given.

[0123] In any case, by providing the microcode prediction circuit 138 and the injection circuit 140, the system performance can be improved by reducing the likelihood of triggering flushing later when it is determined that the processing circuitry needs supplementary operation. This improves the overall performance of the system by avoiding the performance impact of performing flushing.

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

[0125] While illustrative embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to these specific embodiments, and various changes and modifications may be made therein by those skilled in the art without departing from the scope of the invention as defined by the appended claims.

[0126] Based on some examples, this technology includes:

[0127] (1) An apparatus comprising:

[0128] Processing circuitry to execute instructions;

[0129] Prediction circuitry to generate predictions for one or more required supplementary operations in the instructions; and

[0130] An injection circuit is used to inject microcode corresponding to the supplementary operation into the processing circuit in response to the prediction.

[0131] (2) The apparatus as described in Clause 1, wherein:

[0132] The prediction circuit is adapted to generate the prediction based on one or more of the instructions.

[0133] (3) The apparatus as described in Clause 1, comprising:

[0134] Branch prediction circuitry is used to generate the predicted direction of branch instructions;

[0135] The prediction circuit is adapted to generate the prediction based on the prediction direction.

[0136] (4) The apparatus as described in Clause 1, wherein:

[0137] In response to the prediction, the processing circuitry is adapted to suspend the execution of the instruction until the microcode is injected into the processing circuitry.

[0138] (5) The apparatus as described in Clause 4, wherein:

[0139] The processing circuitry is adapted to determine whether the supplementary operation is required in response to one or more of the instructions; and

[0140] When it is determined that the supplementary operation is required, the injection circuit is adapted to inject the microcode into the processing circuit, and the processing circuit is adapted to continue the execution of the instruction.

[0141] (6) The apparatus as described in Clause 1, comprising:

[0142] A flushing circuit is used to generate flushing in response to an incorrect prediction.

[0143] (7) The apparatus as described in Clause 1, wherein:

[0144] The processing circuitry is adapted to suppress the execution of the supplementary operation in response to an incorrect prediction.

[0145] (8) The apparatus as described in Clause 7 includes: a masking circuit to suppress the execution of the supplementary operation by applying a predicate to mask the supplementary operation.

[0146] (9) The apparatus as described in Clause 1, wherein:

[0147] The processing circuitry is adapted to execute the instructions in a safe state;

[0148] The supplementary operation is a state transition initialization operation, and the prediction circuit generates the prediction based on the required change of the security state; and

[0149] The processing circuit is adapted to respond to the state transition initialization operation by initializing the processing circuit in response to the required change of the security state.

[0150] (10) The apparatus as described in Clause 9, wherein:

[0151] Each subset of the instructions indicates an address having security attributes that indicate the requirements regarding the security state; and

[0152] The prediction circuit is adapted to generate the prediction based on the security attributes of each of the subsets of the instructions.

[0153] (11) The apparatus as described in Clause 10, wherein:

[0154] The subset of the instructions is memory access instructions; and

[0155] The address is a memory access address.

[0156] (12) The apparatus as described in Clause 10, wherein:

[0157] The address of each instruction in the subset of instructions identifies the storage location in the storage circuit where the instruction is stored.

[0158] (13) The apparatus as described in Clause 9, wherein:

[0159] The instructions include branch instructions;

[0160] The apparatus includes a branch prediction circuit to generate a predicted direction for the branch instruction; and

[0161] The prediction circuit is adapted to generate the prediction when the prediction direction indicates a required change in the security state.

[0162] (14) The apparatus as described in Clause 13, wherein:

[0163] The predicted direction indicates the branch target address of the branch instruction; and

[0164] The branch target address has security attributes that indicate the requirements regarding the security status.

[0165] (15) The apparatus as described in Clause 1, wherein:

[0166] One or more of the instructions correspond to an array access operation, wherein the array access operation identifies the location of the array and the index of the array;

[0167] The supplementary operation is an array boundary check operation; and

[0168] The processing circuitry is adapted to respond to the array boundary check operation by comparing the index with the array size of the array and returning an error indication when the index is outside the array size.

[0169] (16) The apparatus as described in Clause 1, comprising:

[0170] A decoding circuit is used to decode the instruction;

[0171] The injection circuit injects the microcode into the decoding circuit.

[0172] (17) A method comprising:

[0173] Execute instructions;

[0174] Generate predictions for one or more of the required supplementary operations in the instructions; and

[0175] In response to the prediction, microcode corresponding to the supplementary operation is injected into the processing circuit.

[0176] (18) An apparatus comprising:

[0177] A device for executing instructions;

[0178] A means for generating predictions of one or more required supplementary operations in the instructions; and

[0179] And means for injecting microcode corresponding to the supplementary operation into the processing circuit in response to the prediction.

Claims

1. An apparatus comprising: A processing circuit is adapted to execute instructions from an instruction stream depending on the security state of the processing circuit, the instruction stream including a state transition instruction and subsequent further instructions, wherein the processing circuit changes the security state of the processing circuit from a secure state to a non-secure state in response to the state transition instruction. The issuing circuit is adapted to issue the further instructions to be speculatively executed depending on the security state before the state transition instructions are completed, each of the further instructions having a requirement regarding the security state; The issuing circuit is adapted to issue the further instructions, regardless of whether the requirements regarding the security status are met; as well as The completion circuit is adapted to perform a completion operation on each of the further instructions in response to the execution of the state transition instruction after the security state of the processing circuit has changed, including checking whether the requirement regarding the security state is met, and completing each of the further instructions when the requirement regarding the security state indicates the unsafe state.

2. The apparatus of claim 1, wherein: The requirement regarding the security status indicates the required security status; and the completion operation includes checking whether the required security status matches the unsafe status.

3. The apparatus of claim 2, wherein performing the operation includes: When the completion circuit determines that there is a mismatch between the required safety state and the unsafe state, it triggers flushing.

4. The apparatus of claim 1, wherein: Each of the further instructions indicates a target address having security attributes that indicate the requirement regarding the security status.

5. The apparatus of claim 1, wherein: During the speculative execution of the further instructions, the processing circuitry is adapted to delay state updates with respect to each of the further instructions.

6. The apparatus of claim 5, wherein: The further instructions are part of a block of instructions, each of which has the same requirement regarding the security state; and The state update for each of the further instructions updates at least one data value that is visible to instructions outside the block of instructions.

7. The apparatus of claim 6, wherein: The state update updates at least one data value of at least one of the following: cache; Register files; and Memory.

8. The apparatus of claim 5, wherein: The completion operation includes issuing the state update when the completion circuit determines that the requirement regarding the security state has been met.

9. The apparatus of claim 1, wherein: The safe and unsafe states are non-speculatory.

10. A data processing method, comprising: Instructions from an instruction stream, including state transition instructions and subsequent further instructions, are executed depending on the security state of the processing circuitry. In response to the state transition instruction, the security state of the processing circuit is changed from a secure state to a non-secure state; The further instructions are issued to be executed speculatively depending on the security state before the state transition instructions are completed, each of the further instructions having a requirement regarding the security state; The further instructions are issued regardless of whether the requirements regarding the security status are met; and In response to the execution of the state transition instruction after the security state of the processing circuit has changed, a completion operation is performed on each of the further instructions, including checking whether the requirement regarding the security state is met, and completing each of the further instructions when the requirement regarding the security state indicates the unsafe state.

11. An apparatus comprising: An instruction execution device for executing instructions from an instruction stream, depending on the security state of the instruction execution device, the instruction stream including state transition instructions and subsequent further instructions; A changing device for changing the security state of the instruction execution device from a secure state to a non-secure state in response to the state transition instruction; Issuing device for issuing the further instructions to be speculatively executed depending on the security state before the state transition instructions are completed, each of the further instructions having a requirement regarding the security state; The further instructions are issued regardless of whether the requirements regarding the security status are met; as well as An operation execution device is configured to perform a completion operation on each of the further instructions in response to the execution of the state transition instruction after a change in the security state of the instruction execution device, the completion operation comprising checking whether the requirement regarding the security state is met, and completing each of the further instructions when the requirement regarding the security state indicates the unsafe state.

Images