MOAT: Securely Mitigating Rowhammer with Per-Row Activation Counters

TL;DR

This work analyzes in-DRAM Rowhammer mitigation under the PRAC+ABO framework, showing that the prior Panopticon approach is insecure to practical Jailbreak patterns. It then introduces MOAT, a provably secure design with dual thresholds $ETH$ and $ATH$, a minimal per-bank tracker, and a safe refresh-based reset, achieving robust protection with low overhead (e.g., average slowdown ≤0.28% and ~7 bytes per bank in SRAM). The paper also analyzes the impact of delayed ALERTs via a Ratchet Attack, deriving bounds on tolerable $T_{RH}$ (MOAT with $ATH=64$ tolerates about $T_{RH}=99$ under current ABO timing) and demonstrates performance-attack patterns (TSA) that could modestly increase slowdown but do not imply a DoS for benign workloads. Overall, MOAT provides a practical, secure mitigation strategy for Rowhammer within the PRAC+ABO framework, balancing security, latency, and hardware overhead for contemporary DRAM.

Abstract

The security vulnerabilities due to Rowhammer have worsened over the last decade, with existing in-DRAM solutions, such as TRR, getting broken with simple patterns. In response, the DDR5 specifications have been extended to support Per-Row Activation Counting (PRAC), with counters inlined with each row, and ALERT-Back-Off (ABO) to stop the memory controller if the DRAM needs more time to mitigate. Although PRAC+ABO represents a strong advance in Rowhammer protection, they are just a framework, and the actual security is dependent on the implementation. In this paper, we first show that a prior work, Panopticon (which formed the basis for PRAC+ABO), is insecure, as our Jailbreak pattern can cause 1150 activations on an attack row for Panopticon configured for a threshold of 128. We then propose MOAT, a provably secure design, which uses two internal thresholds: ETH, an "Eligibility Threshold" for mitigating a row, and ATH, an "ALERT Threshold" for initiating an ABO. As JEDEC specifications permit a few activations between consecutive ALERTs, we also study how an attacker can exploit such activations to inflict more activations than ATH on an attack row and thus increase the tolerated Rowhammer threshold. Our analysis shows that MOAT configured with ATH=64 can safely tolerate a Rowhammer threshold of 99. Finally, we also study performance attacks and denial-of-service due to ALERTs. Our evaluations, with SPEC and GAP workloads, show that MOAT with ATH=64 incurs an average slowdown of 0.28\% and 7 bytes of SRAM per bank.

Figures (17)

• Figure 1: (a) Current in-DRAM trackers are either not secure or incur impractical SRAM overheads. (b) PRAC is a framework, and security depends on implementation: We break prior Panopticon design and propose the provably secure MOAT design.
• Figure 2: Overview of Alert-Back-Off (ABO).
• Figure 3: Overview of Panopticon and Jailbreak Pattern.
• Figure 4: Randomized Jailbreak (probabilistic attack).
• Figure 5: Breaking (Deterministic and Randomized) Panopticon configured for a threshold of 128.