Data processing system, host device and apparatus for managing cache consistency

Abstract

The consistency control circuit (10) supports processing of a secure speculative read transaction received from a requesting master device (4). The secure speculative read transaction is of the type that requests that target data be returned to a requesting cache (11) of the requesting master device (4) while inhibiting any change in a consistency state associated with the target data in other caches (12) in response to the secure speculative read transaction. In response, at least when the target data is cached in a second cache associated with a second master device, at least one of the consistency control circuit (10) and the second cache (12) is configured to return a secure speculative read response while maintaining the target data in the same consistency state within the second cache. This helps mitigate speculative side channel attacks.

Description

Technical Field

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

[0002] A data processing apparatus may support speculative execution of instructions, wherein an instruction is executed before it is known whether the input operands of the instruction are correct or whether the instruction needs to be executed at all. For example, a processing apparatus may have a branch predictor for predicting the outcome of a branch instruction so that subsequent instructions may be speculatively fetched, decoded, and executed before it is known what the true outcome of the branch should be. Other systems may also support load speculation, wherein the value to be loaded from memory is predicted before the true value is actually returned from memory, to allow subsequent instructions to be processed more quickly. Other forms of speculation are also possible. Summary of the invention

[0003] At least some examples provide a system comprising:

[0004] multiple master devices with associated caches; and

[0005] Coherence control circuitry for managing coherence between caches based on a coherence protocol that assigns one of a plurality of coherence states to each data item in a given cache, wherein:

[0006] The coherence control circuitry is configured to support processing of a secure speculative read transaction received from a requesting master device, the secure speculative read transaction being of a type that requests that target data be returned to a requesting cache of the requesting master device while inhibiting any changes to coherence states associated with the target data in other caches responsive to the secure speculative read transaction; and

[0007] In response to the secure speculative read transaction, at least when the target data is cached in a second cache associated with a second master device, at least one of the consistency control circuitry and the second cache is configured to return a secure speculative read response while maintaining the target data in the same consistency state within the second cache.

[0008] At least some examples provide an interconnect including:

[0009] a plurality of interfaces for communicating with a master device having an associated cache; and

[0010] Coherence control circuitry for managing coherence between caches based on a coherence protocol that assigns one of a plurality of coherence states to each data item in a given cache, wherein:

[0011] The coherence control circuit is configured to support processing of a secure speculative read transaction received from a requesting master device, the secure speculative read transaction being of a type that requests that target data be returned to the requesting master device while inhibiting any changes to a coherence state associated with the target data in caches of other masters responsive to the secure speculative read transaction; and

[0012] In response to the secure speculative read transaction, at least when the target data is cached in a second cache associated with a second master device, the consistency control circuit is configured to return or request the second cache to return a secure speculative read response while maintaining the target data in the same consistency state within the second cache.

[0013] At least some examples provide a master device including:

[0014] processing circuitry capable of speculative execution of data access operations; and

[0015] interface circuitry for issuing transactions to an interconnect for managing coherence between the master's cache and at least one other cache based on a coherence protocol that assigns one of a plurality of coherence states to each data item in a given cache;

[0016] Wherein, in response to the processing circuit speculatively performing a read operation to request target data that is not present in the cache of the master device, the interface circuit is configured to issue a secure speculative read transaction to the interconnect, wherein the secure speculative read transaction is of the following type: requesting that the target data be returned to the master device while prohibiting any change in the consistency state associated with the target data in the at least one other cache in response to the secure speculative read transaction. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0018] Figure 1 schematically illustrates an example of a system having several master devices and an interconnect for managing consistency between the master devices;

[0019] Figure 2A and Figure 2B illustrates processing of a type of read transaction that requests target data to be returned to a requesting cache while allowing changes in the coherence state in other caches;

[0020] Figure 3 An example of a potential security attack that may derive information about secret data based on a change in the coherency state in another cache is shown;

[0021] FIG. 4A to FIG. 4C illustrates processing of a safe speculative read transaction, which ensures that the transaction does not trigger a coherence state change in another cache while the read operation that triggered the transaction remains speculative;

[0022] Figure 5 Shows Figure 4C a first alternative for handling a case where a secure speculative read transaction hits data in a cache coherency state that is not permitted in the cache of a requesting master;

[0023] Figure 6 Shows the process Figure 4C A second alternative to the situation shown in;

[0024] Figure 7 An example of a shared cache for caching data distributed by multiple requestors is shown;

[0025] Figure 8 is a method showing promotion of a speculative entry to a non-speculative entry upon speculation resolution associated with a load operation that allocates data;

[0026] Fig. 9 A flow chart illustrating a lookup of a shared cache in response to a read request triggered by a given requester is shown;

[0027] Fig.10 An example of training a data prefetcher based on the addresses of resolved correct memory accesses is shown; and

[0028] Fig.11 An example is illustrated of training a data prefetcher based on addresses of speculative memory accesses and initially allocating prefetched data into a speculative region of a cache. DETAILED DESCRIPTION

[0029] The data processing apparatus may have security mechanisms for ensuring that some secret information is accessible to certain processes running on the data processing system, but not to other processes. For example, processes may be assigned a given privilege level, and some data may be accessible only to processors having a certain privilege level or higher. Memory protection techniques may be used to enforce the desired memory access permissions.

[0030] Recently, it has been recognized that such security measures to protect secret data from unauthorized access can in principle be circumvented by a security attack that exploits a combination of speculative execution and caches present in many modern processors. This attack exploits the property that the effects of speculatively executed instructions can remain in the cache after any architectural effects of the speculatively executed instructions have been canceled. In some variants of this attack, an attacker can train a branch predictor or other speculation mechanism to trick more privileged code into speculatively executing incorrect instruction sequences designed to make privileged code access memory address patterns that depend on sensitive information, so that less privileged code that cannot access the sensitive information can use cache timing side channels (measure access times for cached addresses) to detect which addresses have been allocated to or evicted from the cache by more privileged code to give some information that can allow sensitive information to be inferred. There are some mechanisms available to protect the master's own cache against exposing side channel information about changes in cache allocation caused by speculative read operations performed on the same master (e.g., partitioning speculative and non-speculative data in the cache).

[0031] However, the inventors recognize that not only changes in cache allocations in the master's own cache can be affected by speculatively executed reads. In a system including two or more master devices with associated caches and a coherence control circuit for managing coherence between caches based on a coherence protocol that assigns one of several coherence states to each data item in a given cache, it is also possible that when a read operation is speculatively executed by one master, such a read can trigger a change in the coherence state associated with the data cached in the cache of a second master. This change in the coherence state at the cache of the second master can be retained even when the original speculative read operation at the requesting master is subsequently cancelled due to mis-speculation. Even if this change in the coherence state at the cache of the second master does not cause any data to be evicted or newly allocated to the cache of the second master, the change in the coherence state can still cause a difference in the time it takes to service a read or write request in the cache of the second master. This difference in access time in the second cache can be detected by an attacker to infer information about the address accessed by the requesting master that initiated the original speculative read. This may allow a process that does not have access to the secret data, but does have access to data whose coherence state has changed in the cache of the second master device, to obtain information that may be used to infer properties of the secret data used to derive the address requested by the requesting master device.

[0032] In the techniques discussed below, coherence control circuitry may support processing of a secure speculative read transaction received from a requesting master device, the secure speculative read transaction being of a type that requests that target data be returned to the requesting master device while inhibiting any changes in a coherence state associated with the target data in caches of other masters that are responsive to the secure speculative read transaction. In response to the secure speculative read transaction, at least when the target data is cached in a second cache associated with a second master device, the coherence control circuitry and at least one of the second cache may return a secure speculative read response while maintaining the target data in the same coherence state within the second cache.

[0033] Thus, by defining the type of read transaction that a requesting master can issue to ensure that no matter what response is returned, secure speculative read transactions will not trigger a change in the coherence state in the cache of another master, which can mitigate the above-described type of attack. When reads are performed speculatively, then these can trigger secure speculative read transactions, rather than another form of transaction, so that no change in the coherence state occurs at the cache of the second master and therefore this eliminates the opportunity to derive information about what address the requesting master has requested based on examining the data allocated in the second cache.

