Encoding of the input to the storage circuit

Abstract

A data processing apparatus comprises: branch prediction circuitry adapted to store at least one branch prediction state entry associated with an instruction stream; input circuitry adapted to receive at least one input to generate a new branch prediction state entry, wherein the at least one input comprises a plurality of bits; and encoding circuitry adapted to perform an encoding operation to encode at least some of the plurality of bits based on a value associated with a current execution environment in which the instruction stream is being executed. This prevents potential attacks that exploit the ability of branch prediction entries trained by one execution environment to be used as a basis for branch prediction by another execution environment.

Description

Technical Field

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

[0002] In a side-channel attack (SCA), the attacker manipulates the state of a data processing device in order to infer properties of the device that would otherwise be hidden. For example, timing information associated with restricted data might reveal whether the data is stored in the data processing device's cache or main memory (e.g., DRAM). Summary of the Invention

[0003] At least some examples provide a data processing apparatus comprising: storage circuitry adapted to store an entry; input circuitry for receiving at least one input to generate an access request for the entry, wherein the at least one input comprises a plurality of bits; and encoding circuitry for performing an encoding operation to encode at least some of the plurality of bits based on a value associated with a current execution environment.

[0004] At least some examples provide a data processing method comprising: storing an entry; receiving at least one input to generate an access request for the entry, wherein the at least one input comprises a plurality of bits; and performing an encoding operation to encode at least some of the plurality of bits based on a value associated with a current execution environment.

[0005] At least some examples provide a data processing device comprising: a storage device for storing an entry; a receiving device for receiving at least one input to generate an access request for the entry, wherein the at least one input comprises a plurality of bits; and an execution device for performing an encoding operation to encode at least some of the plurality of bits based on a value associated with a current execution environment.

[0006] Other aspects, features and advantages of the present technology will become apparent from the following description of examples read in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1 schematically illustrates an example of a data processing apparatus according to some embodiments;

[0008] Figure 2 An example of a data processing apparatus having a branch predictor is schematically shown;

[0009] Figure 3 An example of an encoding circuit for encoding a portion of an input to a branch prediction circuit is shown;

[0010] Figures 4A-4C An example of encoding a portion of input based on a key associated with the current execution context is shown;

[0011] Figure 5A An example of applying a reverse encoding operation to an encoded destination address output by a branch prediction circuit based on a recomputed key associated with a current execution context is shown;

[0012] Figure 5B An example of applying an encoding operation to an instruction address used as part of a query for searching branch prediction circuitry is shown;

[0013] Figure 6 An example of generating a key based on multiple identifiers associated with a current execution context is shown;

[0014] Figure 7 An example of a monitoring circuit for detecting instruction fetch failure rates is shown;

[0015] Figure 8 shows a graph illustrating an example in which an increase in instruction fetch failure rate of 20% or more triggers an error response;

[0016] Figure 9 Another example of a branch predictor is shown, the branch predictor including a branch target buffer and a branch direction predictor;

[0017] Figure 10 For comparison, a form of a branch target buffer is shown, in which context information identifying a given execution context is specified in the tag information of each branch target entry;

[0018] Figure 11 An alternative implementation is shown in which a region table is used to compress context information into a shorter region identifier, which is used as tag information in a branch target buffer;

[0019] Figure 12 shows a potential security issue that can arise in a system using such a region table, where an attacker can exploit the property that different execution contexts can reuse the same region identifier from the region table;

[0020] Figure 13 An example is shown in which branch information based on an encryption key associated with a corresponding execution context is encrypted before being stored in a branch target prediction structure and decrypted when read from the branch target prediction structure;

[0021] Figure 14 Shown according to Figure 13 Examples of entries of an example branch target buffer and a region table;

[0022] Figure 15 shows an example of changing the encryption key when a zone table entry is updated;

[0023] Figure 16 and Figure 17 A corresponding example of using encryption to protect a multi-target indirect branch predictor from such an attack is shown;

[0024] Figure 18 is a flow chart illustrating a method of performing a branch target prediction lookup; and

[0025] Figure 19 is a flow chart illustrating a method for generating a target tag value for a lookup based on a zone table;

[0026] Figure 20 An example is shown in which the storage circuit takes the form of a TLB;

[0027] Figure 21 An example is shown in which the storage circuitry takes the form of an instruction cache;

[0028] Figure 22 An example is shown in which the storage circuit takes the form of a data cache;

[0029] Figure 23 An example in which the storage circuit is in the form of a VIPT cache is shown;

[0030] Figure 24 Explained in Figure 23 The example uses a lower-level listener filter to manage alias consistency handling;

[0031] Figure 25 An example is shown in which the storage circuit takes the form of a main memory; and

[0032] Figure 26 An example of data processing according to some embodiments is schematically illustrated. DETAILED DESCRIPTION

[0033] Before discussing the embodiments with reference to the drawings, the following description of the embodiments is provided.

[0034] The processing circuitry may perform data processing in one of a plurality of execution environments. For example, each execution environment may correspond to a different software process executed by the processing circuitry, software at different privilege levels (e.g., an application and an operating system), different portions of a given software process, different virtual machines executing on the processing circuitry, and the like. The storage circuitry may be used to store entries. The input circuitry may be used to receive at least one input to generate an access request for the entry, wherein the at least one input comprises a plurality of bits. For example, the input may specify a read request for data stored in the entry. To reduce the amount of storage required, some embodiments may indirectly store data associated with the entry, for example, in one or more other storage circuits.

[0035] The present technology provides encoding circuitry for performing an encoding operation based on a value associated with a current execution context to encode at least some of a plurality of bits of input received by input circuitry. The current execution context may include a currently executing instruction stream. The encoded version of the input may then be used to access an entry by storing the entry or by retrieving the entry.

[0036] Counterintuitively, it has been recognized that memory circuits (particularly microarchitectural memory circuits or memory circuits storing soft state) can provide a route that an attacker can use to circumvent security protections provided on processing circuitry that restrict one execution environment from accessing data associated with another execution environment. This is because the memory circuits may allow access to an entry from an execution environment different from the one to which the entry was assigned.

[0037] By providing encoding circuitry to apply an encoding of at least some bits of the input to the storage circuitry based on a value associated with the current execution environment, even if two different execution environments provide the same input, access requests will be different because the encoding of at least some bits of the input is based on a value specific to the execution environment, making it more difficult for one execution context to infer information about the address space of another execution context. This reduces the risk of attacks of the type described above. Surprisingly, such encoding circuitry is beneficial because such storage circuitry would not typically be considered a risk.

[0038] In some examples, the storage circuitry includes branch prediction circuitry; and the entries include branch prediction state entries related to an instruction stream executed in a current execution environment. The branch prediction circuitry can be used to predict the outcome of branch instructions before those branch instructions are actually executed. By predicting the branch outcome before the branch instruction is actually executed, subsequent instructions following the branch can be fetched and speculatively executed before execution of the branch instruction is complete. Consequently, if the prediction is correct, performance is saved because subsequent instructions can be executed more quickly than if the branch outcome were only fetched once the outcome is actually known. The storage circuitry can allow access to the entries of the execution environment to which the entries were assigned from different execution environments, such that branch prediction state assigned to the branch prediction circuitry by a first execution environment can be used to control the behavior of branches executed in a second execution environment. Previously, this would only be considered a performance issue, as if the second execution environment encountered an incorrect entry assigned by a different context, and the second execution environment might later identify the misprediction during execution of the branch once the actual branch outcome of the branch was determined to not match the prediction. However, it has been recognized that instructions that are incorrectly executed in a speculative manner due to mispredicted branches may still affect data in caches or other non-architectural storage structures used by the data processing device, which an attacker may use to attempt to obtain certain information about potentially sensitive data accessible to a second execution environment. The current execution environment refers to one or more states associated with the data processing device or its underlying system. For example, this may include any combination of the following: processor ID, core ID, machine ID, execution privilege level, application ID, process ID, (virtual) machine ID, storage location ID, memory ID, memory group ID, or any partition of any of the foregoing elements associated with the instructions executed on the data processing device. Similarly, other elements that may constitute the current execution environment may include any combination of the following: system boot count, values stored in (system writable) registers, and random or pseudo-random numbers. In some embodiments, the execution environment can be considered to be an encapsulated / isolated environment in which interference from other execution environments will be prohibited.

[0039] In some embodiments, the storage circuit includes a cache. When the storage circuit includes a cache, this creates a need for the data stored in the cache to remain correct. The cache should store correct data in association with the location associated with the data (e.g., in a memory location). If incorrect data is stored, or correct data is stored in association with the wrong memory location, then incorrect data will be provided when requested, resulting in data operations not being performed correctly. In contrast, for example, a branch table predictor can include any type of data, even invalid data. Hitting incorrect or invalid data in the branch predictor will result in a misprediction, which may affect performance, but can be resolved when the branch is executed and the misprediction is detected.

[0040] In some embodiments, the memory circuitry includes address translation circuitry; at least one entry includes a translation from an input address in an input address space to an output address in an output address space. As an example, the address translation circuitry may include a translation lookaside buffer (TLB). The TLB is used to provide fast translation between input addresses (e.g., virtual addresses) and output addresses (intermediate physical addresses or physical addresses).

[0041] In some embodiments, a data processing apparatus includes tag comparison circuitry for comparing tags associated with entries to determine whether the entry should be accessed in response to an access request, wherein at least one input includes an input tag; and the tag associated with the entry is compared to the input tag and accessed in response to a match. Typically, when accessing a cache, the access request will include an input address (e.g., a virtual address) comprising a tag, an index, and an offset. Typically, the index identifies a set of entries within the cache, the tag identifies which entry in the set contains the requested data, and the offset is an indicator of the desired data within the cache line identified by the index and tag. However, as a result of encoding the input, entries may exist in the cache that use a previous encoding scheme (i.e., are associated with a different version of the execution environment value). Such entries should not be used. Therefore, unencoded tags and indexes are stored with entries in the cache, and when an access request is used to select a specific entry in the cache to ensure that the correct entry is selected using the current encoding, the unencoded tags and indexes stored with the entry are compared with the unencoded tags and indexes of the access request. It will be appreciated that when an access request takes the form of a write request, the cache line will be read and a portion of the cache line will be modified. Thus, a write request will effectively include a read request and should therefore utilize the indexing process just described.

[0042] In some embodiments, the storage circuit comprises an instruction cache; the at least one entry comprises at least one instruction. The at least one instruction may be, for example, a plurality of instructions.

[0043] In some embodiments, the storage circuit comprises a data cache; and at least one entry comprises a data value stored at a memory location in the memory circuit. When the cache is a data cache, the encoding process should take into account the fact that the data cache can be accessed by multiple different processing circuits. For consistency reasons, it is generally important that the same data does not appear multiple times in the data cache. In many cases, this may result in the same data having different values. Therefore, it will be understood that the encoding process should provide the same data when requested by multiple different processors. In particular, if each processor requests the same data, the same data should be provided despite the encoding process. In some embodiments, at least one entry comprises a set of values.

[0044] In some embodiments, the data processing apparatus includes further storage circuitry for storing associations between execution environments and memory locations, wherein each of the memory locations is associated with at most one of the execution environments. A memory location (e.g., uniquely identifying an entry in a data cache) may be associated with an execution environment. The further storage circuitry stores associations between execution environments and memory locations such that, given a particular memory location, the execution environment associated with that memory location can be determined. Since the execution environments form the basis of encoding operations, given a particular memory location, the associated execution environment can be determined so that some bits constituting an access request are appropriately encoded in order to access the entry. In this context, the current execution environment corresponds to the execution environment associated with the memory location to be accessed.

[0045] In some embodiments, the access request is a memory access request to a requested one of the memory locations; and the current execution environment is one of the execution environments associated with the requested one of the memory locations.

[0046] In some embodiments, the memory location includes a page in the memory circuit that is set to be writable. To maintain consistency, it may only be relevant whether a specific memory location (e.g., a page or a group of pages of memory) is writable. When a page is writable, multiple versions of the data in the page may be stored in the cache at the same time, resulting in potential consistency issues.

[0047] In some embodiments, the additional memory circuitry includes address translation circuitry. The address translation circuitry may, for example, take the form of a translation lookaside buffer (TLB). The TLB provides for translation of input addresses (e.g., virtual addresses) to output addresses (e.g., physical addresses). Thus, the TLB may be used to indicate an execution context associated with a particular page or group of pages in the memory circuitry.

[0048] In some embodiments, the data cache comprises a Virtually Indexed Physically Tagged (VIPT) cache comprising a plurality of sets and a multi-way; and a data value may be stored in more than one of the plurality of sets within each way in the multi-way. This typically occurs because certain bits of the index differ from the physical address from which it comes. As a result, there may be several different sets (e.g., aliases) referenced by the index. It will be appreciated that the present technology is relevant to VIPT caches because the set (e.g., alias) in which particular data is stored may change between execution environments. In this case, each execution environment is uncertain about the location of data belonging to another execution environment in the storage circuitry because it may not be known which set in the other execution environment will store the data, thereby adding a layer of security. Therefore, each execution environment may use a different encoding to give one of the different aliases.

[0049] In some embodiments, a data processing apparatus includes indexing circuitry for storing an indication of a set in which a data value is stored in association with at least one input and an execution environment. When a VIPT cache is used, indexing circuitry may be provided to provide an indication of a set in which a data value is stored in association with at least one input. In this case, the at least one input may take the form of a physical address. Thus, given a physical address, a specific set in which a data value is stored for a particular execution environment may be determined. The indexing circuitry may take the form of a snoop filter, which is used to provide consistency between sets in the VIPT cache. In a VIPT cache, when an address is accessed, its virtual address is used to look up the address in the cache. If a miss occurs, the line may still be in the cache under another alias (e.g., one of the other sets that the virtual address may point to). Therefore, in the event of a miss, a linefill request is generated to a lower-level memory system, which may check the snoop filter or other structure that tracks cache contents. If this indicates that the physical address already resides in the VIPT cache, a snoop is sent to evict the line from the cache so that it can be allocated under the new (requested) alias.

[0050] In some embodiments, the indexing circuit is a snoop filter or directory.

[0051] In some embodiments, the storage circuit comprises a DRAM comprising memory locations; and the access request is a memory access request for a requested one of the memory locations. Thus, the particular memory location may take the form of a page in the DRAM.

[0052] In some embodiments, the current execution environment is based on processing circuitry that provides input to input circuitry to generate the access request.

[0053] In some embodiments, a data processing device includes: multiple processing circuits, including a processing circuit; and additional storage circuitry for storing associations between execution environments and memory locations. A rowhammer attack exploits the fact that certain bits in DRAM are susceptible to flipping. This is accomplished by repeatedly pushing the expected value of a target bit into adjacent bits, thereby "hammering" the adjacent bits into the target bit. After numerous operations, charge will repeatedly leak from the adjacent bits into the target bit, causing the target bit to flip. Of course, to conduct this attack, it is necessary not only to identify the vulnerable bits but also to identify the adjacent bits of the target bit. Therefore, one way to prevent this attack is to effectively randomize the location of specific data or otherwise obfuscate the location of data between different execution environments. This can be achieved by associating each execution environment with a processing circuit and also associating each execution environment with one or more memory locations. Additional storage circuitry (e.g., a TLB or data cache) can be used to store the associations between execution environments and memory locations. Therefore, when accessing a location, the corresponding execution environment is provided, allowing for consistent encoding. Consequently, multiple processes can access the same memory location, if appropriate. In such embodiments, the same physical address is used (e.g., across processors). In some embodiments, a higher level of granularity is used so that close addresses are physically close to each other. This can be achieved by dividing the memory into multiple chunks and effectively "randomizing" the mapping between physical addresses and the beginning of each chunk.

