JP7307727B2 - Encode the input to the branch prediction circuit - Google Patents

Description

The technique relates to the field of data processing. More specifically, it relates to branch prediction.

A data processing apparatus may have branch prediction circuitry for predicting the outcome of branch instructions before they are actually executed. By predicting the branch outcome before the branch instruction is actually executed, it is possible for subsequent instructions following the branch to begin being fetched and speculatively executed before the branch instruction has completed execution. , which saves performance if the prediction is correct, because subsequent instructions can be executed earlier than they are fetched only after the outcome of the branch is actually known.

At least some examples include a branch prediction circuit configured to store at least one branch prediction state entry associated with a sequence of instructions and receiving at least one input to generate a new branch prediction state entry. at least a portion of the bits based on values associated with the input circuit and the current execution environment in which the sequence of instructions is being executed, wherein the at least one input includes the bits. and a coding circuit configured to perform an encoding operation for encoding.

At least some examples include means for storing at least one branch prediction state entry associated with a sequence of instructions, and means for receiving at least one input to generate a new branch prediction state entry, comprising: means for receiving, wherein one input includes multiple bits; and means for encoding at least a portion of the multiple bits of said at least one input based on a value associated with a current execution environment in which a sequence of instructions is being executed. and a data processing apparatus.

At least some examples include storing at least one branch prediction state entry in association with a sequence of instructions and receiving at least one input to generate a new branch prediction state entry; receiving, one input comprising multiple bits; and encoding at least a portion of the multiple bits based on a value associated with a current execution environment in which the sequence of instructions is being executed. do.

Further aspects, features and advantages of the present technique will become apparent from the following description of examples read in conjunction with the accompanying drawings.

Fig. 2 schematically shows an example of a data processing apparatus with a branch predictor; FIG. 13 shows an example of a coding circuit for the encoded portion of the input to the branch prediction circuit; FIG. 4 is an illustration of an encoded portion of a key-based input associated with the current execution context; FIG. 10 is an illustration of an encoded portion of a key-based input associated with the current execution context; FIG. 10 is an illustration of an encoded portion of a key-based input associated with the current execution context; FIG. 10 illustrates an example of applying a reverse encoding operation to an encoded destination address output by a branch prediction circuit based on a recalculation key associated with the current execution context; FIG. 10 illustrates an example of applying an encoding operation to an instruction address used as part of a query for retrieving a branch prediction circuit; FIG. 4 is an illustration of generating a key based on multiple identifiers associated with the current execution context. FIG. 4 shows an example of a monitor circuit for detecting the rate of instruction fetch faults; FIG. 11 is a graph showing an example where an increase in instruction fetch faults at a rate of 20% or more triggers an error response; FIG. FIG. 11 shows another example of a branch predictor comprising a branch target buffer and a branch direction predictor; FIG. 4 illustrates one form of a branch target buffer in which context information identifying a given execution context is specified within the tag information for each branch target entry for comparison. FIG. 10B shows an alternative implementation in which a region table is used to compress context information into short region identifiers that are used as tag information in branch target buffers. A potential security hazard that can arise in systems using such region tables, where an attacker may take advantage of the property that different execution contexts can reuse the same region identifier from a region table. FIG. 4 illustrates the problem; [0014] FIG. 5 is an illustrative example in which branch information is encrypted before being stored in a branch target prediction structure and decrypted when read out from the branch target prediction structure, based on an encryption key associated with the corresponding execution context; . 13 shows an illustration of a branch target buffer entry and region table in accordance with the illustration of FIG. 12; FIG. FIG. 11 illustrates an example of changing encryption keys when a region table entry is updated; FIG. 4 shows an illustration corresponding to using encryption to protect a multi-target indirect branch predictor from such attacks. FIG. 4 shows an illustration corresponding to using encryption to protect a multi-target indirect branch predictor from such attacks. 4 is a flow diagram illustrating a method of performing a branch target prediction lookup; Fig. 3 is a flow diagram illustrating a method for generating target tag values for lookup based on region tables;

A processing circuit can perform data processing in one of a plurality of execution environments. For example, each execution environment may represent a different software process executed by a processing circuit, different privilege levels of software (e.g., applications and operating systems), different portions of a given software process, different It may correspond to a virtual machine, etc. A branch prediction circuit may be provided for storing at least one branch prediction state entry associated with a sequence of instructions. A branch prediction state entry may specify the predicted nature of a branch, such as a predicted taken or not taken result, or a predicted branch target address. Branch prediction circuitry can be used to predict the outcome of branch instructions before they are actually executed, allowing early fetching and speculative prediction of subsequent instructions based on the nature of the predicted branch. enable execution. Input circuitry may be provided for receiving at least one input for generating a new branch prediction state entry, where the at least one input includes multiple bits. For example, the input may be at least a portion of the instruction address of the branch instruction for which the new entry is assigned to the branch prediction circuit, and/or the actual branch instruction for the branch instruction that may be used as the branch target address predicted for future opportunities. branch target address can be specified. To reduce storage requirements, some embodiments may store branch target addresses indirectly, for example, by specifying them as offsets from the address of the branch instruction.

Branch prediction mechanisms are generally viewed as performance enhancing mechanisms whose mispredictions are not fatal to the security of data processed by the system, but only affect the level of performance achieved. Therefore, one might not normally expect security measures to protect the contents of the branch predictor to be necessary.

The techniques are for performing an encoding operation to encode at least a portion of bits of an input received by an input circuit based on values associated with a current execution environment in which the sequence of instructions is being executed. A coding circuit is provided. The encoded version of the input can then be used to form new branch prediction state entries to be generated for the branch prediction circuit.

Counter-intuitively, the branch prediction circuit provides a route that an attacker can use to circumvent the security protections in place in processing circuits that restrict one execution environment from accessing data associated with another execution environment. It is recognized that you can get The reason for this is that the branch prediction state assigned to the branch prediction circuit by the first execution environment may be accessible from execution environments that have different branch prediction state entries. can be used to control the behavior of branches executed in the second execution environment. Previously, this was simply viewed as a performance issue, as if the second execution environment hit the wrong entry allocated by a different context, and the actual branch outcome of the branch did not match the prediction. , the misprediction could later be identified during execution of the branch by the second execution environment. However, erroneously speculatively executed instructions due to mispredicted branches can still have an impact on data in caches or other non-architectural storage structures used by data processors, and attackers can be utilized to attempt to obtain some information that may be important data accessible from the second execution environment.

input by providing coding circuitry to apply, upon generation of a new branch prediction state entry, encoding at least some bits of an input to the branch prediction circuitry based on values associated with a current execution environment; is based on execution-environment-specific values, the branch predictor will output differently even if two different execution environments are given the same input, tricking another execution context. Certain execution contexts make it more difficult to train the branch prediction circuit with malicious branch information, in an attempt to force the same branch prediction state entry to be reused. This reduces the risk of the types of attacks discussed above. Such a coding circuit is useful and surprising because branch predictors are usually not considered to pose a security risk, but purely as a performance enhancement measure.

In some instances, the encoding operation may include encoding at least some of the bits of the input value based on a value indicative of current execution permissions for which the sequence of instructions is executing. This allows execution environments associated with different execution permissions to encode input in different ways, exposing data accessible to the victim execution environment but not to an attacker. Attempts have made it difficult for an attacker to be able to successfully control the victim execution environment with different execution permissions to branch to the desired target address, because the value associated with the attacker's execution environment is used to encode , it may be difficult for an attacker to guess which values in the input match target inputs encoded using different values associated with different execution environments to attack. It is from.

Encoding operations applied by the coding circuitry may include any operation that changes the bit values of at least some bits of the input based on values associated with the current execution environment. A mere concatenation of the values associated with the current execution environment and the input received by the input circuit is not considered an encoding of at least some bits of the input, because in this case all bits of the input Note that it will still hold the original value. Thus, encoding generally changes the value of at least one bit using a transformation defined by a value associated with the current execution environment.

For example, an encoding operation may involve encoding at least some bits using a key, where the key is based on the current execution environment in which the sequence of instructions is being executed. The encoding operation can include rearranging at least some of the bits using the key (eg, applying bit shifts or other permutations). Additionally, the encoding operation may involve toggling at least some of the bits of the input using the key. For example, toggling may be implemented by applying an XOR (exclusive OR) operation to at least some bits of the input and a key derived from values associated with the current execution environment. XOR operations may be efficient from a performance and hardware standpoint. Alternatively, the encoding operation may include a hash function applied to at least some bits of the input based on the key. the encoding operation can be reversible (e.g., applying a second XOR operation using the same key to the result of the first XOR operation can restore the original input); Or it can be a one-way hash function.

An input to a branch prediction circuit may contain multiple pieces of information. Encoding can be applied to different parts of the input. It is not necessary to encode the entire input.

For example, at least one input may include an index of the instruction address of a branch instruction, which can be used to form a new branch prediction state entry that provides a prediction for that branch instruction. When querying the branch prediction circuit, the branch prediction circuit may receive a query value containing an indication of the instruction address of the instruction for which the branch is predicted, and use the query value to perform a search. The search may, for example, identify whether the branch prediction circuit stores branch prediction state entries associated with one or more instructions, corresponding to the instruction address specified by the query value. For example, each entry may contain some tag information or other state data that allows a search to identify whether a query given to the branch prediction circuit matches that entry. If the query misses and it is subsequently determined that the instruction address indicated by the query corresponds to a branch instruction, specify the tag information or other state corresponding to the query that caused the miss and the actual determined for the branch instruction. A new branch prediction state entry can be assigned to the branch prediction circuit that specifies the branch information for .

In one instance, the coding circuitry encodes at least some of the bits of the query value using a key derived from one or more values associated with the current execution environment prior to performing the search. Arithmetic can be performed. Thus, different execution environments encode the same query differently based on keys specific to that environment, altering the mapping between input queries and entries in the branch prediction circuit that are returned as matching, thereby In order to trick a branch associated with some other query value in a different execution environment into using a prediction state assigned by the attacker's execution environment, an attacker uses which of the inputs as a query to train a branch predictor. It makes it more complicated to predict when to give a value. The advantage of applying the coding to the query value (as opposed to the predicted branch state, such as the predicted destination address for the branch) is that applying the encoding operation to the query input to the branch prediction circuit is an attack. It is essential to apply any decoding when reading branch state information from the branch predictor, as the predicted branch information can still be stored in the clear in the branch prediction circuit. It is not. This can improve performance by avoiding an additional timing pass through the decoding circuitry as it exits the branch predictor.

In another example, at least one input whose bits are encoded by the coding circuit to form a new branch prediction state entry is the destination address of a branch instruction (“branch target address” or “branch target offset”). (also known as ). In this case, the apparatus includes an inverse for performing an inverse encoding operation on output from the branch predictor output in response to a branch predictor search triggered based on a query value indicative of an instruction address. Encoding circuitry (or decoding circuitry) may also be included. An inverse encoding operation can be any operation that reverses the effect of the encoding operation applied by the coding circuit and restores the original values of the bits whose values were modified by the encoding operation. In this case, rather than changing the mapping between query values and accessed branch prediction circuit entries, the predicted branch state is encoded in an environment-specific manner based on a key associated with the current execution environment, Even if the second execution environment thereby hits a branch prediction state entry trained by the first execution environment, the resulting branch prediction will be made if the same entry is accessed from the first execution environment. Expectations may differ. This makes it more difficult for an attacker to successfully control where different execution environments branch by maliciously training the branch predictor. This can improve performance by reducing the chance of hitting the wrong branch predictor state entry.

