💻 computer science

ColumnKeeper: Efficient Solutions to the ColumnDisturb Vulnerability in DRAM-based Systems

This paper introduces ColumnKeeper, the first set of mitigation mechanisms (deterministic CK-D and probabilistic CK-P) that effectively prevent the newly discovered ColumnDisturb vulnerability in DRAM by tracking column activations or probabilistically refreshing rows, achieving high security with minimal performance, energy, and area overheads.

Original authors: Andreas Kosmas Kakolyris, F. Nisa Bostanci, Ataberk Olgun, Ismail Emir Yuksel, Harsh Songara, Konstantinos Marios Sgouras, Umut Baser, Konstantinos Kanellopoulos, A. Giray Yaglikci, Onut Mutlu

Published 2026-06-23

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Andreas Kosmas Kakolyris, F. Nisa Bostanci, Ataberk Olgun, Ismail Emir Yuksel, Harsh Songara, Konstantinos Marios Sgouras, Umut Baser, Konstantinos Kanellopoulos, A. Giray Yaglikci, Onut Mutlu

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine your computer's memory (DRAM) is a massive, high-speed library. Inside this library, there are millions of tiny shelves (rows) holding books (data). For decades, computer scientists have worried about a problem called RowHammer. This is like a mischievous child who keeps running back and forth between two specific shelves, shaking the floor so hard that the books on the neighboring shelves fall off and get mixed up.

For a long time, we thought that was the worst that could happen. But this paper introduces a new, stranger problem called ColumnDisturb.

The New Problem: The "Column" Shaking

Instead of shaking the floor between two shelves, imagine the library has a unique design where the shelves are arranged in vertical columns that share a common support beam.

ColumnDisturb happens when someone repeatedly hits one specific vertical column of books. Because of the way the library is built (using what the paper calls an "open-bitline architecture"), hitting one column doesn't just affect the books on that shelf. It vibrates the entire support beam, causing books to fall off three entire sections of shelves at once.

The Old Problem (RowHammer): Affects a few nearby shelves.
The New Problem (ColumnDisturb): Affects thousands of shelves across three different sections simultaneously.

Existing security guards (mitigation mechanisms) were trained to watch for the "shaking floor" problem. They are useless against this new "vibrating beam" problem because they are looking at the wrong angle and don't understand that one hit affects three sections at once.

The Solution: ColumnKeeper

The authors propose a new security system called ColumnKeeper. Think of it as a new set of rules for the library guards to prevent books from falling. They offer two different styles of guards:

1. The Deterministic Guard (ColumnKeeper-D)

This guard is like a precise accountant.

How it works: The guard knows that when you hit a column, it affects the "odd-numbered" books in one section and the "even-numbered" books in the neighboring section.
The Trick: Instead of just counting "how many times was this column hit?", this guard keeps two separate scorecards: one for odd hits and one for even hits.
Why it's smart: If you hit the column in a way that only affects the odd books in the neighbor's section, the guard doesn't get confused and think both sections were hit. It avoids "double-counting" the hits.
The Action: Once the score on either card gets too high, the guard picks a random book from the affected sections and puts it back on the shelf (refreshes it) before it falls. It does this one book at a time, slowly, so it doesn't stop the library from working.

2. The Probabilistic Guard (ColumnKeeper-P)

This guard is like a coin-flipping gambler.

How it works: This guard doesn't keep a scorecard at all. Every time a column is hit, the guard flips a coin.
The Action: If the coin comes up "heads" (which happens with a very specific, calculated probability), the guard immediately goes and refreshes a book in the three affected sections.
Why it's good: It's much simpler to build (less hardware needed) and cheaper. While it's not 100% guaranteed to catch every single hit, the math shows that the chance of a book falling is so incredibly low (like winning the lottery multiple times in a row) that it's safe enough for almost any situation.

How Well Does It Work?

The authors tested these guards in a simulated computer environment. Here is what they found:

Speed: The guards are very fast. In the current "safe" scenario (where it takes 1 million hits to break the memory), the guards slow down the computer by almost nothing (less than 0.5%). Even in a "near-future" scenario where the memory is more fragile (128,000 hits), the slowdown is still very small (around 1-3%).
Energy: The guards don't use much extra electricity.
Size: The hardware needed to add these guards is tiny. The "Accountant" guard takes up about 0.1 square millimeters of space on a chip, and the "Gambler" guard takes up even less (0.03 square millimeters). That's roughly the size of a grain of sand.