[0054] In some embodiments, the encoding operation includes encoding at least some of the bits using a key, wherein the key is based on the current execution environment. The encoding operation may include using the key to rearrange at least some of the bits (e.g., shift or otherwise reorder the bits). In addition, the encoding operation may include using the key to toggle at least some of the bits of the input. For example, the toggle may be implemented by applying an XOR (exclusive OR) operation to at least some of the bits of the input and a key derived from a value associated with the current execution environment. In terms of hardware performance, the XOR operation can be very efficient and can be inverted by reapplying the XOR using the same operands.

[0055] In some embodiments, the encoding circuit is adapted to encode at least some of the plurality of bits by performing a hash function using a key. In some embodiments, the hash function is a one-way hash such that reversing the encoding when starting from the result is computationally intractable.

[0056] In some embodiments, the encoding operation includes rearranging or switching at least some of the plurality of bits using a key.Such embodiments may be computationally efficient and, therefore, may be performed with limited negative impact on the speed or efficiency of the system.

[0057] In some embodiments, the key is further based on any combination of one or more key input values indicating at least one of: exception level, privilege level, ASID, VMID, NS, physical processor core number and logical core number, one or more registers, a system reset counter, and a previously generated random number. The key input value may include an exception level (distinguishing between different operating modes, such as user mode, kernel mode, and hypervisor mode); a privilege level (distinguishing between different execution permissions); an ASID (address space ID - distinguishing between different application-level execution contexts); a VMID (virtual machine ID - distinguishing 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 machines); an NS (non-secure / secure state, indicating the current security state of the device); a physical processor core number (distinguishing between processors executing on different processor cores provided in the hardware); a logical core number (distinguishing between execution environments executed by different logical partitions of a shared processor core provided in the hardware); one or more registers (so that additional inputs can be provided if necessary to provide additional changes in the key); a system reset counter (indicating the number of system resets, or in some embodiments, the least significant bit indicating the number of system resets); and a previously generated random number (to provide random variation in the key - note that this does not have to be a truly random number, and in some embodiments, the previously generated random number may be a pseudo-random number).

[0058] In some embodiments, at least one of the one or more registers is a software-writable register. By providing at least one software-writable register, the software itself can participate in the selection of the key. In some cases, this allows for further partitioning of separate process control execution environments. For example, the software can record the current value of a software-writable register, change the current value to a new value in order to execute a sensitive code segment, and then change the value of the software-writable register back to the previous value. In this way, the sensitive code is treated as an isolated execution environment, and therefore the surrounding code is less able to determine where the data associated with the execution environment is stored. In some other embodiments, different values of the software-writable register can be used to operate in different contexts simultaneously. For example, in the case of a web browser, by providing different values for the software-writable register, each tab can be associated with a different execution environment, thereby isolating each tab from every other tab.

[0059] In some embodiments, the previously generated random number includes at least one of: an element for each logical processor; an element for each physical processor; and a system-wide element. By providing random variation in the generated key, it is more difficult for an attacker who is able to identify the key (or the function used to derive the key) used by one device to apply that knowledge to other devices that may use different random numbers. At least a portion of the previously generated random number can be generated at startup so that it varies each time the data processing apparatus is started to provide further assistance in protecting the key associated with a given execution environment. For example, a hardware random number generator or pseudorandom number generator can be triggered to generate a new random number each time the apparatus is started.

[0060] In some embodiments, the key is based on a one-way transformation applied to the one or more key input values. By applying a time-intensive operation (e.g., a one-way hash) to only some of the one or more key input values, some of the benefits of a one-way (e.g., secure) hash can be obtained without requiring continuous expenditure of processing resources when performing the hash. It will be appreciated that it is the nature of a one-way transformation to completely alter the output value due to even small changes in the input values. Thus, by even periodically applying a one-way transformation, significant changes can be provided to the resulting overall key.

[0061] In some embodiments, the access request is made to a memory location; and the key is based on the memory location.

[0062] In some embodiments, a data processing apparatus includes event monitoring circuitry configured to modify one of one or more registers in response to an event. The event may indicate a situation where a risk to one of a key or a key input value has been determined. Therefore, by modifying one of the one or more registers in response to the event, the risk of improperly inferring the key value is reduced.

[0063] There are many different examples of such events that can cause the key value to be updated. However, in some embodiments, the event is the passage of a period of time. By periodically changing the value stored in one of the one or more registers (used to provide the key input value), it is possible to infer that any successful attack on the key will only last for a period of time, after which the key is changed and the encoding used is changed, causing the location of the data to be moved again.

[0064] The present technology may also be related to one or more of the related examples described below.

[0065] In some related examples, the encoding operation may include encoding at least some of the plurality of bits of the input value based on a value indicating the current execution permissions in which the instruction stream is being executed. This enables execution environments associated with different execution permissions to encode the input differently, thereby making it more difficult for an attacker to successfully control a victim execution environment with different execution permissions to branch to a desired target address in an attempt to expose data that is inaccessible to the attacker but accessible to the victim execution environment, because it may be difficult for the attacker to guess what value of the input, when encoded using a value associated with the attacker's execution environment, will match a target input that has been encoded using a different value associated with another execution environment to be attacked.

[0066] The encoding operation applied by the encoding circuitry may include any operation that changes the bit value of at least some bits of the input based on a value associated with the current execution context. Note that merely concatenating the value associated with the current execution context with the input received by the input circuitry is not considered to encode at least some bits of the input, as in that case all bits of the input would still retain their original values. Thus, in general, encoding changes the value of at least one bit using a transformation defined by the value associated with the current execution context.

[0067] In some related examples, the encoding operation includes using a key to encode at least some bits, wherein the key is based on the current execution environment in which the instruction stream is being executed. In some related embodiments, the encoding operation includes using a key to rearrange at least some bits (e.g., shifting or otherwise reordering the bits). In some related embodiments, the encoding operation includes using a key to switch at least some of the bits of the input. For example, the switch can be implemented in the following manner: an XOR (exclusive OR) operation is applied to at least some bits of the input and a key derived from a value associated with the current execution environment. In terms of hardware and performance, the XOR operation can be very efficient. Alternatively, the encoding operation can include applying a hash function based on the key to at least some bits of the input. The encoding operation can be reversible (e.g., using the same key to apply a second XOR operation to the result of a previous XOR operation can restore the original input), or it can be a one-way hash function.

[0068] The input to the branch prediction circuit can include multiple pieces of information. Encoding can be applied to different parts of the input. It is not necessary to encode the entire input.

[0069] For example, in some related examples, at least one input includes an indication of an instruction address of a branch instruction, which can be used to form a new branch prediction state entry (providing a prediction for the branch instruction). When querying the branch prediction circuit, the branch prediction circuit receives a query value including an indication of the instruction address of the instruction for which a branch prediction is to be made, and uses the query value to perform a search. The search can, for example, identify whether the branch prediction circuit stores any of the following branch prediction state entries: any branch prediction state entries associated with one or more instructions corresponding to the instruction address specified by the query value. For example, each entry can include some tag information or other state data that enables the search to identify whether the query provided to the branch prediction circuit matches the entry. If the query misses, and it is subsequently determined that the instruction address indicated by the query corresponds to a branch instruction, a new branch prediction state entry can be assigned to the branch prediction circuit, the new branch prediction state entry specifying tag information or other state corresponding to the query that resulted in a miss and the actual branch information determined for the branch instruction.

[0070] In some related examples, before performing the search, the encoding circuitry performs an encoding operation on at least some of the plurality of bits of the query value using a key derived from one or more values associated with the current execution environment. Thus, different execution environments encode the same query differently based on their environment-specific keys to alter the mapping between the input query returned as a match and the entries of the branch prediction circuitry, thereby making it more complex for an attacker to predict what value should be provided as input to the query to train the branch predictor in order to trick a branch associated with a different query value in a different execution environment into using a prediction state assigned by the attacker's execution environment. An advantage of applying the encoding to the query value (rather than to the predicted branch state, such as a predicted destination address for the branch) is that applying the encoding operation to the query input to the branch prediction circuitry may be sufficient to thwart the attacker, and thus, when reading the branch state information from the branch predictor, no decoding need be performed because the predicted branch information can still be stored in the branch prediction circuitry in plain text. This can improve performance by avoiding an additional timing path through the decoding circuitry at the output of the branch predictor.

[0071] In some related examples, at least one input whose bits are encoded by the encoding circuit to form a new branch prediction state entry may include an indication of a destination address of the branch instruction (also referred to as a "branch target address" or "branch target offset"). In this case, the apparatus may further include an inverse encoding circuit (or decoding circuit) for performing an inverse encoding operation on an output of the branch prediction circuit, the output of the branch prediction circuit being output in response to a search of the branch prediction circuit triggered by a query value (indicative of the instruction address). The inverse encoding operation may be any operation that reverses the effect of the encoding operation applied by the encoding circuit to restore the original value of the bit whose value was transformed by the encoding operation. In this case, rather than changing the mapping between the query value and which entry of the branch prediction circuit is accessed, the predicted branch state is encoded in an environment-specific manner based on a key associated with the current execution environment, such that even when a second execution environment encounters a branch prediction state entry trained by the first execution environment, the resulting branch prediction may differ from the prediction if the same entry is accessed from the first execution environment. This makes it more difficult for an attacker to successfully control the location to which different execution environments branch by maliciously training the branch predictor. This improves performance by reducing the chance of hitting the wrong branch predictor state entry.

[0072] In some related examples, the reverse encoding circuitry recalculates a value of a key associated with a current execution context and performs a reverse encoding operation using the recalculated value of the key. Thus, if the current execution context changes between a time when a branch prediction state entry is assigned and a time when the branch prediction state entry is accessed for prediction, then when recalculating a key derived from the value associated with the current execution context, the reverse encoding operation may produce different information than was provided as the predicted branch state when the entry was assigned.

[0073] In some related examples, encoding operations are applied to both the instruction address and the destination address of the branch in order to combine the two approaches discussed above.

[0074] In some related examples, the 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, the key can be based on any combination of one or more of the following:

[0075] Exception levels (distinguishing between different operating modes, such as user mode, kernel mode, and hypervisor mode);

[0076] Privilege levels (distinguishing between different execution permissions);

[0077] ASID (Address Space ID - distinguishes different application-level execution contexts);

[0078] VMID (Virtual Machine ID - distinguishes 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);

[0079] NS (non-safe / safe state, indicating the current safety state of the device);

[0080] Physical processor core number (to distinguish between processors executing on different processor cores provided in the hardware);

[0081] Logical core number (to distinguish between execution environments executed by different logical partitions of a shared processor core provided in the hardware); and

[0082] One or more software-writable registers (so that software can provide additional input for deriving the key to provide additional variation in the key, e.g., to make it more difficult for a process that knows the context identifier (e.g., ASID or VMID) of a process executing under it to predict the value of the key used by that process).

[0083] In some related examples, the key may also be generated based on a previously generated random number. This may provide additional variation in the keys generated for a given combination of identifiers associated with the current execution environment, making it more difficult for an attacker who is able to identify the key used by one device (or the function used to derive the key) to apply that knowledge to other devices that may use different random numbers. The random number may include at least one of: an element for each logical processor; an element for each physical processor; and a system-wide element. At least a portion of the previously generated random number may be generated at startup so that it changes each time the data processing device is started to further resist the destruction of the key associated with a given execution environment. For example, a hardware random number generator or a pseudo-random number generator may be triggered to generate a new random number each time the device is started. At least a portion of the previously generated random number may be a pseudo-random number - true randomness may not be required.

[0084] In some related examples, the instruction stream may be executed in one of a plurality of execution environments suitable for execution with a minimum execution permission (an execution permission level with the least privilege). For example, the execution environment with the minimum execution permission may include an application or a sub-portion of an application. In some examples, the encoding circuitry may further perform the encoding operation based on an identifier of one of the plurality of execution environments with the minimum execution permission in which the instruction stream is being executed. This may allow different portions of application-level software (which may share the same address translation mechanism and therefore may be expected to share a mapping of branch predictor inputs to entries in the branch predictor) to use different encodings of the branch predictor inputs to reduce the risk of one application or portion of an application creating the aforementioned form of attack against another application or portion of an application that shares the same address translation mechanism.

[0085] In some related examples, monitoring circuitry can be provided to detect an instruction fetch failure rate or an instruction decode failure rate when executing an instruction stream in a speculative state, and to generate an exception or generate an error response in response to the detected instruction fetch failure rate and / or instruction decode failure rate meeting a predetermined criterion (e.g., increasing to exceed a predetermined threshold). For example, the threshold can be at least 20% higher than the previous failure rate. Alternatively, the threshold can be 20% higher than the average failure rate for other applications. This can provide a technique for detecting the above-mentioned forms of attack. If the number of instruction fetch failures increases, one possible explanation could be that an attacker is attempting to train the branch predictor to trick other code into executing instructions from inappropriate branch addresses, which are then detected as mispredictions. When the speculative instruction fetch failure rate or decode failure rate increases, a warning of a potential attack can be issued by triggering an exception or error response. How the software chooses to respond to such a warning may depend on the specific software being executed, but providing a monitoring circuit to trigger an interrupt / error response in the event that an abnormally high number of instruction fetch failures is detected can provide a hardware framework for enabling the software to respond in a manner appropriate to the software.

[0086] In some related examples, the branch prediction circuitry may include a branch target prediction structure including a plurality of branch target entries, each branch target entry specifying at least a branch target address. The encoding circuitry may include encryption circuitry configured to encrypt at least a portion of a new branch target entry to be written to the branch target prediction structure using an encryption key associated with a current execution environment.

[0087] In some related examples, each branch target entry specifies tag information. The apparatus may have branch target prediction circuitry that performs a branch target prediction lookup on an instruction fetch address associated with a current execution environment. The branch target prediction lookup may include determining whether any one of a subset of branch target entries specifies tag information corresponding to a target tag determined for the instruction fetch address. In the case of a fully associative cache implementation, the subset of branch target entries looked up in the branch target prediction lookup may include all branch target entries of the branch target prediction structure, or in a set associative implementation, may include only some branch target entries (an appropriate subset of the branch target entries). In a set associative implementation, the subset of branch target entries to be looked up may be selected, for example, based on a portion of an address of a given branch instruction.

[0088] In some related examples, the target label can be determined in some manner based on some attribute of the instruction fetch address (some attribute indicating the current execution point represented by the instruction fetch address), the current execution context in which the fetch address appears, or some past history of recent operation of the processing circuitry. The specific label used can vary depending on the type of branch target prediction architecture implemented. For example, the target label can be derived from the instruction fetch address or one or more identifiers associated with the current execution context, or can be derived based on a past history of branch outcomes that resulted in the instruction(s) identified by the instruction fetch address.

[0089] In some related examples, the value of a target tag may be reusable in more than one execution environment. Thus, the target tag may not be unique to a particular execution environment. For example, this may be because a particular branch target prediction structure uses a tag that is completely independent of an identifier associated with the current execution environment, or because the tag includes at least a portion derived from a value associated with the current execution environment to conserve circuit area in a tag information storage device of the branch target prediction structure. The tag information and the target tag may be based on a compressed version of one or more execution environment identifiers that identify the current execution environment, such that the value of the compressed identifier can be reused from one execution environment to another.

[0090] Therefore, there is no guarantee that the target label used in one execution environment will not match the label information assigned to the entry of the branch target prediction structure after executing a branch instruction associated with a different execution context. This may result in false positive hits in the branch target prediction structure, so that an incorrect branch target address may sometimes be returned, and therefore a branch misprediction may result in the execution of the wrong instruction after the branch. Although such false positive hits may cause processing performance to degrade, branch misprediction resolution circuitry may have been provided to handle the misprediction by triggering the processor to flush the pipelined instructions following the mispredicted branch, and once the branch result has been resolved, instruction fetching is resumed from the correct processing path. Therefore, false positive hits caused by reusing label values in multiple execution environments are not generally considered a major problem because they can be resolved in a similar manner to other causes of branch mispredictions, and although this will affect performance, it is not generally considered a risk to data security.