The de-encoding circuitry can recompute the values of the keys associated with the current execution environment and perform de-encoding operations using the re-computed values of the keys. Therefore, when the current execution environment changes between the time the branch prediction state entry is assigned and the time the branch prediction state entry is accessed to make a prediction, the value associated with the current execution environment is derived. Because the key is recomputed, the reverse encoding operation may yield different information to that given as the predicted branch state for that entry assignment.

To combine the two approaches discussed above, it is also possible to apply the encoding operation to both the instruction address and the destination address of the branch.

A key associated with the current execution environment can be based on a combination of one or more identifiers associated with the current execution environment. For example, keys can be based on any combination of one or more of the following:
Exception level (distinguishes between different modes of operation, e.g. user mode, kernel mode, hypervisor mode)
Privilege level (distinguishes different execute permissions)
ASID (address space ID - distinguishes between different application level execution contexts)
VMID (virtual machine ID - distinguishes between different operating system or virtual machine level execution contexts or applications with the same ASID running under the control of different operating systems or virtual machines)
NS (non-secure/secure) (non-secure/secure state indicating the current security state of the device)
Number of physical processor cores (distinguishes processes running on different processor cores provided in the hardware)
Number of logical cores (distinguishes execution environments running on different logical partitions of shared processor cores provided in hardware)
One or more software writable registers (e.g., this executes under the process so that software can provide further input used to derive the key to provide further variants of the key). making it more difficult for a process that knows the context identifier, such as the ASID or VMID, of the process it is using to predict the value of the key used by that process).

Also, the key can be further generated based on a previously generated random number. This can give further variants of the key generated for a given combination of identifiers associated with the current execution environment, the key used by a device (or the function used to derive the key) makes it difficult for an attacker who is able to identify , to apply that knowledge to other devices that may use different random numbers. The random number may include at least one of a per logical processor component, a per physical processor component, and a system wide component. At least some of the previously generated random numbers can be generated at start-up, so that they change each time the data processing apparatus starts up, providing additional protection against key destruction associated with a given execution environment. provide resistance. For example, a hardware random number generator or pseudo-random number generator can be triggered to generate a new random number each time the device is booted. At least some of the previously generated random numbers may be pseudo-random numbers, for which true randomness may not be desired.

In some embodiments, a sequence of instructions may be executed in one of multiple execution environments configured to execute with the lowest execution permissions (the least privileged execution permission level). For example, an execution environment with lowest execution permissions may contain an application or a sub-portion of an application. In some instances, the coding circuitry may perform the encoding operation further based on an identifier of one of multiple execution environments in which the sequence of instructions is executing with the lowest execution permission. This means that different pieces of application-level software can share the same address translation regime, and therefore can be expected to share the mapping of branch predictor inputs to branch predictor entries. to reduce the risk of one application or part of an application creating the forms of attack discussed above against another application or part of an application sharing the same address translation regime. making it possible.

Detecting the rate of instruction fetch or decode faults and raising an exception or satisfying a predetermined criterion, such as an increase above a predetermined threshold, while a sequence of instructions is executing speculatively A supervisory circuit may be provided to produce an error response in response to the detection rate of instruction fetch and/or decode faults. For example, the threshold may be at least 20% higher than the previous rate. Alternatively, the threshold can be 20% above the average rate for other applications. This can provide techniques for detecting the forms of attacks discussed above. If the number of instruction fetch faults increases, a possible explanation is that an attacker is trying to trick other code into training the branch predictor to execute instructions from improper branch addresses. , which is later detected as a misprediction. Warning of potential attacks can be provided by triggering exceptions or error responses when the rate of speculative instruction fetch or decode faults increases. How the software chooses to respond to such warnings may depend on the specific software being run, but it may be Providing supervisory circuitry to trigger interrupt/error responses can provide a hardware framework for allowing software to respond in an appropriate manner to the software.

In one instance, the branch prediction circuit may include a branch target prediction structure including a plurality of branch target entries, each branch target entry specifying at least one branch target address. The coding circuitry may comprise encryption circuitry for encrypting at least a portion of new branch target entries written to the branch target prediction structure using an encryption key associated with the current execution environment.

Each branch target entry can specify tag information. The apparatus may have branch target prediction circuitry that performs branch target prediction lookups for instruction fetch addresses associated with the current execution environment. A branch target prediction lookup may include determining whether any of the subset of branch target entries specify tag information corresponding to the target tag determined for the instruction fetch address. Can the subset of branch target entries looked up in a branch target prediction lookup include all of the branch target entries of the branch target prediction structure for fully-associative cache implementations? , or only some of the branch target entries (a proper subset of the branch target entries) in a set-associative implementation. In a set-associative implementation, the subset of branch target entries that are looked up may be selected based, for example, on part of the address of a given branch instruction.

In general, the target tag is part of a recent operation of the processing circuitry that indicates some aspect of the instruction fetch address, the current execution environment in which the fetch address occurs, or the current execution point represented by the instruction fetch address. It can be determined in some way based on some property of the past history. The particular tags used may vary depending on the type of branch target prediction structure implemented. For example, the target tag can be derived from the instruction fetch address, or from one or more identifiers associated with the current execution environment, or past branch results leading to the instruction identified by the instruction fetch address. may be based on the history of

Target tag values may be reusable in multiple execution environments. Therefore, target tags do not have to be unique to a particular execution environment. This is because, for example, a particular branch target prediction structure uses tags that are completely independent of the identifiers associated with the current execution environment, or to save circuit area in storing tag information for branch target prediction structures. In addition, the tag information and the target tag are compressed versions of one or more execution environment identifiers that identify the current execution environment, while the tags include at least a portion derived from values associated with the current execution environment. can be based on different versions, so the compressed identifier value can be reusable for each execution environment.

Therefore, it cannot be guaranteed that the target tag used in one execution environment will not match the tag information assigned to entries in branch target prediction structures after execution of branch instructions associated with different execution contexts. Since this can result in false positive hits in the branch target prediction structure, the wrong branch target address can sometimes be returned and branch mispredictions can cause the wrong instruction to be executed after the branch. While such false-positive hits can cause processing performance degradation, they can also trigger the processor to flush pipelined instructions after a mispredicted branch and exit the correct processing path once the branch outcome is resolved. Branch misprediction resolution circuitry may already be in place to handle mispredictions by restarting instruction fetching. Thus, while false-positive hits caused by tag value reuse across multiple execution environments may be resolved in a manner similar to other causes of branch misprediction, and while this affects performance, It would typically not be considered a major problem as it would not typically be considered a risk to data security.

However, it has been recognized that, in practice, such false positive hits in branch target prediction circuitry can pose security vulnerabilities to the data processed by the data processing apparatus. A device may restrict access to some data to certain execution environments, for example using a privilege-based data access protection scheme. A false-positive hit in the branch target prediction circuit can circumvent such security mechanisms, resulting in critical It is recognized that information about information can be obtained by a first execution environment controlled by an attacker. This is surprising because branch prediction mechanisms are usually viewed as performance-enhancing mechanisms whose mispredictions are not fatal to the security of data processed by the system, but only affect the level of performance achieved. is.

The reason for the potential security vulnerability is that an attacker in control of a first execution context could trigger a second execution environment and set its branch target address to a certain known address (hereinafter "fake If the reuse of target tag values between execution environments can be exploited to hit an entry assigned by the first execution environment that indicates the "hit target address"), this would allow an attacker to A second execution environment can be controlled to branch to certain malicious code located at the false hit target address. Consequently, it can be determined that the branch prediction is incorrect because the actual target address of the branch executed by the second execution environment may not match the false hit target address; To reverse the architectural effects of the erroneously executed instruction, any architectural state associated with the erroneously executed instruction can then be rewound to its previous correct state value, while the erroneously Executed instructions can also cause data in caches, or non-architectural processor state such as the translation lookaside buffer (TLB) to change, which can occur after a misprediction has been resolved. may also persist. Attackers may use fake hit target addresses to ensure that the specific addresses where data is cached as a result of mis-executed instructions depend on the important information they wish to access. Sometimes malicious code is designed in Therefore, an attacker can then execute instructions in a first execution environment designed to probe what data has been cached, and during the period in which the mispredicted instruction was executed, a second Performance indicators such as cache miss counts or memory access latency measurements can be used to probe what information has been cached by the execution environment. This allows an attacker to obtain information about potentially sensitive data processed by the second execution environment and bypass the security mechanisms of the system.

Accordingly, at least some of the new branch target entries written to the branch target prediction structure may be encrypted using the encryption key associated with the corresponding execution environment assigned to that branch information. Either the new branch target entry's tag information, or the new branch target entry's branch data (specifying at least the predicted branch target address), or both, can be encrypted. If the tag information is at least partially encrypted using the encryption key when assigning a new branch target entry, then during a branch target prediction lookup, the encryption circuitry uses the determined target address for the instruction fetch address. The tag can be encrypted using a (recomputed) encryption key associated with the current execution environment, and the branch target prediction circuit will determine if any subset of the branch target entries corresponds to the target tag. The encrypted target tag can be compared to the tag information of a subset of the branch target entries to identify whether it specifies tag information to or the encrypted target tag stored in the entry being looked up. The encrypted tag information is either decrypted (unencrypted) and compared to the target tag. If the branch data is encrypted when a new entry is assigned to the branch prediction structure, then the apparatus specifies a subset of the branch target entries identified as specifying tag information corresponding to the target tag in the branch target prediction lookup. may further comprise decryption circuitry for decrypting an encrypted portion of the branch data of one of the .

For example, in one particular instance, in a branch target prediction lookup, if none of the subset of branch target entries looked up specify tag information corresponding to a target tag, and the instruction fetch address does not specify a branch instruction. When specifying a block of one or more instructions to contain, the cryptographic circuitry can encrypt the actual branch information determined for the branch instruction using a cryptographic key associated with the current execution environment. , the branch target prediction circuit may assign the branch target entry to a branch target prediction structure that specifies tag information corresponding to the encrypted branch information and target tag. On the other hand, on a lookup hit, if one of the subset of branch target entries specifies tag information corresponding to the target tag, then the branch information stored in that entry is associated with the current execution environment. The decrypted branch information can be output as predicted branch information for a given branch instruction.

Therefore, in this example, the branch information in the branch target prediction structure is protected by the cryptographic key associated with the corresponding execution environment associated with that branch information, so if one execution environment assigns branch information, that environment is encrypted using the key associated with that environment, so that if a false positive hit happens to happen when another execution environment reuses the same tag information for that entry, the branch information will be passed to the other execution environment. It will be decrypted using the associated key and will not show the same branch target address as originally provided by the execution environment that allocated the entry. It is surprising that encryption is useful in branch predictors, since branch predictors are usually thought of purely as a performance enhancement measure that does not affect data security or consistency. By encrypting branch information using execution environment-specific keys, it is easier for attackers to control where different execution environments branch if they do not know the key associated with each execution environment. Difficult, which makes the types of attacks discussed above much more difficult.

In some instances, the encryption circuitry and decryption circuitry may comprise separate circuitry. For example, in some cases, the operations applied to decrypt encrypted branch information may not be the same as the operations applied to encrypt the branch information, so separate encryption and decoding methods can be applied. Alternatively, the encryption and decryption operations may actually be the same operation. For example, the encryption operation can include applying a reversible operation (e.g., XOR) to the branch information and the encryption key, and the decryption operation can be applied to the encrypted branch information and the encryption key. applying the same reversible operation (eg, XOR) to the . Therefore, in some instances, both the encryption and decryption circuitry may correspond to the same circuitry provided in hardware (no need to provide two separate circuit units). Alternatively, decrypting branch information for one entry in the branch target prediction structure in parallel with encrypting branch information for another entry, even though the encryption and decryption operations are identical. It may still be useful to have separate encryption and decryption circuits so that the

In some instances, encryption keys may include static keys that are fixed to the current execution environment. Therefore, each execution environment can be associated with some fixed key that never changes. This makes it even more difficult for an attacker to predict the outcome of decrypting a value encrypted using one encryption key using a decryption key different from the one used for encryption. may be sufficient to provide sufficient security, in which case one or more of the keys is unknown. Multiple environment-specific keys can be stored in each execution environment's storage structure, but since multiple execution environments can be large, this can require a significantly large amount of storage. A simple technique for determining a static key for the current execution environment is to extract the static key from a common key shared by multiple execution environments and at least one environment identifier unique to the current execution environment. can be derived. For example, the common key may be a previously generated random number as discussed above. For example, the common key may be hashed or modified based on the identifier of the current execution environment, such as the ASID, VMID, etc. mentioned above.

In another approach, the encryption key can include dynamic keys that are variable in the current execution environment. Thus, as well as changing from environment to environment, encryption keys can also change from time to time for a particular environment. This can provide significant security as it reduces the chances of an attacker being able to derive keys for a given environment by observing the behavior of the data processing system over time. Accordingly, the device may comprise key generation circuitry for generating updated encryption keys for the current execution environment. For example, a key generation circuit may use a linear feedback shift register (LFSR) to generate new random or pseudo-random values for a cryptographic key for a given execution environment when needed. A random or pseudo-random number generator such as shift register) may be provided. The timing at which the keys are updated can be arbitrary, or can be in response to some predetermined event, or can be at the expiration of a fixed period of time or number of branch prediction events. . In some instances, the tag information for each branch target entry is stored in the clear, so no encryption or decryption is applied to the tag information. This can simplify tag comparison. Encrypting the branch information may be sufficient to reduce the probability of attacks such as those discussed above.

