Rowhammer is a phenomenon in DRAM devices, first introduced in 2014, that allows an attacker to induce bit flips in a victim row by repeatedly activating its neighboring rows, also known as aggressor rows. These bit flips can compromise system security in various environments, including local code execution, web browsers, and even over the network. Numerous attacks have shown that existing mitigations deployed by DRAM vendors can be bypassed. At the same time, CPU vendors have been hesitant to adopt deterministic mitigations, as current proposals often require an impractically large number of expensive counters to protect the worst-case devices (i.e., those with the lowest Rowhammer thresholds). The required number of counters grows as devices become more vulnerable.
With CHaRM, we propose a flexible and efficient in-CPU Rowhammer mitigation that breaks the dependency between the counter requirement and the supported Rowhammer threshold. CHaRM provides deterministic security guarantees for arbitrary Rowhammer thresholds, all while maintaining a fixed efficiency budget (in terms of storage, area, power, and energy). Importantly, CHaRM is implemented using only efficient SRAM structures, avoiding the need for expensive, searchable CAM-based counters used in prior work. CHaRM achieves its flexibility and efficiency through two key mechanisms: Checkpointed and Hashed counters.
What is Rowhammer?
In a Rowhammer attack, the attacker hammers a victim row by repeatedly activating its adjacent rows. A bit flip occurs only if the victim row is hammered a specific number of times, referred to as the Rowhammer threshold (Rthresh). The hammer count of a victim row is defined as the cumulative number of activations to all adjacent rows that can influence it. These neighboring rows are typically specified by the blast radius in the literature, which specifies the number of rows on each side of the victim row that can affect it. For example, a blast radius of 1 means that row Rn can be hammered by activating rows Rn−1 and Rn+1. The figure below shows two common patterns used in Rowhammer attacks: (a) the single-sided pattern, where one aggressor hammers two adjacent victim rows, and (b) the double-sided pattern, where two aggressor rows sandwich a victim row.
Optimal frequent item tracking for Rowhammer mitigation
Deterministic Rowhammer mitigations use a tracker that counts the number of activations to each row. Once the activation count of a row reaches a critical threshold (referred to as the activation threshold Athresh), a mitigation is triggered to refresh the potential victim rows adjacent to this aggressor row. A naive tracker would maintain a counter per row, requiring 64K or 128K counters per bank, an impractically large design for adoption. To reduce this overhead, state-of-the-art mitigations leverage the Misra-Gries algorithm, which provides the optimal number of counters necessary to track all rows that have been activated more than a specific threshold (e.g., Athresh).
While Misra-Gries offers optimality, its counter requirements grow exponentially for lower thresholds, making it impractical for worst-case DRAM devices with very low Rowhammer thresholds. Furthermore, Misra-Gries-based trackers rely on searchable CAM structures, which must be scanned on every activation, introducing additional complexity, area, and power overhead, making them impractical for commercial CPUs.
These challenges prompt a key question: how can we implement an efficient and practical tracker that supports all thresholds, including the worst-case?
CHaRM’s design
CHaRM overcomes the prior work’s efficiency challenge using hashed counters, where a hash function maps each activated row to an entry in a fixed-sized table, called Counters Table (CNT). Each CNT entry tracks its currently occupying row and its activation count, and triggers a mitigation once the counter reaches the Athresh. While this design achieves both flexibility (CNT size is fixed, independently from the threshold) and efficiency (only using tagless SRAM counters), it comes with a shortcoming: CNT entry evictions.
CNT entry evictions happen whenever an activated row maps to an entry that is already occupied with another row; a common case when the CNT table size is small. Since evicting an entry loses tracking the evicted row, a naive implementation needs to mitigate it upon eviction; this incurs high performance overhead since evictions can be frequent. However, our key insight is that the activation counts of most of these evicted rows are rarely close to the threshold in practice. Hence, CHaRM fixes this issue by using a counter checkpointing mechanism.
CHaRM uses a second table, called Counters Checkpoint Table (CCT), where it is used to store a checkpoint of the counters that have been evicted from the CNT, instead of mitigating them immediately. The CCT table also uses a hash function to assign one of its entries to an evicted row. Entries in the CCT table can be shared among multiple rows (i.e., the rows that have the same hash value), and only positive updates are applied. Hence, whenever a CNT-evicted row is activated again, it first looks up the CCT table and initializes its counter in the CNT table with the checkpointed value in the CCT table.
Below, you can see the CHaRM design and its structure.
Sizing the CHaRM tables and experimental results
The flexible design of CHaRM allows CPU vendors to size the tables (CNT and CCT) to find the best trade-off between efficiency overhead (performance, area, power, energy) and the supported threshold. This flexibility enables vendors to optimize for negligible performance impact on average DRAM devices. In the case of a device with a lower threshold, or if future devices become more vulnerable to Rowhammer, the same CHaRM configuration can still provide the same security guarantees, at the cost of higher performance overhead.
Our results show that for all Rowhammer thresholds, CHaRM achieves negligible performance overhead (below 1%), while improving area, power, and energy by 3x, 4x, and 6x, respectively, compared to the state of the art.
More information and artifacts
Our paper, CHaRM is now available and will be presented at the ACM CCS ’25 in Taipei, Taiwan. Additionally, you can find the artifacts of our paper on GitHub and Zenodo.
FAQs
Why a flexible mitigation is needed, and why CHaRM is a good solution?
Rowhammer continues to be an industry-wide problem as evident by recent JEDEC proposals for mitigating Rowhammer (e.g., PRAC). We do not know how badly Rowhammer thresholds will drop in the next 5-10 years. Having a flexible mitigation, like CHaRM, provides a knob to handle this uncertainty. Even if the threshold remains fixed, CHaRM offers significantly better efficiency trade-offs (performance, storage, area, power, energy) than prior work.
Does CHaRM scale to support multiple DIMMs?
The low storage and efficiency requirements of CHaRM allow it to scale to high-end server CPUs, where multiple DIMMs can be installed. For example, for a Rowhammer threshold of 2044, CHaRM requires only 6.12 KB of SRAM per rank. In a server CPU with 8 channels and two dual-rank DIMMs per channel, the total SRAM requirement is just 195.84 KB, only 0.32% of the L3 cache capacity in such systems, which is a subset of the available on-chip SRAM.
Can an adversary abuse CHaRM to affect the performance of bening applications?
An attacker can bring all entries in the CCT table to the Athresh (i.e., saturate all the checkpoints), which triggers an entire bank refresh. However, we provide a performance evaluation for such attacks and show that the overhead for benign applications remains tolerable, reaching only 4% for an Athresh of 512. In addition, we provide further discussion in the paper on how to reduce the likelihood and impact of such performance attacks.
Acknowledgments
This work was supported by the Swiss State Secretariat for Education, Research and Innovation under contract number MB22.00057 (ERC-StG PROMISE), and a Microsoft Swiss JRC grant.