[0034] This scheme is unusual because typically the requesting master will issue a coherence transaction requesting a certain data item to be returned, and will expect that the target data should be returned in a certain coherence state (specified based on the type of transaction), regardless of the coherence state associated with the data in other caches. Such a traditional transaction would require that the other caches should trigger any changes in the coherence state required to ensure that the target data can be returned to the requesting master and stored in the requesting master's cache. In contrast, for a safe speculative read transaction, the priority is to ensure that there is no change in the coherence state at the cache of the other master, and to ensure that a response that can achieve this is returned, but the following matters can be made optional: whether the target can actually be returned to the requesting master, and / or what coherence state the data is returned in. Whether the target data can be returned may depend on what coherence state is associated with the target data if the target data is cached in the cache of another master. Therefore, instead of returning a known coherence state at the requesting master and implementing any required changes in the coherence state at the second cache, the safe speculative read transaction ensures that the coherence state at the second cache remains the same, but may result in different results at the requesting master.

[0035] Different implementations may respond to safe speculative read transactions in different ways.

[0036] In one example, in response to a secure speculative read transaction, when target data is cached in the second cache in a coherence state that would not allow the target data to be cached in the requester cache without changing the coherence state of the target data in the second cache, the coherence control circuit or the second cache may return a no-data response indicating that the target data cannot be provided by the second cache until the speculative read operation that triggered the secure speculative read transaction is resolved as non-speculative. With this scheme, if the current coherence state of the target data in the second cache cannot accommodate caching the target data in the requester cache as well, a response indicating that it is currently impossible to provide the target data to the requester master cache is provided, and therefore in this case, the requester master does not receive the target data in response to the secure speculative read transaction.

[0037] With this implementation, if the requesting master receives a no-data response, the requesting master may wait until the speculative read operation that triggered the secure speculative read transaction has been resolved as a correct speculation, and may then issue another transaction to the coherence control circuitry that is of a type that requests that the target data be returned to the requesting cache while allowing changes to the coherence state associated with the target data in other caches. At this point, the changes to the coherence state in the other caches may be safe because the original read is no longer speculative and therefore security attacks based on changes to the coherence state caused by an incorrectly speculated read operation will no longer be a risk (if the original speculation is incorrect, continued processing based on the speculation will be canceled so that another transaction will not be issued).

[0038] In an alternative, instead of having a current coherence state of the target data in the second cache that would not allow an indication to be returned that the target data could not be provided when the target data was cached in the requester cache, the secure speculative read response may instead include an uncacheable read response that does provide the target data to the requester master, but which prohibits the requester cache from caching the target data. This may allow a speculatively executed read operation to use the target data returned from the second cache as a result of that particular operation, but this returned data may then be discarded and not cached to avoid the need to provide any change in coherence state in the second cache. Again, this prevents an attacker from having the opportunity to obtain information about secret data based on side channel information derived from a change in coherence state triggered by an incorrectly speculated read operation.

[0039] In some implementations, although an uncacheable read response may prohibit the target data from being cached in the requesting master in a consistent manner consistent with the coherence protocol, the requesting master may still have a non-coherent speculative buffer to buffer data associated with the speculative read operation while the speculative read operation remains speculative, and in response to the uncacheable read response, the returned target data may be allocated to the speculative buffer. This may allow further instructions executed after the original speculative read to continue as needed using the returned target data. However, coherence is not maintained between the data in the speculative buffer and the data in the second cache to avoid the need to trigger a change in the coherence state in the second cache.

[0040] If data is held in such a speculative buffer outside the control of the consistency scheme, once the speculative read operation that triggered the safe speculative read transaction is resolved as correctly speculated, the requesting master device may issue a consistency upgrade request to the consistency control circuit to request that the non-consistent version of the target data in the speculative buffer be upgraded to a consistent version of the target data. For example, the consistency upgrade request may be a request to request that the latest version of the target data be returned to the requesting master device (e.g., a consistency change-enabled transaction that is allowed to trigger a change in the consistency state at the cache of other master devices). If the target data is still cached in the cache of the second master device, it may be returned from the second cache, or by the time the speculative read operation is resolved, the second cache may no longer hold the data and the data may need to be obtained from another location. By issuing a request to retrieve the target data once the speculative read operation is resolved, this ensures that any subsequent changes to the target data held in other locations are made available to the master device, so that the master device does not continue to use potentially outdated information. Once the retrieved data has been returned, the requesting master device may allocate this data to its requesting cache, rather than in the speculative buffer, and cancel the speculative buffer entry. Alternatively, the coherence upgrade request may be a request for an indication of whether the data has changed since the uncacheable response was received. For example, the coherence control circuit and / or the second cache may track whether any writes to the target data have occurred since the uncacheable response was provided, and if so, notify the requesting master device to trigger the cancellation of the speculative buffer entry and the retrieval of the latest data.

[0041] After allocating the target data to the non-uniform speculative buffer, in response to determining that a change to the target data since the target data was provided by the uncacheable read response will cause incorrect execution, the requesting master device may cancel subsequent operations that were speculatively executed based on the target data provided by the uncacheable read response. This ensures that subsequent operations that use potentially inconsistent copies of the target data (which have not been updated after the change to the target data in other cache locations) are canceled to prevent incorrect results. Detection of whether a change to the target data will cause incorrect execution may, for example, include determining whether the instruction that triggered the speculative read transaction is reordered relative to any other instructions that read or write the target data or any barrier instructions.

[0042] Thus, while the coherence protocol may require that uncacheable read responses prohibit caching of the returned data in a consistent manner within the requesting master cache, it may be possible at the microarchitectural level to buffer this data outside the protection of the coherence scheme, but in this case, when the data becomes non-speculative, a mechanism can be provided to check whether any subsequent changes have been made to the data since it was allocated to the speculative buffer (e.g., re-fetching the data and comparing it with previously fetched values ​​to check whether subsequent speculative operations may have used inconsistent data) before any consistent version of the data is allocated to the requesting master cache.

[0043] In implementations where a secure speculative read transaction triggers an uncacheable read response as described above, in some cases, the secure speculative read response may always include an uncacheable read response, regardless of the coherency state of the target data in the second cache. In this case, even if the target data is missed in the second cache and must be retrieved from another cache or main memory, or even if the target data is held in the second cache in a coherency state that would allow the target data to be cached in a coherent manner in the requesting cache of the requesting master, the uncacheable read response may still be returned to inhibit coherent caching in the requesting cache. This means that the same response is returned to the requesting master regardless of what particular coherency state is associated with the target data in the second cache, which may be simpler to implement.

[0044] Alternatively, a non-cacheable read response may be returned if the target data is cached in the second cache in a consistency state in which caching of the target data in the requester cache would not be permitted without changing the consistency state at the target data in the second cache. However, if, in response to a secure speculative read transaction, the target data is cached in the second cache in a consistency state permitted by the consistency protocol without changing the consistency state in the second cache, then in this case, the secure speculative read response may instead include a cacheable read response that provides the target data and permits the requester cache of the requester master to cache the target data in a consistent manner. While this scheme may result in different responses depending on the consistency state in the second cache, it means that when the consistency state does not permit caching in the requester cache, then the data may be consistently retained at the requester master, so that instructions following the speculative read may continue to use the data while complying with the consistency scheme, potentially improving performance and eliminating the need for safeguards to check consistency once speculation has been resolved.

[0045] Similarly, while a no data response is returned when the target data is cached in the second cache in a state that does not allow caching in the requesting master cache, a cacheable read response may be returned when the target data is cached in a coherency state that allows caching in the requesting cache.

[0046] For all of the above examples of secure speculative read transactions and corresponding secure speculative read responses, when the target data does not exist in other caches managed according to the consistency protocol, the consistency control circuit may obtain the target data from another level of cache or memory shared between multiple master devices. That is, the secure speculative read transaction may initiate a line fill operation to obtain the target data from another level of cache or memory and distribute the target data to a given cache without waiting for any speculative operation that triggered the secure speculative read transaction to be resolved. This is an advantage of implementing secure speculative read transactions (compared to replacement techniques, in which standard read transactions are used instead, but only to ensure that consistency state changes are not triggered in other caches, and the issuance of the read transaction is delayed until any speculation associated with the read has been resolved and it is known with certainty that the read is correctly speculated). If no transaction is issued at all until the read is resolved as correct, then in the case where no cache currently holds the target data, the line fill request will have to be postponed until the speculation has been resolved. Since the line fill operation is typically much slower than accessing data from the cache, delaying the line fill request will cause a significant reduction in performance. In contrast, for a safe speculative read transaction, although obtaining the target data from another cache may sometimes need to be delayed in order to ensure that the coherence state does not change in the other cache due to the still unresolved speculative access, the longest latency operation to another level of cache or main memory can still be initiated early using a safe speculative read transaction. This helps improve performance.