Alternatively, in addition to (or instead of) encrypting the branch information indicating the branch target address, the tag information can be encrypted. Thus, if an instruction fetch address is identified as referring to a block of instructions containing a branch, and a miss in the branch target prediction lookup, the target tag is the cryptographic key associated with the current execution environment. and the encrypted target tag can be specified as tag information for the assigned branch target entry. In a branch target prediction lookup, decoding circuitry can decode tag information for each of a subset of branch target entries, and branch target prediction circuitry can compare the decoded tag information with the target tags. can. Alternatively, the encrypted target tag from the branch target lookup can be compared directly with the encrypted tag information stored in the branch target prediction structure to determine if the tags match. , avoiding the need for decryption.

In some cases, the tag and branch information can be separately encrypted or decrypted, with one encryption applied to the tag and another applied to the branch, in which case the tag encryption (desired If so, any of the techniques that deal with comparisons in encrypted or decrypted form can be used. However, in other instances tag information and branch information can be encrypted together in a single encryption scheme. If the encrypted value depends not only on the branch information and the environment-specific encryption key, but also on the tag information supplied with the branch (tag information can add additional complexity to the encryption of the branch information). can), this can provide additional security as it may be difficult to break the encryption applied to the branch information. However, in this case, the decoding circuit must branch the entire block of tags and each looked-up entry before the decoded tag can be compared with the target tag to see if there is a matching entry. This may be slow as information may need to be decoded, and if so the decoded branch information can be output.

So, in summary, the technique followed for encryption/decryption and the extent to which branch information and tags are encrypted may depend on the desired trade-off between performance and security.

In general, any information that indicates a branch target address can be used as branch information. In some instances, the branch information (before encryption or when viewed in the clear after decryption) may explicitly indicate the branch target address. A branch target address can be indicated as an absolute address or as a relative address using an offset to the current instruction fetch address where the branch target prediction lookup is performed. In some instances, the branch target address may not be specified directly by the branch information, but the branch information may provide a pointer to some other structure that specifies the branch target address, or Can be used to calculate branch target addresses. Thus, in general, branch information can include any information that allows a predicted branch target address to be determined.

In some instances, the branch information may not specify any other information other than the branch target address. However, in some instances the branch information may further indicate at least one other branch information, and some predictions of branch instructions within a block of one or more instructions identified by the instruction fetch address. It expresses the nature of being For example, the additional information may be whether the branch is a conditional branch instruction, whether the branch target address should be predicted using some other branch target predictor separate from the branch target prediction structure (e.g., target a branch target predictor for predicting the target of a polymorphic branch whose address varies depending on past processing results preceding the branch), or where the branch represents a function call or function return; You can specify whether or not Such additional branch information can be encrypted/decrypted along with information specifying the branch target address.

Although the target tag may depend on the range of properties of the instruction fetch address, in one instance the branch target prediction circuit determines the target tag as a function of at least one environment identifier associated with the current execution environment. can be done. This can help avoid false positive hits between predictions made for the same address that occur in different environments. For example, the environment identifier can include a virtual machine identifier identifying a virtual machine associated with the address and/or a process identifier identifying a process associated with the address.

If the target tag depends on at least one execution environment identifier associated with the current execution environment, one might expect that there should be no reuse of target tag values between execution environments. In practice, however, there may be many different environments that may be executed by the data processing apparatus, although the number of different environments having information stored in the branch target prediction structure may be much smaller at any given time. In turn, expressing the complete environment identifier in each entry's tag information can require a large number of bits, and in practice much of this information can be redundant, but it is a branch target prediction look. For the purposes of up, since it is only necessary to distinguish the current execution environment from other execution environments that currently have branch information cached in the branch target prediction structure, we also call the current execution environment a branch target prediction structure. This is because there is no need to distinguish it from other environments that do not have branch information represented within the structure. Therefore, storing the complete environment identifier unnecessarily increases the size of each region entry, the number of comparators required to compare each bit of tag information with the target tag, and the circuit Enlarge area.

Thus, to reduce circuit area and power consumption, some implementations may provide a region table with multiple region entries, each region entry containing branch context information rather than branch context information. Maps to region identifiers containing fewer bits. Branch context information can include at least one identifier associated with the corresponding execution environment. When performing a branch target prediction lookup, the target tag is determined based on a target region identifier mapped to branch context information (including at least one identifier) by a region table associated with the current instruction fetch address. be able to. The tag information for each branch target entry can specify a region identifier instead of an execution environment identifier. Thus, the region table compresses a large set of execution environment identifiers, and any other information used to identify branch context information, into shorter identifiers that are used as tags within branch target prediction structures. It effectively makes it possible to save area.

In such a region table approach, the number of region entries can be finite, so when a new execution environment is encountered that does not already have a corresponding region entry assigned in the region table, a previously assigned to a different execution environment will be assigned. A region entry that has been deleted may need to be reused for the current execution context. If a region entry is reused, the corresponding region identifier may still be used as a tag for the entry in the branch target prediction structure. While these stale branch target entries may be invalidated from the branch target prediction structure to prevent false-positive hits, performing such invalidation may prevent the reused selected Removing the region identifier information may require specialized circuitry to walk through the branch target prediction structure, which can be costly in terms of performance and complexity. In practice, this performance cost may not be justified, since in all cases an obsolete entry is expected to be removed if there is a branch misprediction based on that entry. Therefore, implementations using region tables tend not to invalidate branch target entries when updating the region table, which is prone to false positive hits in the branch target prediction structure. Therefore, encryption/decryption of branch information as discussed above may be particularly useful for branch target predictors that use region tables to improve security.

The encryption key associated with each execution environment can be stored in a separate storage structure, but given the region table, it is efficient if each region entry specifies the encryption key associated with the corresponding execution environment. There are some cases. Thus, the encryption key can be read from the region table at the same time as looking up the target region identifier, obviating the need for a separate lookup of a separate storage structure. This approach also means that there is no need to store encryption keys for every execution environment. Alternatively, keys may be maintained only for specific execution environments that are currently mapped to region identifiers by region tables. For other execution environments, there is no need to maintain any cryptographic keys, as they are not currently involved in branch target prediction structures. Therefore, this approach can further reduce the number of keys that need to be stored.

The encryption key associated with a given execution environment can be updated when the mapping given by a given realm entry in the realm table is also updated. That is, when a Region Entry in the Region Table must be assigned to a different Execution Environment, the encryption key specified for that Region Entry is used to generate a new key for the Execution Environment associated with that Region Entry after a mapping update. can also be updated. This prevents the old key associated with one environment from remaining the same for the new environment, thus ensuring that each environment uses a different key.

In some implementations, the branch context information mapped to region identifiers by the region table may include one or more execution environment identifiers that identify the current execution environment, but may include any other information. can't

However, in other approaches branching context information may also depend on other information. For example, the branch context information may further include the portion of the instruction fetch address where a given region entry was assigned to the region table by a previous branch target prediction lookup. Therefore, a portion of the instruction fetch address is used to look up the region table and identify the corresponding region identifier, which translates that portion of the instruction fetch address into the respective branch target of the branch target prediction structure. • Avoids the need to store tag information in entries. Often the most significant portion of an instruction fetch address may be the same as many fetch addresses used by a given execution environment, all used within a given time frame for a particular execution environment. The number of different values for its most significant portion used across instruction fetch addresses of may be relatively small. Therefore, by representing this portion of the instruction fetch address in the region table and compressing it into a short region identifier along with the execution environment identifier, the amount of tag storage required for each branch target entry, and the target • The amount of comparison logic for comparing tags to stored tag information can be reduced.

Other forms of branch target prediction structures may use tags independent of the execution environment identifier associated with a given execution environment. For example, one type of branch target prediction structure can be used to predict the target address of certain branch instructions that change behavior depending on the previous branch taken. For example, the branch target address of a given branch instruction may be different, depending on, for example, the results of earlier conditional instructions, which conditional instructions themselves may depend on the past history of branch outcomes. It can be calculated as one of a range of branch target addresses. For such branch target prediction structures, the tag may depend on the instruction fetch address and the history of branch outcomes of previous branch instructions preceding the instruction at the instruction fetch address, but the environment identifier of the current execution environment. can be independent of Thus, with this type of tag, the value of the tag can be reusable in multiple execution environments, as the history of a given instruction address and branch outcome may have been generated in different environments. In an attempt to force the victim environment to branch to some instruction address controlled by the attacker environment due to false-positive hits between different environments, this again gives the attacker a branch target prediction structure, It may provide a path to be populated with branch information for a given branch history that is expected to be used in some victim environment of interest. By using encryption (and decryption if necessary) of branch information and/or tag information in branch target prediction structures as discussed above, Decrypting encrypted branch information can make such an attack more difficult because it is less likely to reach known addresses that can be controlled by the attacker.