[0091] However, it has been recognized that such false positive hits in the branch target prediction circuitry can, in fact, create a vulnerability in the security of data being processed by a data processing apparatus. The apparatus may, for example, use a privilege-based data access protection scheme to restrict access to certain data to certain execution environments. It has been recognized that false positive hits in the branch target prediction circuitry can allow such security mechanisms to be circumvented, enabling a first execution environment controlled by an attacker to obtain information about sensitive information accessible to a second execution environment but not to the first execution environment. This is surprising, as branch prediction mechanisms are generally considered to be performance-enhancing mechanisms, and their false positives are not critical to the security of the data being processed by the system, but only affect the achieved performance level.

[0092] The potential security vulnerability arises because an attacker controlling a first execution context can exploit the reuse of target tag values between execution environments to trigger a second execution environment to hit an entry allocated by the first execution environment that indicates a known address (hereinafter referred to as the "mistaken target address") as its branch target address. This can allow the attacker to control the second execution environment to branch to some malicious code located at the mistaken target address. Ultimately, the branch prediction may be determined to be incorrect because the actual target address of the branch executed by the second execution environment may not match the mistaken target address, and therefore any architectural state associated with the misexecuted instruction may be rolled back to a previous correct state value to reverse the architectural effects of the misexecuted instruction. At the same time, the misexecuted instruction may also have changed non-architectural processor state, such as data in caches or translation lookaside buffers (TLBs), which may persist after the misprediction is resolved. The attacker may have designed malicious code at the mistaken target address to ensure that the specific address of data cached due to the misexecuted instruction depends on the sensitive information the attacker wishes to gain access to. Thus, an attacker could then execute instructions in the first execution environment designed to detect which data has been cached, and use performance indicators (e.g., cache miss counts or memory access latency measurements) to detect what information the second execution environment cached during the time the mispredicted instruction was executed. This could then allow the attacker to obtain information about potentially sensitive data processed by the second execution environment, thereby circumventing the system's security mechanisms.

[0093] Thus, at least a portion of a new branch target entry to be written to the branch target prediction structure may be encrypted using an encryption key associated with the corresponding execution environment to which the branch information is assigned. Tag information for the new branch target entry or branch data for the new branch target entry (specifying at least the predicted branch target address), or both, may be encrypted. If the tag information is at least partially encrypted using the encryption key when the new branch target entry is assigned, then during a branch target prediction lookup, either encryption circuitry may encrypt the target tag determined for the instruction fetch address using the (recalculated) encryption key associated with the current execution environment, and the branch target prediction circuitry may compare the encrypted target tag with tag information for a subset of the branch target entries to identify whether any of the subset of branch target entries specifies tag information corresponding to the target tag, or the encrypted tag information stored in the lookup entry may be decrypted and compared with the (unencrypted) target tag. If the branch data is encrypted when the new entry is assigned to the branch prediction structure, the apparatus may further include decryption circuitry for decrypting the encrypted portion of the branch data for one of the subset of branch target entries identified in the branch target prediction lookup as specifying tag information corresponding to the target tag.

[0094] In some related examples, in a branch target prediction lookup, when none of the branch target entries in the lookup subset of branch target entries specifies tag information corresponding to the target tag, and the instruction fetch address specifies one or more instruction blocks including a branch instruction, the encryption circuitry may encrypt the actual branch information determined for the branch instruction using an encryption key associated with the current execution environment, and the branch target prediction circuitry may assign a branch target entry to a branch target prediction structure, the branch target entry specifying the encrypted branch information and tag information corresponding to the target tag. On the other hand, upon a lookup hit, when one of the branch target entries in the subset of branch target entries does specify tag information corresponding to the target tag, the branch information stored in the entry may be decrypted using the encryption key associated with the current execution environment, and the decrypted branch information may then be output as the predicted branch information for the given branch instruction.

[0095] Thus, in these examples, because the branch information in the branch target prediction structure is protected by an encryption key associated with the corresponding execution environment (with which the branch information is associated), if one execution environment assigns branch information, the branch information will be encrypted using the key associated with that environment, and then if a false positive hit happens when another execution environment reuses the same tag information for that entry, the branch information will be decrypted using the key associated with the other execution environment and will therefore not indicate the same branch target address as originally provided by the execution environment that assigned the entry. While branch predictors are typically viewed as purely performance-enhancing measures that do not impact data security or integrity, encryption is surprisingly useful in branch predictors, but by encrypting branch information using execution environment-specific keys, attacks of the type discussed above are made more difficult because it is difficult for an attacker to control where another execution environment branches to without knowing the keys associated with each execution environment.

[0096] In some related examples, the encryption circuitry and the decryption circuitry may comprise separate circuitry. For example, in some cases, the operation applied to decrypt the encrypted branch information may be different from the operation applied to encrypt the branch information, and therefore separate encryption and decryption methods may be applied. Alternatively, the encryption and decryption operations may actually be the same operation. For example, the encryption operation may include applying a reversible operation (e.g., XOR) to the branch information and an encryption key, and the decryption operation may include applying the same reversible operation (e.g., XOR) to the encrypted branch information and the encryption key. Therefore, in some examples, both the encryption circuitry and the decryption circuitry may correspond to the same circuitry provided in hardware (without having to provide two separate circuit units). Alternatively, although the encryption and decryption operations are the same, it may still be useful to provide separate encryption and decryption circuitry to allow decryption of branch information for one entry of the branch target prediction structure to be performed in parallel with encryption of branch information for another entry.

[0097] In some related examples, the encryption key may comprise a static key that is fixed for the current execution environment. Thus, each execution environment may be associated with a fixed key that never changes. This may be sufficient to provide adequate security, as it may still be difficult for an attacker to predict the result of decrypting an encrypted value using an encryption key and a decryption key that is different from the key used in encryption, where one or more keys are unknown. Although multiple environment-specific keys can be stored in a storage structure for each execution environment, this may require a large amount of storage due to the potentially large number of execution environments. A simpler approach to determining a static key for the current execution environment may be to derive the static key from a common key shared between multiple execution environments and at least one environment identifier specific to the current execution environment. For example, the common key may be a previously generated random number as described above. For example, the common key may be hashed or modified based on the identifier of the current execution environment(s) (e.g., the ASID, VMID, etc. described above).

[0098] In some related examples, the encryption key may include a dynamic key that is variable for the current execution environment. Thus, in addition to changing with the environment, the encryption key may also change from time to time for a specific environment. This may provide greater security because it may reduce the chance that an attacker will be able to derive a key for a given environment by observing the behavior of the data processing system over a period of time. Thus, the apparatus may include a key generation circuit for generating an updated encryption key for the current execution environment. For example, the key generation circuit may include a random or pseudo-random number generator (e.g., a linear feedback shift register) for generating a new random value or pseudo-random value for the encryption key for a given execution environment when needed. The timing at which the key is updated may be arbitrary, or may be in response to certain predetermined events, or may be upon the expiration of a specific time period or a specific number of branch prediction events.

[0099] In some related examples, the label information in each branch target entry can be stored in plain text, without encrypting or decrypting the label information. This can simplify label comparison. As mentioned above, encrypting branch information is sufficient to reduce the possibility of attacks.

[0100] Alternatively, in some related examples, in addition to (or instead of) encrypting the branch information indicating the branch target address, the tag information may be encrypted. Thus, upon a branch target prediction lookup miss, when the instruction fetch address is identified as referencing an instruction block that includes a branch, the target tag may be encrypted using an encryption key associated with the current execution environment, and the encrypted target tag may be designated as tag information for the assigned branch target entry. In the branch target prediction lookup, the decryption circuitry may decrypt the tag information for each subset of the branch target entries, and the branch target prediction circuitry may compare the decrypted tag information with the target tag. Alternatively, the encrypted target tag from the branch target lookup may be compared directly with the encrypted tag information stored in the branch target prediction structure to identify whether the tags match, thereby avoiding the need for decryption.

[0101] In some related examples, the tag and branch information may be encrypted or decrypted separately, with one encryption scheme applied to the tag and another encryption scheme applied to the branch, and in such cases any of the methods for handling tag encryption (compared in encrypted or decrypted form as needed) may be used. However, in other examples, the tag information and branch information may be encrypted together in a single encryption scheme. This may provide additional security because it may be more difficult to break the encryption scheme applied to the branch information if the encrypted value depends not only on the branch information and an environment-specific encryption key, but also on the tag information provided with the branch (which may provide additional entropy for the encryption of the branch information). However, this may be slower because in such a case the decryption circuitry may need to decrypt the entire block of tag and branch information for each entry being looked up before the decrypted tag can be compared with the target tag to see if there is a matching entry (and if so, the decrypted branch information can be output).

[0102] Thus, in general, the method used for encryption / decryption and the extent to which branch information and labels are encrypted may depend on the desired tradeoff between performance and security.

[0103] In general, any information indicating a branch target address may be used as branch information. In some related examples, the branch information (when seen in plain text before encryption or after decryption) may explicitly indicate the branch target address. The branch target address may be indicated as an absolute address, or as a relative address using an offset relative to the current instruction fetch address for which a branch target prediction lookup is being performed. In some related examples, the branch target address may not be directly identified by the branch information, but the branch information may provide a pointer to some other structure that identifies the branch target address or can be used to calculate the branch target address. Thus, in general, branch information may include any information that allows the predicted branch target address to be determined.

[0104] In some related examples, the branch information may not specify any other information other than the branch target address. However, in some related instances, the branch information may also indicate at least one other fragment of branch information that represents a certain prediction attribute of the branch instruction in one or more instruction blocks identified by the instruction fetch address. For example, the additional information may specify whether the branch is a conditional branch instruction, whether the branch target address should be predicted using some other branch target predictor that is separate from the branch target prediction structure (e.g., a branch target predictor for predicting the target of a polymorphic branch, where the target address of the polymorphic branch changes based on past processing results before the branch), or whether the branch represents a function call or a function return. This additional branch information can be encrypted / decrypted together with the information identifying the branch target address.

[0105] Although the target label can depend on the attribute range of the instruction fetch address, in some related examples, the branch target prediction circuitry can determine the target label based on at least one environment identifier associated with the current execution environment. This can help avoid false positives between predictions made for the same address in different environments. For example, the environment identifier can include a virtual machine identifier that identifies the virtual machine associated with the address, and / or a process identifier that identifies the process associated with the address.

[0106] It is contemplated that if the target tag depends on at least one execution environment identifier associated with the current execution environment, then target tag values should not be reused between execution environments. However, in practice, there may be a large number of different environments that can be executed by a data processing apparatus, but the number of different environments that have information stored in the branch target prediction structure at any one time may be much lower. Consequently, representing a complete environment identifier in the tag information of each entry may require a large number of bits, and in practice, much of this information may be redundant, since for branch target prediction lookup purposes, 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, and not to distinguish the current execution environment from other environments that do not have branch information represented in the branch target prediction structure. Consequently, storing the complete environment identifier may unnecessarily increase the size of each region entry and the number of comparators required to compare the corresponding bits of the tag information with the target tag, thereby increasing circuit area.

[0107] Therefore, in order to reduce circuit area and power consumption, some related examples may provide a region table with multiple region entries, each region entry mapping branch context information to a region identifier comprising fewer bits than the branch context information. The branch context information may include at least one identifier associated with the corresponding execution environment. When performing a branch target prediction lookup, a target tag may be determined based on a target region identifier, which is mapped by the region table to branch context information (comprising at least one identifier) associated with the current instruction fetch address. The tag information of each branch target entry may specify a region identifier in place of the (one or more) identifiers of the execution environment. Thus, the region table effectively allows a larger set of execution environment identifiers and any other information used to identify branch context information to be compressed into a shorter identifier, which is used as a tag in the branch target prediction structure to save area.

[0108] In related examples using such region tables, the number of region entries may be limited, and therefore, when encountering a new execution context that does not yet have a corresponding region entry assigned to it in the region table, a region entry previously assigned to a different execution context may need to be reused for the current execution context. When a region entry is reused, the corresponding region identifier may still be used as a tag for certain entries in the branch target prediction structure. While these outdated branch target entries from the branch target prediction structure can be invalidated to prevent false hits, performing such invalidation can be expensive in terms of performance and complexity, as it may require special circuitry to traverse the branch target prediction structure to evict information for the reused selected region identifier. In practice, this performance cost may not be justified, as in any case, if a branch misprediction occurs based on that entry, it is desirable to evict the outdated entry. Consequently, related examples using region tables often do not invalidate branch target entries when the region table is updated, and are therefore prone to false hits in the branch target prediction structure. Therefore, encryption / decryption of branch information, as described above, is particularly useful for branch target predictors using region tables to improve security.

[0109] Although the encryption keys associated with each execution environment can be stored in a separate storage structure, when a region table is provided, it may be valid for each region entry to specify the encryption key associated with the corresponding execution environment. Therefore, in some related examples, the encryption key can be read from the region table at the same time as the target region identifier is looked up, thereby eliminating the need for a separate lookup in a separate storage structure. This approach also means that encryption keys do not need to be stored for all execution environments. Instead, keys can only be maintained for the specific execution environment that is currently mapped to the region identifier by the region table. For other execution environments, no encryption keys need to be maintained because the branch target prediction structure does not currently involve any encryption keys. Therefore, this approach can also reduce the number of keys that need to be stored.

[0110] In some related examples, the encryption key associated with a given execution environment can be updated when the mapping provided by a given region entry in a region table is also updated. That is, when a region entry in a region table must be assigned to a different execution environment, the encryption key specified for that region entry can also be updated to generate a new key for the execution environment associated with the region entry after the updated mapping. This prevents an old key associated with one environment from remaining the same for a new environment, thereby ensuring that each environment uses a different key.

[0111] In some related examples, branch context information mapped to a region identifier by a region table may include one or more execution environment identifiers identifying a current execution environment, but may not include any other information.

[0112] However, in other related examples, the branch context information may also depend on other information. For example, the branch context information may also include a portion of the instruction fetch address based on which a previous branch target prediction lookup resulted in a given region entry being assigned to the region table. Thus, a portion of the instruction fetch address is used to look up the region table and identify the corresponding region identifier, thereby avoiding the need to store that portion of the instruction fetch address as tag information in each branch target entry of the branch target prediction structure. Typically, the most significant portion of the instruction fetch address may be the same for a large number of fetch addresses used by a given execution environment, and the number of different values of the most significant portion used on all instruction fetch addresses used within a given time frame in a particular execution environment may be relatively low. Therefore, by representing that portion of the instruction fetch address in the region table and compressing it together with the execution environment identifier into a shorter region identifier, this can reduce the amount of tag storage required for each branch target entry and the amount of comparison logic used to compare the target tag with the stored tag information.

[0113] Other forms of branch target prediction structures can use labels that are independent of the execution environment identifier associated with a given execution environment. For example, in some related examples, one type of branch target prediction structure can be used to predict the target addresses of certain branch instructions whose behavior varies depending on the previous branches executed. For example, the branch target address of a given branch instruction can be calculated as one of a series of different possible branch target addresses, for example depending on the results of earlier conditional instructions, and these conditional instructions themselves may depend on the past history of branch results. For this type of branch target prediction structure, the label can depend on the instruction fetch address and the history of branch results of previous branch instructions before the instruction at the instruction fetch address, but can be independent of the (one or more) environment identifiers of the current execution environment. Therefore, using this type of label, since a given instruction address and a history of branch results may be generated in different environments, the value of the label may be reused in more than one execution environment. Again, this can provide an attacker with a way to populate the branch target prediction structure with branch information from a given branch history expected to be used in a victim environment to be attacked, attempting to force the victim environment to branch to an instruction address controlled by the attacker environment due to false positives between different environments. As described above, such attacks can be made more difficult by using encryption (and decryption, if necessary) of branch information and / or tag information in the branch target prediction structure, because decrypting the encrypted branch information using the encryption key of the wrong environment is less likely to result in a known address that can be controlled by the attacker.