[0047] It will be appreciated that secure speculative read transactions may not be the only type of read transaction supported. The requesting master device may tend to use secure speculative read transactions when performing speculative read operations on at least data that is considered potentially sensitive. However, other types of read transactions may be implemented for non-speculative read operations or speculative read operations on known insensitive data. Such other types of read transactions may return target data while allowing changes in the consistency state in the cache of another master device. On the other hand, for some implementations, all reads (speculative or non-speculative) may trigger secure speculative read transactions. This may be more efficient, especially in systems where most or even all reads are speculatively executed and it is not possible to safely determine whether the data is considered sensitive. Therefore, in general, providing support for secure speculative read transactions may be useful for protecting against the risk of side channel attacks, but which read operations trigger secure speculative read transactions or another type of read transactions may vary from implementation to implementation.

[0048] In addition to the cache associated with a specific master device, the system may also include one or more shared caches shared between master devices. The shared cache can be accessed according to a request from one of several requesters, each of which includes a given master device or a given process executed on a given master device. In some cases, different processes on the same master device can be identified as separate requesters. Such a shared cache can also cause potential opportunities for speculative side channel attacks. In order to improve performance, it may be desirable for a requester to access data allocated by a different requester once the data has been allocated non-speculatively. However, for speculatively allocated data, if a requester can access the data while the data speculatively allocated by another requester remains speculative, this may allow an attacker to control a requester that does have access to secret information to allocate data to an address in the cache that depends on the secret information after an incorrectly speculated read, and then the other requester will be able to access the timing information from the shared cache to determine which address is allocated and thus derive information about the secret. This would be undesirable.

[0049] One technique for addressing this problem may be to operate a shared cache so that the allocation requester that caused the speculative allocation of data to the shared cache is tracked. In response to a request to read data that was speculatively allocated to the shared cache by the allocation requester, while the operation that triggered the allocation of the data remains speculative, the shared cache may return a miss response when the request is triggered by a requester other than the allocation requester, indicating that the data is not cached in the shared cache. Therefore, while the allocation requester itself can hit the speculatively allocated data and therefore benefit from the performance gain associated with caching this information in the shared cache, other requesters cannot see the data until any speculation is resolved and it is determined that the data has been correctly allocated. This avoids the attacker being able to obtain side channel information for incorrect speculative allocations in the shared cache.

[0050] In other words, in response to a request from a given requester to read target data speculatively allocated to the shared cache by an allocation requester, while the operation triggering the speculative allocation of the data remains speculative, the shared cache may return a hit response providing the target data when the given requester is the allocation requester, and return a miss response indicating that the data does not exist in the other level cache when the given requester is a requester other than the allocation requester.

[0051] In the case where a miss response is returned when hitting speculative data allocated by a different requestor, if the data speculatively allocated to the cache is dirty, the cache may also write the dirty data back to another level of cache or memory before or in parallel with returning the miss response.

[0052] The other level of cache or memory may have a mechanism for distinguishing between speculative and non-speculative data, so that if the corresponding speculative operation is determined to be incorrectly predicted, the speculative data can be identified and discarded. The shared cache may also ensure that if data is speculatively fetched into the shared cache from another level of cache or memory, it is obtained in a clean state so that the data does not need to be written back to the other level of cache or memory if the speculation turns out to be incorrect.

[0053] The shared cache can be implemented in different ways. In one example, the shared cache may have a speculative cache area and a separate main cache area. Speculatively allocated data may be stored in the speculative cache area, while non-speculatively allocated data may be stored in the main cache area. The speculatively allocated data may be transferred to the main cache area in response to an indication that the operation that triggers the allocation of the data has been resolved as non-speculative by the allocation requester. Although in some cases, the resolution of each speculative operation may be notified to the shared cache separately to trigger the promotion of the speculatively allocated data to the non-speculative main cache area, this may result in a large amount of communication with the shared cache. It may be more efficient to associate each cache entry with a group of speculatively executed operations, and then once each operation in the group has been correctly resolved, this may trigger the transfer of any entry associated with the operation in the group from the speculative cache area to the main cache area.

[0054] In another example, a single speculative cache region in a shared cache may be shared among all requesters. In this case, each entry in the speculative cache region may additionally specify metadata identifying which requester is the assigned requester, thereby controlling whether a request from a given requester should be considered a hit or a miss. Alternatively, several different separate speculative cache regions may be provided, each corresponding to a given requester, and in this case, requests from a given requester may only hit in the speculative cache region dedicated to that particular requester.

[0055] Alternatively, both speculative and non-speculative data may be cached in the same region of a shared cache. In this case, the shared cache may store metadata associated with each data item in the shared cache indicating whether the data remains speculative, and if the data remains speculative, indicating which requester is the allocation requester. In this case, a given operation or group of operations being resolved as correctly speculative may then trigger an update of the metadata associated with the item allocated by the operation or group of operations to indicate that the data is now non-speculative.

[0056] In cases where metadata is used to distinguish which entries are relevant to each requester, a partitioning scheme may still be applied to limit the maximum number of entries that can be allocated to a given requester to store speculative data, or the size of the shared region is chosen to be large enough that conflicts for cache entries are unlikely. This may be useful to reduce the likelihood of one requester evicting another requester's speculative data, which otherwise could risk leaking timing information.

[0057] In the case where the second requester can perceive a cache miss in the shared cache even though the first requester may have allocated speculative data to the shared cache, some implementations may allow the second requester to also allocate a second entry for the same address. In this case, some additional tracking information may be assigned to one or both of the entries associated with the first and second requesters so that when the speculation is resolved, the separate entries can then be merged into a single entry while maintaining consistency. Alternatively, other implementations may reduce the complexity of handling separate entries for the same address in the shared cache by requiring that when a given entry is promoted from speculative to non-speculative when speculation is resolved, any additional speculative entries for the same address be invalidated.

[0058] Another area that an attacker may exploit based on a speculative side channel may be the presence of a data prefetcher for speculatively prefetching data into a cache based on a prefetch address that is predicted based on the address of a data access operation previously performed by the processing circuitry. For example, a data prefetcher may have circuitry to predict a prefetch address based on monitoring of previously accessed addresses, such as detecting whether an address is executed in a given stride pattern (a sequence of addresses with a regular offset between successive addresses). An attacker may be able to control the operation of a given processor such that the stride pattern executed depends in some way on secret information, for example if the base address from which the stride starts or the offset between successive addresses depends on part of a secret. Thus, a data prefetcher trained on the address of a speculatively executed instruction may leak information by revealing the base address or the data stride.

[0059] In one technique discussed below, a system having a cache and a data prefetcher can be controlled so that the cache and the data prefetcher inhibit data speculatively prefetched by the data prefetcher based on a prefetch address from triggering eviction of non-speculative data from the cache, wherein the prefetch address is predicted based on a previously accessed address of a speculatively executed data access operation. This can be accomplished in different ways.

[0060] In one example, the data prefetcher may predict prefetch addresses based only on previously accessed addresses associated with data access operations that have been resolved as correctly speculative by the processing circuitry. By training the data prefetcher based only on correctly calculated addresses of resolved data access operations, rather than on addresses that are still speculative and potentially incorrect, this means that incorrectly accessed addresses will not affect future prefetch predictions, reducing the risk of the data prefetcher leaking information.

[0061] An alternative solution may be to provide a cache that includes a main cache area and a speculative cache area. The cache in this case may be arranged to allocate data prefetched by a data prefetcher to the speculative cache area, and once it is determined that the prediction of the prefetch address for a given data item is correct, the cache may transfer the given data item to the main cache area. With this scheme, the data prefetcher may be trained based on the addresses of speculative memory accesses that remain to be resolved, but by avoiding contaminating the main cache area based on speculative accesses until the speculative accesses are known to be correct, this prevents any non-speculative data from being evicted by the speculative prefetched data, so that an attacker cannot obtain information about which data addresses have been prefetched based on analysis of the contents of the main cache area. The contents of the speculative cache area may be accessible to other data access operations while the processor remains in the same operating state in which the speculative data is allocated. However, data allocated to the speculative cache region may be discarded in response to an event representing a change in state, which change may indicate a transition to code that will not be able to access some data that was accessible prior to the event (e.g., the event may be an exception, a change in privilege level, a change in security mode, etc.), such that a transition from more privileged code to an attacker's less privileged code would, for example, render previously speculatively prefetched data inaccessible that has not yet been confirmed to be correct.

[0062] Therefore, regardless of which of these schemes is adopted for the prefetcher, this reduces the scope of speculative side channel attacks of the type described above by eliminating the option of evicting non-speculative data from the cache due to prefetching data from an address predicted based on a previous access address for a speculatively executed data access operation for which the correct one is not yet known.