FIG. 1 schematically illustrates an example of a data processing apparatus 2 having a processing pipeline comprising multiple pipeline steps. The pipeline includes a branch predictor 4 for predicting the outcome of branch instructions and for generating a sequence of fetch addresses for fetched instructions. Fetch step 6 fetches the instruction specified by the fetch address from instruction cache 8 . A decode step 10 decodes the fetched instructions to generate control information for controlling subsequent steps in the pipeline. A rename process 12 performs register renaming, mapping the architectural register specifiers specified by the instruction to physical register specifiers that specify registers 14 provided in hardware. Register renaming can be useful to support out-of-order execution, but it also prevents failures between instructions that specify the same architectural register by moving them into the hardware register file. This is because it can be eliminated by mapping to different physical registers, increasing the likelihood that instructions can be executed in an order different from their program order as they were fetched from cache 8, and increasing the likelihood that operands will be available ahead of time. Performance can be improved by allowing backward instructions to execute while other instructions are waiting. The ability to map architectural registers to different physical registers can further facilitate architectural state rollback in the event of a branch misprediction. Issue step 16 queues instructions awaiting execution until the operands needed to process those instructions are available in registers 14 . Execution step 18 executes the instructions to perform the corresponding processing operations. A writeback process 20 writes back to the registers 14 the results of the executed instruction.

The execution step 18 uses a branch unit 21 for evaluating whether the branch instruction was correctly predicted, an arithmetic logic unit (ALU) 22 for performing arithmetic or logic operations, and floating point operands. Floating point unit 24 for performing operations and load operations for loading data from the memory system into registers 14 or store operations for storing data from registers 14 to the memory system. may include multiple execution units, such as the load/store unit 26 of the In this example, the memory system includes level 1 instruction cache 8, level 1 data cache 30, level 2 cache 32 shared between data and instructions, and main memory 34, although this is possible. It should be appreciated that this is just one example of a memory hierarchy, and that other implementations may have additional levels of caches or different arrangements. Load/store unit 26 may use translation lookaside buffer 36, and fetch unit 6 may use translation lookaside buffer 37 to retrieve virtual addresses generated by the pipeline. It can be mapped to a physical address that identifies a location within the memory system. It should be appreciated that the pipeline shown in FIG. 1 is just one example, and that other examples may have different sets of pipeline steps or execution units. For example, an in-order processor may not have a rename step 12 .

FIG. 2 illustrates an example of providing inputs to branch predictor 4 to generate new branch prediction state entries to be assigned. The input contains multiple bits. For example, the inputs in this example specify the instruction address of an instruction identified as a branch, and a branch destination address (target address) that indicates the address to which the branch will be taken when it is taken. A coding circuit 52 is provided for performing an encoding operation on at least some bits of the input based on values 54 associated with the current execution environment in which the sequence of instructions is being executed. The encoded input values resulting from the encoding operation are then provided to branch prediction circuit 4 . For example, encoding can be applied to all or part of either or both of the input instruction address or destination address.

Figures 3A-3C illustrate different examples of implementing the encoding operation (in example Figures 3A and 3B it is applied to part of the destination address of the branch, but as in example Figure 3C can also be applied to instruction addresses). As shown in FIGS. 3A-3C, some bits of the input address can be removed before the encoding operation is applied to the remaining bits. In FIG. 3A, a rearrangement of the relative order of the remaining bits is performed based on keys derived from values associated with the current execution environment (or current execution permissions). For example, a right shift by the number of bits specified by the key, or some other bit permutation may be performed. In the example of FIG. 3B, the encoding operation is implemented as an XOR of the key and selected bits of the input to the branch predictor. XOR is an example of a reversible encoding operation where the reverse encoding operation can be performed by performing a further XOR based on the corresponding key. In the example of FIG. 3C, a hash function can be applied to bits of the input selected based on the key. Note that the key need not contain the same number of bits as the selected bits to be encoded. In general, regardless of the particular form of encoding applied, some values of the input will have their bit values modified before the input to be encoded is presented to the branch prediction circuit. In the examples of FIGS. 3A and 3B showing encoding of the destination address, the removed bits may be bits whose values can be inferred or known when applying the inverse encoding. be. For example, if the instructions are already aligned to their size, one or more low order bits of the address can be removed so that they are always zero. Similarly, if the destination address is expressed as an offset from the instruction address, the high-order bits may always be zero, so there is no need to restore them when applying the reverse encoding. can be removed before applying. In contrast, for encoding instruction addresses, this approach does not require reverse encoding, and since the transformation can be a one-way transformation, there is no need to ensure that the removed bits can be restored by reverse encoding. .

Figures 4A-4B show two examples of querying the branch prediction circuit to retrieve predicted branch information in response to a query specifying a given instruction address. FIG. 4A may be used in an example where coding circuit 52 of FIG. 2 applies an encoding operation to at least some bits of a branch's destination address. In this example, a query is given to the branch prediction circuit specifying the instruction address on which the branch prediction is to be made. Branch prediction circuit 4 performs a lookup of its storage structure to determine if any entry matches the query, and if an entry matches, the encoded destination address (current execution generated by coding circuitry 52 based on values 54 associated with the environment) are retrieved and output. Inverse encoding circuitry 56 (which may be identical to coding circuitry 52 in some embodiments, or may be different depending on the encoding/decoding algorithm implemented) performs matching (as in FIG. 2). 2, except that the branch prediction entries for FIG. Apply the reverse encoding operation to the destination device to be encoded based on a recalculation key 58 formed in the same manner as the values associated with the current execution environment 54 used in . Thus, if the matching entry is accessed after being triggered by the same execution environment that the query assigned the entry to, the resulting destination address output by de-encoding circuit 56 will be the same as the one originally given as input in FIG. same as the specified destination address. However, if the matching entry is accessed from a different execution environment than that assigned the entry, the decoded destination address 60 will be different than originally assigned. The encoding/decoding algorithm and/or the key (or the method used to generate the key) allows an attacker to reverse-encode the address 60 using a different key than the one that encoded the address. ) should be given as input in Figure 2 to match the desired branch target address where the attacker wants some other execution environment to branch can be chosen to make it difficult to predict

FIG. 4B illustrates the encoding operation applied by coding circuit 52 to the instruction address (or other tag information used by branch prediction circuit 4 to locate matching entries) for querying branch prediction circuit 4. It shows an alternative technique used. In this case, when querying the branch prediction circuit 4 to perform a branch information search, the corresponding coding circuit 52 (which may be the same physical circuit as used in FIG. 2, or may be a different circuit). ) performs the same encoding operation based on the recalculated recalculated key 58 (which is recalculated at the time the branch predictor is queried) based on the identifier associated with the current execution environment. Apply to the queried instruction address, eg, apply a one-way hash to encode the instruction address according to the key. In this approach, the data output from the branch prediction circuit 4 need not be encoded, but instead a mapping between the query given as input to the branch predictor and the locations in the branch predictor that are likely to match the query. The use of reversible arithmetic is not essential, as scrambling provides resistance to attacks. Therefore, the branch prediction circuit 4 is searched based on the hashed query information and the destination address 62 output from the matching entry is output in the clear without any de-encoding applied and the query It can be used as a predicted branch target address for branches represented by instruction addresses provided as inputs.

FIG. 5 shows an example of forming a key from multiple identifiers associated with the current execution environment. These identifiers can be obtained from one or more control registers associated with processing pipeline 2, which specify the nature of the current execution environment. For example, a key can be based on any of the following:
・Exception level 79
・Execution privilege level 80
- Address space ID (ASID) 81
- Virtual machine ID (VMID) 82
- Security status (NS) 83
・84 physical cores
・85 logical cores
• A random value 86, which can be a true random number or a pseudo-random number. The (pseudo)random numbers include a different per logical processor (pseudo)random number 89 for each logical processor, a different per physical processor (pseudo)random number 90 for each physical processor core, and all logical or Of the system (pseudo)random numbers 91, shared among the physical processor cores but different from system to system to reduce the chance that a key break on one system can be reused on another system. can be derived from at least one of (or any one or more of these). Each of these elements 89, 90, 91 of the random number can be updated each time the data processing device 2 starts up.
• One or more software writable register values 87, which can be written to the registers 14 under software control to add more randomness to the encoding operation.
• Container ID 86 (an identifier that distinguishes different parts of the execution environment at the lowest privilege level with the most restricted access rights).

Of course, it is not necessary to consider all of these parameters for a particular implementation. Encoding operations (and, if necessary, By generating the key for the reverse encoding operation), two different execution environments with different privilege levels are unlikely to have the same key, so an attacker can gain many data accesses in one execution environment. It is difficult to train a branch predictor to trick a privileged execution environment into branching to malicious code that can lead to exposure of secure data. Furthermore, by adding a (pseudo-)random value to the key generation process, it is still difficult for an attacker to determine which key. In particular, using random values means that even if an attacker had complete access to a system, any information obtained by reverse engineering would be different because the (pseudo)random values would be different. This means that it cannot be used to predict the keys that will be used in other systems. Similarly, it may be desirable to have different keys generated for each execution environment on each logical processor core. For complexity and performance reasons, it may not be desirable to have a separate (pseudo-)random number generator for each logical processor. In this case, it may be possible to obtain the same result by using per-processor or per-system-level (pseudo-)random numbers with the number of logical and/or physical cores in the key generation process. In some embodiments, the key generation process may include hashing together various key inputs. The hashing algorithm used can be a (secure) one-way hash.

That is, in some instances a key may be based on a one-way transformation applied to at least one key-in parameter, where the at least one key-in parameter is at least Although it contains one value (eg, ASID, VMID, or the exception level discussed above), it can also contain other inputs, such as random numbers of software writable values. By using a one-way transformation to generate the keys, this is possible even if an attacker could observe all but one of the inputs, know the algorithm, and observe some of the generated keys. also means that an attacker cannot figure out what the missing input (e.g. a random number) is, and thus cannot predict what the keys are for different execution environments. means that you cannot