The "What If" Scenarios

The paper also looked at what happens if the memory becomes extremely fragile in the future (requiring only 16,000 hits to break).

The Problem: The guards would have to refresh books so often that the library would slow down significantly.
The Fix: The paper suggests two ways to fix this:
1. Smaller Shelves: If the library sections (subarrays) were smaller, the guards wouldn't have to check as many books.
2. Parallel Guards: If the library allowed multiple guards to work on different sections at the exact same time (a feature called Subarray-Level Parallelism), the slowdown would be much less severe.

Summary

ColumnKeeper is the first system designed to stop this new "ColumnDisturb" vibration problem. It offers two choices:

ColumnKeeper-D: A smart, precise system that counts hits carefully to avoid unnecessary work.
ColumnKeeper-P: A simpler, cheaper system that uses random chance to stay safe.

Both options protect your computer's memory from crashing or leaking data, with very little cost to speed or battery life, and they can be built into future computers with almost no extra space required.

Technical Summary: ColumnKeeper

1. Problem Statement

Modern DRAM chips are susceptible to read disturbance phenomena, most notably RowHammer and RowPress, where repeated access to "aggressor" rows induces bit-flips in neighboring "victim" rows. While existing mitigation strategies track row activations to refresh potential victims, a newly discovered phenomenon called ColumnDisturb renders these approaches ineffective.

ColumnDisturb differs fundamentally from row-based disturbances:

Mechanism: It is induced by repeatedly accessing (hammering) the same column of DRAM cells rather than rows.
Scope: Due to the open-bitline architecture of modern DRAM, where sense amplifiers are shared between neighboring subarrays in an interleaved manner, hammering a single column affects all cells sharing that bitline. Consequently, a single row activation in a subarray disturbs cells across three consecutive subarrays (the activated subarray and its immediate neighbors).
Impact: This affects thousands of rows and millions of cells simultaneously. Existing RowHammer mitigations, which operate at row granularity and track specific aggressor rows, cannot defend against ColumnDisturb because they fail to account for the subarray-level blast radius and the specific bitline sharing patterns.
Naive Mitigation Failures: Simply increasing the DRAM refresh rate to counteract ColumnDisturb causes severe performance and energy penalties, particularly as the ColumnDisturb threshold ( $N_{CD}$ ) decreases with technology scaling. Similarly, modifying existing row-tracking mechanisms (like PRAC) to refresh all rows in three subarrays upon a threshold breach leads to excessive unnecessary refreshes and high overheads.

2. Methodology: ColumnKeeper

The authors propose ColumnKeeper, the first set of mechanisms designed to mitigate ColumnDisturb bit-flips with low performance, energy, and area overheads. ColumnKeeper operates at the subarray granularity and employs two variants: a deterministic mechanism (ColumnKeeper-D or CK-D) and a probabilistic one (ColumnKeeper-P or CK-P).

Shared Components

Both variants utilize a Row Pointer Table (RPT) to manage the target of preventive refreshes. The RPT maintains one entry per subarray, pointing to the next row to be refreshed. When a refresh is triggered, the mechanism refreshes the pointed-to row and increments the pointer in a round-robin fashion. This ensures that all rows in an affected subarray are refreshed iteratively before the ColumnDisturb threshold is reached, avoiding the latency of refreshing all rows simultaneously.

ColumnKeeper-D (CK-D): Deterministic Mitigation

CK-D is designed to provide deterministic security guarantees by accurately tracking activations while avoiding "double-counting."

Double-Counting Problem: In an open-bitline architecture, a row activation in a central subarray affects even columns in one neighbor and odd columns in the other. A naive counter that sums all activations in a neighbor would overestimate the hammer count for specific bitlines, triggering unnecessary refreshes.
Solution: CK-D maintains two separate counter tables per subarray: Counter Table-Even (CT-E) and Counter Table-Odd (CT-O).
- When a row in subarray $k$ is activated, CK-D increments both CT-E and CT-O for subarray $k$ (as all columns are affected).
- For the neighboring subarrays ( $k-1$ and $k+1$ ), it increments only the specific counter corresponding to the affected bitlines (e.g., CT-E for $k-1$ and CT-O for $k+1$ ).
Trigger: The mechanism calculates the maximum of the even and odd counters for a subarray. If this value reaches a threshold ( $N_{PR} = N_{CD} / S$ , where $S$ is the subarray size), it triggers a preventive refresh for that subarray using the RPT.
Security: The authors prove via induction that CK-D deterministically prevents bit-flips under worst-case access patterns.

