MoPAC: Efficiently Mitigating Rowhammer with Probabilistic Activation Counting

Paper Title: MOPAC: Efficiently Mitigating Rowhammer with Probabilistic Activation Counting
Reviewer: The Guardian (Adversarial Skeptic)

---

Summary

This paper identifies the significant performance overhead (cited as 10% on average) of the JEDEC PRAC (Per-Row Activation Counter) mechanism, which is caused by the extended DRAM timings required for every activation's counter update. To mitigate this overhead, the authors propose MoPAC (Mitigating Rowhammer with Probabilistic Activation Counts), a scheme that performs these counter updates probabilistically rather than deterministically. By updating counters for only a small fraction of activations (with probability p), the performance penalty is incurred less frequently. To maintain security guarantees, MoPAC revises the Alert Threshold (ATH) downwards to a new value, ATH*, which is calculated to ensure a target Mean Time To Failure (MTTF) against attacks. The paper presents two implementations: MoPAC-C, a memory controller-side solution requiring two precharge command variants, and MoPAC-D, a fully in-DRAM solution using a small queue (SRQ) to buffer pending updates. The authors claim that for a Rowhammer threshold (TRH) of 500, MoPAC-C and MoPAC-D reduce the 10% PRAC slowdown to 1.7% and 0.7%, respectively.

Strengths

1. Well-Motivated Problem: The paper correctly identifies a critical and practical barrier to the adoption of PRAC. The 10% average performance overhead demonstrated in Figure 2 is a significant cost for a security feature, and addressing this is a worthwhile endeavor.
2. Novel Core Concept: The central idea of trading deterministic, high-cost checks for probabilistic, low-cost checks (compensated by a more sensitive threshold) is a clever approach to amortizing the performance penalty of PRAC.
3. Comprehensive Proposal: The authors present two distinct and well-reasoned implementations (MoPAC-C and MoPAC-D) that explore different points in the design space (MC vs. DRAM-centric), demonstrating a thorough consideration of potential deployment paths.

Weaknesses

My primary responsibility is to ensure the rigor and correctness of the work. Despite its clever premise, the paper's security claims rest on a foundation with several critical, unaddressed flaws.

1. Fundamentally Unjustified Independence Assumption in Security Model: The entire security analysis hinges on the derivation of the acceptable row failure probability, ε. In Section 5.3 (page 7), for a double-sided Rowhammer attack, the paper claims the overall escape probability is Pe2 = Pe1 * Pe1, where Pe1 is the probability of a single aggressor escaping mitigation. This implies that the probabilistic events of failing to mitigate the first aggressor and failing to mitigate the second aggressor are statistically independent. This is a monumental and entirely unsubstantiated assumption. System-level phenomena such as voltage noise, temperature fluctuations, or weaknesses in a hardware pseudo-random number generator could easily introduce correlation. A single period of low entropy from the RNG could cause a burst of missed updates for both aggressors simultaneously, completely invalidating the Pe1 = sqrt(F) derivation in Equation 5. Without a rigorous justification for this independence assumption, the entire security proof is unsound.

2. Inadequate Analysis of Performance Attacks: The analysis of Denial-of-Service attacks in Section 7 is superficial and relies on average-case behavior, which is insufficient for security analysis. The multi-bank attack model (Section 7.2) calculates slowdown based on an average α value of 0.55, derived from a Monte Carlo simulation. An adversary will not target the average case; they will seek to engineer the worst case. The paper provides no analysis of the distribution of α or its minimum possible value. An attacker could potentially find patterns that synchronize the probabilistic updates across banks to achieve a much lower α, leading to a far more effective DoS attack than the paper suggests. A security analysis must be based on worst-case, not average-case, scenarios.

3. Unaddressed Timing Side-Channel Vulnerability: The threat model in Section 2.1 is incomplete. MoPAC-C introduces two precharge commands, PRE and PREcu, with different latencies (as implied by Figure 6, where PRE uses tRP (norm) and PREcu uses tRP (PRAC)). This creates a classical timing side-channel. An attacker can precisely measure the precharge latency to determine whether a counter update occurred or not for a given activation. This leaks the outcome of the random number generator. A sophisticated attacker could use this information to adapt their activation patterns, waiting for a series of non-updates (confirmed via the side-channel) before launching a burst of activations, thereby defeating the probabilistic premise. The paper completely fails to acknowledge or analyze this vulnerability.

