Authors:
Lucian Cojocar, INT31
Annie Leong, Intel® Product Assurance and Security
More than a decade after Rowhammer was first disclosed1, researchers continue to challenge assumptions that many believed were already settled. Mitigations that once appeared effective have been bypassed, attacker costs have changed, and memory technologies continue to evolve.
Over the years, we’ve learned that the most important lesson is not about any individual mitigation. It’s about resilience. Security assumptions have a finite lifespan, and defenses that seem sufficient today may face new challenges tomorrow.
This blog examines several lessons the industry has learned from more than a decade of Rowhammer research. We’ll look at the strengths and limitations of different mitigation approaches, the growing role of shared-responsibility mechanisms, and why validation and defense-in-depth remain essential for reducing exposure.
Rowhammer is a reminder that security is a continuous process of reassessment, adaptation and collaboration across the ecosystem.
Lessons Learned
In-DRAM Mitigations
One of the first lessons Rowhammer taught the industry is that no single mitigation should be treated as a complete solution. Early responses focus on protections implemented directly inside the DRAM device, including Target Row Refresh (TRR) and later, on-die Error Correction Code (ECC).
TRR2 was designed to detect dangerous row activation patterns and refresh them before data corruption could occur. Over time, researchers demonstrated that implementation details matter. Work such as TRRespass showed that some assumptions underlying TRR could be challenged and that identifying what to refresh can be just as important as determining when to refresh.
As memory density increased, on-die ECC became widely adopted in newer memory generations to improve reliability and correct low-level errors. While this added another layer of protection, subsequent research demonstrated that on-die ECC alone was not sufficient to prevent all Rowhammer attacks. Research such as Phoenix highlighted that observable bit flips may still occur on DDR5 devices despite on-die ECC being mandated. This is expected as any ECC design would have a limit ECC capabilities.
The broader lesson is not that these mitigations failed. Rather, the lesson is that protections implemented entirely within DRAM are difficult to validate externally and should be viewed as one layer in a broader defense-in-depth strategy.
Mitigations Requiring Both DRAM and Memory Controller (MC) Support
One lesson from early Rowhammer mitigations is that protections implemented entirely in the DRAM are not transparent to the platforms for security scrutiny. Newer Rowhammer mitigations shift from DRAM-only protection toward a shared-responsibility model between the MC and the DRAM device. Rather than relying entirely on the memory device to detect and mitigate row disturbance events, the mechanisms below distribute mitigation decisions across both components.
Refresh Management (RFM) is one example of this approach at which the MC sends the RFM commands. The memory controller issues RFM commands, while the DRAM determines which rows require maintenance and the frequency at which those commands should be issued. This gives DRAM additional opportunities to perform targeted maintenance operations while allowing the device to communicate its requirements through mode register settings.
Adaptive Refresh Management (ARFM) extends this concept by allowing the memory controller to select different threshold levels. This provides a way to balance performance and mitigation frequency, enabling platforms to choose between more aggressive protection or lower operational overhead.
Direct Refresh Management (DRFM) shifts more responsibility to the memory controller by allowing it to identify potential aggressor rows. While this moves the "what to refresh" decision closer to the platform, implementation details remain somewhat device-dependent. For example, the DDR5 specification does not clearly define behavior when a memory bank does not contain the DRFM-latched address, potentially leaving the final refresh decision to the DRAM device.
Per-Row Activation Counting (PRAC) takes a different approach. Instead of relying on the memory controller to identify at-risk rows, the DRAM maintains internal accounting of row activations and tracks activity against internally-defined thresholds. Enabling PRAC still requires collaboration with MC. The DRAM can notify the MC and push back on the memory traffic when needed. In addition, MC must use different timings to accommodate DRAM to update the row counters. PRAC allows the DRAM to participate more actively in mitigation decisions when internal resources become constrained.
What's particularly interesting about these mechanisms is not the individual mitigations themselves, but how they change the relationship between the memory controller and DRAM. As mitigation responsibility becomes more distributed, validation becomes increasingly important. Optional features, device-specific behavior, and evolving specifications can make it difficult to verify that protections are operating consistently across systems.
PRAC's standardization provides a good example that In-DRAM transparency became critical for building confidence when DRAM internal row counting was introduced. The DDR5 specification introduced an optional counter test mode to help verify that PRAC functionality is operating as expected.
Ultimately, shared-responsibility mitigations can improve system resilience, but they also increase ecosystem complexity and dependency. For example, in DDR5, PRAC and DRFM cannot be simultaneously enabled as mandated in the DDR5 specification. Effective Rowhammer protection depends not only on the mitigation mechanisms themselves, but also on specification maturity, rigorous validation, and interoperability across vendors.
Memory Controller Solutions
While recent standards increasingly distribute mitigation responsibilities between DRAM device and memory controller, another class of solutions places most of the decision-making within the memory controller itself. These platform-driven approaches introduce a different set of capabilities and challenges.
MC-based mitigations such as Pseudo Target Row Refresh (pTRR)3 attempt to solve both sides of the Rowhammer problem: determining which rows to protect and when protection is needed. Unlike DRAM-managed approaches, these mitigations rely on the platform having sufficient visibility into memory behavior to identify potential victim rows and issue targeted refresh operations.
By design, the effectiveness of these mitigations depends heavily on how accurately the platform understands the underlying DRAM topology.
One challenge for pTRR is in-DRAM row swizzling, a.k.a. row scrambling. This challenge arises from the internal design of DRAMs where “logical” row addresses do not necessarily coincide with the “physical” row addresses. While transparent to software, row swizzling can make neighboring rows appear very different from what the platform expects. Since pTRR relies on identifying adjacent rows, inaccurate assumptions about row mappings can reduce mitigation effectiveness. Characterization studies have shown that row swizzling can account for a significant portion of mapping inaccuracies.
Another challenge is row repair. Modern DRAM devices often remap defective rows to improve manufacturing yield and reliability. While beneficial for device quality, row repair can obscure physical adjacency relationships from the platform. A mitigation may correctly identify a logical neighbor while missing the actual physical neighbor that requires protection.
To address these challenges, Intel performs characterization studies and compatibility checks to better understand the impact of row swizzling and row repair on mitigation effectiveness. Intel also works closely with memory vendors to improve visibility into these behaviors and establish tighter requirements around row mapping accuracy.
The key lesson from deploying pTRR at scale is that mitigation algorithms alone are not enough. Effective protection depends on accurate row-mapping information, continuous validation, and close collaboration across the memory ecosystem. Features such as row swizzling and row repair can significantly influence mitigation accuracy, making characterization and qualification just as important as the mitigation mechanism itself.
System Error Correction
Preventive mitigations discussed in previous sections aim to reduce the likelihood of Rowhammer induced errors. ECC provides an additional layer of resilience when those measures are unable to stop every bit flip.
ECC increases the difficulty of successful exploitation. However, ECC was originally designed to improve system reliability in the presence of random faults. Rowhammer presents a different challenge because it intentionally induces errors that may not match the assumptions underlying traditional ECC protection schemes.
Researchers have demonstrated this limitation through attacks such as ECCploit on DDR3 and ECC.fail on DDR4, which explored ways to bypass ECC protections under specific conditions. These attacks do not make ECC ineffective, but they demonstrate that error correction alone should not be viewed as a complete defense against Rowhammer.
Cryptographic ECC3 (an Intel proprietary feature) extends traditional ECC by applying nonlinear cryptographic transformation to data using a secret key before it is stored in memory and after it is read from memory. It helps prevent attackers from exploiting predictable ECC behavior while preserving the ability to detect and correct memory errors.
As an example, for Confidential Computing (CC) environments, strong security assurances cannot rely solely on DRAM-level protections. Attestation, platform security architecture, firmware protections, and memory mitigations, including cryptographic ECC, must work together to provide meaningful protection.
Ultimately, ECC remains a valuable component of a Rowhammer defense strategy, but its effectiveness is maximized when combined with complementary protections. In practice, resilience comes from layering multiple mitigations rather than relying on any individual protection mechanism.
Ongoing Intel Work
Historically, Rowhammer resistance has not been a standard component of platform memory validation. As Rowhammer research has continued to evolve, this has created a growing need for validation methodologies that go beyond traditional compatibility and reliability testing.
To help address this gap, Intel's Platform Memory Validation program works with independent validation laboratories to identify memory devices that have been assessed for Rowhammer resistance on Intel platforms. These laboratories also verify DRAM and DIMM compliance with JEDEC requirements and validate interoperability across supported Intel platform configurations.
The resulting validation data provides customers with additional insight into memory quality and compatibility. Traditional validation activities may include checks such as verifying that a DIMM's Serial Presence Detect (SPD) contents are valid, confirming checksum integrity, and ensuring a platform can successfully boot and operate with a specific memory configuration. Expanding validation to include Rowhammer-related testing helps provide greater confidence that memory devices meet both functional and security-related expectations.
As memory technologies and Rowhammer mitigations become more sophisticated, validation must evolve alongside them. Expanding memory validation to include security-focused testing will be increasingly important for building confidence in future platforms and memory technologies.
Summary
As an industry, we have learned several important lessons from Rowhammer. First, effective in-DRAM mitigations must address both when and what to refresh. Visibility into DRAM behavior is important for understanding how well these protections work in practice.
Second, newer mitigation techniques can improve resilience, but they introduce complexity. Stronger protection comes from greater dependency on ecosystem-wide interoperability.
Third, MC-based mitigation demonstrated that accurate understanding of DRAM design and close collaboration with memory vendors are required for mitigation effectiveness.
Finally, perhaps the most important lesson is that resilience comes from layering protection. Effective Rowhammer defense requires multiple complementary layers working together and ongoing validation to ensure that those layers continue to operate as intended. Summarized in Table 1: Technology and Mitigation Comparison.
For additional information and best practices, see Reducing Exposure to Rowhammer.
Table 1: Technology and Mitigation Comparison
| Technology | Mitigates What? | When Does Mitigation Occur? | Where Is Decision Made? | Pros | Cons / Lessons Learned |
|---|---|---|---|---|---|
| In-DRAM TRR (Target Row Refresh) | Protect victim rows from excessive neighboring row activations | After suspicious row activations exceed an internal threshold | DRAM | Transparent to system software; low platform overhead; widely deployed | Limited external visibility; effectiveness depends on vendor implementation; Bypassed by TRRespass |
| On-die ECC | Corrects certain DRAM cell errors before data leaves the DRAM device | After errors occur | DRAM | Improves reliability and masks some errors | Limited transparency; not designed specifically for Rowhammer; disturbance errors |
| RFM (Refresh Management) |
Provides additional refresh opportunities for potentially vulnerable rows | when MC issues RFM commands | Command from MC DRAM to execute | Creates standardized cooperation between controller and DRAM | DRAM may lack the resources to determine potential victim rows |
| ARFM (Adaptive Refresh Management) | Same objective as RFM with additional flexibility | Based on selected threshold level | Threshold selection from user Command from MC DRAM to execute | Trade-offs between performance and protection | Adds configuration complexity |
| DRFM (Direct Refresh Management) | Protects MC-identified victim rows | When MC identifies a potential victim | MC | mitigation decisions closer to the platform | Specification ambiguity remains for MC and DRAM |
| PRAC (Per-Row Activation Counting) | Tracks per-row activity and refreshes rows exceeding activation thresholds | When row activation count exceeds threshold | DRAM with MC coordination | Fine-grained tracking; Presence of testing mode |
Introduces complexity and performance impact; optional feature in DDR5 |
| pTRR (Pseudo Target Row Refresh) | Identifies and refreshes likely victim rows using MC knowledge of DRAM | When MC detects suspicious activation patterns | MC | Platform-visible; flexible and ease of implementation | Depends on accurate row mapping; may require characterization |
| ECC | Detects and corrects memory errors | After an error occurs | Memory subsystem | Improves reliability and resilience; raises attack difficulty | Designed for reliability not security focus; can be bypassed under some attack scenarios |
| Cryptographic ECC | Protects against predictable ECC exploitation while maintaining error correction capability | After errors occur | Memory subsystem | Stronger integrity guarantees than conventional ECC | Additional implementation complexity |
Looking Forward
After a decade of Rowhammer, I expect new variants and attack techniques to emerge. That is the nature of security research which is a continuously evolving field. What matters is how the industry responds. As an ecosystem, we must continue to apply lessons learned and incorporate them into resilient systems designs, validation and deployment practices.
Intel takes reports of potential Rowhammer vulnerabilities seriously and continues to investigate and reproduce findings. Recently, for example, we worked to reproduce results from academic papers such as Sledgehammer, RowPress, ρHammer, McSee, and Phoenix, among others, after they were disclosed to us through the PSIRT process. This effort reflects our commitment to tracking emerging threats.
I encourage researchers to follow coordinated vulnerability disclosure and engage all relevant stakeholders, including OEMs and ODMs and memory vendors. Effective assessment and mitigation often require collaboration across the ecosystem, particularly when platform configurations and implementation details fall outside Intel’s control.
Perhaps the most important lesson from a decade of Rowhammer research is security assumptions will eventually be challenged. Implementation bugs can occur at any layer! Attackers adapt, new techniques emerge and defense mechanisms can contain flaws. Resilience comes from designing systems that remain secure when an individual layer falls short and from fostering collaboration across the ecosystem.
As an industry, we have come a long way in how we understand and address Rowhammer. While Rowhammer is unlikely to be solved completely, the lessons learned over the past decade have strengthened the foundation of modern memory security. Going forward the challenge is to continue to apply the lessons learned and be adaptive as new attack techniques emerge. Defense-in-depth remains our best strategy for building resilient systems.
Stay tuned for more.
Footnotes
1 Rowhammer failures were observed at Intel in 2012. See presentation in DRAMSec workshop https://www.youtube.com/watch?v=0iaAny0l494
2 Target Row Refresh (TRR) is an umbrella term for a family of mitigation techniques that is implemented inside the logic of DRAM. TRR identifies rows that may be at risk by detecting a pattern, then “hijack” a refresh command to refresh rows that may experience data loss.
3 Techniques for Probabilistic Dynamic Random Access Memory Row Repair (US Patent No.: 9,449,671 B2).
Share Your Feedback
We want to hear from you. Send comments, questions, and feedback to the INT31 team.
About the Authors
Lucian Cojocar is a security researcher in INT31 focused on hardware-software security, memory-system reliability, and the Rowhammer problem. His research investigates vulnerabilities that arise from complex interactions between hardware and software, with particular expertise in DRAM security, fault attacks, and systems security. Lucian develops techniques to analyze, understand, and mitigate security threats and helps to build more secure and resilient modern computing platforms.
Annie Leong is the Technical Guidance Development Director in the Intel Product Assurance and Security organization. She works with technical leaders and product architecture experts across the company to develop security guidance and best practices for hardware and software ecosystems. Annie also collaborates with industry partners, researchers, and software communities to drive security adoption and deployment.