[0063] Figure 1An example of a data processing system 2 (e.g., an integrated circuit or system on a chip) is schematically illustrated, which includes several master devices 4, 6 and an interconnect 10 for managing coherency between the master devices and other caches. In this example, the master devices include a central processing unit (CPU) 4 for performing general processing and a graphics processing unit (GPU) 6 for performing graphics processing. The CPU and GPU include caches 11, 12. Some master devices may have more than one cache, such as a level 1 cache associated with a particular core 9 and a level 2 cache shared between the cores (for simplicity, the level 2 caches are shown in FIG. 1 ). Figure 1 1 and 2). Each of the master devices 4, 6 has a coherence interface 16, 22 for interacting with the coherent interconnect. For example, the coherence interface 16, 22 may be responsible for generating the required coherence protocol transactions in response to cache accesses from the associated master device, and responding to snoop requests from the interconnect 10 with appropriate responses and changes in coherence state. It will be appreciated that this is only one example of some master devices, and other types of master devices may also be provided, such as a network interface controller for controlling the transmission and reception of data over a network, a display controller for controlling the display of data on a screen, or a DMA (direct memory access) controller for controlling the transfer of data between, for example, a memory and a peripheral device. Examples of coherence protocols that may be used are the AMBA® 4 ACE and AMBA® 5 CHI coherence protocols provided by Arm® Ltd of Cambridge, England, but it will be appreciated that the techniques discussed herein may also be applied to other coherence protocols.

[0064] The coherent interconnect 10 includes several slave interfaces 24 for communicating with the coherent interfaces 16, 22 of respective master devices 4, 6, and several master interfaces 26 for communicating with slave devices, such as a memory 33 or a cryptographic unit 34 for providing cryptographic support for operations performed on the master device. In this context, the slave interface 24 is an interface that acts as a slave (responds to transactions rather than initiates transactions) in the bus protocol used (such as the AMBA® protocol discussed above). Therefore, the interface 24 that communicates with the master devices 4, 6 is a slave interface because it responds to transactions initiated by the corresponding master interface 16, 22 at the master devices 4, 6. Similarly, the master interface 26 is an interface that acts as a master device in the bus protocol and is responsible for initiating transactions to which the corresponding slave interface will respond. Therefore, the interface 26 of the interconnect 10 that communicates with the slave devices 33, 34 is a master interface. Although in Figure 1 1, but some devices may communicate with the interconnect 10 through both master ports and slave ports. The coherent interconnect 10 may include a system cache 30 shared between master devices. The system cache 30 provides faster access to data than if the corresponding data had to be fetched from main memory 33.

[0065] like Figure 1 As shown in , the consistent interconnect 10 may include a snoop filter 40 for tracking which data addresses are cached at certain master devices 4, 6. The snoop filter 40 can be used to reduce snoop traffic by allowing the consistent interconnect 10 to determine when data is not cached at a particular master device. The snoop filter 40 is not necessary, and in some embodiments, an interconnect 10 that does not attempt to track data cached at each master device can be provided. In this case, when a master device 4, 6 initiates a read or write transaction for data that can be shared with other master devices, the consistent interconnect 10 can trigger a snoop transaction to be issued to each other master device that may have a cached copy of the data from the same address, and manage changes in the consistency state at these other master devices and / or respond to the requesting master device with a more up-to-date version of the data when necessary. However, if there are many master devices, this solution of broadcasting snoops to all cached master devices may be complex and may result in a large amount of consistency traffic being exchanged within the system 2.

[0066] This can also help reduce the amount of snoop traffic by providing a snoop filter 40 that can at least partially track which addresses are cached at various master devices. In some cases, the snoop filter 40 can accurately track the data stored in the cache of each master device so that the coherent interconnect 10 can determine exactly which data is cached where. Therefore, when a transaction is received from an initiator master device that points to data that may be sharable, the interconnect 10 can determine from the contents of the snoop filter 40 which other masters are caching data from the same address and send a snoop transaction to those masters indicated in the snoop filter, avoiding the need to send snoops to other masters that do not currently store the data.

[0067] However, other snoop filters may not track the contents of the cache accurately. For example, a filter scheme may be used that ensures that the snoop filter 40 avoids false negatives, ensuring that any data present in the cache 11, 12 is recorded as present in the snoop filter, but that allows some false positives, so that sometimes the snoop filter 40 may indicate that data is cached in a given master device, but in fact the master device has invalidated the data. This scheme that allows some inaccuracy can reduce the overhead of updating the snoop filter because it means that every invalidation of the cache 11, 12 that is not from the master device must be reflected at the snoop filter.

[0068] In some cases, the system cache 30 and snoop filter 40 may be combined. For example, if the system cache 30 acts as an inclusive cache that caches all addresses cached by any of the master's caches 11, 12, each cache entry may specify additional metadata identifying which caches have cached which addresses, so that the coherent interconnect 10 can determine from the system cache 30 whether data is cached at a particular master without snooping the master.

[0069] FIG2 shows an example of handling a coherence change allowing a read transaction. This is a class of read transactions that cannot be guaranteed not to expose secret information through changes in the coherence state of other caches, and therefore may not be securely used in response to some speculative read operations. The read transaction specifies a target address and returns the target data associated with the address to the requesting master 4, 6 that issued the request. In the following example, it is assumed that the requesting master that issued the request is the CPU 4 and the second master that is snooped based on the request is the GPU 6, but it will be understood that this can be reversed.

[0070] Figure 2A An example is illustrated in which the read transaction results in a hit in the second cache 12 of the second master device 6. Thus, when the requesting master device 4 issues a coherence change allow read transaction, the interconnect 10 issues a snoop request to the second master device 6. In response, the second master device looks up the target address in its cache and determines whether it holds the target data in a valid state. If the current coherence state of the target data in the cache of the second master device will not allow the target data to be cached in the cache 11 of the requesting master device 4 at the same time, the cache of the second master device changes the coherence state of the target data in the second cache 12 to a state consistent with the data cached at the requesting master device.

[0071] For example, the coherence protocol may include defining, for a given cache, one of the following coherence states for each cache line:

[0072] Modified (the cache holds the only valid copy of the cache line and the data has been modified);

[0073] Exclusive (the cache has the only valid copy of the cache line, and the data is clean);

[0074] Shared (the cache holds a valid copy of the cache line, but the cache does not have the right to modify the data, and other caches may or may not also hold valid copies); and

[0075] Owned (this cache holds a valid copy of the cache line, which is dirty, and so if the cache line is evicted, this cache will need to write the data back to memory, other caches may also hold valid copies, or may not hold valid copies);

[0076] Invalid (the cache does not hold a valid copy of every cache line).

[0077] For example, if the consistency state of the snooped target data is exclusive or modified, in order to cache the data at the requesting master device, this may require that the consistency state in the cache 12 of the second master device be downgraded to shared or owned. The specific consistency state transition triggered by the read transaction may depend on the specific consistency protocol used (it will be appreciated that the MOESI protocol described above is only one example). In any case, regardless of the consistency state of the snooped data in the cache 12 of the second master device 6, the data is returned to the requesting master device 4 via the interconnect 10, and the requesting master device then caches the returned data in its cache 11.

[0078] Figure 2B The response to a coherence change allowed read transaction is shown when the request misses in the cache 12 of the second master (and also misses in the caches of any other master managed by the coherent interconnect). In this case, when the second master 6 is snooped by the interconnect 10, the second master returns a miss indication indicating that the data is not present in the cache 12 of the second master 6, which triggers the coherence control circuit (interconnect) 10 to issue a line fill request to another cache or main memory 33. In some cases, if the snoop filter 40 indicates that the data is not present in the second master cache, it may not be necessary to actually snoop the second master 6 and receive a miss indication, instead, the interconnect 10 may directly trigger a line fill request in response to a read transaction received from the requesting master 4.

[0079] Therefore, if the read transaction misses in all other caches managed by the interconnect 10, a line fill request is triggered to fetch data from another cache (e.g., a system cache in a downstream interconnect or memory controller), or from memory 33. It may take longer to service a line fill request than if the data is already available in one of the master's caches. Eventually, the other cache or memory returns the data to the interconnect, which is then provided to the requesting master 4 and cached in the requesting master's cache 11.

[0080] Therefore, regardless of whether the request hits or misses in the master's cache, the requesting master 4 always obtains the data and caches it in its own cache using a coherency change to allow the read. If necessary, a change in the coherency state can be triggered at other master caches to allow the requesting master to cache the data. It will be appreciated that Figure 2A and Figure 2B The example of a read transaction shown is only one type of read transaction that can be supported, and coherent interconnect 10 may also support other types of read transactions, which may be performed in the same manner as described above. Figure 2A and Figure 2B The different approaches shown are handled, but may result in a change in the coherency state at the cache 12 of the second master.