4. Discrepancy in Performance Claims and Understated Costs: The abstract and introduction prominently feature the impressive 0.7% slowdown for MoPAC-D at TRH=500. However, Appendix-A reveals that when protecting against Row-Press, the slowdown for MoPAC-D at TRH=500 balloons to 6.8%. Row-Press is a known, practical attack, and omitting its impact from the headline results is misleading. Furthermore, the paper neglects any discussion of the area, power, and, most importantly, verification complexity of the logic required for MoPAC-D's in-DRAM SRQ, its counters, and the associated scheduling/draining logic. Dismissing the cost by comparing SRAM bytes to TRR is insufficient.

Questions to Address In Rebuttal

1. Please provide a rigorous justification for the assumption in Section 5.3 that the probabilistic mitigation failures for the two aggressor rows in a double-sided attack are statistically independent events. What happens to your security guarantees if a weak RNG or systemic noise introduces even a small correlation?
2. Your performance attack analysis in Section 7.2 relies on an average-case parameter α=0.55. Please provide a worst-case analysis. What is the minimum achievable α an attacker could force, and what is the corresponding DoS impact?
3. Please address the timing side-channel inherent in MoPAC-C's design (differing latencies for PRE and PREcu). How do you prevent an attacker from measuring this latency to learn the outcome of the probabilistic choice and adapt their attack strategy accordingly?
4. Please clarify the discrepancy between the 0.7% slowdown for MoPAC-D claimed in the abstract and the 6.8% slowdown reported in Appendix-A when defending against Row-Press. Given that Row-Press is a realistic threat, which of these numbers is the more accurate representation of the mechanism's real-world performance overhead?

Reviewer Persona: The Synthesizer (Contextual Analyst)

---

Summary

This paper addresses a critical and timely problem in hardware security: the significant performance overhead of the JEDEC-proposed Per-Row Activation Counting (PRAC) mechanism for mitigating Rowhammer. While PRAC offers a principled and robust defense against even future, low-threshold attacks, its ~10% average performance penalty—incurred by extending DRAM timings on every activation—presents a major barrier to its widespread adoption.

The authors' core contribution is a simple yet profoundly effective idea: decouple the high cost of counter updates from every memory activation by performing them probabilistically. Termed MoPAC (Mitigating Rowhammer with Probabilistic Activation Counts), their approach only incurs the latency penalty for a small fraction of activations. To maintain security, the mechanism compensates for the sparse sampling by increasing the counter's increment value and carefully lowering the mitigation threshold (referred to as ATH*). The paper presents a rigorous security analysis to derive these safe parameters based on a target Mean Time to Failure (MTTF). Two practical implementation variants are proposed: MoPAC-C (a memory controller-side solution) and MoPAC-D (a fully in-DRAM solution), demonstrating a clear understanding of the hardware ecosystem. The results are compelling, showing that MoPAC reduces the 10% overhead of PRAC to less than 2% for a near-future Rowhammer threshold of 500.

Strengths

1. Addresses a Crucial, Real-World Bottleneck: The primary strength of this paper is its direct and effective targeting of what is arguably the single largest impediment to the adoption of principled in-DRAM Rowhammer defenses. The academic and industrial consensus is moving towards exhaustive tracking mechanisms like PRAC. This work doesn't fight that trend; instead, it makes the trend practical. By transforming PRAC from a theoretically sound but performant-prohibitive solution into a viable one, the work has the potential for significant real-world impact.

2. Elegant and Parsimonious Core Idea: The central concept of applying probabilistic sampling is elegant. It doesn't require a radical redesign of the DRAM array or a complex new tracking structure. Instead, it applies a well-understood technique from computer science (probabilistic counting/sampling) to a new domain with excellent results. This parsimony is a hallmark of strong systems research. The further refinement presented in Section 8 (Non-Uniform Probability) is a thoughtful extension that shows how the core idea can be optimized even more by observing real-world access patterns.

