MOAT: Securely Mitigating Rowhammer with Per-Row Activation Counters

TL;DR

This paper introduces MOAT, a provably secure in-DRAM mitigation technique for Rowhammer attacks, improving upon prior methods by using dual thresholds to prevent exploitative activation patterns while maintaining low performance overhead.

Contribution

Proposes MOAT, a new secure design with dual thresholds for Rowhammer mitigation, addressing vulnerabilities in previous frameworks like Panopticon, and demonstrating its effectiveness and low overhead.

Findings

MOAT can tolerate Rowhammer thresholds up to 99.

MOAT incurs minimal performance slowdown of 0.28%.

MOAT uses 7 bytes of SRAM per bank.

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.