The threat resides in the chips’ data memory-dependent prefetcher, a hardware optimization that predicts the memory addresses of data that running code is likely to access in the near future. By loading the contents into the CPU cache before it’s actually needed, the DMP, as the feature is abbreviated, reduces latency between the main memory and the CPU, a common bottleneck in modern computing. DMPs are a relatively new phenomenon found only in M-series chips and Intel’s 13th-generation Raptor Lake microarchitecture, although older forms of prefetchers have been common for years.

Prefetchers usually look at addresses of accessed data (ignoring values of accessed data) and try to guess future addresses that might be useful. The DMP is different in this sense as in addition to addresses it also uses the data values in order to make predictions (predict addresses to go to and prefetch). In particular, if a data value “looks like” a pointer, it will be treated as an “address” (where in fact it’s actually not!) and the data from this “address” will be brought to the cache. The arrival of this address into the cache is visible, leaking over cache side channels.

Our attack exploits this fact. We cannot leak encryption keys directly, but what we can do is manipulate intermediate data inside the encryption algorithm to look like a pointer via a chosen input attack. The DMP then sees that the data value “looks like” an address, and brings the data from this “address” into the cache, which leaks the “address.” We don’t care about the data value being prefetched, but the fact that the intermediate data looked like an address is visible via a cache channel and is sufficient to reveal the secret key over time.

One of the most effective mitigations, known as ciphertext blinding, is a good example. Blinding works by adding/removing masks to sensitive values before/after being stored to/loaded from memory. This effectively randomizes the internal state of the cryptographic algorithm, preventing the attacker from controlling it and thus neutralizing GoFetch attacks. Unfortunately, the researchers said, this defense is both algorithm-specific and often costly, potentially even doubling the computing resources needed in some cases, such as for Diffie-Hellman key exchanges.

One other defense is to run cryptographic processes on the previously mentioned efficiency cores, also known as Icestorm cores, which don’t have DMP. One approach is to run all cryptographic code on these cores. This defense, too, is hardly ideal. Not only is it possible for unannounced changes to add DMP functionality to efficiency cores, running cryptographic processes here will also likely increase the time required to complete operations by a nontrivial margin. 

The threat resides in the chips’ data memory-dependent prefetcher, a hardware optimization that predicts the memory addresses of data that running code is likely to access in the near future. By loading the contents into the CPU cache before it’s actually needed, the DMP, as the feature is abbreviated, reduces latency between the main memory and the CPU, a common bottleneck in modern computing. DMPs are a relatively new phenomenon found only in M-series chips and Intel’s 13th-generation Raptor Lake microarchitecture, although older forms of prefetchers have been common for years.

Prefetchers usually look at addresses of accessed data (ignoring values of accessed data) and try to guess future addresses that might be useful. The DMP is different in this sense as in addition to addresses it also uses the data values in order to make predictions (predict addresses to go to and prefetch). In particular, if a data value “looks like” a pointer, it will be treated as an “address” (where in fact it’s actually not!) and the data from this “address” will be brought to the cache. The arrival of this address into the cache is visible, leaking over cache side channels.

Our attack exploits this fact. We cannot leak encryption keys directly, but what we can do is manipulate intermediate data inside the encryption algorithm to look like a pointer via a chosen input attack. The DMP then sees that the data value “looks like” an address, and brings the data from this “address” into the cache, which leaks the “address.” We don’t care about the data value being prefetched, but the fact that the intermediate data looked like an address is visible via a cache channel and is sufficient to reveal the secret key over time.

One of the most effective mitigations, known as ciphertext blinding, is a good example. Blinding works by adding/removing masks to sensitive values before/after being stored to/loaded from memory. This effectively randomizes the internal state of the cryptographic algorithm, preventing the attacker from controlling it and thus neutralizing GoFetch attacks. Unfortunately, the researchers said, this defense is both algorithm-specific and often costly, potentially even doubling the computing resources needed in some cases, such as for Diffie-Hellman key exchanges.

One other defense is to run cryptographic processes on the previously mentioned efficiency cores, also known as Icestorm cores, which don’t have DMP. One approach is to run all cryptographic code on these cores. This defense, too, is hardly ideal. Not only is it possible for unannounced changes to add DMP functionality to efficiency cores, running cryptographic processes here will also likely increase the time required to complete operations by a nontrivial margin.