[0081] The CPU 4 or GPU 6 or other host device may support speculative execution of instructions, including instructions that may trigger a read operation to read data from memory. Speculative loads executed in a trusted application may exploit a cache timing side channel to leak data to an untrusted application. An example of such a side channel attack is described in the "Spectre" attack. The attack uses the following (or similar) code sequence:

[0082] unsigned long untrusted_value = ...;

[0083] if (untrusted_value <arr1->length) {

[0084] unsigned char secret = arr1->data[untrusted_value];

[0085] unsigned char value2 = arr2->data[secret * 64];

[0086] }

[0087] If the CPU mis-speculates the "if" condition (mechanisms that cause mis-speculation include malicious training of the branch predictor, and / or provision of an out-of-bounds array index), the CPU speculatively fetches the first value and possibly the second value from memory. By using a cache side channel, the value of the secret can be inferred because the cache set used by the second access is data-dependent and can be detected using a simple timing side channel. This side channel can be exploited by probing the local cache hierarchy or by probing the coherency effects associated with speculative accesses.

[0088] The condition in the above example will always be false when attempting to extract the secret value, since this exists outside the bounds of the first array, i.e., the access will never become non-speculative. If speculative state is never allowed to affect non-speculative state, the timing side channel described above becomes invalid. For caches, speculative loads can affect non-speculative state by installing and evicting cache lines without regard to their speculative / non-speculative state; in particular, affecting non-speculative lines in a way that can be measured by speculative lines. One way to achieve this isolation is to exploit the following properties:

[0089] Speculative accesses should be installed in isolated parts of the cache and should not be allowed to evict non-speculative cache lines or speculative cache lines from other masters, or visibly affect their state (through timing).

[0090] Load retirement (or earlier becoming non-speculative) promotes the speculative cache line to a non-speculative cache line.

[0091] Hardware prefetchers should be treated as speculative accesses; or trained when promoted rather than when speculative accesses are performed to avoid side channels.

[0092] For example, for a cache in a single core, a speculative region can be added, dedicated to speculative data and separate from the main cache region. Cache lines in the speculative region are promoted to non-speculative cache lines when a load is retired and are invalidated if the load is suppressed. When promoted, the speculative cache line evicts the non-speculative cache line when necessary and the line is invalidated. The speculative region of the cache can be cleared on a context switch / system call (which occurs from the suppression of the load described earlier) or a speculation barrier. The core can also clear the speculative line when rolling back a mis-speculated branch, if configured to do so (this provides stricter guarantees for non-trusted code protection applications).

[0093] However, side-channel information useful to an attacker can also be leaked through changes in the coherency of one master's cache that are triggered by speculative read operations on another master. Figure 2A and Figure 2B The type of read transaction shown in can leak this secret information because an attacker can use the cache timing side channel to detect the Figure 2A The read transaction shown triggers a change in the consistency state of the second master device 6. Figure 3 An example of how such an attack may be made by an attacker who may control processing executed on a first master (eg, CPU 4) and a second master (eg, GPU 6) in a system having a coherent interconnect for managing coherence as described above is shown.

[0094] like Figure 3 As shown in FIG. 5 , at step 50, the attacker controls the second master device 6 to allocate an array of data accessible to the attacker into its cache 12. The array allocated to the cache of the second master device need not be any array containing secret information, but is simply allocated to its cache to enable detection of secret-based changes.

[0095] In step 52, the attacker directs the vulnerable software executed on the first master device 4 to read the secret information. The vulnerable software may, for example, be more privileged software that can access secrets that are not directly accessible to the attacker itself. For example, the attacker may use malicious training of branch predictor states or provide an out-of-bounds array index to the vulnerable software in order to trick the vulnerable software into reading the secret while waiting for the boundary check operation to be resolved. This may cause the vulnerable software to access the secret when it should be accessing other data. It will be appreciated that there is a range of ways that the attacker may use to ensure that the vulnerable software reads the secret.

[0096] At step 54, the attacker may direct the vulnerable software to calculate an index based on the secret (or based on a subset of bits of the secret), and at step 56, cause the vulnerable software to read the array previously allocated to the second master cache at step 50, wherein the array element read is selected based on the index calculated at step 54. The read at step 56 may trigger a read transaction to be issued to the second master cache. Figure 2A The coherent interconnect 10 is shown and thus the snoop request is issued to the second master 6. At step 58, the snoop request may then trigger a change in the coherency state of the target data (index element of the array) in the second master cache 12.

[0097] At step 60, the attacker may then measure cache access timing for accesses to different elements of the previously allocated array in the cache 12 of the second master device to estimate which element was accessed by the first master device. For example, if the array was previously allocated in an exclusive state, where the second master device 6 is the only master device holding a valid copy of the data, and a read transaction from the first master device 4 subsequently causes the indexed element to transition to a non-exclusive state requiring permission to modify the data, then write accesses to the indexed element will be serviced more slowly than accesses to other elements of the array. Even if a single attempt at such an attack is insufficient to identify the exact index accessed by the first master device 4, this may be repeated several times to infer the index accessed using statistical methods. Thus, at step 62, some information about the secret may be inferred from the cache access timing in the cache of the second master device.

[0098] This form of attack is possible because the speculative operations of steps 52 to 56 are allowed to trigger changes in the coherence state in the cache of another master, even though it is not yet known whether these operations have been correctly executed. In practice, the way in which the attacker will be able to control master 1 to execute steps 52 to 56 will rely on incorrect speculation, causing master 1 to temporarily execute its operations but then detect that these operations are incorrect and rewind the architectural effects of these operations. However, if there is a change in the coherence state in master 2's cache due to these operations, this effect will persist even if the architectural effects of the speculatively executed operations have been undone at master 1.

[0099] FIG. 4A to FIG. 4C Illustrated is a safe speculative read transaction (coherency change inhibit transaction) that can be used by a requesting master for a speculative read operation to ensure that the read transaction cannot trigger any changes in the coherency state of the requested data at other caches. Figure 4A The processing of a secure speculative read transaction is illustrated in the case where the target data is cached in the cache 12 of the second master device 6 in a consistency state that would allow caching of the data in the requestor cache 11 of the requestor master device 4 without changing the consistency state in the cache 12 of the second master device. For example, this may be a hit to data that is maintained in a shared or owned state in the MOESI protocol, although it will be appreciated that different states may be considered to allow caching in other masters in other protocols. When the consistency state of the target data in the cache 12 of the second master device does not allow caching in the requestor master device, the response to the secure speculative read transaction may be similar to that described in the example above. Figure 2A The same is shown because the second master 6 returns the snooped data to the requesting master 4 via the interconnect 10, which is then cached in the requesting master cache. The consistency state of the target data at the second master 6 remains the same in this case and therefore there is no change in the consistency state to be probed by an attacker based on speculation.

[0100] When a safe speculative read transaction results in a miss in the second master's cache 12 and in all other caches for which coherence is maintained by the interconnect 10, then this is treated as Figure 2B is handled in the same way as shown. Therefore, Figure 4B and Figure 2B Exactly the same. Note that Figure 4A and Figure 4B In the example, the type of the snoop request 70 sent to the second master device 6 is the same as Figure 2A and Figure 2B The snoop request shown in FIG. 1 is a different type of snoop request to indicate to the second master device that it can only return the data if the data is maintained in a coherent state that also allows caching of the data in the requesting master device cache.

[0101] like Figure 4C As shown in , in the case where a secure speculative read transaction triggers a hit in the cache of the second master device 6 when the data is held in a coherent state that would not allow caching of the data in the requesting master device cache without a change in the coherence state at the second master device 6, then in this case the data is not returned, and instead the second master device 6 returns a HitNoData response 72. The HitNoData response indicates to the requesting master device 4 that, although the data exists in the second master device 6, it cannot currently be provided to the requesting master device 4. Therefore, no data is returned to the requesting master device 4. Since there is no cache of the target data at the requesting master device 4, there is no need to change the coherence state of the data held at the second master device cache. By Figure 4A , Figure 4B and Figure 4C Keeping the coherence state the same at the second master 6 in each of the three cases shown avoids any opportunity for an attacker to gain side channel information from changes in the coherence state triggered by speculative operations.