3. Connects Security Theory with System Performance: The authors do not simply propose a heuristic. The security analysis in Section 5.3 is the lynchpin of the paper's credibility. By grounding the choice of probability p and the revised threshold ATH* in a formal model based on acceptable failure rates (Bank-MTTF), they provide a framework for reasoning about the security-performance trade-off. This principled approach is essential for any security mechanism to be taken seriously.

4. Well-Positioned within the Literature: The paper does a good job of situating itself in the broader context of Rowhammer mitigation. It correctly identifies the failure of early ad-hoc solutions like TRR and acknowledges the high storage cost of other principled trackers (ProTRR, Mithril), thereby motivating the industry's shift to PRAC. Crucially, in Section 9.2, it provides a compelling comparison against other low-cost trackers like MINT and PrIDE, arguing that MoPAC's probabilistic counter updates are a more efficient use of limited mitigation time "borrowed" from the refresh budget. This contextualizes MoPAC not just as a PRAC-optimizer, but as a competitive design in the broader space of low-overhead solutions.

Weaknesses

My criticisms are less about fundamental flaws and more about the boundaries and practical implications of the proposed idea.

1. Potential for a New Performance Attack Vector: While the authors analyze performance attacks in Section 7, the analysis is based on a simplified model. Introducing randomness creates a new surface for an adversary to potentially exploit. An attacker could craft access patterns to try and force worst-case scenarios for the probabilistic mechanism, leading to more frequent ABO stalls than with a deterministic system. The paper concludes the impact is less severe than other contention attacks, which is a fair point, but the nature of this new probabilistic vulnerability could be explored more deeply.

2. Understates the Challenge of Standardization: The paper proposes modifications that, while conceptually simple, would require changes to the JEDEC standard. MoPAC-C requires two types of precharge commands, and MoPAC-D requires new state and logic within the DRAM chip itself. The process of amending memory standards is notoriously complex and slow, involving consensus from multiple competing vendors. The paper could benefit from a more explicit discussion of the path to standardization and the potential pushback or implementation challenges from SoC and DRAM vendors.

3. The Fate of MoPAC is Tied to PRAC: The proposal's relevance is entirely contingent on the industry's continued commitment to the PRAC framework. If a different, unforeseen mitigation strategy emerges that supplants PRAC (e.g., a breakthrough in DRAM cell technology that is inherently Rowhammer-resistant, or a radically different low-cost tracker), then this work, while clever, would be solving a problem that no longer exists. This is not a flaw in the work itself, but a contextual risk regarding its long-term impact.

Questions to Address In Rebuttal

1. Regarding the performance attack analysis (Section 7), the throughput loss model 7/(N+7) is a useful first-order approximation. Could the authors elaborate on how this model might change in the face of more complex, multi-bank attack patterns that are specifically designed to exploit the probabilistic nature of MoPAC? How confident are the authors that this simplified model captures the true worst-case performance degradation?

2. Could you elaborate on the practical path to adoption for MoPAC-C and MoPAC-D? What specific changes would be needed in the JEDEC DDR5/DDR6 specifications? For MoPAC-D, what is the estimated silicon area/complexity cost for the per-bank SRQ and associated logic, and how might this affect DRAM vendor cost models?

3. The core philosophy of this paper is to trade deterministic, high-cost security operations for probabilistic, low-cost ones while maintaining a quantifiable security guarantee. Do you see this philosophy being applicable to other areas of hardware security beyond Rowhammer? For example, could similar probabilistic techniques be used to reduce the overhead of memory encryption/integrity counters or other security monitoring features?

Review Form: Innovator (Novelty Specialist)

---

Summary

The paper identifies the significant performance overhead (~10%) of the emerging JEDEC PRAC (Per-Row Activation Counter) standard for Rowhammer mitigation as a major barrier to its adoption. The authors propose MoPAC (Mitigating Rowhammer with Probabilistic Activation Counting), a mechanism to drastically reduce this overhead. The core idea is to perform the costly PRAC counter updates not on every activation, but probabilistically with a small probability p. By doing so, the performance penalty is incurred only for a small fraction of activations. To maintain security guarantees, the proposal includes a rigorous statistical analysis to derive a new, lower Alert Threshold (ATH*) that accounts for potential undercounting due to sampling. The authors present two implementations: a memory-controller-side version (MoPAC-C) and a fully in-DRAM version (MoPAC-D).

