Papers
Topics
Authors
Recent
Search
2000 character limit reached

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

Published 21 Jun 2026 in cs.CR and cs.AR | (2606.22632v2)

Abstract: Modern DRAM chips are vulnerable to read disturbance phenomena such as RowHammer and RowPress, which induce bitflips after accessing nearby rows a certain number of times (the read disturbance threshold). ColumnDisturb is a new, fundamentally different DRAM read disturbance phenomenon. Specifically, ColumnDisturb (i) disturbs DRAM columns instead of rows, and (ii) increases the number of affected DRAM cells from those in only a few neighboring rows to all cells across three consecutive DRAM subarrays. We propose ColumnKeeper, the first set of ColumnDisturb mitigations, in two variants: ColumnKeeper-D (CK-D), a deterministic mechanism, and ColumnKeeper-P (CK-P), a probabilistic one. CK-D exploits DRAM's open-bitline architecture to provide deterministic security guarantees at low performance and energy overheads: it uses two counters per subarray to track activations affecting the odd and even columns, and refreshes one row in a subarray when either counter reaches a predetermined threshold. CK-P instead refreshes one row in three consecutive subarrays upon a row activation in the middle subarray, with a predetermined probability, providing configurable security guarantees at low area overhead. Both mechanisms prevent ColumnDisturb bitflips at low performance, energy, and area overheads. At the current experimentally-demonstrated ColumnDisturb threshold (1M), CK-D and CK-P incur very low average single-core performance overheads of 0.15% and 0.36%, respectively. For near-future thresholds (128K), these rise to a still low average of 1.70% and 2.73%. Mitigating ColumnDisturb at low thresholds (e.g., 16K) remains possible by adopting smaller subarray sizes or enabling subarray-level parallelism. CK-D and CK-P require low area overheads of 0.1 mm2 and 0.03 mm2, respectively. ColumnKeeper is freely available at https://github.com/CMU-SAFARI/ColumnKeeper .

Summary

  • The paper proposes ColumnKeeper, a novel framework that uses subarray-granular tracking to prevent bitflips induced by ColumnDisturb in DRAM systems.
  • It implements dual mechanisms—deterministic (CK-D) and probabilistic (CK-P)—using round-robin scheduling for precise activation tracking with minimal performance and energy overhead.
  • Extensive simulation and Monte Carlo analyses confirm robust security margins and negligible degradation across diverse workloads, even under adversarial conditions.

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

Introduction and Motivation

DRAM reliability continues to be challenged by read disturbance phenomena that enable data corruption via repeated memory accesses. While RowHammer and RowPress have been extensively studied and addressed, ColumnDisturb—an orthogonal column-based disturbance vector—was recently identified and shown to threaten all DRAM cells sharing a column across three consecutive subarrays. ColumnDisturb's broad spatial blast radius and the reduced activation threshold with future process scaling render existing RowHammer mitigations ineffective, prompting the need for new defensive frameworks. Figure 1

Figure 1: DRAM chip, bank, and subarray organization illustrating open-bitline connectivity critical to ColumnDisturb's propagation.

ColumnDisturb Phenomenon

Unlike row-based hammers where aggressor-induced bitflips are restricted to a few neighboring rows, ColumnDisturb enables a single row activation to impact every row along a shared bitline in the local and adjacent subarrays. Analysis demonstrates that with current DRAM devices, ColumnDisturb can induce bitflips after approximately one million row activations, with technology scaling trends forecasting a reduction of this threshold by nearly two orders of magnitude. Bitflips propagate rapidly and broadly, as each hammer targets millions of DRAM cells.

Inefficacy of Naive Mitigations

Simple approaches such as aggressively shortening the refresh window quickly become infeasible. As shown in Figure 2, while tightening the refresh rate slightly degrades performance and power at high thresholds, reducing the ColumnDisturb threshold to 128K hammers results in over 50% system slowdown and a 6× energy increase for real workloads. Similarly, adapting existing per-row mitigation logic (such as PRAC) results in overzealous refreshes and unacceptable system cost, as these mechanisms do not account for cross-subarray propagation or the scale of vulnerable cells. Figure 2

Figure 2: Normalized performance and energy cost of mitigating ColumnDisturb via global DRAM refresh reduction; overheads become prohibitive at low thresholds.

ColumnKeeper Mechanisms

ColumnKeeper introduces two memory-controller-resident mitigation strategies—CK-D (deterministic) and CK-P (probabilistic)—both exploiting subarray-granular activation tracking. This approach aligns with the blast radius of ColumnDisturb and is compatible with the open-bitline architecture. Both schemes employ a round-robin mechanism to ensure every row in affected subarrays is refreshed within a secure interval, minimizing over-refresh and double-counting.

  • CK-D maintains two counters per subarray (for odd/even columns) and increments them based on the propagation established by the open-bitline structure. Once a counter reaches its threshold (calculated as NCD/SN_{CD} / S where SS is the number of rows), a preventive refresh is issued, and the corresponding counter and row pointer are updated.
  • CK-P eliminates counter state, issuing preventive refreshes probabilistically after each activation in a subarray or its neighbors. The probability is tuned to bound the annual expected failure rate by a configurable parameter. Both mechanisms rely on an RPT (row pointer table), per subarray, to cycle through all rows efficiently. Figure 3

    Figure 3: Pitfall of naive accounting—double-counting activations can cause unnecessary refreshes. CK-D avoids this for minimal overhead.

    Figure 4

    Figure 4: CK-D architecture: dual counter tables and round-robin row pointer per subarray enable precise, low-overhead mitigation.

Security Guarantees