[0102] When the requesting master 4 receives the HitNoData response 72, it waits for the speculative read operation that triggered the secure speculative read transaction to complete. Figure 4C Step 74 is resolved as non-speculative and correctly predicted. At this point, the requesting master 4 then issues another read transaction 76 (which may be, for example, Figure 2A and Figure 2B A read of the type shown in , which is then read with Figure 2A The other transaction causes the target data to be returned from the second master device 6 to the requesting master device 4 and cached in the cache 11 of the requesting master device 4. At this point, it is safe to update the consistency state of the data held at the second master device 6 because the read operation is no longer speculative.

[0103] Therefore, if an attacker uses incorrect speculation to trick the requesting master device 4 into requesting access to data that is not what the author of the code being executed by the requesting master device 4 intended, then this read operation will be resolved as a mis-speculation and will be canceled, so that another read transaction 76 will never be triggered. Note that when another read transaction 76 is issued, it is possible that the target data may have been invalidated from the cache of the second master device 6 by this time, so sometimes the response to another read transaction 76 can be changed to something like Figure 2B As shown, here it results in a miss and a line fill request to another cache 30 or memory 33, rather than returning data from the cache of the second master device 6.

[0104] use FIG. 4A to FIG. 4C An alternative to the safe speculative read transactions shown in would be to only support Figure 2A and Figure 2B The consistency change shown in allows read transactions, but delays issuing such transactions until a given read operation at the requesting master 4 has been resolved as correctly speculated. However, in this case, in the event of a miss in the other master's cache, a line fill request issued to the other cache 30 or memory 33 will have to be delayed until the speculation is resolved, which can trigger long delays because line fill requests are typically associated with much greater latency than the time it takes to obtain data from the other master's cache. In contrast, by supporting FIG. 4A to FIG. 4C The safe speculative read transaction shown guarantees that there will be no changes in the consistency state of other masters triggered by this transaction, which makes the line fill request Figure 4B In the miss case shown in , the line fill request can be triggered earlier because the line fill request can be triggered without waiting for speculation to be resolved. Therefore, support for such safe speculative read transactions can help improve performance while mitigating against the above-mentioned types of attacks.

[0105] Figure 5 Shows the process Figure 4C The miss case, and the case when the safe speculative read transaction hits in the second cache when the consistency state of the target data allows the cache in the requesting master device, can be respectively as shown in Figure 4B and Figure 4A However, in the case where the transaction hits in the second cache, but the data is held in a coherent state that would not be allowed to be cached in the requesting master without a change in the coherence state at the second cache, Figure 5 In response to the uncacheable read response 80, instead of returning the HitNoData response 72, an uncacheable read response 80 may be returned which does provide the target data from the second master device 6, but indicates that the target data cannot be cached in a consistent manner by the requesting master device. Therefore, since the data will not be cached at the requesting master device, there is no need to change the consistency state of the corresponding data in the cache 12 of the second master device 6, and thus similarly, this prevents incorrectly speculated read operations from being used to trigger changes in the consistency state in other caches, which changes may persist after the read operation has been determined to be misspeculated. In response to the uncacheable read response 80, Figure 5 In step 82, the requesting master device 4 then uses the returned data as the result of the speculative read operation so that subsequent operations using the data can be speculatively continued. However, after using the data as the result of the speculative read operation, the returned data is then discarded without being cached in the requesting cache 11 of the requesting master device 4. This means that if a subsequent read operation triggers a memory access to the same address, this will once again trigger a transaction to be issued to the interconnect 10 to request the data. That is, in response to the non-cacheable read response 80, the requesting master device 4 may write the returned data to its internal registers instead of to its cache.

[0106] In some implementations, the safe speculative read transaction may be returned when the coherency state at the second cache 12 does not allow the cache at the requesting master's cache 11 to be returned. Figure 5 , but may be triggered if the coherence state allows caching at the cache 11 of the requesting master device Figure 4A or triggered if the request misses in the second cache 12 Figure 4B behavior.

[0107] Alternatively, other implementations may not only Figure 5 In the scenario shown, a non-cacheable read response 80 is returned, and when the request hits in the second cache 12 and the coherence state does not allow caching of the target data in the requesting cache 11, Figure 4A In the illustrated scenario, an uncacheable read response 80 may also be returned. That is, even though the data may be cached in the requester cache 11 in this case, the hardware implementation may be simpler if the safe speculative read transaction always returns an uncacheable read response when the request hits in the second cache 12 regardless of the consistency state of the data cached in the second cache 12.

[0108] Figure 6 Shows the Figure 4C and Figure 5 Replacement. Figure 6 , when the safe speculative read transaction triggers a hit in the cache of the second master 6 and the data is held in that cache in a coherent state that does not allow simultaneous caching in the cache of the requesting master 4 unless the coherence state is changed at the second master 6, then likewise, the non-cacheable read transaction 80 is returned to the requesting master. However, if Figure 1 As shown in , the requesting master 4 may have a speculative buffer 90 that may be used to cache speculative results separately from its primary cache 12. The speculative buffer 90 may be outside the coherency scheme managed by the coherent interconnect 10, and therefore the values ​​in the speculative buffer 90 cannot be guaranteed to be consistent with corresponding data stored elsewhere in the system. Therefore, although the non-cacheable read response 80 requires that the requesting master 4 cannot cache the data in the cache 11 that obeys the coherency scheme, the requesting master 4 may still store the returned data in the non-coherent speculative buffer 90. Therefore, in addition to Figure 5 In addition to writing the returned data to the register as the result of the speculative read operation at step 82, the use of Figure 6 In the scheme shown in , the data is also stored to the non-uniform speculative buffer 90 at step 84. This means that subsequent read requests to the same address can be processed faster because they can hit the speculative data in the speculative buffer 90.

[0109] However, with this scheme, once the speculative read operation that triggered the original secure speculative read transaction has been resolved, the requesting master device 4 may need to take additional steps to check whether the data is still consistent. At step 100, the requesting master device 4 may determine that the speculative read operation has been resolved as correct. By this time, there may have been changes in the target data at the second master device 6 or elsewhere in the system, so in order to ensure continued consistency and avoid polluting its cache 11 with outdated values, in step 102, the requesting master device 4 may issue a request to upgrade the non-consistent copy of the data in the speculative buffer 90 to a consistent copy that can be allocated to its primary cache 11. For example, the consistency upgrade request can be a request to retrieve the latest version of the target data (for example, using Figure 2A and Figure 2B ), the latest version of the target data, when returned, may then be cached in the cache of the requesting master device at step 106. Alternatively, if the interconnect 10 and one of the second master devices 6 track whether a write to the target data has occurred since the snoop triggered by the secure speculative read transaction was issued, the consistent upgrade request may be a request to verify whether the data value should have changed. In any case, upon receiving a response to the consistent upgrade request 104, the requesting master device 4 may check whether the data should have changed since it was cached in the speculative buffer (either by comparing the original and re-retrieved data values, or by checking the response 104 indicating whether a write has occurred), and if so, the speculative data may be discarded from the speculative buffer 90 and any subsequent operations using the data may be canceled because these may be based on incorrect inconsistent values. If the requesting master device 4 confirms that the execution of any subsequent operation based on the speculatively buffered data is correct, the result of such operation may be maintained and the speculatively buffered data may be allocated to the main cache 11. The particular approach taken to ensure coherency following non-coherent accesses to buffers outside the control of coherent interconnect 10 may be an implementation choice dependent on the needs of the particular system and the particular coherency protocol used. For example, existing memory disambiguation techniques may be used to check coherency at the time of speculatively executed read resolution.

[0110] In general, the safe speculative read transaction shown in the above example can be used for read operations triggered by speculative operations before knowing whether the target address of the read is correct or whether the read is needed at all. However, in some cases, safe speculative read transactions can be used for all read requests, such as in some master devices, most or even all reads can be performed speculatively, so it may be simplest to always use the safe form of read transactions.

[0111] However, in other systems, it may sometimes be possible to determine that the risk of the above-described form of attack is reduced, and in that case it may be considered appropriate to use a consistency change allowed read form of transaction even for speculative requests (e.g., if some other mitigation measures for side channel attacks are being taken). Using a consistency change allowed form of read transaction in this case may improve performance in some cases by caching data returned from the second master earlier. However, by providing support for a safe form of speculative read transactions, this avoids the need to employ other mitigation measures and ensures safety.

[0112] Figure 7 An example of a shared cache 30 shared between multiple requestors is shown. One example is a system cache 30 that can be accessed by multiple masters 4, 6, or can be independently accessed by different software processes running on the same master 4. Figure 7 In the example of , the shared cache 30 includes a speculative region 120 and a main cache region 122. The speculative region 120 is dedicated to speculatively allocated data while such data remains speculative (i.e., such that the corresponding operation to which it is allocated has not yet been resolved as correct). The main region 122 is dedicated to non-speculative data associated with operations that have been resolved as correct. The entries in the speculative region store the data 130 and an address tag 132 indicating a portion of the address of the data, an indication of the allocation requester 134 that caused the data to be allocated to the shared cache 30, and a load identifier or load group identifier 136 that provides an indication of which load operation or group of load operations caused the data to be speculatively allocated. Once the loads (or groups of loads) that caused the data to be allocated have all been resolved as correctly executed, this allows the shared cache 30 to track when data can be promoted from the speculative region 120 to the main region 122. In contrast, data in the main area 122 may store the tag 132 and the data 130, but need not provide information about the allocation request 134 or the load ID or group ID 136. Figure 7 As shown in FIG. 1 , the master region may also specify other forms of metadata 140 associated with a particular data entry. This metadata may also indicate entries in the speculative region, although this is not shown in the example for simplicity. Figure 7 Although Figure 7 Separate speculative and primary cache regions 120, 122 are shown, but in other embodiments these may be combined into a single region, and additional metadata associated with each entry may mark whether the entry is considered speculative or non-speculative.

[0113] Figure 8 A flow chart is shown that illustrates the processing performed by the shared cache to determine when a speculative entry can be promoted to the primary region. At step 150, the shared cache receives an indication that a load operation associated with a particular load identifier X, or a load group associated with a particular group identifier X, has been resolved as correctly speculative. In response, at step 152, the shared cache promotes any speculative cache lines that have identifier X designated as the load ID or group ID 136 from speculative to non-speculative. Promotion from speculative to non-speculative may be accomplished either by a physical transfer of data from an entry in the speculative region 120 to an entry in the primary region 122, or by updating metadata in the shared cache region to indicate that the speculative entry is now non-speculative.

[0114] Although Figure 8 Examples of using load identifiers or load group identifiers to identify which entries can be promoted to non-speculative when speculative loads are resolved as correct are shown, but other implementations may use addresses of cache entries to identify which entries can be promoted when corresponding load operations are resolved as correct.

[0115] Fig. 9 1 shows a flow chart illustrating the processing of a speculative read request for data at a given target address #A by a specific requestor X. Requestor X may be a specific master device 4, 6 or an individual process running on the master device. Fig. 9 The request is received by the shared cache at step 160. At step 162, the shared cache 30 determines whether the request misses in the cache, that is, no entry is associated with address #A in the speculative region 120 or the main region 122. If there is a miss, then at step 164, a miss response is returned. For example, this may trigger the fetching of data from a lower level cache or memory and / or the allocation of a new entry associated with address #A (if the read request that triggered the allocation is speculative, this will be allocated as a speculative entry).

[0116] If there is no miss, then at step 165 it is determined whether the request hits a non-speculative entry (an entry in the main area 122, or an entry in a shared area indicated by metadata as non-speculative). If so, then at step 166 a hit response is returned to provide the data for access by requester X. A hit response may be returned for a non-speculative entry regardless of which requester caused the data to be allocated. Thus, a non-speculative entry may be hit by any requester (subject to any other memory access control permissions defined by the system). If at step 168 it is determined that the read request hits a speculative entry allocated by requester X, this is also considered a hit and a hit response is returned at step 166.

[0117] On the other hand, if it is determined in step 170 that the speculative read request hits a speculative entry allocated by a requester that is not requester X, then in step 172, it is determined whether the data is dirty (modified relative to the data in another level of cache or memory). If the data is dirty, then in step 174, the data is written back to the other level of cache or memory. If the data is clean, step 174 can be omitted. In any case, in step 164, a miss response is returned. Therefore, while the data allocated to the shared cache remains speculative, only the requester that allocated the data can see the data and any other requester cannot access the data. In addition, since speculative data cannot be allocated to cause the eviction of non-speculative data in the shared cache, this means that requesters other than the requester that allocated the speculative entry are completely unaware of any effect of the speculatively allocated entry. This eliminates the opportunity for cache timing side channels to detect speculative allocations and thus prevents attackers from being able to use incorrectly speculated memory accesses and cache timing side channels to leak information about secret data.

[0118] like Figure 1 As shown in , one of the master devices, in this example, the CPU 4, may have a data prefetcher 200 for predicting future access patterns of memory accesses and prefetching data at addresses predicted to be needed in the future into the cache 11 before the corresponding memory access instructions are actually executed by the processor core of the master device 4. For example, the prefetcher 200 may detect certain stride patterns, where the addresses accessed are sequences of addresses separated by regular intervals. Once the stride pattern is detected, the prefetcher 200 may continue to fetch data into the cache 11 associated with addresses at intervals offset by the detected stride until it is detected that the processor core no longer executes data access instructions with addresses matching the stride pattern. This may improve performance.

[0119] Since the data accesses triggered by the prefetcher 200 may be viewed as a form of load speculation, to avoid invoking the above-described coherence side channel, the prefetcher may trigger a type of data access that uses safe speculative read transactions to obtain data from the coherent interconnect as described above.

[0120] However, even if the data accesses triggered by the prefetcher 200 do not trigger any changes in the coherence state of the caches in other master devices, they may still cause changes in the allocations in the cache 11 within the same master device 4 having the prefetcher 200. In particular, if the prefetcher 200 can be controlled by an attacker to prefetch data from an address speculatively predicted based on some information that depends on the secret information, the corresponding changes in the allocations in the cache 11 can be detected using a timing side channel to leak information about the secret. For example, in the code example shown above, the second data access may be replaced by a stream of accesses to memory locations having a well-defined pattern using a stride that depends on the secret. Thus, such a stream may trigger hardware prefetcher activity that may leak information by revealing the data stride and thus revealing the secret. In other examples, the secret may be used to derive the base address of the sequence of accesses and thus the prefetcher may reveal information about the base address. This problem arises from the fact that a typical hardware data prefetcher 200 will typically train the prediction circuitry based on the addresses of any memory accesses issued, whether those accesses are executed speculatively or non-speculatively, and because data fetched by the hardware prefetcher 200 evicts non-speculative data from cache 11, it is typically permissible.

[0121] Therefore, by providing a hardware prefetcher 200 that is prohibited from evicting non-speculative data from cache 11 to make way for prefetched data whose addresses are predicted based on previous access addresses of speculative access transactions that have not yet been resolved as correct or incorrect, an attacker's avenues for deriving information from prefetcher activity are eliminated. Fig.10 and Fig.11 Two alternative techniques for achieving this are shown.

[0122] Fig.10 A first example is shown in which a data prefetcher has a prefetch address prediction circuit 202 that is trained based on the addresses of previously executed memory accesses that have been resolved as correctly executed. Therefore, the prefetch request generation circuit 204 can then generate a prefetch request based on the address predicted by the prefetch address prediction circuit 202 to request data from the consistent interconnect 10. Once the consistent interconnect 10 returns the requested data, this can be cached in the cache 11 and previously allocated non-speculative data can be allowed to be evicted from the cache. In this case, since incorrectly speculated memory accesses that an attacker can use to trigger inappropriate memory accesses to addresses that depend on secret information are not used for training of the prefetch address prediction circuit 202, there is no risk associated with changing the pattern of cache allocation in the cache 11 based on the predicted prefetch address. It is safe to allocate prefetched data to the cache in the same way as non-speculative data, so that any traditional cache allocation strategy such as least recently used can be used. Therefore, eliminating incorrectly speculated addresses from the training of the prefetch address prediction circuit 202 mitigates attacks.

[0123] Fig.11 An alternative scheme for reducing the risk of attacks via the data prefetcher 200 is shown. In this case, the prefetch address prediction circuit 202 of the prefetcher 200 is trained based on the addresses of speculatively executed memory accesses before it is known whether these accesses are correct or incorrect. However, when the data prefetched from the predicted address is returned from the memory system, the prefetched data is initially allocated to the speculative region 210 of the cache 12, which is maintained separately from the main cache region 212 used to cache non-speculative data. Therefore, the allocation caused by the prefetch cannot cause the eviction of non-speculative data from the main cache region 212. If the privilege level of the processor 4 changes, or a speculation barrier instruction is executed, the speculative region 210 can be flushed to ensure that less privileged processes cannot gain access to the prefetched data in case it is incorrectly speculated, thereby reducing the opportunity for information accessed in a more privileged state to be leaked to software executing in a less privileged state. Note that in addition to data prefetched by prefetcher 200 , speculative region 210 may also be used to store data speculatively loaded triggered by load / store instructions executed by the processor core.

[0124] When the prefetcher prediction (or other prediction used as a basis for speculation) is determined to be correct, the data in the speculative region 210 can be promoted to the main region 212. Therefore, by using a dedicated speculative region 210 (which can be flushed when an event occurs indicating that there may be a risk that an attacker can gain access to a result that may be incorrectly speculated), this reserves the main region 212 for non-speculative results that have been determined to be correct. This means that even if the data prefetcher 200 can be trained to load data into the cache 11 with an address that depends on the secret based on the address of the incorrectly speculated memory access, an attacker who does not have access to the secret cannot gain access to information about the prefetch pattern of the address by probing the cache access time in the main region 212.

[0125] More example arrangements are documented in the following clauses:

[0126] (1) A device comprising:

[0127] multiple master devices; and

[0128] a shared cache shared between the master devices for access pursuant to a request by one of a plurality of requesters, each requester comprising a given master device or a given process executing on a given master device;

[0129] wherein in response to a request by a given requestor to read target data speculatively allocated to the shared cache by an allocation requestor, while an operation triggering the speculative allocation of the data remains speculative, the shared cache is configured to:

[0130] returning a hit response providing the target data when the given requestor is the allocation requestor, and

[0131] A miss response indicating that the data does not exist in the another level cache is returned when the given requestor is a requestor other than the allocation requestor.

[0132] (2) A device comprising:

[0133] processing circuitry capable of speculative execution of data access operations;

[0134] a cache for caching data obtained in response to a data access operation; and

[0135] a data prefetcher to speculatively prefetch data into the cache associated with a prefetch address predicted based on a previous access address of a data access operation performed by the processing circuitry;

[0136] wherein the cache and the data prefetcher are configured to inhibit data speculatively prefetched by the data prefetcher based on a prefetch address predicted from a previous access address of a speculatively executed data access operation from triggering eviction of non-speculative data stored in the cache associated with a data access operation that has been resolved as non-speculative.

[0137] (3) The apparatus of clause (2), wherein the data prefetcher is configured to predict the prefetch address based only on previous access addresses associated with data access operations that have been resolved as non-speculative by the processing circuitry.

[0138] (4) An apparatus as described in clause (2), wherein the cache includes a primary cache area and a speculative cache area,

[0139] And the cache is configured to allocate data prefetched by the data prefetcher to the speculative cache area, and in response to determining that the prediction of the prefetch address for a given data item allocated to the speculative cache area is correct, transfer the given data item to the primary cache area.

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

[0141] Although illustrative embodiments of the present invention have been described herein in detail 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 effected therein by those skilled in the art without departing from the scope and spirit of the invention as defined in the appended claims.

Claims

1. A data processing system, comprising: multiple masters with associated caches; as well as Coherence control circuitry for managing coherence between caches based on a coherence protocol that assigns one of a plurality of coherence states to each data item in a given cache, wherein: The coherence control circuit is configured to support processing of a secure speculative read transaction received from a requesting master device, the secure speculative read transaction being of a type that requests that target data be returned to the requesting master device while inhibiting any changes to a coherence state associated with the target data in caches of other masters responsive to the secure speculative read transaction; In response to the secure speculative read transaction, at least when the target data is cached in a second cache associated with a second master device, at least one of the coherence control circuitry and the second cache is configured to return a secure speculative read response while maintaining the target data in the same coherence state within the second cache; and In response to the secure speculative read transaction, when the target data does not exist in the second cache and any other cache managed according to the consistency protocol, the consistency control circuit is configured to obtain the target data from another level of cache or memory shared among the multiple master devices and return the target data to the requesting master device in a cacheable read response, and the cacheable read response allows the cache associated with the requesting master device to cache the target data.

2. The system of claim 1 , wherein in response to the secure speculative read transaction, when the target data is cached in the second cache in a coherence state that would not allow the target data to be cached in the requester cache without changing the coherence state of the target data in the second cache, the secure speculative read response includes a no-data response indicating that the target data cannot be provided by the second cache until the speculative read operation that triggered the secure speculative read transaction is resolved as non-speculative.

3. The system of claim 2 , wherein in response to receiving the no-data response, the requesting master device is configured to issue another transaction to the coherency control circuit when the speculative read operation has been resolved as non-speculative, the other transaction being of a type that requests that the target data be returned to the requesting cache while allowing changes to the coherency state associated with the target data in other caches.

4. The system of claim 1 , wherein in response to the secure speculative read transaction, when the target data is cached in the second cache in a coherence state that would not allow the target data to be cached in the requester cache without changing the coherence state of the target data in the second cache, the secure speculative read response includes providing an uncacheable read response of the target data to the requester cache, the uncacheable read response prohibiting the requester cache from caching the target data.

5. The system of claim 4, wherein in response to the uncacheable read response, the requesting master device is configured to allocate the target data to a non-coherent speculative buffer for buffering data associated with the speculative read operation while the speculative read operation remains speculative.

6. The system of claim 5 , wherein in response to the speculative read operation that triggered the secure speculative read transaction being resolved as non-speculative, the requesting master device is configured to issue a consistency upgrade request to the consistency control circuit to request that the non-consistent version of the target data in the non-consistent speculative buffer be upgraded to a consistent version of the target data.

7. A system according to any one of claims 5 and 6, wherein in response to determining that changes to the target data since the target data was provided by the uncacheable read response will cause incorrect execution, the requesting master device is configured to cancel subsequent operations speculatively executed based on the target data provided by the uncacheable read response. 8 . The system of claim 4 , wherein in response to the secure speculative read transaction, the secure speculative read response includes the uncacheable read response regardless of a coherency state of the target data in the second cache.

9. The system of claim 1 , wherein in response to the secure speculative read transaction, when the target data is cached in the second cache in a coherence state that the coherence protocol would allow the target data to be cached in the requester cache without changing the coherence state of the target data in the second cache, the secure speculative read response includes providing a cacheable read response for the target data, the cacheable read response allowing the requester cache to cache the target data.

10. The system of claim 1, comprising another level of cache shared among the plurality of master devices for access based on a request by one of a plurality of requesters, each requester comprising a given master device or a given process executing on a given master device; Wherein, in response to a request to read data speculatively allocated to the other level cache by an allocation requestor, while the operation triggering the allocation of the data remains speculative, the other level cache is configured to return a miss response indicating that the data is not cached in the other level cache when the request is triggered by a requestor other than the allocation requestor.

11. The system of claim 10 , wherein the another level of cache is configured to store speculatively allocated data in a speculative cache area separate from a primary cache area for storing non-speculatively allocated data, and to transfer the speculatively allocated data to the primary cache area in response to an indication that an operation triggering allocation of the data has been resolved as non-speculative by the allocation requestor.

12. The system of claim 10, wherein the another level cache is configured to store metadata associated with each piece of data cached in the another level cache, the metadata indicating whether the data remains speculative and, if the data remains speculative, indicating which requestor is the allocation requestor.

13. An apparatus for managing cache coherence, comprising: a plurality of interfaces for communicating with a master device having an associated cache; as well as Coherence control circuitry for managing coherence between caches based on a coherence protocol that assigns one of a plurality of coherence states to each data item in a given cache, wherein: The coherence control circuit is configured to support processing of a secure speculative read transaction received from a requesting master device, the secure speculative read transaction being of a type that requests that target data be returned to the requesting master device while inhibiting any changes to a coherence state associated with the target data in caches of other masters responsive to the secure speculative read transaction; In response to the secure speculative read transaction, at least when the target data is cached in a second cache associated with a second master device, the coherence control circuit is configured to return or request the second cache to return a secure speculative read response while maintaining the target data in the same coherence state within the second cache; and In response to the secure speculative read transaction, when the target data does not exist in the second cache and any other cache managed according to the consistency protocol, the consistency control circuit is configured to obtain the target data from another level of cache or memory shared among the multiple master devices and return the target data to the requesting master device in a cacheable read response, and the cacheable read response allows the cache associated with the requesting master device to cache the target data.

14. A data processing main device, comprising: processing circuitry capable of speculative execution of data access operations; as well as interface circuitry for issuing transactions to an interconnect for managing coherence between the master's cache and at least one other cache based on a coherence protocol that assigns one of a plurality of coherence states to each data item in a given cache; Wherein, in response to the processing circuit speculatively performing a read operation to request target data that is not present in the cache of the master device, the interface circuit is configured to: issue a secure speculative read transaction to the interconnect, the secure speculative read transaction being of the following type: it requests that the target data be returned to the master device while prohibiting any change in the consistency state associated with the target data in the at least one other cache in response to the secure speculative read transaction; and when the target data is not present in the at least one other cache managed according to the consistency protocol, receive the target data in a cacheable read response received from the interconnect in response to the secure speculative read transaction, the cacheable read response allowing the cache of the master device to cache the target data.

Images