FIG. 6 illustrates an example in which monitoring circuitry 95 is provided to monitor the rate of instruction fetch faults encountered by fetch step 6 and/or instruction decode faults encountered by decode step 10 . The rate of fetch faults and the rate of decode faults may be monitored separately or as a combined rate. Also, in some instances, only one of these types of faults may be monitored (eg, fetch faults only or decode faults only). Fetch and decode faults can occur for a variety of reasons, one being a branch misprediction by branch predictor 4 . There may be more frequent branch mispredictions if an attacker uses a branch predictor to attempt to cause attacks such as those discussed above. Therefore, the rate of instruction fetch and decode faults can be used as an indicator that can give hints that an attack is underway. Monitoring circuit 95 can trigger an error response (such as by generating an interrupt or exception) if an increase in the rate of instruction fetch or decode faults is detected in a given period of time by a fixed threshold. . FIG. 7 shows a graph aggregating the rate of instruction fetch faults over successive time durations T. FIG. As shown in FIG. 7, if the increase in the rate of instruction fetch faults increases above a threshold (eg, 20%) from one period to the next, the fault handling response is can be triggered. Those skilled in the art will appreciate that there are many ways to use the fault rate to detect attacks within the scope of the present invention (e.g. comparing it to a predetermined threshold or (compared to the fault rate of the execution of How the software chooses to respond to such exceptions may vary, but this provides a means of communicating to the software that an attack is in progress.

FIG. 8 schematically illustrates another example of a branch predictor 4, a branch direction predictor (BDP) 140 for predicting whether a branch instruction will be taken or not taken; A branch target buffer (BTB) 142 for predicting the target address to which the branch instruction will redirect program execution if taken, and a block of program instructions to be fetched from cache 8; A fetch queue 144 for queuing fetch addresses to be processed (although in some cases the fetch queue may be considered part of the fetch step 6 instead of part of the branch predictor 4, the functionality is Note that they are identical). The addresses placed in fetch queue 144 represent the addresses of blocks of instructions to be fetched from instruction cache 8 and are derived from previous predictions of the branch predictor. A unit of instructions fetched from cache 8 in a block is sometimes referred to as a "fetch block" and may have a fixed default size, e.g., 16, 32, or 64 bytes, although in some cases In some cases, partial fetch block fetching may be performed with a size smaller than the default size if the starting address at which the fetch is performed is not aligned with a natural fetch block boundary.

BDP 140, sometimes referred to as a branch history buffer or branch outcome predictor, records branch history information for predicting the outcome of taken/untaken branch instructions. Any known taken/untaken branch prediction scheme may be used for BDP 140 . For example, gshare or TAGE are examples of known branch direction prediction algorithms.

BTB 142 maintains prediction information for multiple branch instructions identified by tags corresponding to portions of instruction addresses for the branch instructions (and possibly context identifiers or other information in the current execution environment). (depending on other information such as the identifier of the Prediction information includes the target address for the branch as well as the instruction address (program counter or PC) of the corresponding branch instruction, some attributes of the branch (e.g., indirect, unconditional, function call , function return, .

Branch predictor 4 further includes a multi-target branch target predictor 146, which is a special kind of branch target buffer used to predict target addresses of branch instructions that are polymorphic, i.e. their Since branch target addresses change from time to time, different instances of execution of branch instructions at the same instruction fetch address may result in different target addresses depending on the results of previous instructions that advanced the branch. Both BTB 142 and multi-target indirect branch target predictor 146 are examples of branch target prediction structures. Additionally, branch predictor 4 comprises a region table 148 that is used to compress context identifiers into short region identifiers that are used as tag information for BTB 142 .

When fetch step 6 initiates a new fetch for a given fetch address to fetch a block of instructions from instruction cache 8, branch predictor 4 uses BDP 140, BTB 142 and target predictor 146 for multi-target branches. , the fetch address is further looked up. If BTB 142 holds predicted branch information, including the branch target address for the program counter address represented by the current fetch address, that information is read from BTB 142 and recognized by BDP 140 . Lookups may be controlled by branch prediction control logic 150 . If the branch is predicted by BDP 140 not to be taken, branch prediction control logic 150 increments the current fetch address incremented by a fixed stride amount by adder 152 as the next fetch address. The next fetch address that selects the version so that it will be used in subsequent cycles sequentially follows the current fetch address. On the other hand, if BDP 140 predicts the branch to be taken, branch prediction control logic 150 selects the predicted branch target output by BTB 142 as the next fetch address. For some instruction fetch addresses, BTB 142 may output an attribute indicating that the address refers to a block of instructions containing a branch previously detected as polymorphic, in which case the polymorphic Branch attributes control branch prediction control logic 150 to select the branch target address output by target predictor 146 for multi-target branches as the next fetch address instead of the output of BTB 142 . A multi-target branch target predictor bases its predicted target address on the branch history of previous branches preceding the current execution point identified by the current instruction fetch address. in contrast to predictions made by irrelevant BTB142.

The next fetch address output by branch prediction control logic 150 is assigned to fetch queue 144 so that when the address eventually reaches the front of the queue, fetch step 6 places the corresponding block of instructions into instruction cache 8 . fetched from Additionally, the next fetch address is input as the current fetch address in subsequent processing cycles to trigger another lookup in the branch predictor 4 for that fetch address. This process continues cycle by cycle to step through the executing program code. If a branch misprediction is detected in branch unit 21, when the actual result of the branch instruction differs from the predicted result produced by branch predictor 4, a signal is sent back to fetch step 6 and placed in the fetch queue. to resume fetching from the actual branch target address and update the contents of the various prediction structures 140, 142, 146 based on the actual outcome of the branch to increase the likelihood that predictions will be correct in the future. .

In summary, the BTB 142 (sometimes known as the branch target address cache (BTAC)) is the branch predictor 4's cache used to identify the predicted target address of a branch. It is a component. Thus, the BTB effectively contains each entry containing the branch location (of the branch instruction, program counter, or branch instruction address), the predicted target address for the branch, and possibly whether the branch is conditional, It can also be a cache of small entries giving other characteristics such as an attribute specifying whether a branch represents a function call or a function return. To avoid unnecessary address collisions, since different execution contexts (e.g., different processes running by processor 2 or different virtual machines) may use the same virtual address to refer to different branches. Each BTB entry may be tagged with contextual information such as process identifiers and/or virtual machine identifiers.

FIG. 9 shows an implementation of the BTB in an embodiment that does not use region table 148. FIG. In this example, the BTB 142 includes a plurality of entries 156, each entry 156 including a tag portion 158 that provides tag information for identifying whether the entry is associated with the current fetch address during a BTB lookup, and a branch target. • a data portion 160 that provides predicted branch information including an address 166 and any other information 168 associated with the current corresponding branch; In this example, the tag portion 158 includes as tag information the execution environment (context) where the corresponding branch is executed and the instruction fetch address 164 corresponds to the branch (the program counter of the block of instructions contains the branch). ), specify one or more execution environment identifiers 162 . The data portion includes a branch target address 166 and other information 168 such as attributes specifying whether the branch is conditional, function core, function return, and so on.

In some implementations, data portion 160 may further include the least significant bits of branch address 164 (not shown in FIG. 9). This may be useful in superscalar processors, where multiple instructions are executed per cycle, in which case branch predictor 4 needs to predict blocks of multiple instructions in parallel, so each entry may map to a block of instructions. The least significant bits of the instruction fetch address may be omitted from the tag portion 158 so that any instruction within the block can match against the entry. However, if an instruction fetch address is input from the block represented by a given entry, but the instruction fetch address is later than the address of the last branch that occurred in the block associated with that entry, then the No branch is taken after the instruction fetch address, so the branch prediction associated with that branch should not be performed. Thus, by including the least significant bits of the branch address in data portion 160 of branch target address entry 156, this is represented by the matching entry given the current instruction fetch address looked up in BTB 142. allows a decision to be made as to whether a given prediction should be executed.

The cache provided in the BTB can be implemented in various ways. In some instances, a cache can be fully associative such that branch information for a given branch can be placed anywhere within the BTB. In practice, however, a set-associative cache implementation may be more efficient, in which case the branch information for a given branch can be stored during a branch target buffer lookup. May be limited to a specific set (identified based on instruction fetch addresses for instruction blocks containing branches) to reduce the number of entries that must be looked up for a given fetch address .

Typically, the BTB can have a relatively large number of entries, eg thousands, so that it can store enough branch information to provide sufficiently high performance. However, in practice, one execution context can have branch information cached for many instructions in that context, so the number of contexts with information stored in the BTB at a given time can be up to, for example, 10. and possibly much less. Again, many of the branch instructions associated with a given context may all share the same value for the high portion of branch instruction address 164 . This means that if implemented in the manner shown in FIG. 3, the tag information 158 may contain a large amount of redundant information as it explicitly shows the full context of the identifier. , a complete branch instruction address may require a relatively large number of bits for tag 158, increasing the circuit area required for BTB 142 and the comparators required for tag comparison during BTB 142 lookup. also increase the number of

To improve the area efficiency of the BTB, branch predictor 4 can use region table 148 to compress this redundant information into short tag values, as shown in FIG. In the example of FIG. 10, each BTB entry 156 still has a tag portion 158 and a data portion 160, the data portion 160 being the same as in FIG. However, instead of representing the execution context identifier 162 of tag 158 and the full branch instruction address tag 164 within BTB 152, the tag portion is instead the sub-portion 169 of the tag portion of the branch instruction address, as well as the context identifier 162 and the branch instruction. Only the region identifier 171 pointing to the corresponding region entry 170 in the region table specifying the upper portion 167 of the address is specified. Note that the region identifier is not explicitly shown in FIG. 10 for each region entry 170, but is implied from the index of the corresponding region entry 170 (e.g., the first entry in the region table is region identifier #0, the next entry may be associated with region identifier #1, etc.). Region table 148 may be much smaller than BTB 142, having, for example, between 10 and 100 entries, such as 32 in the example of FIG. When looking up the BTB 142, one or more context identifiers identifying the current execution context and the upper bits (eg, bits 48-21) of the program counter are looked up in the region table to find the corresponding region identifier. The region identifier and the lower portion of the program counter tag bits (eg, bits 20-16) are then used as the tag information to look up the BTB 142 . Note that the least significant bits (eg, 15-0) of the program counter are not used at all in the tag, as they are the bits used to index the corresponding set in the set associative's BTB 142 . Thus, region table 148 allows the size of tag portion 158 of BTB entry 156 to be reduced. This is because for the purpose of looking up the BTB 142 it is not necessary to distinguish the current execution context from all other execution contexts, instead what is needed is to keep the current execution context in the BTB 142 with branch information It takes advantage of the fact that it is what distinguishes it from any other execution context it has.

However, when implementing BTB 142 using region table 148, as shown in FIG. 11, this means that branch predictor 4 does not allow branches from one execution context to match the branch information of BTB entries allocated by a different execution context. can lead to some false hits that match This can be seen by comparing FIGS. 10 and 11, which show the contents of the BTB in one example before and after the update to the region table 148. FIG. In FIG. 10, the BTB contains branch information for the current three branches at addr1, addr2 and addr3 respectively (represented by entries 156-1, 156-2 and 156-3 respectively). The branches represented by entries 156-1 and 156-3 are associated with process 1 represented by region table entry #A, and the branch represented by BTB entry 156-2 is associated with region table entry #B. It is associated with process 2 to be represented.

As shown in FIG. 11, a third process now executes a branch instruction, requiring information to be allocated to BTB 142, but process 3 does not currently have any entries in allocated region table 148. do not have. If all region table entries are already occupied, this requires region entry 170 to be deleted and reassigned to a new process, eg, region entry 170-1 previously assigned to process 1. may now be updated to provide the context identifier and the upper address bits associated with process 3. Branch target buffer entry 156-1 may be further updated to replace the previous branch 1 with the new branch associated with process 3. FIG. However, another BTB entry 156-3, specifying region identifier #A of the updated region table entry, may not be invalidated in this step, branch 3 previously associated with process 1. continue to provide information associated with Invalidation logic to walk through the BTB 142 to remove such stale branches when there are updates to the region table is typically not provided because it requires additional circuitry. and such erroneous branch information is expected to be detectable in all cases if predictions are made based on that information, because in execution step 18 This is because the actual branch outcome of a branch differs from the prediction if branch prediction data from the wrong execution context is used, and invalidation of the BTB entries involved can be triggered. Whilst this may cause performance degradation, the same misprediction resolution logic in processing pipeline 2 may cause mispredictions for other reasons not actually related to region table identifier reuse. can be reused, so this is not a big problem. Thus, in a typical BTB implementation using the region table 148, entries with region identifiers that map to the region table entry being updated will be executed in different execution contexts, as in example 156-3 shown in FIG. may persist with stale branch information assigned by

Therefore, if a region table entry is updated, the old entry in BTB 142 may be hit for subsequent branch instructions from new processes assigned to the updated region table entry, which is a different execution context. may cause false hits on previously allocated branch information from . Previously, this was only viewed as a performance issue, not a security issue. However, an attacker could use this property of the BTB to control the speculative execution of another execution context not under the attacker's control, exposing information about secret data managed by that process. It is recognized that it is possible. This is possible if both of the following conditions are met:
• Condition 1: process A can use the target address given to BTB 142 by another process B;
• Condition 2: process B can control the target of the BTB entry accessed by process A;
In the upper illustration of FIG. 11, reuse of region identifiers used as tag information in BTBs between different contexts allows process 3 to use the target address given by process 1 (condition 1). Again, process 1 can control the target of the BTB entry accessed by process 3 because it branches at the desired target address, which shares tag bits [20:16] with process 3's branch. , which will assign the desired target address to the BTB 142 entry hit by process 3 . More generally, these conditions can occur in branch target prediction structures where tag information 158 values can be reused across multiple execution contexts. The region table is one reason why this can happen, but another reason is simply that the tag information does not depend on the identifier of the current execution context (current execution environment).

The above two conditions can be used as the basis for the following attacks. First, an attacker in control of process 1 would have to do something designed to be executed by victim process 3 in order to control it to perform some action that could expose sensitive data to the attacker. It is possible to execute a branch instruction that results in a BTB entry being allocated that specifies a branch target address that maps to a malicious sequence of instructions. After the realm table is updated and the realm identifier previously used by attacker process 1 is reassigned to victim process 3, victim process 3 replaces the tag in the stale BTB entry assigned by attacker process 1 with Instructions are executed from addresses that match the data, and branch predictions are made based on that information provided by the attacker. This would allow the speculative execution of a sequence of instructions to form a branch target address given by an attacker, i.e. by leaving footprints as in non-architectural states (e.g. data caches) , is a special instruction given by an attacker that tricks the victim process 3 into exposing secret data. These instructions may include, for example, memory access instructions that compute the memory address of their target using secret information that the attacker wishes to access. Therefore, data loaded into caches 30, 32 by memory access instructions may depend on secret information. Ultimately a branch misprediction was identified and the architectural state of registers 14 of processor pipeline 2 was rewound to a point prior to a series of instructions being mispredicted and speculatively executed by victim process 3. , data loaded from memory by erroneously speculatively executed instructions can still persist in the caches 30,32. Thus, when execution switches back to attacker process 1, the attacker can attempt to access each possible address resulting from computing the target address based on the secret data. When performing such memory accesses, the attacker process 1 can measure performance data, such as execution times for load instructions, or cache miss counts, etc. From side-channel information such as, it can be determined whether the data from a given address was placed in the cache by victim process 3 or not, which was accessible to victim process 3 but not to the attacker. It can be used to infer the nature of secret data that was not accessible to process 1.

For such an attack to be successful, the two conditions given above need to be met. FIG. 12 illustrates a technique for breaking this second condition that thwarts such attacks by making it difficult for an attacker to control the branch target addresses used by the victim context in the event of a false positive hit. is shown. A branch target prediction structure 142, 146 is associated with the current execution context and an encryption circuit 174 for encrypting branch information written to the branch target prediction structure based on an encryption key associated with the current execution context. A decryption circuit 176 is provided for decrypting the branch information read from the branch target prediction structure based on the encryption key. A key generation circuit 179 (eg, a linear feedback shift register or other random number generator) can generate keys from time to time for each context. Branch target prediction circuit 178 (branch prediction control logic 150 of FIG. 8), as well as for generating target tag values and looking up branch target entries to identify branch information for a given instruction fetch address. , which can correspond to any cache access circuit associated with the branch target prediction structures 142, 146) generates a target tag from the instruction fetch address (e.g., using the region table 148) and branches The branch target prediction structure can be controlled to output encrypted branch information if there is a hit in the target prediction structure. If there is a miss and the branch is subsequently executed by execution step 18, the actual branch information for the branch is encrypted by encryption circuit 174 and associated with the tag information identifying the branch to the branch target prediction circuit. Written to the branch target prediction structure under control. The encryption and decryption circuits 174, 176 are shown as separate circuits in FIG. 12, but may be identical circuits (eg, XOR circuits).

As discussed above, an alternative to encrypting branch information is to encrypt a portion of the target tag, in which case decryption circuit 176 may not be required.

FIG. 13 shows an example of the contents of region table 148 and branch target buffer 142 when encryption/decryption is applied. In this example, each region table entry 170 stores an encryption key 180 associated with the corresponding execution context represented by that region table entry 170 . The keys 180 correspond as random or pseudo-random numbers by a linear feedback shift register (LFSR) or other random number generator 179 such that the keys are different for different execution contexts reusing the same region table entry. It can be generated each time the region table entry 170 is updated. If the BTB 142 lookup misses, fetching continues sequentially beyond the current fetch address, but if a branch from the fetched block of instructions is taken in execution step 18, the actual branch information is determined; It can be assigned to a new branch entry 156 in BTB 142 . When allocating a new entry in the BTB, the branch information is encrypted using the corresponding encryption key 180 stored in the region table 148 for the current execution context. Optionally, a key can be used to encrypt the tag information 158 as well. However, tag encryption is not mandatory. In some embodiments, any additional information 168 stored as predicted branch data 160 may not be encrypted, so only branch target information may be encrypted, but all of branch information 160 may be encrypted. security can be stronger.

During a branch prediction lookup that generates a hit in BTB 142, simply outputting branch information 160 directly from BTB 142 at this time so that tag information 158 matches the target tag generated for the current instruction fetch address. Instead, the branch information is first decrypted using the corresponding encryption key 180 associated with the current execution context defined by the region table 148, then the decrypted branch information returns the next fetch address. used by branch prediction logic 150 to derive The encryption and decryption used to protect the BTB context can be implemented using private key cryptography or using public key cryptography. Since branch target address prediction may be on the critical timing path of the processing pipeline, relatively lightweight cryptographic methods (e.g. branch XORing the information with the key 180) may be useful.

As shown in FIG. 14, this technique can thwart the second condition for the attack discussed above, because the branch information is processed using the key associated with the execution context assigned to that information. by encrypting the same BTB entry 156-3 is accessed from a new execution context and then decrypted using the new execution context's key, it will have the target address Instead, it would generate garbage information, making it difficult for an attacker to push malicious targets into the BTB and control different execution contexts to execute malicious code from a known location. Because it becomes For example, in FIG. 14, an attacker controlling process 1 assigns a particular entry 156-3, then region entry 170-1 is updated to point to process 3 as in FIG. When updating the region table, a new key 180 is generated for region table entry 170-1, so if there is a subsequent hit at BTB entry 156-3 during execution from new execution context 3, the new key is generated. The branch information decoding used does not give the same branch target address as the branch target address originally given by process 1 . Region table entry #A has a new key, while the old information in the branch target information is encrypted with an obsolete key (no longer available in the region table, key 1). To be able to create an attack of the type discussed above and control the victim process 3 to jump to the malicious target address T, the attacker writes Dec(Enc(T', key1), New key) A different target address T' must be given such that ==T, which means that given enough bits for the encryption key, an attacker who does not know the old and new keys will be able to force victim process 3. can be made infeasible to predict the value of T' that must be branched to T at .

13 and 14 show an example in which keys associated with individual execution contexts are cached in region table 148, this is not required, and a separate cache for storing the keys associated with each execution context is shown. storage structures are also possible.

In the examples of FIGS. 13 and 14, the key is a one-time-use dynamic key because it is updated each time a region table replacement occurs. This can make attacks difficult, because the attacker must identify the key and use it to retrieve the secret information before the key's lifetime expires. It reduces the likelihood that someone can learn information about a key by observing a series of branch prediction results from the BTB in the available time before the key is updated. Nevertheless, in other implementations, instead of dynamic keys allocated to region table entries, the same key is used for a given execution context throughout the life of that context. , you can use static keys for each execution context. In this case, an efficient way to generate keys for each context to reduce storage requirements is to provide a common key that is shared among all execution contexts, but that common From the key, it may be to derive a context-specific key by hashing the common key with the context identifier associated with the context.

15 and 16 show examples of using the multi-target indirect branch predictor 146. FIG. For polymorphic branches whose target addresses change from time to time during the program, the BTB 142, which provides fixed target addresses for each branch program counter address, may not be able to provide reliable predictions. A separate prediction structure 146 may be provided. For such polymorphic branches, the branch information in the BTB 142 is updated such that the BTB's predicted target address should not be used in the future, but instead the branch target address for such branches. , may provide an indicator that the multi-target indirect branch predictor 146 should be used to predict. The multi-target indirect branch predictor has multiple branch target entries 190 (e.g., previous branch is performed or not performed). Thus, the same branch instruction can be assigned to multiple entries of multi-target indirect branch predictor 146 corresponding to different branch histories leading up to that branch. Tag information 194 further depends on the instruction fetch address of the block of instructions containing the branch. Unlike BTB 142, tag information does not include the context identifier of the corresponding execution context or the upper bits of the program counter address. Since the tags associated with each entry in the multi-target indirect branch predictor 46 are independent of the current execution context, this again means that tag values can be reused across multiple execution contexts. ing. If an attacker controlling process 2 knew the access pattern (branch history) used to reach a particular indirect branch in victim process 1, the attacker would pose a similar security problem: Pushing a malicious target address tagged with a known branch history pattern (eg, tag A in FIG. 14) accessed by process 1 can be exploited for the problems discussed above. The assumption here is that an attacker can intentionally predict tag conflicts in the multi-target indirect branch predictor 146 .

To prevent this weakness from being exploited, the encryption key 180 from the region table can also be used to encrypt the contents of the multi-target indirect branch predictor 146, as shown in FIG. Thus, when branch information is assigned to entry 190 of multi-target indirect branch predictor 146, encryption key 180 for the current execution context is read from the region table, which corresponds to branch information 192 and, optionally, It is used to encrypt the tag 194 of the entry 190 to be used. Upon lookup of multi-target indirect branch predictor 146, branch information 192 is decrypted using encryption key 180 of the current execution context, whereby the current execution context is assigned by the previous execution context. If an entry is hit, decryption using a key different from the key used to encrypt the data will cause garbage data to be output, unlike the address originally given by the previous execution context. leads to

Thus, even in implementations that do not use region table 148, if the branch predictor uses multi-target indirect branch predictor 146 or another prediction structure that uses tags that are independent of the current execution context, then Encrypting the contents of the branch predictor prevents an attacker from using false positive hits in the branch prediction structure to control the victim process to execute malicious code intended to reveal sensitive data. may be useful for

FIG. 17 is a flow diagram illustrating a method for performing branch target prediction lookups and updating branch information in branch target prediction structures 142,146. It should be understood that FIG. 17 does not show all aspects of branch prediction that can be implemented (e.g., branch direction prediction by BDP 140, as well as halting execution of speculatively executed instructions, mispredicting Not shown are the steps performed to unwind the processor state in the case of (these can be implemented similarly to any known branch prediction technique).

At step 200, a target tag is obtained for an instruction fetch address at which a branch predictor lookup is performed. The specific nature of the target tag depends on how the branch predictor structure is implemented. For example, for a BTB implemented using a region table 148 as discussed above, the target tag may be determined from the region table based in part on the context identifier of the current execution context and the instruction fetch address. can be done. This approach is discussed in more detail in connection with FIG. 18 below. Alternatively, for the multi-target indirect branch predictor 146, the target tag is based on the instruction fetch address and the history of previous taken/not taken results. Other methods of generating target tags are also possible.

In step 202, branch prediction control logic 150 controls branch target prediction structures 142,146 to look up a subset of branch target entries 156,190. The subset of entries may be selected based on instruction address, for example, or, in a fully associative cache implementation, may include all entries of the branch target prediction structure. The branch prediction circuit determines whether any of the set of selected entries specify tag information corresponding to the target tag obtained for the given branch instruction in step 200 . If no subset of branch target entries specify tag information corresponding to the target tag, then the lookup in the branch target prediction structure is a miss and branch prediction control logic 150 outputs an incremented version of the current fetch address. is output from adder 152 as the next fetch address. Once the corresponding block of instructions is decoded, decode process 10 determines at step 203 whether any instruction within the block is a branch instruction. If it does not contain a branch instruction, no branch information needs to be updated and the method ends. If the block of instructions fetched/decoded contains a branch instruction, then in step 204 a victim entry is selected from the subset of branch target entries looked up. For example, if one of the subset of branch target entries is currently invalid, the invalid entry can be selected as the victim entry. If all of the subset of branch target entries are currently valid, one of the valid entries is deleted to make room for new branch information. Any deletion policy can be used to select victim entries (eg round robin or least recently used).

At step 206, once the actual branch information has been resolved by execution process 18 for a given branch instruction, the actual branch information is encrypted using the encryption key associated with the current execution context. Branch information may include information for deriving or specifying a branch target address, and may also include other information about the branch as discussed above. The encryption key can be read from the region table 148 or from a separate storage device. In some cases, the target tag can also be encrypted. At step 208 , the encrypted branch information and (optionally encrypted) tag information determined based on the target tag are written to the victim entry selected at step 204 .

If at step 202 there is a hit in the branch target prediction structures 142, 146 and one of the subset of branch target entries looked up specified tag information corresponding to the target tag, then at step 210: The branch information stored in that matching entry is decrypted using the encryption key associated with the current execution context. At step 212, the decoded branch information is output as a prediction for the given branch instruction. Branch target addresses derived from the decoded branch information are assigned to fetch queue 144 to control subsequent fetching of instructions, and other predictions for branch instructions specified by the decoded branch information. The attributes that are used can control other aspects of the processing pipeline. When the branch reaches execution, the actual branch information can be determined for the branch instruction to determine whether the prediction was correct. If there is a misprediction, the instructions following the branch instruction can be flushed from the pipeline, and if the branch should not be taken, the branch's A signal can be sent to fetch step 6 to resume fetching instructions from the correct target address. Branch predictor 4 is also stored in branch target prediction structures 142, 146 based on actual branch outcomes so that subsequent predictions for the same instruction fetch address are more likely to be more accurate the next time. can be updated to correct branch information

FIG. 18 illustrates in greater detail how target tags are obtained in step 200 of FIG. Fig. 4 is a flow diagram showing; At step 220, region table 148 is looked up based on the branch context information associated with the current instruction fetch address. For example, the branch context information may include one or more context identifiers identifying the execution context in which the branch is executed, and may further include branch instruction address bits above the instruction fetch address. At step 222, the branch prediction control circuit determines that the region table contains matching region table entries 190 where the branch context information stored in entry 190 matches the branch context information provided for the given branch instruction. determine whether there are If it contains a matching region table entry, then there is a hit in the region table and in step 224 the target tag is the region ID associated with the matching region table entry and one of the tag portions of the instruction address or It is determined as containing a plurality of low-order bits (eg, bits 20:16 in the example of FIG. 13). Again, in step 226, the encryption key corresponding to the current execution context is returned from the region table by reading the key from the matching region table entry.

If in step 222 the lookup misses in the region table such that there is no matching region table entry with branch context information that matches the branch context information provided at the current instruction fetch address, then in step 230: A victim realm table entry is selected, e.g., an invalid realm table entry that has not yet been mapped to a particular context, or a valid realm table entry that will be deleted if no invalid entry exists. . Again, deletion policies such as LRU or round robin can be used to select victim region table entries. At step 232, the encryption key 180 stored in the victim realm table entry is updated. For example, a linear feedback shift register or other random or pseudorandom number generator may be triggered to output a new random or pseudorandom number. The updated encryption key is written to the victim region table entry. Additionally, at step 234 , the branch context information determined for the given branch instruction at step 220 is written to the victim region table entry selected at step 230 . The region identifier associated with the victim region table entry has been mapped to a new execution context, and when looked up from the current execution context, any entry in BTB 142 previously mapped to that region identifier will now result in a false positive. Hits may be returned because they were assigned by a previous execution context sharing the same region identifier. However, by updating the encryption key in step 232, the encrypted context of these false positive entries will not behave in the manner expected by the previous execution context that assigned these entries to BTB 142. Therefore, this prevents a malicious process from being able to control a specific branch target address executed by another context in order to map it to a specific address chosen by the attacker. Following step 234, the method of FIG. 18 continues to step 224 where the region table lookup hits to return the target tag for subsequent lookups of the branch target prediction structure and to return the encryption key. Steps 224 and 226 are performed in the same manner as if generated. Following completion of FIG. 18, the generated tag can be used for branch target prediction lookup according to step 202 et seq. of FIG.

In summary, the branch information in the branch target prediction structure is encrypted based on the encryption key associated with the execution context that caused the branch information to be assigned to the branch target prediction structure. Upon lookup of the branch target prediction structure, if there is a hit, the branch information from the matching entry is decrypted using the encryption key associated with the current execution context. Encryption and decryption make it much harder for an attacker to gain access to critical data from another execution context by exploiting false positive hits in entries of branch target prediction structures to contexts that have assigned entries from different contexts. This is useful for branch target prediction structures that use tag information with values that can be reused in multiple execution contexts to ensure

It should be appreciated that the specific examples shown in FIGS. 8-18 are but one example of how a branch predictor may be implemented. More generally, when generating a new branch prediction entry, some of the inputs to the branch predictor can be encoded based on values associated with the current execution context, allowing branching for a given query input. When querying the predictor, the query input can be encoded using values associated with the execution environment that is triggering the query, or the output of the branch predictor can be associated with the latest execution environment. and/or to control the victim process to control branches to specific addresses using false hits in the branch predictor between different execution environments. In addition, it makes it difficult for an attacker to guess which states should be trained in the branch predictor.

Further exemplary arrangements are detailed in the following sections.
(1) a branch prediction circuit configured to store at least one branch prediction state entry associated with a sequence of instructions, and an input for receiving at least one input to generate a new branch prediction state entry; A circuit configured to encode at least a portion of the plurality of bits based on the input circuit and a value indicative of current execution permissions for which a sequence of instructions is being executed, wherein at least one input includes the plurality of bits. A data processing apparatus, comprising: a coding circuit configured to:
(2) Clause (1), wherein the coding circuitry is configured to encode at least some of the bits by using a key, the key being based on current execution permissions under which the sequence of instructions is being executed; data processing equipment.
(3) The data processing apparatus of clause (2), wherein the coding circuit is configured to encode at least part of the plurality of bits by rearranging at least part of the plurality of bits using the key.
(4) The data processing apparatus of clause (2), wherein the coding circuit is configured to encode at least part of the plurality of bits by toggling at least part of the plurality of bits using a key.
(5) The data processing apparatus of clause (2), wherein the coding circuitry is configured to encode at least a portion of the plurality of bits by performing a hash function using the key.
(6) The data processing device according to clause (5), wherein the hash function is reversible.
(7) A data processing apparatus according to clause (2), wherein the coding circuit is configured to encode at least part of the plurality of bits by performing an XOR operation with the key.
(8) The data processing device according to clause (5), wherein the hash function is a one-way hash function.
(9) the at least one input includes an indication of an instruction address of a branch instruction, and the branch prediction circuit is configured to receive a query value including an indication of an instruction address of the branch instruction and perform a search using the query value; , the data processing apparatus according to any one of clauses (2) to (8), wherein the coding circuit is configured to encode at least some of the bits of the query value using the key prior to retrieval.
(10) the coding circuitry is configured to recalculate the value of the key associated with the current execution environment and perform an encoding operation on at least a portion of the multiple bits of the query value using the recalculated value of the key; A data processing apparatus according to clause (9), wherein the data processing apparatus is
(11) at least one input including an indication of a destination address of a branch instruction, the branch prediction circuit receiving a query value including an indication of an instruction address of the branch instruction and performing a search using the query value; any one of clauses (2) through (10), wherein the apparatus comprises decoding circuitry for performing decoding on an output of the branch prediction circuitry output in response to receiving the query value. The data processing device according to .
(12) The data processing apparatus of clause (11), wherein decoding includes recalculating the value of the key and then performing the decoding function.
(13) The key is any combination of values indicating the exception level, privilege level, ASID, VMID, NS, number of physical processor cores, and number of logical cores at which the sequence of instructions is being executed, and one or more software A data processing apparatus according to any one of clauses (1) to (12) further based on a writable register.
(14) The data processing apparatus of any of clauses (1) through (13), wherein the key is further based on a previously generated random number.
(15) The data processing apparatus of clause (14), wherein the previously generated random number includes at least one of a per logical processor element, a per physical processor element, and a system wide element.
(16) The data processing apparatus of clause (15), wherein at least some of the previously generated random numbers are generated at startup.
(17) The data processing apparatus according to any one of clauses (14) to (16), wherein at least some of the previously generated random numbers are pseudo-random numbers.
(18) the key is based on a one-way transformation applied to at least one key input parameter, including at least one value associated with the current execution environment or current execution permissions, clauses (1) through (17); ).
(19) the sequence of instructions is capable of executing in one of a plurality of execution environments configured to execute with the lowest execution permissions, the coding circuitry controlling multiple execution environments in which the sequence of instructions is being executed; A data processing apparatus according to any one of clauses (1) to (17), configured to encode at least part of the plurality of bits further based on an identifier of one of the environments.
(20) detecting the rate of any combination of instruction fetch faults and instruction decode faults during speculative execution of a sequence of instructions, and noting that the rate increases above a predetermined threshold; 19. A data processing apparatus according to any one of clauses (1) to (19), comprising a monitoring circuit configured to generate an interrupt or generate an error response in response.
(21) The data processing apparatus of clause (20), wherein the predetermined threshold is at least 20% above the previous rate.
(22) means for storing at least one branch prediction state entry associated with a sequence of instructions; and means for receiving at least one input for generating a new branch prediction state entry, the at least one input being data comprising a plurality of bits, comprising: means for receiving; and means for encoding at least a portion of the plurality of bits of the at least one input based on a value indicative of current execution permissions for which a sequence of instructions is being executed. processing equipment.
(23) storing at least one branch prediction state entry associated with a sequence of instructions and receiving at least one input to generate a new branch prediction state entry, the at least one input being A method comprising: receiving a plurality of bits; and encoding at least a portion of the plurality of bits based on a value indicative of current execution permissions for a sequence of instructions being executed.
(24) a branch including processing circuitry for performing data processing in one of a plurality of execution contexts and a plurality of branch target entries, each branch target entry indicating at least one branch target address; a branch target prediction structure specifying information; an encryption circuit for encrypting branch information written to the branch target prediction structure using an encryption key associated with the current execution context; and decryption circuitry for decrypting branch information read from the branch target prediction structure using an associated encryption key.
(25) each branch target entry specifies tag information, the apparatus comprising a branch target prediction circuit for performing a branch target prediction lookup on an instruction fetch address associated with a current execution context; the target prediction lookup includes determining whether any of the subset of branch target entries of the branch target prediction structure specify tag information corresponding to the target tag determined for the instruction fetch address; A device according to clause (24).
(26) The apparatus of clause (25), wherein the target tag value is reusable in two or more of the multiple execution contexts.
(27) If none of the subset of branch target entries specify tag information corresponding to the target tag, and if the instruction fetch address specifies a block of at least one instruction containing a branch instruction, then the encryption circuitry , configured to encrypt the actual branch information for the branch instruction using an encryption key associated with the current execution context, the branch target prediction circuit specifying the encrypted branch information, and the target tag Apparatus according to clause (25) or (26), configured to allocate a branch target entry of a branch target prediction structure that specifies tag information corresponding to .
(28) if one of the subsets of branch target entries specifies tag information corresponding to a target tag, the decoding circuit converts the branch information stored in said one of the subsets of entries to the current A branch target prediction circuit configured to decrypt using an encryption key associated with the execution context, and a branch target prediction circuit configured to output the decrypted branch information as predicted branch information for the instruction fetch address. , an apparatus according to any one of clauses (25) to (27).
(29) The apparatus of any of clauses (24) through (28), wherein the encryption key comprises a static key fixed to the current execution context.
(30) the static key for the current execution context is dependent on a common key shared by at least two of the plurality of execution contexts and at least one context identifier specific to the current execution context, clause The device according to (29).
(31) The apparatus of any of clauses (24) through (30), wherein the encryption key comprises a dynamic key that is variable in the current execution context.
(32) Apparatus according to clause (31), comprising a key generation circuit for generating updated encryption keys for the current execution context.
(33) If none of the subset of branch target entries specify tag information corresponding to the target tag, and if the instruction fetch address specifies a block of at least one instruction containing a branch instruction, then the encryption circuitry , is configured to encrypt the target tag using an encryption key associated with the current execution context, and the branch target prediction circuit generates a tag for the branch target entry assigned the encrypted target tag. information, in a branch target prediction lookup, the decoding circuit is configured to decode tag information for each of a subset of the branch target entries; with the target tag.
(34) The apparatus of any of clauses (24) through (33), wherein the branch information further indicates at least one branch information other than a branch target address.
(35) The apparatus of clause (25), wherein the branch target prediction circuit is configured to determine the target tag dependent on at least one context identifier associated with the current execution context.
(36) comprising a region table containing a plurality of region entries, each region entry mapping branch context information to a region identifier containing fewer bits than the branch context information, the branch context information being associated with a corresponding execution context; Apparatus according to clause (25), comprising at least one context identifier.
(37) The apparatus of clause (36), wherein the target tag for the instruction fetch address includes a target region identifier mapped to branch context information associated with the instruction fetch address by the region table.
(38) The apparatus of clauses (36) or (37), wherein each realm entry specifies a cryptographic key associated with a corresponding execution context.
(39) If the mapping given by a given region entry in the region table is updated, the branch target prediction circuit updates the encryption key associated with the execution context associated with the given region entry after the mapping update. A device according to any of clauses (36) to (38), adapted for triggering.
(40) The branch context information for a given region entry further includes a portion of the instruction fetch address to which the given region entry was assigned in the region table by a previous branch target prediction lookup, from clause (36) ( 39).
(41) the branch target prediction circuit is configured to determine if the target tag depends on an instruction fetch address and a history of branch outcomes of previous branch instructions preceding the instruction at the instruction fetch address; A device according to clause (25).
(42) means for performing data processing in one of a plurality of execution contexts; and a branch target prediction structure, each branch target entry specifying branch information indicative of at least one branch target address; means for storing branch target entries; means for encrypting branch information written to the means for storing using an encryption key associated with the current execution context; and means for decrypting branch information read from the means for storing using an associated encryption key.
(43) a branch target of a branch target prediction structure, performing data processing in one of a plurality of execution contexts, each branch target entry specifying branch information indicative of at least one branch target address; - Storing the entry, encrypting the branch information written to the branch target prediction structure using the encryption key associated with the current execution context, and using the encryption key associated with the current execution context. and decoding branch information read from the branch target prediction structure.

In this application, the phrase "configured to" is used to mean that an element of the device has a configuration that enables it to perform the defined action. In this context, "configuration" means the arrangement or manner of interconnection of hardware or software. For example, an apparatus may have dedicated hardware that provides defined operations, or a processor or other processing device may be programmed to perform the functions. "Configured to" does not imply that the device element must be altered in any way to provide the defined behavior.

Although illustrative embodiments of the present invention have been described in detail herein with reference to the accompanying drawings, the present invention is not limited to these precise embodiments, but rather will allow those skilled in the art to follow the appended claims. It should be understood that various changes and modifications may be made therein without departing from the scope and spirit of the invention as defined by.

Claims (25)

a branch prediction circuit configured to store at least one branch prediction state entry associated with a sequence of instructions;
input circuitry for receiving at least one input to generate a new branch prediction state entry, said at least one input including a plurality of bits;
and coding circuitry configured to perform an encoding operation to encode at least a portion of the plurality of bits based on values associated with a current execution environment in which the sequence of instructions is being executed. A processing device ,
the encoding operation includes encoding the at least a portion of the plurality of bits using a key, the key being based on the current execution environment in which the sequence of instructions is being executed;
the at least one input includes an index of a destination address of a branch instruction;
the branch prediction circuitry configured to receive a query value including an indication of an instruction address of an instruction and perform a search using the query value;
The data processing device, comprising a reverse encoding circuit for performing a reverse encoding operation on the output of the branch prediction circuit output in response to receiving the query value. 2. A data processing apparatus as claimed in claim 1, wherein said encoding operation comprises encoding said at least some of said plurality of bits based on a value indicative of current execution permissions under which said sequence of instructions is being executed. . 3. A data processing apparatus according to claim 1 or 2, wherein said encoding operation comprises rearranging or toggling said at least some of said plurality of bits using said key. 3. The de-encoding circuit is configured to re-compute the value of the key associated with the current execution environment and perform the de-encoding operation using the re-computed value of the key. 4. The data processing device according to any one of 1 to 3 . The key is
exception level, privilege level, ASID, VMID, NS, number of physical processor cores and number of logical cores at which said sequence of instructions is being executed, one or more software writable registers, and a previously generated random number; 5. A data processing apparatus according to any one of claims 1 to 4 , further based on any combination of one or more key input values indicative of at least one of them. The previously generated random number is
elements per logical processor,
6. A data processing apparatus as claimed in claim 5 , comprising at least one of: a per physical processor element; and a system wide element. 7. A data processing apparatus according to claim 5 or 6 , wherein said keys are based on unidirectional transformations applied to said one or more key input values. The sequence of instructions can be executed in one of a plurality of execution environments configured to execute with lowest execution permissions, and the coding circuitry causes the sequence of instructions to execute with the lowest execution permissions. 8. Data processing according to any one of claims 1 to 7 , arranged to perform said encoding operation further based on an identifier of an execution environment of said plurality of execution environments being executed. Device. During the speculative execution of said sequence of instructions, any combination of rate of instruction fetch faults and instruction decode faults is detected and an exception is raised in response to said rate meeting a predetermined condition. 9. A data processing apparatus as claimed in any preceding claim, comprising a monitoring circuit configured to generate or generate an error response. the branch prediction circuit comprising a branch target prediction structure including a plurality of branch target entries, each branch target entry specifying at least a branch target address;
The coding circuitry comprises encryption circuitry for encrypting at least a portion of new branch target entries written to the branch target prediction structure using an encryption key associated with the current execution environment. 10. A data processing apparatus according to any one of claims 1-9 . each branch target entry specifying tag information and branch data specifying at least the branch target address;
The data processing apparatus comprises a branch target prediction circuit for performing a branch target prediction lookup on an instruction fetch address associated with the current execution environment, the branch target prediction lookup being performed on the branch target prediction structure. 11. The data processing of claim 10 , comprising determining whether any of a subset of branch target entries specify tag information corresponding to the target tag determined for said instruction fetch address. Device. 12. A data processing apparatus as claimed in claim 11 , wherein said target tag value is reusable in more than one execution environment. 13. A data processing apparatus as claimed in claim 11 or 12 , wherein said encryption circuitry is arranged to encrypt at least part of said tag information of said new branch target entry using said encryption key. . the encryption circuitry is configured to encrypt at least a portion of the branch data of the new branch target entry using the encryption key;
Said data processing apparatus stores said at least part of said branch data of one of said subset of branch target entries identified in said branch target prediction lookup to specify tag information corresponding to said target tag. 14. A data processing apparatus according to claim 13 , comprising a decoding circuit for decoding the . 15. A data processing apparatus as claimed in any one of claims 10 to 14 , wherein said encryption key comprises a static key fixed to said current execution environment. wherein said static key for said current execution environment is dependent on a common key shared by at least two of said plurality of execution environments and at least one identifier unique to said current execution environment; Item 15. The data processing device according to item 15 . 15. A data processing apparatus as claimed in any one of claims 10 to 14 , wherein said encryption key comprises a dynamic key variable to said current execution environment. 18. A data processing apparatus as claimed in claim 17 , comprising key generation circuitry for generating updated cryptographic keys for said current execution environment. A region table comprising a plurality of region entries, each region entry mapping branch context information to a region identifier containing fewer bits than said branch context information, said branch context information being associated with a corresponding execution environment. 15. A data processing apparatus as claimed in any one of claims 11 to 14 , comprising at least one identifier. 20. The data processing apparatus of claim 19 , wherein said target tag for said instruction fetch address comprises a target region identifier mapped to said branch context information associated with said instruction fetch address by said region table. 21. A data processing apparatus as claimed in claim 19 or 20 , wherein each realm entry specifies said encryption key associated with said corresponding execution environment. When the mapping given by a given region entry of the region table is updated, the branch target prediction circuit updates the encryption associated with the execution environment associated with the given region entry after the mapping update. 22. A data processing apparatus according to any one of claims 19 to 21 , arranged to trigger a key update. The branch target prediction circuit is configured to determine the target tag in dependence on the instruction fetch address and a history of branch outcomes of previous branch instructions preceding the instruction at the instruction fetch address. A data processing apparatus according to any one of claims 11 to 14 and 19 to 22 . means for storing at least one branch prediction state entry associated with a series of instructions;
means for receiving at least one input to generate a new branch prediction state entry, said at least one input including a plurality of bits;
and means for performing an encoding operation to encode at least a portion of the plurality of bits of the at least one input based on values associated with a current execution environment in which the sequence of instructions is being executed. A processing device ,
the encoding operation includes encoding the at least a portion of the plurality of bits using a key, the key being based on the current execution environment in which the sequence of instructions is being executed;
the at least one input includes an index of a destination address of a branch instruction;
the means for storing is configured to receive a query value including an indication of an instruction address of an instruction and perform a search using the query value;
A data processing apparatus comprising means for performing a reverse encoding operation on an output of said means for storing output in response to receiving said query value. storing at least one branch prediction state entry associated with a sequence of instructions by a branch prediction circuit ;
receiving , by an input circuit, at least one input for generating a new branch prediction state entry, said at least one input comprising a plurality of bits;
performing , by coding circuitry, an encoding operation to encode at least a portion of the plurality of bits based on values associated with a current execution environment in which the sequence of instructions is being executed . hand,
the encoding operation includes encoding the at least a portion of the plurality of bits using a key, the key being based on the current execution environment in which the sequence of instructions is being executed;
the at least one input includes an index of a destination address of a branch instruction;
The method includes:
receiving, by the branch prediction circuitry, a query value that includes an indication of an instruction address of an instruction, and performing a search using the query value;
performing, by a reverse encoding circuit, a reverse encoding operation on the output of the branch prediction circuit output in response to receiving the query value;
A method, including

Images