[0114] Certain embodiments will now be described with reference to the accompanying drawings.

[0115] Figure 1 An example of a data processing device 2 is schematically shown. In this embodiment, a signal or input is sent to input circuitry 50 to access a specific entry 3 in storage circuitry 4. This access can take the form of a read or write, for example. Upon receiving the input, input circuitry 50 generates an access request, which is sent to storage circuitry 4 via encoding circuitry 52. The access request includes a reference to entry 3 in storage circuitry 4 in the form of an address. If, for example, data is stored at that specific address as part of the access, the access request may include the data. Encoding circuitry 52 transmits data between storage circuitry 4 and input circuitry 50 and encodes the address. In particular, if the address received by the input circuitry includes multiple bits, some or all of those bits will be encoded by encoding circuitry 52. The encoding is based on the current execution environment, such as the current execution environment under which data processing device 2 is operating. The modified access request is then sent to storage circuitry 4.

[0116] The encoding performed by encoding circuitry 52 makes it difficult to determine the actual entry 3 accessed at the storage circuitry. However, because the encoding is based on the current execution environment, the entry 3 accessed should be consistent as long as the address provided to input circuitry 50 remains unchanged. Therefore, the data remains accessible to the execution environment itself. However, other execution environments implementing different encodings via encoding circuitry 52 will find it difficult to determine the exact entry 3 in which the data is stored. Conversely, given a particular entry, the current execution environment will have difficulty determining the corresponding input address for a different execution environment.

[0117] Thus, security is achieved by obscuring where data belonging to another execution environment is stored, thereby making it difficult for one execution environment to access data belonging to another execution environment.As will be discussed below, the present technology is relevant to many different pieces of hardware.

[0118] Figure 26 A flowchart 375 illustrating a method according to some embodiments is shown. At step 380, an input is received to access an entry stored in a storage circuit. At step 385, certain bits of the input (e.g., bits constituting an access address of the entry to be accessed) are encoded. This encoding is based on the current execution environment. At step 390, an access request is then generated based on the encoded bits. As a result, the access request itself becomes obfuscated to other execution environments that are unaware of the exact encoding performed.

[0119] Branch target buffer

[0120] Figure 2An example of a data processing apparatus 2 having a processing pipeline comprising multiple pipeline stages is schematically illustrated. The pipeline includes a branch predictor 4 (an example of the claimed storage circuitry) for predicting the outcome of a branch instruction and generating a series of fetch addresses for instructions to be fetched. A fetch stage 6 fetches the instruction identified by the fetch address from an instruction cache 8. A decode stage 10 decodes the fetched instruction to generate control information for controlling subsequent stages of the pipeline. A rename stage 12 performs register renaming to map architectural register designators identified by the instruction to physical register designators identifying registers 14 provided in the hardware. Register renaming can be useful for supporting out-of-order execution because it can eliminate hazards between instructions that specify the same architectural register by mapping architectural registers to different physical registers in the hardware register file, thereby increasing the likelihood that instructions can be executed in an order different from the program order in which they were fetched from cache 8. This can improve performance by allowing later instructions to execute while earlier instructions wait for operands to become available. The ability to map architectural registers to different physical registers can also facilitate rollback of architectural state in the event of a branch misprediction. Issue stage 16 queues instructions for execution until the required operands for processing those instructions are available in registers 14. Execute stage 18 executes the instructions to perform the corresponding processing operations. Write-back stage 20 writes the results of the executed instructions back to registers 14.

[0121] The execution stage 18 may include a plurality of execution units (e.g., a branch unit 21) for evaluating whether a branch instruction has been correctly predicted; an ALU (arithmetic logic unit) 22 for performing arithmetic or logical operations; a floating point unit 24 for performing operations using floating point operands; and a load / store unit 26 for performing load operations to load data from the memory system to the register 14, or store operations to store data from the register 14 to the memory system. In this example, the memory system includes a level 1 instruction cache 8, a level 1 data cache 30, a level 2 cache 32 shared between data and instructions, and a main memory 34, but it should be understood that this is merely one example of a possible memory hierarchy and other implementations may have additional cache levels or different arrangements. The load / store unit 26 may use a translation lookaside buffer 36, and the fetch unit 6 may use a translation lookaside buffer 37 to map virtual addresses generated by the pipeline to physical addresses identifying locations within the memory system. It should be understood that Figure 2 The pipeline shown is just one example, and other examples may have different sets of pipeline stages or execution units. For example, an in-order processor may not have a rename stage 12.

[0122] Figure 3An example of providing input to a branch predictor 4 to generate a new branch prediction state entry to be assigned is shown. The input comprises a plurality of bits. For example, the input in this example specifies the instruction address of the instruction identified as a branch, and a branch destination address (target address) which indicates the address to which the branch is branched when the branch is executed. An encoding circuit 52 is provided to perform an encoding operation on at least some of the bits of the input based on a value 54 associated with the current execution environment in which the instruction stream is being executed. The encoded input value resulting from the encoding operation is then provided to the branch prediction circuit 4. For example, encoding may be applied to all or part of one or both of the instruction address or the destination address of the input.

[0123] Figures 4A to 4C Different examples of performing encoding operations are shown (applied to a portion of the destination address of a branch in Examples 4A and 4B, but could also be applied to an instruction address as in Example 4C). Figures 4A to 4C As shown, some bits of the input address may be removed before the encoding operation is applied to the remaining bits. Figure 4A In , a rearrangement of the relative order of the remaining bits is performed based on a key derived from a value associated with the current execution environment (or current execution permissions). For example, a right shift (or rotation) of a number of bits specified by the key may be performed, or some other reordering of the bits may be performed. Figure 4B In the example of , the encoding operation is performed as an XOR of a key with selected bits of the input to the branch predictor. XOR is an example of a reversible encoding operation for which a reverse encoding operation can be performed by performing another XOR based on the corresponding key. Figure 4C In the example of , a hash function may be applied to selected bits of the input based on a key. Note that the key need not include the same number of bits as the selected bits to be encoded. In general, regardless of the particular form of encoding applied, the bit values of some values of the input are changed before the encoded input is provided to the branch prediction circuitry. In the example of , which shows encoding of the destination address Figure 4A and Figure 4B In the example of , the bits that are removed may be bits whose values can be inferred or known when the reverse encoding is applied. For example, if instructions are already aligned to their size, one or more low-order bits of the address may be removed since these are always zero. Similarly, if the destination address is represented as an offset from the instruction address, the highest order bits may always be zero and so may be removed before applying the encoding since they do not need to be restored when the reverse encoding is applied. In contrast, for encoding of instruction addresses, there is no need to ensure that the removed bits can be restored by reverse encoding since this method does not require reverse encoding and the transformation may therefore be a one-way transformation.

