Update August 9th, 2023: Added AE Appendix to the Paper.
Update August 2nd, 2023: Added AWS advisory.


Leaking Inaccessible Data with Software-based Power Side Channels

Collide+Power is a novel method to exploit the fundamental way we build and share components in CPUs. We do not target specific programs but instead the underlying CPU hardware itself. This advance in software-based power side channels echoes the discovery of Meltdown and Spectre — where similarly, the underlying hardware provided unforeseen attack possibilities, leaking actual data values.

The root of the problem is that shared CPU components, like the internal memory system, combine attacker data and data from any other application, resulting in a combined leakage signal in the power consumption. Thus, knowing its own data, the attacker can determine the exact data values used in other applications. We present two attacks belonging to the Collide+Power attack family: The first attack breaks the isolation between CPU hyperthreads, leaking arbitrary data across programs. The second attack breaks the isolation between user programs and the operating system, leaking arbitrary data not just from the operating system but any security domain on the same computer.

The Collide+Power technique can enhance any side-channel signal related to power, such as RAPL (PLATYPUS) or frequency throttling (Hertzbleed). While the leakage rates with current proof-of-concepts are comparably low, future attacks may be faster and indicate the necessity of security patches.

Who is behind Collide+Power?

Collide+Power was discovered and reported by:

How does Collide+Power work?

Collide+Power at a high level can be described in the following three steps:

First, the attacker fills the targeted CPU component with attacker-controlled data values. This step can be as simple as moving data to specific memory locations. One of the example components is the CPU cache. In the figure, the attacker fills one cache set with the attacker-controlled data.

Second, the attacker forces the victim data to replace or overwrite the attacker-controlled data in the targeted CPU component. For the CPU cache, the victim data is replacing an attacker-controlled cache line, implying that the data might travel over the busses depending on the cache state and, therefore, the attacker-controlled data collides with the victim secret.

Finally, this collision produces a data-dependent power consumption due to how CPUs are designed and built. Replacing the attacker-controlled value with the secret value consumes more power if more bits have to be changed. By changing the attacker-controlled values and measuring the power consumption over many thousand iterations of this overwriting process, the attacker can find the exact secret value of the victim.

What are the different Collide+Power variants?

The paper proposes two Collide+Power variants:

In the first variant, a victim program constantly accesses important secret data, e.g., a decryption key to encrypt or decrypt a large chunk of data. The victim constantly reloads the secret into the targeted and shared CPU component during this process. An attacker running on a thread on the same physical core can now use Collide+Power to force collisions between the secret and attacker-controlled data. This attack variant assumes that hyperthreading is enabled.

The second variant removes the need for the victim to access the secret data. Here an attacker exploits a so-called prefetch gadget within the operating system. This prefetch gadget can be used to bring arbitrary data into the shared CPU component and again force data collisions and recover the data. This variant has drastically reduced leakage rates but does not require hyperthreading.

What is the impact of Collide+Power?

Collide+Power can use any signal related to power:

Collide+Power demonstrates data leakage with power side channels beyond what the state-of-the-art assumed. Previous software-based power side-channels attacks like PLATYPUS and Hertzbleed target cryptographic implementations and require precise knowledge of the algorithm or victim program executed on the target machine. In contrast, Collide+Power targets the CPU memory subsystem, which abstracts the precise implementation away as all programs require the memory subsystem in some way. Furthermore, any signal reflecting the power consumption can be used due to the fundamental physical power leakage exploited by Collide+Power. In the paper, we evaluated the following two interfaces:

Running Average Power Limit (RAPL) is an interface that directly reports the power consumption of a modern CPU. Due to the findings of PLATYPUS this interface is no longer accessible to unprivileged users. This prohibits using the interface to mount unprivileged Collide+Power attacks.

Frequency throttling side channels exploit timing variations due to the adaptive power management of modern CPUs. Hertzbleed discovered that these timing variations can be used as replacements to direct power measurements. However, as our evaluation shows, these timing variations are more challenging to exploit than the clean power signal from the RAPL interface.

Therefore, only the frequency throttling induced timing variations can be used as a signal for Collide+Power in an unprivileged context. This results in strongly reduced leakage rates with the current state-of-the-art, and it is highly unlikely to be the target of a Collide+Power attack as an end-user.

How to mitigate Collide+Power?

The root cause for Collide+Power is the hardware:

First of all, you do not need to worry. The leakage rates of Collide+Power are relatively low with the current state-of-the-art, and it is highly unlikely to be a target of a Collide+Power attack as an end-user. Nevertheless, we assume that nearly all CPUs are affected by Collide+Power as the exploited leakage is fundamentally a result of how we build CPUs. Finally, we want to clarify that Collide+Power is no CPU bug, as the shared components were always intended to share data from different security domains.

Since Collide+Power is a technique independent of the power-related signal, possible mitigations must be deployed at a hardware level to prevent the exploited data collisions or at a software or hardware level to prevent an attacker from observing the power-related signal.

Preventing data collisions in hardware is a highly complex redesign of general-purpose CPUs, which we think is unlikely to happen in the near future due to the number of shared hardware components in a CPU.

Therefore, the more realistic mitigation is preventing an attacker from observing the power-related signal. These mitigations are in line with mitigations against PLATYPUS and Hertzbleed Therefore, depending on the signal used, there are mitigations. For example, all modern operating systems prevent direct access to the RAPL interface for unprivileged users. Furthermore, Intel provides a configuration to enable the filtered RAPL mode, which obfuscates the data-dependent power consumption in the interface. Unfortunately, we are unaware of concrete deployed mitigations against frequency throttling side channels.

We reported Collide+Power to AMD, ARM, and Intel under the responsible disclosure process, and CVE-2023-20583 was assigned to Collide+Power.

AMD and ARM provide dedicated information and guidelines for Collide+Power:

Intel provides no dedicated guidelines for Collide+Power but provided guidelines for PLATYPUS and Hertzbleed:

Further, general guidelines and information:

Update August 2nd 2023:

Amazon Web Services (AWS) published an advisory for Collide+Power.


We thank the vendors AMD, ARM, and Intel for professionally handling the responsible disclosure.

We thank Robert Primas, Daniel Weber, and Moritz Lipp for engaging discussions. Furthermore, we thank Brian Johannesmeyer and Jakob Koschel for their help and expertise with the operating system prefetch gadget.

This research is supported in part by the European Research Council (ERC project FSSec 101076409), the Austrian Science Fund (FWF SFB project SPyCoDe F8504), and the Semiconductor Research Corporation (SRC) Hardware Security Program (HWS). A generous gift from AWS, Red Hat, and Google provided additional funding. Any opinions, findings, conclusions, or recommendations expressed in this paper are those of the authors and do not necessarily reflect the views of the funding parties.

Additional information

You might be wondering why we decided to create another vulnerability name and logo:

Communication. Do you remember what CVE-2020-8694, CVE-2020-8695, CVE-2022-23823, and CVE-2022-24436 are? Collide+Power combines elements of these two attacks: PLATYPUS and Hertzbleed. Similarly, the logo combines the two elements which enable Collide+Power: Data collisions and a way to measure power consumption.

The SVG and PNG versions of the logo are free to use under a CC0 license.