ColumnKeeper-P (CK-P): Probabilistic Mitigation

CK-P aims to reduce hardware complexity by eliminating activation counters entirely.

Mechanism: Upon any row activation in a subarray, CK-P probabilistically issues preventive refreshes to the activated subarray and its two neighbors with a predetermined probability ( $P_{PR}$ ).
Configuration: The probability $P_{PR}$ is calculated to ensure that the probability of a successful ColumnDisturb attack within a specific timeframe (e.g., one year) remains below a configurable bound ( $P_Y$ ).
Trade-off: This approach offers lower area overhead but provides configurable security guarantees rather than deterministic ones.

Handling Implicit Activations

Both mechanisms must account for implicit activations caused by periodic refreshes (REF) and RowHammer preventive refreshes (RFM).

Periodic Refreshes: Since REF commands do not specify a subarray, CK-D conservatively subtracts a safety margin ( $2S$ ) from the threshold calculation to account for the maximum possible hammer count a row receives from global refreshes.
RowHammer Mitigation Integration: When combined with RowHammer defenses (like PRAC), ColumnKeeper treats its own refreshes as explicit activations. For external REF/RFM commands that may affect any subarray, CK-D increments all counters (or refreshes all subarrays in CK-P) to maintain security.

3. Key Contributions

First Mitigation for ColumnDisturb: The paper introduces the first practical mechanisms (CK-D and CK-P) specifically designed to mitigate ColumnDisturb bit-flips.
Architectural Insight: The design leverages the open-bitline architecture to separate odd and even column tracking (in CK-D), avoiding the overestimation of activation counts that plagues naive solutions.
Security Analysis:
- CK-D: Proven to deterministically prevent bit-flips against worst-case access patterns.
- CK-P: Provides configurable security guarantees, with the probability of failure bounded mathematically and validated via Monte Carlo simulations.
Comprehensive Evaluation: The authors evaluate the mechanisms using cycle-accurate simulation (Ramulator 2.0) and power analysis (DRAMPower) across 62 single-core and 60 multi-core workloads.

4. Results

The evaluation demonstrates that ColumnKeeper achieves significant security with minimal overheads at current and near-future thresholds.

Performance Overhead:
- At the current experimental threshold ( $N_{CD} = 1M$ ), CK-D and CK-P incur average single-core performance overheads of 0.15% and 0.36%, respectively.
- At a "near-future" threshold ( $N_{CD} = 128K$ ), overheads rise to 1.70% (CK-D) and 2.73% (CK-P).
- For very low thresholds ( $N_{CD} = 16K$ ), overheads are significant (e.g., ~1.7% average for CK-D) but can be mitigated by reducing subarray sizes or enabling Subarray-Level Parallelism (SALP).
Energy and Area:
- Energy overheads are low at current thresholds (<2% for $N_{CD}=1M$ ) but increase as the threshold drops.
- Area overheads are minimal: 0.1 mm² for CK-D and 0.03 mm² for CK-P.
Multi-Core Impact: Multi-core workloads show slightly higher overheads due to increased row-buffer conflicts, but the relative performance of CK-D over CK-P remains consistent.
In-DRAM Implementation: The paper explores an in-DRAM implementation of CK-D (reusing PRAC signals) which significantly reduces overheads at low thresholds (e.g., maintaining >0.97 IPC at $N_{CD}=16K$ ) by avoiding conservative counter increments for RFM commands.

5. Significance and Claims

The paper claims that ColumnKeeper is the first solution capable of defending against ColumnDisturb without the prohibitive performance and energy costs associated with naive mitigation strategies (like global refresh rate increases).

Practicality: The mechanisms are designed to be implemented in the memory controller (or potentially in-DRAM) with low area and power costs, making them viable for near-term adoption.
Scalability: While current thresholds are manageable, the paper acknowledges that future technology scaling will lower $N_{CD}$ . ColumnKeeper's effectiveness at these lower thresholds is shown to be achievable through architectural modifications (smaller subarrays, SALP) or in-DRAM integration.
Open Source: The authors state that ColumnKeeper is freely available to the research community to facilitate further study and development of DRAM security.

The work concludes that while ColumnDisturb poses a fundamental challenge to DRAM isolation, it can be effectively mitigated with targeted architectural mechanisms that respect the physical realities of modern DRAM subarrays.