[0124] Figure 5A and Figure 5B Two examples of querying branch prediction circuitry to retrieve predicted branch information in response to a query specifying a given instruction address are shown. Figure 3 The encoding circuit 52 applies an encoding operation to at least some bits of the branch destination address in an example in which Figure 5A . In this example, a query is provided to the branch prediction circuitry, the query specifying the instruction address for which a branch prediction is to be made. The branch prediction circuitry 4 performs a lookup of its storage structures to identify whether any entry matches the query, and if an entry matches, the encoded destination address (generated by the encoding circuitry 52 based on a value 54 associated with the current execution environment) is retrieved and output. Based on a recalculated key 58, a reverse encoding circuitry 56 (which may be the same as the encoding circuitry 52 in some embodiments, or may be different, depending on the encoding / decoding algorithm implemented) applies a reverse encoding operation to the encoded destination device, wherein the recalculated key 58 is used in conjunction with the and Figure 3 The recalculated key 58 is formed in the same manner as the value 54 associated with the current execution context used in the example, except that the recalculated key 58 is based on when the query of the branch prediction circuitry is performed rather than when the matching branch prediction entry is written to the branch prediction circuitry (e.g. Figure 3 Therefore, if a matching entry is accessed after a query triggered by the same execution environment as the one that assigned the entry, the final destination address output by the reverse encoding circuit 56 will be the same as the one that assigned the entry. Figure 3 . However, if the matching entry is accessed from an execution environment different from the execution environment in which the entry was assigned, the decoded destination address 60 will be different from the originally assigned destination address. The encoding / decoding algorithm and / or key (or method for generating the key) may be selected to make it difficult for an attacker to predict which alternative values of the destination address should be used as input. Figure 3 , so that the reverse-encoded address 60 (when reverse-encoded using a key different from the key used to encode it) matches the desired branch target address that the attacker wants some other execution environment to branch to.

[0125] Figure 5B An alternative method for querying the branch prediction circuitry 4 is shown in an example where the encoding circuitry 52 applies an encoding operation to the instruction address (or other tag information used to locate a matching entry in the branch prediction circuitry 4). In this case, when querying the branch prediction circuitry 4 to perform a search for branch information, the corresponding encoding circuitry 52 (which may be the same as the instruction address) is generated based on the recalculated key 58. Figure 3The same physical circuitry used in the branch predictor, or which may be different circuitry, applies the same encoding operation to the queried instruction address, wherein the recalculated key 58 is recalculated based on an identifier associated with the current execution environment (recalculated when querying the branch predictor), for example applying a one-way hash based on the key to encode the instruction address. With this approach, since the data output from the branch prediction circuitry 4 does not need to be encoded, it is not necessary to use reversible operations, but rather resistance to attacks is provided by scrambling the mapping between the query provided as input to the branch predictor and the locations in the branch predictor that are believed to match the query. Thus, the branch prediction circuitry 4 is searched based on the hashed query information, and the destination address 62 output from the matching entry can be output in plain text without applying any reversal encoding and used as the predicted branch target address for the branch represented by the instruction address provided as the query input.

[0126] Figure 6 An example of forming a key from multiple identifiers associated with the current execution environment is shown. These identifiers can be obtained from one or more control registers associated with the processing pipeline 2, and these identifiers specify the properties of the current execution environment. For example, the key can be based on any of the following:

[0127] Abnormality level 79;

[0128] Execution privilege level 80;

[0129] Address space ID (ASID) 81;

[0130] Virtual Machine ID (VMID) 82

[0131] Safe status (NS) 83;

[0132] Physical core number 84;

[0133] Logical core number 85;

[0134] A random value 86, which may be a true random number or a pseudo-random number. The (pseudo)random number may be derived from at least one of the following: a per-logical-processor (pseudo)random number 89, which is different for each logical processor; a per-physical-processor (pseudo)random number 89, which is different for each logical processor;

[0135] A random number 90, which is different for each physical processor core; and a system (pseudo) random number 91, which is shared between all logical or physical processor cores in the data processing system, but can be different for different systems to reduce the chance that a key interrupt on one system can be reused by another system (or any one or more thereof). Each of these elements 89, 90, 91 of the random number can be updated each time the data processing apparatus 2 is started.

[0136] • One or more software writable register values 87, which can be written to registers 14 under software control to provide additional entropy for the encoding operation.

[0137] • Container ID 88 (an identifier that distinguishes different parts of the execution environment, which may be at the lowest privilege level with the most restrictive access rights, for example).

[0138] Of course, not all of these parameters need to be considered for a particular implementation. In general, by generating keys for encoding operations (and reverse encoding operations, if desired) based on one or more identifiers 80-85, 88 associated with the current execution environment and, optionally, based on additional parameters (e.g., random numbers of software-defined values), it is unlikely that two different execution environments with different privilege levels will have the same key, and therefore it is difficult for an attacker to train the branch predictor in one execution environment to trick an execution environment with greater data access privileges into entering a branch into malicious code that could lead to the exposure of secure data. Furthermore, by adding (pseudo)random values to the key generation process, it is even more difficult for an attacker to determine what the key will be. In particular, the use of random values means that even if an attacker has full access to one system, any information obtained through reverse engineering cannot be used to predict the key used on another system because the (pseudo)random values will be different. Similarly, it may be desirable to generate different keys for each execution environment on each logical processor core. For complexity and performance reasons, it may be undesirable to have a separate (pseudo)random number generator for each logical processor. In this case, the same result can be achieved by using a per-processor or system-level (pseudo)random number along with the logical and / or physical core number in the key generation process. In some embodiments, the key generation process can include hashing the various key inputs together. The hashing algorithm used can be a (secure) one-way hash.

[0139] That is, in some examples, the key can be based on a one-way transformation applied to at least one key input parameter, where the at least one key input parameter includes at least one value associated with the current execution environment (e.g., the ASID, VMID, or exception level discussed above), but can also include other inputs, such as a random number that is a software-writable value. By using a one-way transformation to generate the key, this means that even if an attacker can observe all but one of the inputs, and they know the algorithm, and they can observe some of the generated keys, they cannot compute what the missing input is (e.g., the random number), which in turn means they cannot predict what the key will be for a different execution environment.

[0140] Figure 7 An example is shown in which a monitoring circuit 95 is provided to monitor the instruction extraction failure rate encountered by the extraction stage 6 and / or the instruction decoding failure rate encountered by the decoding stage 10. The extraction failure rate and the decoding failure rate can be monitored separately or as a combined failure rate. In addition, in some examples, only one of these types of failures can be monitored (e.g., only extraction failures, or only decoding failures). Although extraction and decoding failures may occur for a variety of reasons, one of the reasons may be branch mispredictions by the branch predictor 4. If an attacker attempts to use the branch predictor to attack as described above, more frequent branch mispredictions may occur. Therefore, the instruction extraction failure rate and the decoding failure rate can be used as indicators that can indicate that an attack is being launched. If the number of instruction extraction or instruction decoding failures detected within a given time period or the instruction extraction failure rate or the instruction decoding failure rate increases by a certain threshold, the monitor circuit 95 can trigger an error response (e.g., raise an interrupt or exception). Figure 8 A graph is shown that tracks the instruction fetch failure rate over consecutive time periods of duration T. Figure 8 As shown, if the increase in the instruction fetch failure rate from one time period to the next is greater than a threshold (e.g., 20%), a fault handling response can be triggered. Those skilled in the art will appreciate that there are many ways to use the failure rate to detect an attack (e.g., comparing with a predetermined threshold, or comparing with the failure rate caused by previous executions of the program), all of which are within the scope of the present invention. The way in which the software chooses to respond to this anomaly may vary, but this provides a way to signal to the software that an attack is underway.

[0141] Figure 9Another example of a branch predictor 4 is schematically shown, which includes: a branch direction predictor (BDP) 140 for predicting whether a branch instruction will be taken; a branch target buffer (BTB) 142 for predicting the target address to which the branch instruction will redirect program execution if the branch instruction is taken; and a fetch queue 144 for queuing fetch addresses identifying blocks of program instructions to be fetched from the cache 8 (note that in some cases, the fetch queue can be considered part of the fetch stage 6 rather than part of the branch predictor 4, but the functionality will be the same). The addresses placed in the fetch queue 144 represent the addresses of the blocks of instructions to be fetched from the instruction cache 8, which are derived from previous predictions of the branch predictor. The instruction units fetched from the cache 8 in a block can be referred to as a "fetch block", and the fetch block can have a specific default size, such as 16, 32 or 64 bytes, although in some cases, when the starting address from which the fetch is to be performed is not aligned with a natural fetch block boundary, a fetch of a partial fetch block can be performed with a size smaller than the default size.

[0142] BDP 140, which may also be referred to as a branch history buffer or branch outcome predictor, records branch history information to predict the taken / not-taken outcome of branch instructions. Any known branch taken / not-taken prediction scheme may be used for BDP 140. For example, gshare or TAGE are examples of known branch direction prediction algorithms.

[0143] BTB 142 stores prediction information for a plurality of branch instructions, where the prediction information is identified by a tag corresponding to a portion of the instruction address of the branch instruction (and may depend on other information, such as a context identifier or other identifier of the current execution environment). The prediction information may indicate a target address for the branch, as well as other information, such as the instruction address of the corresponding branch instruction (program counter or PC), some attributes related to the branch (e.g., whether it is indirect, unconditional, a function call, a function return, etc.), or other information used to predict the outcome of the branch, as described below.

[0144] Branch predictor 4 also includes a multi-target branch target predictor 146, a special type of branch target buffer for predicting the target addresses of polymorphic branch instructions, i.e., instructions whose branch target addresses vary from time to time, such that different instances of a branch instruction executed at the same instruction fetch address may result in different target addresses depending on the outcome of the previous instruction that branched. Both BTB 142 and multi-target indirect branch target predictor 146 are examples of branch target prediction structures. Furthermore, branch predictor 4 includes a region table 148, which is used to compress context identifiers into shorter region identifiers for use as tag information for BTB 142.

[0145] When fetch stage 6 initiates a new fetch for a given fetch address to fetch an instruction block from instruction cache 8, branch predictor 4 also searches for the fetch address in BDP 140, BTB 142, and multi-target branch target predictor 146. If BTB 142 holds predicted branch information, including the branch target address for the program counter address represented by the current fetch address, this information is read from BTB 142 and qualified by BDP 140. This search can be controlled by branch prediction control logic 150. When BDP 140 does not predict a branch, branch prediction control logic 150 selects an incremented version of the current fetch address, which is incremented by a certain step by adder 152, as the next fetch address, so that the next fetch address used in the next cycle will sequentially follow the current fetch address. On the other hand, if BDP 140 predicts the branch is taken, branch prediction control logic 150 selects the predicted branch target address output by BTB 142 as the next fetch address. For certain instruction fetch addresses, BTB 142 may output an attribute indicating that the address points to an instruction block containing a branch that was previously detected as polymorphic, and in this case, the polymorphic branch attribute controls branch prediction control logic 150 to select the branch target address to be output by multi-target branch target predictor 146 as the next fetch address, rather than the output of BTB 142. The multi-target branch target predictor bases its predicted target address on the branch history of earlier branches that preceded the current execution point identified by the current instruction fetch address, as opposed to predictions made by BTB 142 that are independent of branch history.

[0146] The next fetch address output by the branch prediction control logic 150 is assigned to the fetch queue 144 so that when the address reaches the front of the queue, the corresponding instruction block is fetched from the instruction cache 8 by the fetch stage 6. In the next processing cycle, the next fetch address is also input as the current fetch address to trigger another lookup of the branch predictor 4 for that fetch address. This process is performed cycle by cycle in order to step through the program code being executed. If a branch misprediction is detected at the branch unit 21, when the actual result of the branch instruction is different from the predicted result generated by the branch predictor 4, a signal is sent back to the fetch stage 6 to reset the fetch queue and resume fetching from the actual branch target address, and the contents of the various prediction structures 140, 142, 146 are updated based on the actual result of the branch to increase the likelihood of correct predictions in the future.

[0147] In summary, the BTB 142 (which may also be referred to as a branch target address cache or BTAC) is a component of the branch predictor 4 that is used to identify the predicted target address of a branch. Thus, the BTB can be effectively a small cache of entries, where each entry provides the branch location (the program counter or the branch instruction address of the branch instruction), the predicted target address of the branch, and possibly other attributes, such as specifying whether the branch is a conditional branch and whether it represents a function call or a function return. Because different execution contexts (e.g., different processes executed by the processor 2 or different virtual machines) may use the same virtual address to reference different branches, in order to avoid unnecessary address conflicts, each BTB entry can be tagged with context information (e.g., a process identifier and / or a virtual machine identifier).

[0148] Figure 10 The implementation of a BTB in an embodiment that does not use region table 148 is shown. In this example, BTB 142 includes multiple entries 156, each of which includes a tag portion 158 that provides tag information, used to identify whether the entry is associated with the current fetch address during a BTB lookup; and a data portion 160 that provides predicted branch information, the data portion 160 including a branch target address 166 and any other information 168 associated with the current corresponding branch. In this example, tag portion 158 specifies one or more execution environment identifiers 162 and an instruction fetch address 164 as tag information, wherein the one or more execution environment identifiers 162 identify the execution environment (context) in which the corresponding branch is executed, and the instruction fetch address 164 corresponds to the branch (the program counter of the instruction block containing the branch). The data portion includes branch target address 166 and other information 168, such as attributes specifying whether the branch is a conditional branch, a function core, a function return, etc.

[0149] In some implementations, the data portion 160 may also include the least significant bits of the branch address 164 (although not in the Figure 10). This may be useful in superscalar processors in which multiple instructions are executed per cycle, in which case the branch predictor 4 may need to predict multiple blocks of instructions in parallel, and therefore each entry may be mapped to an instruction block. The least significant bits of the instruction fetch address may be excluded from the tag portion 158 to allow any instruction within the block to match the entry. However, even if an instruction fetch address from the block represented by a given entry is entered, if the instruction fetch address is after the address of the last branch that appeared in the block associated with that entry, then no branch will appear after that instruction fetch address, and therefore the branch prediction associated with the branch should not be executed. Therefore, by including the least significant bits of the branch address in the data portion 160 of the branch target address entry 156, this can enable a determination of whether the prediction represented by the matching entry should be executed given the current instruction fetch address looked up in the BTB 142.

[0150] The cache provided for the BTB can be implemented in different ways. In some examples, the cache can be fully associative, so that branch information for a given branch can be placed anywhere within the BTB. However, in practice, a set-associative cache implementation may be more efficient, and in this case, the locations where branch information for a given branch is allowed to be stored may be restricted to a specific set (identified based on the instruction fetch address of the instruction block containing the branch) in order to reduce the number of entries that must be looked up for a given fetch address during a branch target buffer lookup.

[0151] Typically, the BTB may have a relatively large number of entries, e.g., in the thousands, in order to be able to store enough branch information to provide sufficiently high performance. However, in practice, the number of contexts that have information stored in the BTB at a given time may be much smaller, e.g., at most ten, because one execution context may have branch information cached for many instructions of that context. Moreover, many branch instructions associated with a given context may all share the same value for the more important portion of the branch instruction address 164. This means that if implemented in the manner shown in FIG4 , the tag information 158 may include a large amount of redundant information, because explicitly indicating the full context identifier and the full branch instruction address may require a relatively large number of bits for the tag 158, which increases the circuit area required for the BTB 142 and also increases the number of comparators required for tag comparisons during lookups of the BTB 142.

[0152] like Figure 11 As shown, in order to improve the area efficiency of the BTB, the branch predictor 4 can use the region table 148 to compress the redundant information into a shorter tag value. Figure 11In the example of FIG. 1 , each entry 156 of the BTB again has a tag portion 158 and a data portion 160 , and the data portion 160 is Figure 10 However, instead of representing the execution context identifier 162 and the complete branch instruction address label 164 in the label 158 within the BTB 152, the label portion instead specifies only the lower portion 169 of the label portion of the branch instruction address and a region identifier 171 pointing to a corresponding region entry 170 in the region table that specifies the context identifier 162 and the upper portion 167 of the branch instruction address. Note that in Figure 11 The region identifier is not explicitly indicated in each region entry 170 in the BTB, but is implied from the index of the corresponding region entry 170 (e.g., the first entry in the region table may be associated with region identifier #0, the next entry with region identifier #1, and so on). The region table 148 may be much smaller than the BTB 142, e.g., having 10 to 100 entries, e.g., in Figure 11 32 in the example of . When looking up BTB 142, one or more context identifiers identifying the current execution context and the upper bits of the program counter (e.g., bits 48 to 21) are looked up in the region table to identify the corresponding region identifier, and the region identifier and the lower portion of the tag bits of the program counter (e.g., bits 20 to 16) are then used as tag information for looking up BTB 142. Note that the least significant bits of the program counter (e.g., 15 to 0) are not used at all in the tag because these least significant bits are the bits used to index into the corresponding set of the set-associated BTB 142. Thus, region table 148 allows the size of tag portion 158 of BTB entry 156 to be reduced. This takes advantage of the fact that for the purpose of looking up BTB 142, it is not necessary to distinguish the current execution context from all other execution contexts; rather, all that is required is to distinguish the current execution context from any other execution context that currently has branch information in BTB 142.

[0153] However, if Figure 12 As shown, when region table 148 is used to implement BTB 142, this may result in some false hits where branch predictor 4 determines that a branch from one execution context matches branch information in a BTB entry assigned by a different execution context. This can be achieved by comparing Figure 11 and Figure 12 See, Figure 11 and Figure 12 The contents of the BTB in one example are shown before and after updating the region table 148. Figure 11, the BTB currently includes branch information for three branches at addr1, addr2, and addr3 (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 process 2 represented by region table entry #B.

[0154] like Figure 12 As shown, a third process then executes a branch instruction and needs to allocate information into BTB 142, but process 3 currently does not have any entry allocated to it in region table 148. If all region table entries are occupied, this requires that region entry 170 be evicted and reallocated to the new process, and thus, for example, region entry 170-1 previously allocated to process 1 may be updated to now provide the context identifier and upper address bits associated with process 3. Branch target buffer entry 156-1 may also be updated to replace the previous branch 1 with the new branch associated with process 3. However, another BTB entry 156-3 specifying the region identifier #A of the updated region table entry may not be invalidated at this stage and may continue to provide information associated with branch 3, which was previously associated with process 1. When the region table is updated, invalidation logic for traversing the BTB 142 to eliminate such stale branches will typically not be provided, as this would require additional circuitry, and it is expected that if predictions are made based on this information, such incorrect branch information can be detected in any case because, at the execution stage 18, if branch prediction data from the wrong execution context is used, the actual branch outcome of the branch will be different from the prediction, and then an invalidation of the BTB entry involved can be triggered. While this may result in a performance loss, in practice, since mispredictions may occur for other reasons unrelated to the reuse of region table identifiers, this is not a big problem because the same misprediction resolution logic in processing pipeline 2 can be reused. Therefore, in a typical BTB implementation using the region table 148, entries with region identifiers that map to region table entries that have been updated may be allowed to persist along with stale branch information assigned by different execution contexts, such as in Figure 12 As shown in Example 156-3.

[0155] Therefore, when a region table entry is updated, the old entry of BTB 142 may hit a subsequent branch instruction from the new process assigned to the updated region table entry, and this may result in an erroneous hit on previously assigned branch information from a different execution context. Previously, this was considered only a performance issue, not a security issue. However, it has been recognized that an attacker may be able to use this property of the BTB to control speculative execution of another execution context that is not under the attacker's control to expose information about secret data managed by that process. This is possible if both of the following conditions are met:

[0156] Condition 1: Process A can use a target address provided in the BTB 142 by another process B.

[0157] Condition 2: Process B can control the target in the BTB entry accessed by process A.

[0158] exist Figure 12 In the above example, process 3 can use the target address provided by process 1 because the region identifier used as tag information in the BTB is reused between different contexts (condition 1). Similarly, process 1 can control the target in the BTB entry accessed by process 3 because it can execute a branch with an expected target address that shares tag bits [20:16] with the branch in process 3, causing the expected target address to be assigned to the entry in BTB 142 that will be hit by process 3. More generally, these conditions may arise in branch target prediction structures in which the value of tag information 158 can be reused between multiple execution contexts. The region table is one reason this may occur, but other reasons may simply be that the tag information does not depend on the identifier(s) of the current execution context (current execution environment).

[0159] The two conditions described above can serve as the basis for the following attack. First, an attacker-controlled process 1 can execute a branch instruction, which results in the allocation of a BTB entry specifying the branch target address. This BTB entry maps to a malicious instruction sequence designed to be executed by victim process 3 in order to control victim process 3 to perform some operation that may expose secret data to the attacker. After the region table has been updated and the region identifier previously used for attacker process 1 has been reassigned to victim process 3, victim process 3 then executes an instruction based on the address that matches the tag data in the outdated BTB entry allocated by attacker process 1, and thus makes a branch prediction based on this information provided by the attacker. This results in speculative execution of the instruction sequence that forms the branch target address provided by the attacker, i.e., special instructions provided by the attacker that are designed to trick victim process 3 into exposing secret data by leaving footprints in non-architectural state (e.g., data caches). These instructions may include, for example, memory access instructions that use secret information to which the attacker wishes to gain access to calculate their target memory address. Therefore, the data loaded into caches 30, 32 by the memory access instructions may depend on the secret information. Even if a branch misprediction is eventually identified, and the architectural state in registers 14 of processor pipeline 2 is therefore rewound to a point prior to the instruction sequence mispredicted and speculatively executed by victim process 3, the data loaded from memory by the incorrectly speculatively executed instruction may still remain in cache 30, 32. Therefore, when execution switches back to attacker process 1, the attacker may attempt to access every possible address that could result from computing the target address based on the secret data. While performing such memory accesses, attacker process 1 may measure performance data, such as the execution time for the load instruction or the number of cache misses. Based on this side-channel information about performance, the attacker may be able to determine whether victim process 3 placed data from a given address into cache, and this may be used to infer properties of secret data that victim process 3 can access but attacker process 1 cannot.

[0160] In order for this attack to succeed, the two conditions provided above need to be met. Figure 13A technique is shown for breaking this second condition, thereby preventing such an attack by making it difficult for the attacker to control the branch target address that would be used by the victim context in the event of a false hit. The branch target prediction structure 142, 146 is provided with: an encryption circuit 174 for encrypting branch information to be written to the branch target prediction structure based on an encryption key associated with the current execution context; and a decryption circuit 176 for decrypting branch information read from the branch target prediction structure based on an encryption key associated with the current execution context. A key generation circuit 179 (e.g., a linear feedback shift register or other random number generator) may generate a key from time to time for each context. The branch target prediction circuit 178 (which may correspond to Figure 9 The branch prediction control logic 150 and any cache access circuitry associated with the branch target prediction structures 142, 146 for generating target tag values and looking up branch target entries to identify branch information for a given instruction fetch address) may generate a target tag based on the instruction fetch address (e.g., using the region table 148) and, if there is a hit in the branch target prediction structure, control the branch target prediction structure to output the encrypted branch information. If there is a miss, and the branch is subsequently executed by the execute stage 18, the actual branch information for the branch is encrypted by the encryption circuit 174 under control of the branch target prediction circuitry and written to the branch target prediction structure in association with the tag information identifying the branch. The encryption circuit 174 and the decryption circuit 176 are arranged in a manner that is consistent with the instructions in the preceding text. Figure 13 They are shown as separate circuits, but may be the same circuit (eg, an XOR circuit).

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

[0162] Figure 14An example of the contents of region table 148 and branch target buffer 142 when encryption / decryption is applied is shown. 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. Key 180 can be generated as a random or pseudo-random number by a linear feedback shift register (LFSR) or other random number generator 179 each time the corresponding region table entry 170 is updated, such that the key is different for different execution contexts that reuse the same region table entry. When a lookup into BTB 142 misses, fetching continues beyond the current fetch address. However, if a branch from the fetched instruction block is executed at execute stage 18, the actual branch information is determined and can be assigned to a new branch entry 156 of BTB 142. When allocating a new BTB entry, the branch information is encrypted using the corresponding encryption key 180 stored in region table 148 for the current execution context. Optionally, tag information 158 can also be encrypted using the key. However, encryption of tags is not required. In some embodiments, any additional information 168 stored as predicted branch data 160 may not be encrypted, and thus only the branch target information may be encrypted, but security may be stronger if all branch information 160 is encrypted.

[0163] At branch prediction lookup time, a hit is generated in the BTB 142, so the tag information 158 matches the target tag generated for the current instruction fetch address. Then, instead of simply outputting the branch information 160 directly from the BTB 142, the branch information is first decrypted using the corresponding encryption key 180 associated with the current execution context as defined by the region table 148, and the decrypted branch information is then used by the branch prediction logic 150 to derive the next fetch address. The encryption and decryption used to protect the BTB context can be implemented using secret key encryption or using public key encryption. Since branch target address predictions may be located on a critical timing path of the processing pipeline, it may be useful to use a relatively lightweight encryption method (e.g., XORing the branch information with the key 180) rather than using, for example, more complex multi-round encryption.

[0164] like Figure 15 As shown, this technique can prevent the second condition for the above-mentioned attack because by encrypting the branch information using the key associated with the execution context that assigned the information, if the same BTB entry 156-3 is accessed from a new execution context and then decrypted using the key of the new execution context, garbage information will be generated instead of the target address assigned by the original context, making it difficult for an attacker to push a malicious target into the BTB and control a different execution context to execute malicious code from a known location. For example, in Figure 15In the example, the attacker controls process 1 to allocate a certain entry 156-3, and then the zone entry 170-1 is updated to point to the following Figure 12 Process 3 is shown. When the region table is updated, a new key 180 will be generated for region table entry 170-1, and therefore, if there is a hit in BTB entry 156-3 subsequently during execution from the new execution context 3, decrypting the branch information using the new key will not produce the same branch target address as the branch target address originally provided by process 1. The old information in the branch target information is encrypted by the outdated key (key 1, which is no longer available in the region table), while region table entry #A has the new key. In order to enable the creation of the type of attack discussed above to control victim process 3 to jump to a malicious target address T, the attacker will need to provide a different target address T' so that Dec(Enc(T', key 1), New key) == T, which gives a sufficient number of bits for the encryption key so that it is infeasible for an attacker who does not know the old and new keys to be able to predict the value of T' required to force victim process 3 to branch to T.

[0165] although Figure 14 and Figure 15 An example is shown in which keys associated with various execution contexts are cached in region table 148, but this is not required, and a separate storage structure may also store keys associated with each execution context.

[0166] exist Figure 14 and Figure 15 In the example shown, the key is a one-time use dynamic key because it is updated each time a region table replacement occurs. This makes an attack more difficult because the attacker will need to identify the key and exploit it to read the secret information before the key's lifetime ends, reducing the likelihood that an attacker can learn information about the key by observing a series of branch prediction results from the BTB during the available time before the key is updated. However, in other implementations, in addition to the dynamic keys assigned to region table entries, a static key for each execution context may be used so that the same key is used for a given execution context throughout the lifetime of the context. In this case, an efficient way to generate a key for each context to reduce storage requirements may be to provide a common key that is shared among all execution contexts, but to derive a context-specific key for each context from the common key by hashing it with the context identifier(s) associated with the context.

[0167] Figure 16 and Figure 17An example of the use of a multi-target indirect branch predictor 146 is shown. For polymorphic branches whose target addresses vary from time to time during a program, a BTB 142 that provides a fixed target address for each branch program counter address may not be able to provide reliable predictions, and therefore a separate prediction structure 146 may be provided. For such polymorphic branches, the branch information in the BTB 142 may be updated to provide an indicator that the predicted target address of the BTB should not be used in the future and that the multi-target indirect branch predictor 146 should instead be used to predict the branch target address for such a branch. The multi-target indirect branch predictor includes a plurality of branch target entries 190, each of which includes information indicating the target address predicted for the branch and tag information 194 based on a history of the outcomes of previous branches (e.g., a bit sequence indicating whether the previous branch was not taken or was taken). Thus, multiple entries in the multi-target indirect branch predictor 146 corresponding to different branch histories leading to the branch can be assigned to the same branch instruction. The tag information 194 also depends on the instruction fetch address of the instruction block containing the branch. Unlike BTB 142, the tag information does not include the context identifier or the upper bits of the program counter address of the corresponding execution context. Because the tag associated with each entry in multi-target indirect branch predictor 146 is independent of the current execution context, this again means that tag values can be reused across multiple execution contexts. If an attacker controlling process 2 knows the access pattern (branch history) used to reach a specific indirect branch in victim process 1, the attacker can exploit this by pushing a known branch history pattern (e.g., Figure 15 The malicious target address marked by label A in

[0045] is used to exploit security issues similar to those discussed above. The assumption here is that an attacker can intentionally predict a label conflict in the multi-target indirect branch predictor 146.

[0168] like Figure 17 As shown, to prevent exploitation of this weakness, the encryption key 180 from the region table can also be used to encrypt the contents of the multi-target indirect branch predictor 146. Thus, when branch information is assigned to an entry 190 of the multi-target indirect branch predictor 146, the encryption key 180 for the current execution context is read from the region table and used to encrypt the branch information 192 and, optionally, the tag 194 of the corresponding entry 190. When looking up the multi-target indirect branch predictor 146, the encryption key 180 of the current execution context is used to decrypt the branch information 192, so that if the current execution context hits an entry assigned by a previous execution context, the decryption is performed using a different key than the key used to encrypt the data, which will result in garbage data being output at an address different from that originally provided by the previous execution context.

[0169] Therefore, even in implementations that do not use region table 148, if the branch predictor uses a multi-target indirect branch predictor 146 or another prediction structure that uses labels that are unrelated to the current execution context, it may be useful to encrypt the contents of the branch predictor again, thereby preventing an attacker from being able to use false hits in the branch prediction structure to control the victim process to execute malicious code designed to give visibility into secret data.

[0170] Figure 18 1 is a flow chart illustrating a method for performing branch target prediction lookup and branch information update in the branch target prediction structures 142, 146. It should be understood that Figure 18 Not all features of branch prediction that may be performed are shown (e.g., not shown are the branch direction predictions by BDP 140, nor the steps taken to halt execution of speculatively executed instructions and roll back processor state in the event of a misprediction - these operations may be performed as with any known branch prediction technique).

[0171] At step 200, a target tag is obtained for the instruction fetch address for which a branch predictor lookup is to be performed. The specific nature of the target tag will depend on how the branch predictor architecture is implemented. For example, for a BTB implemented using region table 148 as described above, the target tag may be determined from the region table based on a context identifier of the current execution context and a portion of the instruction fetch address. Figure 19 This approach is discussed in more detail below. Alternatively, for the multi-target indirect branch predictor 146, the target label is based on the instruction fetch address and a history of previous taken / not-taken outcomes. Other ways of generating the target label are also possible.

[0172] At step 202, the branch prediction control logic 150 controls the branch target prediction structure 142, 146 to search a subset of the branch target entries 156, 190. The subset of entries can be selected, for example, based on the instruction address, or, in a fully associative cache implementation, can include all entries of the branch target prediction structure. The branch prediction circuitry determines whether any of the selected set of entries specifies tag information corresponding to the target tag obtained for the given branch instruction at step 200. If none of the subset of branch target entries specifies tag information corresponding to the target tag, the search in the branch target prediction structure misses, and the branch prediction control logic 150 outputs an incremented version of the current fetch address from the adder 152 as the next fetch address. Once the corresponding instruction block has been decoded, the decode stage 10 determines at step 203 whether any instruction in the block is a branch instruction. If not, the method ends because no branch information needs to be updated. If the fetched / decoded instruction block includes a branch instruction, then at step 204, a victim entry is selected from the subset of the searched branch target entries. For example, if one of the subset of branch target entries is currently invalid, then the invalid entry can be selected as the victim entry. If all subsets of branch target entries are currently valid, then one of the valid entries is evicted to make room for the new branch information. Any eviction strategy can be used to select the victim entry (e.g., round-robin or least recently used entry).

[0173] At step 206, once the execution stage 18 has resolved the actual branch information for a given branch instruction, the actual branch information is encrypted using an encryption key associated with the current execution context. The branch information may include information for deriving or specifying the branch target address, and may also include other information about the branch as described above. The encryption key may be read from the region table 148 or from a separate storage device. In some cases, the target tag may 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.

[0174] If there is a hit in the branch target prediction structure 142, 146 at step 202, and one of the lookup subsets of branch target entries specifies tag information corresponding to the target tag, then at step 210, the branch information stored in the matching entry is decrypted using an encryption key associated with the current execution context. At step 212, the decrypted branch information is output as a prediction for the given branch instruction. The branch target address derived from the decrypted branch information is assigned to the fetch queue 144 to control subsequent fetches of instructions, and other prediction attributes of the branch instruction specified by the decrypted branch information can control other aspects of the processing pipeline. Once the branch reaches the execute stage, the actual branch information is determined for the branch instruction, and a determination can be made as to whether the prediction was correct. If there was a misprediction, the instructions following the branch instruction can be flushed from the pipeline, and a signal can be sent to the fetch stage 6 to resume fetching instructions from the correct target address of the branch (if the branch was taken) or from a sequential address following the instruction address of the branch (if the branch should not have been taken). Furthermore, the branch predictor 4 may be updated to correct the branch information stored in the branch target prediction structures 142, 146 based on the actual branch outcome so that subsequent predictions for the same instruction fetch address are more likely to be correct next time.

[0175] Figure 19 In an embodiment where the branch target prediction structure is BTB 142, Figure 18 200 , wherein the BTB 142 uses the region table 148 to compress the tag portion of each entry. At step 220 , the region table 148 is looked up based on branch context information associated with the current instruction fetch address. For example, the branch context information may include one or more context identifiers that identify the execution context in which the branch is executed, and may also include the upper branch instruction address bits of the instruction fetch address. At step 222 , the branch prediction control circuitry determines whether the region table includes a matching region table entry 190 , wherein the branch context information stored in the entry 190 matches the branch context information provided for the given branch instruction. If so, there is a hit in the region table, and at step 224 , the target tag is determined to include the region ID associated with the matching region table entry and one or more low bits of the tag portion of the instruction address (e.g., in Figure 14 Furthermore, at 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.

[0176] If, in step 222, the lookup in the region table misses, and therefore there is no matching region table entry with branch context information that matches the branch context information provided for the current instruction fetch address, then in step 230, a victim region table entry is selected, such as an invalid region table entry that has not yet been mapped to a particular context, or if there is no invalid entry, a valid region table entry is evicted. In addition, an eviction strategy (e.g., LRU or round-robin) can be used to select the victim region table entry. In step 232, the encryption key 180 stored in the victim region table entry is updated. For example, a linear feedback shift register or other random or pseudo-random number generator can be triggered to output a new random or pseudo-random number. The updated encryption key is written to the victim region table entry. In addition, in step 234, the branch context information determined for the given branch instruction in step 220 is written to the victim region table entry selected in step 230. The region identifier associated with the victim region table entry has been mapped to the new execution context, and any entries of BTB 142 that were previously mapped to that region identifier may now return false positive hits if looked up from the current execution context, since they were assigned by the previous execution context that shared the same region identifier. However, by updating the encryption key at step 232, the encrypted contexts of those false positive entries will not behave in the manner that would have been expected by the previous execution context that assigned those entries to BTB 142, and thus this prevents a malicious process from being able to control a particular branch target address executed by another context to map to an address of the attacker's choosing. After step 234, Figure 19 The method continues to step 224, and steps 224 and 226 are then performed in the same manner as if the region table lookup generated a hit, so as to return a target tag for a subsequent lookup of the branch target prediction structure and to return the encryption key. Figure 19 After that, you can then use Figure 18 The following step 202 uses the generated tag for branch target prediction lookup.

[0177] In summary, branch information in a branch target prediction structure is encrypted based on an encryption key associated with the execution context that caused the branch information to be assigned to the branch target prediction structure. When a hit occurs during a lookup of the branch target prediction structure, the branch information from the matching entry is decrypted using the encryption key associated with the current execution context. This is useful for branch target prediction structures that use tag information with values that can be reused in more than one execution context, because the encryption and decryption make it difficult for an attacker to gain access to sensitive data in another execution context by exploiting a false hit in an entry of the branch target prediction structure from a context different from the context to which the entry was assigned.

[0178] It should be understood that Figures 9 to 19 The specific example shown is merely one way to implement a branch predictor. More generally, when generating a new branch prediction entry, a portion of the input to the branch predictor can be encoded based on a value associated with the current execution context, and when querying the branch predictor for a given query input, either the query input that triggered the query can be encoded using the value associated with the execution context, or the output of the branch predictor can be reverse-encoded or decoded using the value associated with the most recent execution context, or both, making it more difficult for an attacker to guess what state must be trained in the branch predictor in order to control a victim process, thereby exploiting a false hit in the branch predictor between different execution contexts to control a branch to a particular address.

[0179] Translation lookaside buffer

[0180] The present technology also relates to an address translation circuit (e.g., translation lookaside buffer 4), which is another form of the claimed storage circuit. Figure 20 As shown, the translation lookaside buffer 4 includes a plurality of entries 3, each entry 3 providing a translation between an input address (e.g., a virtual address) and an output address (e.g., a physical address). The input address includes a tag 305, an index 310, and an offset 315. The translation lookaside buffer 4 indicates, for each entry, whether the entry is valid (V), whether the data stored at the output address is writable (W), and the process identifier (ASID) associated with the entry. In some embodiments, entries in the TLB may also be listed in association with a virtual machine identifier (VMID), which identifies the virtual machine instance associated with the entry. In some embodiments, entries in the TLB may also be listed in association with an exception level, which indicates the privilege level at which the entry can be accessed. The result value of the entry is combined with the offset value 315 of the input address to generate the output address.

[0181] The index 310 portion of the input address is hashed to determine which entry 3 in the translation lookaside buffer 4 is associated with the address translation. The resulting values of the corresponding entries are combined (assuming the entries are valid and the ASID matches the current ASID) to determine the output address, for example, an address in physical memory. In this example, the encoding circuitry 52 performs a hash function that depends on (e.g., takes as input) an identifier of the current execution environment. Therefore, in a TLB (which is typically set associative), one execution environment will find it difficult to determine the set associated with another execution environment's virtual address because the hash results for different execution environments are unknown. Therefore, for example, it will be difficult to determine which entries in the TLB are being used by another execution environment.

[0182] Maintaining the correctness of the translation lookaside buffer 4 is important. That is, no valid, incorrect entries should exist within the translation lookaside buffer. This can present difficulties because the hash function (or one of its components) may change over time. Furthermore, the encoding circuitry 52 may point to entries 3 in the translation lookaside buffer associated with different execution environments. Therefore, in the context of the current execution environment, the result will be "erroneous." To address this issue, when the encoding circuitry 52 references an entry, a comparison circuit 317 is used to compare the tag 305 and index 310 of the input address with the tag and index of the corresponding entry 3. Other "context controls" are added to restrict the execution environments that can access the entry (e.g., the VMID and / or exception level mentioned above), and the comparison circuitry 317 also compares these to check whether these requirements are met. Furthermore, each entry stores its associated tag and index. If the comparison indicates that the values are identical, the entry's "result" value is output. This "result" value is combined with the input address's offset value 315 to form the output address. If the comparison indicates that the values are not identical, no output is provided; and a "miss" occurs in TLB 4.

[0183] As described above, input is provided to the encoding circuit 52 for encoding the input address. The input (including the current execution environment) can change over time to improve security. The hash function and its input can include any of the techniques previously described. However, in some embodiments, multiple inputs to the hash function are provided on a per-process basis, which not only prohibits access to data belonging to another process, but also enables the use of maintenance operations such as "invalidate by virtual address".

[0184] cache

[0185] In a similar manner to the TLB 4, the present technology is also relevant to caches such as the instruction cache 4, which is Figure 21 Another form of the claimed storage circuit 4 is shown. As in the case of the translation lookaside buffer, it is still desirable to provide the correctness of entry 3. Therefore, after the specific entry to be accessed is identified based on the output of encoding circuit 52 using the current execution environment, comparison circuit 317 is used to verify whether the desired entry has been accessed. If so, the instruction stored at that entry 3 in instruction cache 4 is passed to selection circuit 319. Here, offset 315 of the input address is used to select one of the instructions stored in entry 3, which is output as the accessed instruction. In this case, it is assumed that the instruction is only two bytes long, and the offset indicates which of the two bytes stored in the specific entry 3 is being accessed.

[0186] Note that the instruction cache is typically read-only because instructions cannot be modified. Similarly, since instructions stored in the instruction cache cannot be written, there is no dirty flag indicating that the instruction should be written back to memory as a result of being modified.

[0187] Data Cache

[0188] The present technique can also be used to involve data cache 4, which is such as Figure 22 Another form of the claimed memory circuit is shown. Figure 22 A set-associative data cache 4 is shown, which is divided into four ways 335a, 335b, 335c, and 335d, where each way is divided into multiple sets, each of which can store entries. A hash algorithm can be used to determine the set to be used for a given input address. Each way of the selected set is then checked to locate the requested data.

[0189] In the present technique, a hash algorithm is performed by encoding circuitry 52, which at least in part bases the hash algorithm on the current execution environment. Consequently, other execution environments cannot easily infer where a data item is stored in the cache, thereby limiting their ability to obtain that data. As with instruction cache 4, comparison circuitry 317 is used to provide correctness. In other words, the index and tag combination of the input (e.g., virtual) address is compared to the index and tag stored with each entry 3 to prevent erroneous data (e.g., data stored under an old value in the current execution environment or stored by a different execution environment) from being inappropriately accessed.

[0190] However, when using this technique for a data cache (as opposed to an instruction cache), additional considerations apply. Unlike in an instruction cache, data stored in a data cache can be modified. This can lead to consistency issues in situations where multiple different versions of the same data exist within the cache. Therefore, if two processes attempt to access the same physical address, they should be directed to the same set. If this is not the case, each process will obtain its own copy of the data (e.g., from memory), store it in a different set, and then modify the data.

[0191] This problem does not arise for data that cannot be modified. Although space in the cache may be wasted, there are no consistency issues associated with storing multiple copies of read-only data in the cache. Therefore, with respect to data stored in pages of memory marked as read-only (e.g., not writable), the encoding (e.g., hashing) process can proceed as previously described. Whether the page of memory associated with the data is writable can be stored, for example, in a page table and / or TLB.

[0192] In addition, there are a number of possible solutions to this problem. First, the encoding process performed by the encoding circuitry 52 can be abandoned for data stored in pages that are shared between processes. Similarly, this information can be stored in a page table and / or TLB along with the entry for a given page. Second, the current execution environment can take into account the page of memory containing the data being accessed. For example, the encoding performed by the encoding circuitry can be changed on a page-by-page basis, where the input to the encoding circuitry (the current execution environment) is stored, for example, in a TLB or page table entry.

[0193] In other cases, such as where different processes do not share data, the current execution environment may change between processes so as to obscure the location of data stored for different execution environments.

[0194] Note that in some embodiments, the current execution environment may be different for each of the different modes. This may provide further obfuscation as to where the data is located.

[0195] VIPT cache

[0196] Figure 23 The use of a Virtually Indexed, Physically Tagged (VIPT) cache 4 is shown, which is another type of claimed storage circuit, with which the present technique may be used. The use of a VIPT cache adds further considerations beyond those described above for data caching.

[0197] In particular, in a VIPT cache, some bits of the index will be different than if it came from a physical address, and thus a physical address can map to multiple sets. Thus, the same physical address can be mapped to multiple different sets of the cache (each of these sets may have multiple ways 335). In many architectures, consistency is maintained between all of these "aliases." Therefore, it is important to prohibit the same physical address from residing in multiple locations in the cache at the same time. In this embodiment, this is managed by using a snoop filter 347 belonging to a lower level cache (e.g., a level 2 cache in the case of a level 1 VIPT cache).

[0198] Relative to Figure 24This process is shown in more detail. A request is issued to the L1 VIPT data cache 4. As previously described, at least some bits of the access address associated with the request are encoded by the encoding circuitry 52 using the current execution context. In this way, each execution context can be associated with its own "alias." In this example, the access request results in a miss. However, the data does in fact exist at another alias of the accessed address in the L1 VIPT data cache 4. A miss at the L1 VIPT data cache 4 results in a "wrap request" being issued to the lower-level indexing circuitry (e.g., snoop filters 347, 349). In this case, the snoop filter 347 of the second-level cache knows that the requested data is stored in a different alias of the L1 VIPT data cache 4. Therefore, the data is held by a different execution context. Therefore, a snoop and evict request is sent to the L1 VIPT data cache 4, and the requested access is performed. Once the access is complete, a reallocation request is made to store the data (as modified) from its previously allocated location to its newly requested location due to the encoding circuitry 52.

[0199] Snoop filter 347 is able to determine the index at which each data item is stored in L1 VIPT data cache 4 by watching the fetches performed by L1 VIPT data cache 4. Snoop filter stores the index at which the data is stored (or an identification of an alias that stores a given data item) for each item stored in a higher-level L1 VIPT data cache 4. Alternatively, in some embodiments, snoop filter 347 may query each possible alias.

[0200] Main memory

[0201] Figure 25 An embodiment is shown in which the present technology is applied to a main memory (eg, DRAM) 4 , which is another example of the claimed memory circuit.

[0202] When the physical address is passed to the memory controller 340, the memory controller accesses the relevant channel, DIMM, rank, and bank. At this time, each bit is stored in a unit 343 consisting of rows and columns, and the memory controller accesses the relevant unit to perform the requested memory access.

[0203] One attack that can be performed on DRAM, called a "rowhammer attack," exploits the physical properties of these cells. Specifically, DRAM works by applying charge to components (such as capacitors) that slowly discharge over time. To maintain the value stored in the cell, a periodic "refresh" is performed, where the stored value is read and written back to the cell—thus restoring the charge and preventing it from completely dissipating. As memory density increases, the size of individual cells decreases, and their tolerance to noise decreases. A rowhammer attack works by identifying cells that are susceptible to charge leakage from other neighboring cells. These neighboring cells are then repeatedly hammered (accessed) to continuously apply charge to them. Each small amount of applied charge leaks into the susceptible cells. When the refresh time arrives, the value of the susceptible cell is read. If enough leakage occurs, the value stored in the cell is misinterpreted and refreshed with the wrong value—causing a bit in that cell to flip. For bits representing privilege levels (for example, for memory pages), this can lead to escalation attacks. This can be particularly problematic because locating data stored within main memory can enable an attack to exploit or gain information about code running not only on the local core, but also on other cores in the system.

[0204] Rowhammer attacks are possible largely because of the direct mapping between physical addresses and cells in DRAM.

[0205] Therefore, the present technology can be applied to make the mapping between physical addresses and unit locations obfuscated. In particular, by changing the mapping between systems, any reverse engineering to identify the relationship between physical addresses and unit locations becomes very difficult each time each system is started.

[0206] As in other embodiments, encoding circuitry 52 is provided to encode the access address. In this case, the access address takes the form of a physical address. The current execution environment is used to implement the encoding. In this case, the encoding may take the form of a combination of factors, including a unique machine identifier and an identifier that changes (e.g., randomly generated) each time the system is started. These identifiers are invisible to software, so they cannot be read or modified by software.

[0207] The encoding can be a permutation of the physical address. This makes it possible to undo the encoding. Since the physical address itself does not change, the entire process is invisible to existing software (and is therefore backward compatible).

[0208] Note that where multiple memory controllers are provided (e.g., in a multiprocessor system), each controller may be allocated a portion of the address space and different encodings may be applied to addresses within that address space. Alternatively, a single encoding may be used and a portion of that encoding may be used to select which memory controller to use.

[0209] In some embodiments, rather than permuting every single address, permutations are performed at a higher level of granularity. Thus, physical addresses that are close to each other are more likely to remain physically close to each other. For example, the location of a page can be permuted by permuting only a selection of bits in the physical address.

[0210] Combined system

[0211] It should be understood that the elements of each embodiment in the above-described embodiments can be combined into a single system, wherein each storage circuit makes the location of the data stored by it obscure. In this case, different execution environments can be considered for each item of the storage circuit, and since the consistency of the storage protocol between the storage circuits is improved, security can be improved. On the contrary, a single execution environment can be considered for each item of the storage circuit (for example, each item of the storage circuit can be considered in the same way as the "execution environment"). One reason for doing this is to limit the number of execution environment-specific variables that exist for processing the storage at each item of the storage circuit.

[0212] The following paragraphs list additional example arrangements:

[0213] (1) A data processing apparatus comprising: branch prediction circuitry adapted to store at least one branch prediction state entry associated with an instruction stream; input circuitry adapted to receive at least one input to generate a new branch prediction state entry, wherein the at least one input comprises a plurality of bits; and encoding circuitry adapted to perform an encoding operation to encode at least some of the plurality of bits based on a value associated with a current execution environment in which the instruction stream is being executed.

[0214] (2) The data processing apparatus according to item (1), wherein the encoding operation includes encoding at least some of the plurality of bits based on a value indicating current execution permissions in which the instruction stream is being executed.

[0215] (3) The data processing apparatus of item (1), wherein the encoding operation includes encoding at least some of the bits by using a key, wherein the key is based on a current execution environment in which the instruction stream is being executed.

[0216] (4) The data processing apparatus according to item (3), wherein the encoding operation includes rearranging or switching at least some of the plurality of bits using a key.

[0217] (5) A data processing apparatus according to item (3), wherein at least one input includes an indication of an instruction address of a branch instruction; the branch prediction circuit is adapted to receive a query value including an indication of the instruction address of the instruction and to perform a search using the query value; and the encoding circuit is adapted to perform an encoding operation on at least some of the plurality of bits of the query value using a key prior to the search.

[0218] (6) A data processing device according to item (5), wherein the encoding circuit is suitable for recalculating the value of the key associated with the current execution environment and using the recalculated key value to perform the encoding operation on at least some of the multiple bits of the query value.

[0219] (7) A data processing device according to item (3), wherein at least one input includes an indication of a destination address of a branch instruction; the branch prediction circuit is suitable for receiving a query value including an indication of the instruction address of the instruction and using the query value to perform a search; and the device includes a reverse encoding circuit, which is used to perform a reverse encoding operation on an output of the branch prediction circuit in response to receiving the query value.

[0220] (8) The data processing apparatus according to item (7), wherein the reverse encoding circuit is adapted to recalculate the value of the key associated with the current execution environment and perform the reverse encoding operation using the recalculated key value.

[0221] (9) A data processing apparatus according to item (3), wherein the key is further based on any combination of one or more key input values indicating at least one of the following: exception level, privilege level, ASID, VMID, NS, physical processor core number, and logical core number in which the instruction stream is being executed, one or more software writable registers, and a previously generated random number.

[0222] (10) The data processing apparatus of item (9), wherein the previously generated random number comprises at least one of: an element for each logical processor; an element for each physical processor; and a system-wide element.

[0223] (11) The data processing apparatus of item (9), wherein the key is based on a one-way transformation applied to the one or more key input values.

[0224] (12) A data processing apparatus according to item (1), wherein the instruction stream can be executed in one of a plurality of execution environments suitable for execution with a minimum execution permission; and the encoding circuit is adapted to perform the encoding operation further based on an identifier of one of the plurality of execution environments in which the instruction stream is being executed.

[0225] (13) A data processing apparatus according to item (1), comprising: a monitoring circuit adapted to detect a failure rate of any combination of instruction fetch failures and instruction decode failures when executing an instruction stream in a speculative state, and to generate an exception or an error response in response to the failure rate satisfying a predetermined condition.

[0226] (14) A data processing device according to item (1), wherein the branch prediction circuit includes: a branch target prediction structure, the branch target prediction structure including a plurality of branch target entries, each branch target entry specifying at least a branch target address; and an encoding circuit, the encoding circuit including an encryption circuit, the encryption circuit being used to encrypt at least a portion of a new branch target entry to be written to the branch target prediction structure using an encryption key associated with a current execution environment.

[0227] (15) A data processing apparatus as described in item (14), wherein each branch target entry that specifies at least a branch target address specifies label information and branch data; and the apparatus includes a branch target prediction circuit for performing a branch target prediction lookup on an instruction fetch address associated with a current execution environment, the branch target prediction lookup comprising determining whether any one of a subset of branch target entries of a branch target prediction structure specifies label information corresponding to a target label determined for the instruction fetch address.

[0228] (16) The data processing apparatus according to item (15), wherein the value of the target tag is reusable in more than one execution environment.

[0229] (17) The data processing device according to item (15), wherein the encryption circuit is configured to encrypt at least a portion of the label information of the new branch target entry using an encryption key.

[0230] (18) A data processing device according to item (17), wherein the encryption circuit is configured to encrypt at least a portion of the branch data of the new branch target entry using an encryption key; and the device includes a decryption circuit for decrypting at least a portion of the branch data of one of the subset of branch target entries that is identified in the branch target prediction lookup as specifying tag information corresponding to the target tag.

[0231] (19) The data processing apparatus according to item (14), wherein the encryption key includes a static key fixed for a current execution environment.

[0232] (20) A data processing device according to item (19), wherein the static key for the current execution environment depends on a common key shared between at least two execution environments among the plurality of execution environments and at least one identifier specific to the current execution environment.

[0233] (21) The apparatus according to item (14), wherein the encryption key comprises a dynamic key that is changeable with respect to a current execution environment.

[0234] (22) The apparatus according to item (21), comprising: a key generation circuit for generating an updated encryption key for a current execution environment.

[0235] (23) The apparatus of item (15), comprising: a region table comprising a plurality of region entries, each region entry mapping branch context information to a region identifier comprising fewer bits than the branch context information, the branch context information comprising at least one identifier associated with a corresponding execution environment.

[0236] (24) The apparatus of item (23), wherein the target tag for the instruction fetch address comprises a target region identifier that is mapped by the region table to branch context information associated with the instruction fetch address.

[0237] (25) The apparatus of item (23), wherein each region entry specifies an encryption key associated with a corresponding execution environment.

[0238] (26) An apparatus according to item (23), wherein, when a mapping provided by a given region entry of the region table is updated, the branch target prediction circuit is configured to trigger an update of an encryption key associated with an execution environment after the mapping is updated, wherein the execution environment is associated with the given region entry.

[0239] (27) The apparatus of item (14), wherein the branch target prediction circuit is configured to determine the target label based on the instruction fetch address and a history of branch outcomes of previous branch instructions preceding the instruction at the instruction fetch address.

[0240] (28) A data processing apparatus comprising: a storage component for storing at least one branch prediction state entry associated with an instruction stream; a receiving component for receiving at least one input to generate a new branch prediction state entry, wherein the at least one input comprises a plurality of bits; and an encoding component for encoding at least some of the plurality of bits of the at least one input based on a value associated with a current execution environment in which the instruction stream is being executed.

[0241] (29) A method comprising: storing at least one branch prediction state entry associated with an instruction stream; receiving at least one input to generate a new branch prediction state entry, wherein the at least one input comprises a plurality of bits; and encoding at least some of the plurality of bits based on a value associated with a current execution environment in which the instruction stream is being executed.

[0242] The following clauses also list additional example arrangements:

[0243] (1) A data processing device comprising:

[0244] a branch prediction circuit adapted to store at least one branch prediction state entry associated with an instruction stream;

[0245] input circuitry for receiving at least one input to generate a new branch prediction state entry, wherein the at least one input comprises a plurality of bits; and

[0246] Encoding circuitry is adapted to encode at least some of the plurality of bits based on a value indicative of current execution permissions in which an instruction stream is being executed.

[0247] (2) The data processing device according to item (1), wherein

[0248] The encoding circuitry is adapted to encode at least some of the bits using a key, wherein the key is based on current execution permissions in which the instruction stream is being executed.

[0249] (3) The data processing device according to item (2), wherein

[0250] The encoding circuit is adapted to encode at least some of the plurality of bits by rearranging at least some of the plurality of bits using a key.

[0251] (4) The data processing device according to item (2), wherein:

[0252] The encoding circuit is adapted to encode at least some of the plurality of bits by toggling at least some of the plurality of bits using a key.

[0253] (5) The data processing device according to item (2), wherein:

[0254] The encoding circuit is adapted to encode at least some of the plurality of bits by performing a hash function using a key.

[0255] (6) The data processing device according to item (5), wherein

[0256] Hash functions are reversible.

[0257] (7) The data processing device according to item (2), wherein

[0258] The encoding circuit is adapted to encode at least some of the plurality of bits by performing an XOR operation on a key.

[0259] (8) The data processing device according to item (5), wherein

[0260] The hash function is a one-way hash function.

[0261] (9) The data processing device according to any one of items (2) to (8), wherein:

[0262] at least one input includes an indication of an instruction address of a branch instruction;

[0263] The branch prediction circuitry is adapted to receive a query value including an indication of an instruction address of a branch instruction and to perform a search using the query value; and

[0264] The encoding circuit is adapted to perform an encoding operation on at least some bits of the query value using a key prior to the search.

[0265] (10) A data processing device according to item (9), wherein the encoding circuit is suitable for recalculating the value of the key associated with the current execution environment and using the recalculated key value to perform an encoding operation on at least some of the multiple bits of the query value.

[0266] (11) The data processing apparatus according to any one of items (2) to (10), wherein at least one input comprises an indication of a destination address of a branch instruction;

[0267] The branch prediction circuitry is adapted to receive a query value including an indication of an instruction address of a branch instruction and to perform a search using the query value; and

[0268] The apparatus includes a decoding circuit to decode an output of the branch prediction circuit in response to receiving a query value.

[0269] (12) The data processing device according to item (11), wherein

[0270] Decoding involves recalculating the value of the key and then performing the decoding function.

[0271] (13) The data processing device according to any one of items (1) to (12), wherein:

[0272] The key is also based on any combination of values indicating exception level, privilege level, ASID, VMID, NS, physical processor core number, and logical core number in which the instruction stream is executing and one or more software writable registers.

[0273] (14) The data processing device according to any one of items (1) to (13), wherein the key is further based on a previously generated random number.

[0274] (15) The data processing device according to item (14), wherein

[0275] The previously generated random number includes at least one of the following:

[0276] elements per logical processor;

[0277] elements per physical processor; and

[0278] System-wide elements.

[0279] (16) The data processing device according to item (15), wherein

[0280] At least a portion of the previously generated random number is generated at startup.

[0281] (17) The data processing device according to any one of items (14) to (16), wherein at least a portion of the previously generated random number is pseudo-random.

[0282] (18) A data processing device according to any one of items (1) to (17), wherein the key is based on a one-way transformation applied to at least one key input parameter, wherein the at least one key input parameter includes at least one value associated with a current execution environment or current execution permissions.

[0283] (19) The data processing device according to any one of items (1) to (17), wherein:

[0284] The instruction stream may be executed in one of a plurality of execution environments adapted for execution with a minimum execution permission;

[0285] The encoding circuitry is adapted to encode at least some of the plurality of bits further based on an identifier of one of a plurality of execution environments in which the instruction stream is being executed.

[0286] (20) The data processing device according to any one of items (1) to (19), comprising:

[0287] monitoring circuitry adapted to detect a failure rate of any combination of instruction fetch failures and instruction decode failures while executing an instruction stream in a speculative state; and

[0288] React to an increase in the failure rate above a predetermined threshold by generating an interrupt or generating an error response.

[0289] (21) The data processing device according to item (20), wherein

[0290] The predetermined threshold is at least 20% higher than the previous failure rate.

[0291] (22) A data processing device comprising:

[0292] a storage device for storing at least one branch prediction state entry associated with an instruction stream;

[0293] receiving means for receiving at least one input to generate a new branch prediction state entry, wherein the at least one input comprises a plurality of bits; and

[0294] Encoding means for encoding at least some of the plurality of bits of the at least one input based on a value indicative of current execution permissions in which an instruction stream is being executed.

[0295] (23) A method comprising:

[0296] storing at least one branch prediction state entry associated with an instruction stream;

[0297] receiving at least one input to generate a new branch prediction state entry, wherein the at least one input comprises a plurality of bits; and

[0298] At least some of the plurality of bits are encoded based on a value indicative of current execution permissions within which the instruction stream is being executed.

[0299] (24) A device comprising:

[0300] processing circuitry for performing data processing in one of a plurality of execution contexts;

[0301] a branch target prediction structure comprising a plurality of branch target entries, each branch target entry specifying branch information indicating at least one branch target address;

[0302] encryption circuitry for encrypting branch information to be written to a branch target prediction structure using an encryption key associated with a current execution context; and

[0303] Decryption circuitry is configured to decrypt branch information read from the branch target prediction structure using an encryption key associated with the current execution context.

[0304] (25) The apparatus of item (24), wherein each branch target entry specifies label information; and

[0305] The apparatus includes branch target prediction circuitry to perform a branch target prediction lookup on an instruction fetch address associated with a current execution context, the branch target prediction lookup comprising determining whether any one of a subset of branch target entries of a branch target prediction structure specifies tag information corresponding to a target tag determined for the instruction fetch address.

[0306] (26) The apparatus of item (25), wherein the value of the target tag is reusable in more than one of the plurality of execution contexts.

[0307] (27) An apparatus according to any one of items (25) and (26), wherein, when none of the branch target entries in the subset of branch target entries specifies label information corresponding to the target label, and the instruction fetch address specifies at least one instruction block including a branch instruction, the encryption circuit is configured to encrypt actual branch information of the branch instruction using an encryption key associated with the current execution context, and the branch target prediction circuit is configured to allocate a branch target entry of the branch target prediction structure, which specifies the encrypted branch information and specifies label information corresponding to the target label.

[0308] (28) An apparatus according to any one of items (25) to (27), wherein, when a branch target entry in a subset of branch target entries specifies tag information corresponding to a target tag, the decryption circuit is configured to decrypt the branch information stored in an entry in the subset of entries using an encryption key associated with a current execution context, and the branch target prediction circuit is configured to output the decrypted branch information as the predicted branch information for the instruction fetch address.

[0309] (29) The apparatus according to any one of items (24) to (28), wherein the encryption key comprises a static key fixed for a current execution context.

[0310] (30) The apparatus of item (29), wherein the static key for the current execution context depends on a common key shared between at least two execution contexts of the plurality of execution contexts and at least one context identifier specific to the current execution context.

[0311] (31) The apparatus according to any one of items (24) to (30), wherein the encryption key comprises a dynamic key that is variable for a current execution context.

[0312] (32) The apparatus of item (31), comprising: a key generation circuit for generating an updated encryption key for a current execution context.

[0313] (33) The apparatus of item (25), wherein, when none of the branch target entries in the subset of branch target entries specifies tag information corresponding to the target tag, and the instruction fetch address specifies at least one instruction block including a branch instruction, 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 circuitry is configured to specify the encrypted target tag as the tag information for the assigned branch target entry; and

[0314] In a branch target prediction lookup, the decryption circuitry is configured to decrypt tag information for each branch target entry in a subset of branch target entries, and the branch target prediction circuitry is configured to compare the decrypted tag information with the target tag.

[0315] (34) The apparatus according to any one of items (24) to (33), wherein the branch information further indicates at least one segment of branch information other than the branch target address.

[0316] (35) The apparatus of item (25), wherein the branch target prediction circuit is configured to determine the target label based on at least one context identifier associated with the current execution context.

[0317] (36) The apparatus of item (25), comprising: a region table comprising a plurality of region entries, each region entry mapping branch context information to a region identifier comprising fewer bits than the branch context information, the branch context information comprising at least one context identifier associated with a corresponding execution context.

[0318] (37) The apparatus of item (36), wherein the target tag for the instruction fetch address comprises a target region identifier that is mapped by the region table to branch context information associated with the instruction fetch address.

[0319] (38) The apparatus of any one of items (36) and (37), wherein each region entry specifies an encryption key associated with a corresponding execution context.

[0320] (39) An apparatus according to any one of items (36) to (38), wherein when a mapping provided by a given region entry of the region table is updated, the branch target prediction circuit is configured to trigger an update of an encryption key associated with an execution context after the mapping is updated, wherein the execution context is associated with the given region entry.

[0321] (40) An apparatus as described in any one of items (36) to (39), wherein the branch context information for a given region entry also includes a portion of an instruction fetch address based on which a previous branch target prediction lookup caused the given region entry to be assigned to the region table.

[0322] (41) An apparatus according to item (25), wherein the branch target prediction circuit is configured to determine the target label based on the instruction fetch address and a history of branch outcomes of previous branch instructions preceding the instruction at the instruction fetch address.

[0323] (42) A device comprising:

[0324] An execution component for performing data processing in one of the multiple execution contexts;

[0325] a storage component for storing branch target entries of a branch target prediction structure, each branch target entry specifying branch information indicating at least one branch target address;

[0326] an encryption component for encrypting branch information to be written to the storage component using an encryption key associated with the current execution context; and

[0327] The decryption component is configured to decrypt the branch information read from the storage component using an encryption key associated with the current execution context.

[0328] (43) A method comprising:

[0329] Perform data processing in one of multiple execution contexts;

[0330] storing branch target entries of a branch target prediction structure, each branch target entry specifying branch information indicating at least one branch target address;

[0331] encrypting branch information to be written to a branch target prediction structure using an encryption key associated with the current execution context; and

[0332] The branch information read from the branch target prediction structure is decrypted using an encryption key associated with the current execution context.

[0333] In this application, the phrase "configured to..." is used to indicate that elements of a device have a configuration capable of performing a defined operation. In this context, "configuration" refers to the arrangement or manner in which hardware or software are interconnected. For example, a device may have dedicated hardware to provide the defined operation, or a processor or other processing device that can be programmed to perform that function. "Configured to" does not imply that the device elements need to be modified in any way to provide the defined operation.

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

Claims

1. A data processing device, comprising: a memory circuit adapted to store data; an input circuit for receiving at least one input to generate an access request to the data, wherein the at least one input comprises a plurality of address bits; and encoding circuitry for performing a conversion operation to encode at least some of the plurality of address bits based on a value of a current execution context to generate: a plurality of encoded address bits identifying a location of the data in the storage circuit; and An encoded access request for accessing the data, wherein the encoded access request includes the plurality of encoded address bits.

2. The data processing apparatus according to claim 1, wherein: The storage circuit includes branch prediction circuitry; and The data includes branch prediction state data associated with an instruction stream executing in the current execution environment.

3. The data processing apparatus according to claim 1, wherein: The storage circuit includes a cache.

4. The data processing apparatus according to claim 3, wherein: The storage circuit includes an address translation circuit; and The data includes a translation from an input address in an input address space to an output address in an output address space.

5. The data processing apparatus according to claim 3, comprising: a tag comparison circuit for comparing tags associated with the data to determine whether the data should be accessed in response to the access request, wherein The at least one input comprises an input tag; and The tag associated with the data is compared to the input tag and accessed in response to a match. The data processing apparatus according to claim 3 , wherein: The storage circuitry includes an instruction cache; and The data includes at least one instruction.

7. The data processing apparatus according to claim 3, wherein: The storage circuit includes a data cache; and The data comprises data values stored at memory locations in the memory circuit.

8. The data processing apparatus according to claim 7, comprising: further storage circuitry for storing an association between said execution environment and a memory location, wherein Each of the memory locations is associated with at most one of the execution environments.

9. The data processing apparatus according to claim 8, wherein: The access request is a memory access request to a requested one of the memory locations; and The current execution environment is one of the execution environments associated with the requested memory location.

10. The data processing apparatus according to claim 8, wherein: The memory location comprises a page of the memory circuit that is set to be writable.

11. The data processing apparatus according to claim 8, wherein: The further storage circuitry includes address translation circuitry.

12. The data processing apparatus according to claim 7, wherein: The data cache includes a virtual index physical tag cache, the virtual index physical tag cache including a plurality of sets and a plurality of ways; and The data values may be stored in more than one of the plurality of sets within each way in the plurality of ways.

13. The data processing apparatus according to claim 12, comprising: Index circuitry is configured to store an indication of the set in which the data value is stored in association with the at least one input and execution environment.

14. The data processing apparatus according to claim 13, wherein: The indexing circuit is a snoop filter or directory.

15. The data processing apparatus according to claim 3, wherein: The memory circuit comprises a DRAM comprising memory locations; and The access request is a memory access request to a requested one of the memory locations.

16. The data processing apparatus according to claim 15, wherein: The current execution environment is based on processing circuitry that provides the input to the input circuitry to generate the access request.

17. The data processing apparatus according to claim 16, comprising: a plurality of processing circuits, including said processing circuit; as well as Further storage circuitry is provided for storing an association between the execution environment and the memory location.

18. The data processing apparatus according to claim 1, wherein: The translating operation includes translating at least some of the plurality of address bits by using a key, wherein the key is based on the current execution environment.

19. The data processing apparatus according to claim 18, wherein: The encoding circuit is adapted to encode at least some of the plurality of bits by performing a hash function using the key.

20. The data processing apparatus according to claim 18, wherein: The conversion operation includes rearranging or switching at least some of the plurality of bits using the key.

21. The data processing apparatus according to claim 18, wherein: The key is also based on any combination of one or more key input values indicating at least one of: exception level, privilege level, ASID, VMID, NS, physical processor core number, and logical core number, one or more registers, a system reset counter, and a previously generated random number.

22. The data processing apparatus according to claim 21, wherein: At least one register of the one or more registers is a software writable register.

23. The data processing apparatus according to claim 21, wherein: The previously generated random number includes at least one of the following: elements per logical processor; elements per physical processor; and System-wide elements.

24. The data processing apparatus according to claim 21, wherein: The key is based on a one-way transformation applied to the one or more key input values.

25. The data processing apparatus according to claim 18, wherein: The access request is made to a memory location; and The key is based on the memory location.

26. The data processing apparatus according to claim 21, comprising: An event monitoring circuit is configured to change a register of the one or more registers in response to an event.

27. The data processing apparatus according to claim 26, wherein: The event in question is the passage of time.

28. A data processing method comprising: Store data; receiving at least one input to generate an access request for the data, wherein the at least one input comprises a plurality of address bits; and A conversion operation is performed to encode at least some of the plurality of address bits based on a value of a current execution environment to generate: a plurality of encoded address bits identifying a location of the data; and An encoded access request for accessing the data, wherein the encoded access request includes the plurality of encoded address bits.

29. A data processing device comprising: a storage device for storing data; a receiving device for receiving at least one input to generate an access request to the data, wherein the at least one input comprises a plurality of address bits; and executing means for performing a conversion operation to encode at least some of the plurality of address bits based on a value of a current execution environment to generate: a plurality of encoded address bits identifying a location of said data in said storage device; and An encoded access request for accessing the data, wherein the encoded access request includes the plurality of encoded address bits.

Images