CK-D ensures deterministic elimination of ColumnDisturb bitflips by construction, proven via induction-based analysis under all adversarial access patterns. CK-P's security guarantee is parameterizable; its preventive refresh probability is analytically set to make the probability of a single-year failure trace negligible. Monte Carlo analysis confirms that the actual maximum hammer exposure per cell remains well below the physical threshold for all practical parameterizations. Figure 5

Figure 5: Distribution of maximum hammer count under CK-P's probabilistic scheduling—margin to physical bitflip threshold increases as the annual failure target tightens.

Performance and Energy Evaluation

Extensive experimentation with Ramulator 2.0 and DRAMPower, across 62 single-core and 60 multi-core workloads, quantifies the overheads:

  • At the current threshold (NCD=1MN_{CD} = 1M), average (max) performance degradations are 0.15% (2%) for CK-D and 0.36% (5%) for CK-P in single-core configurations.
  • Multi-core workloads at the same threshold reveal slightly higher, but still low, impact—most critical for memory-intensive applications.
  • At more pessimistic thresholds (e.g., NCD=16KN_{CD} = 16K), slowdowns become significant, yet can be largely mitigated by reducing subarray size or introducing subarray-level parallelism (SALP). Figure 6

    Figure 6: IPC impact of CK-D and CK-P across all single-core workloads and three thresholds; overhead is negligible at 1M activations, becoming notable at lower thresholds.

    Figure 7

    Figure 7: DRAM energy impact of ColumnKeeper on single-core workloads; proportional to refresh aggressiveness and RBMPKI classification.

    Figure 8

    Figure 8: Weighted speedup impact for multi-core workload mixes, indicating higher slowdowns due to increased row-buffer conflicts.

    Figure 9

    Figure 9: Corresponding DRAM energy impact on multi-core mixes. CK-D generally has lower overhead than probabilistic approaches at all but the lowest thresholds.

Robustness to Adversaries and Composability

ColumnKeeper maintains low overhead even when single-core applications are colocated with adversarial hammering processes (Figure 10). CK-D's double-counting correction proves beneficial, particularly under complex multi-core and adversarial access streams. The mechanisms decompose cleanly with state-of-the-art RowHammer mitigations such as Graphene, PRAC, and Hydra (Figure 11). CK-D and CK-P can operate in concert with these defenses, incurring only modest additional cost. Figure 10

Figure 10: Performance under adversarial hammering scenarios; CK-D limits slowdown even in presence of high-rate attacks.

Figure 11

Figure 11: Integrating ColumnKeeper with established RowHammer defenses yields additive, but still practical, overheads.

Architectural Sensitivity and Implementation Costs

ColumnKeeper's efficiency is tightly correlated to subarray size—smaller subarrays reduce preventive refresh scope and minimize disturbance exposure (Figure 12). The impact of physical page allocators and fragmentation is insignificant. Additional microarchitectural support such as SALP reveals further reductions in observable performance loss, thanks to enhanced preventive refresh parallelism (Figure 13). Implementation overheads are minimal: ~7.5KB of static state for CK-D, ~2.5KB for CK-P per system, and sub-0.1 mm² area at standard process nodes. Power costs (~50mW CK-D, ~15mW CK-P) and scheduling latencies are well within DRAM system budgets. Figure 12

Figure 12: Smaller subarrays lower ColumnKeeper's performance cost, especially at aggressive threat thresholds.

Figure 14

Figure 14: Huge page allocation and fragmentation have negligible effect on mitigation efficacy and speedup.

Figure 13

Figure 13: With subarray-level parallelism, single-core IPC degradation at low NCDN_{CD} is significantly reduced.

In-DRAM Implementation and Future Adaptations

A fully in-DRAM variant leveraging alert logic and in-situ row tracking (e.g., via PRAC) further reduces worst-case slowdowns, especially at low thresholds where controller-based mechanisms must conservatively over-refresh (Figure 15). Future process scaling and further threshold reductions can thus be robustly accommodated by modest microarchitecture changes such as SALP, smaller subarrays, or lightweight in-DRAM logic. Figure 15

Figure 15: Direct in-DRAM adaptation of CK-D outperforms controller-based version when RFM commands can be efficiently mapped.

Implications and Future Directions

ColumnKeeper provides the first practical, low-overhead solution to the ColumnDisturb vulnerability in DRAM systems. By shifting to subarray-granular tracking and refresh, and exploiting architectural regularity in modern DRAM, these mechanisms close a key gap in DRAM disturbance defenses. For future systems employing even smaller technology nodes or aggressive parallelism, achievable overheads can remain acceptable by jointly adopting microarchitectural (SALP, reduced subarray size) and controller logic co-designs. The composability of ColumnKeeper with existing RowHammer mitigations ensures comprehensive defense, while its robust statistical analysis fits arbitrary security-risk postures.

Conclusion

ColumnKeeper represents a principled, architecture-aware defense against the ColumnDisturb class of DRAM vulnerabilities. The separation of deterministic and probabilistic design points enables cost-security tradeoff tuning. Detailed simulation across diverse workloads establishes practical viability, while analytic and Monte Carlo analyses confirm robust security margins. The low implementation cost and high generality make ColumnKeeper a strong candidate for deployment in both current and next-generation DRAM-based compute platforms.

Paper to Video (Beta)

No one has generated a video about this paper yet.

Whiteboard

No one has generated a whiteboard explanation for this paper yet.

Open Problems

We haven't generated a list of open problems mentioned in this paper yet.

Collections

Sign up for free to add this paper to one or more collections.

Tweets

Sign up for free to view the 3 tweets with 36 likes about this paper.