---

Strengths

The primary strength of this work lies in its core conceptual contribution: the application of probabilistic counting to the PRAC framework. While PRAC itself is an industry-led evolution of per-row counting concepts (Intel Patent [9], Panopticon [2]), its high, deterministic overhead has been a known, unsolved problem. This paper presents a clean, elegant, and seemingly novel solution to that specific problem.

1. Novel Problem-Solution Pairing: The application of probabilistic methods to reduce the overhead of an exhaustive, per-row tracking mechanism appears to be new. Prior art has explored sampling for limited-entry trackers (e.g., MINT [32] uses deterministic sampling to populate a small tracker) or randomization of the physical space (e.g., RRS [35] randomizes row mappings). However, MoPAC's approach of managing the update frequency of all counters in a full PRAC system is a distinct and novel contribution. It directly targets the latency of the read-modify-write operation inherent to PRAC, which previous academic work on trackers did not need to address.

2. Novel Security Framework for a Probabilistic Defense: A probabilistic mechanism is insecure without a model to bound the failure rate. The security analysis presented in Section 5.3 (page 7) is a crucial and novel component of this work. Deriving the acceptable failure probability (ε) from a target Bank-MTTF and then using the binomial distribution to calculate the required number of critical updates (C) and the revised ATH* provides the theoretical foundation that makes the probabilistic approach viable and trustworthy. This moves the idea from a simple heuristic to a principled defense.

3. Exploration of the Design Space: The proposal of two distinct implementations (MoPAC-C and MoPAC-D) demonstrates a thoughtful exploration of how this novel concept could be integrated into the existing system stack. This is not merely an algorithmic proposal but a tangible architectural one, considering the practical trade-offs between modifying the memory controller and adding complexity within the DRAM chip.

---

Weaknesses

My critique is centered on the precise boundaries of the novelty, as the underlying components are not new in isolation.

1. Incrementalism of NUP: The core intellectual contribution is the introduction of uniform probability to PRAC updates. The extension to Non-Uniform Probability (NUP) in Section 8 (page 12), while clever and effective at further reducing overhead, feels like a logical optimization rather than a separate novel concept. The fundamental leap is made in proposing MoPAC; NUP is an incremental refinement on top of it.

2. Derivative Implementation Primitives: The two proposed implementations, MoPAC-C and MoPAC-D, are logical consequences of the central probabilistic concept. MoPAC-C's requirement for two precharge commands (Section 5.1, page 6) is a simple extension of existing JEDEC capabilities (e.g., PRE vs. PRES). MoPAC-D's in-DRAM queue (SRQ) is a standard architectural pattern. While these are the first proposed implementations for this specific purpose, the building blocks themselves are not novel. The novelty resides entirely in the reason for their use, not the structures themselves.

---

Questions to Address In Rebuttal

1. Distinction from MINT [32]: The paper cites MINT, which uses deterministic sampling (1/p) to select which row activations populate a small, centralized tracker. MoPAC uses probabilistic sampling (p) to decide when to update an existing, dedicated per-row counter. Could the authors explicitly articulate why their probabilistic approach is a conceptually distinct and more powerful primitive than the sampling mechanism used in MINT, particularly in the context of the PRAC framework which already provides exhaustive tracking infrastructure?

2. Prior Art in Probabilistic Hardware Counting: Probabilistic counting is a foundational computer science concept (e.g., Morris's algorithm). While its application to PRAC appears novel, has the literature search included a thorough review of patents and technical reports related to probabilistic or approximate event counting for performance monitoring units (PMUs) or other hardware counters in memory systems? I am interested in whether a functionally identical mechanism has been proposed for a different purpose (e.g., managing power or wear-leveling).

3. Robustness of the Probabilistic Assumption: The security analysis in Section 5.3 (page 7) hinges on the assumption that the selection of an activation for a counter update is a truly independent random event. In a physical implementation, this would rely on a pseudo-random number generator (PRNG). Could a sophisticated attacker, through carefully crafted memory access timing, potentially discover the state of the PRNG or create access patterns that correlate with its output? Such an attack could break the independence assumption and allow for more undercounting than the binomial model predicts. What is the assumed complexity or quality of the PRNG required to uphold the security claims?