Reducing Exposure to Rowhammer

Rowhammer is a DRAM disturbance phenomenon manifested by bit flips that can be triggered by repeated activation of specific DRAM rows. Rowhammer represents a DRAM reliability issue. If successfully exploited, it may affect system integrity, confidentiality or availability. Because Rowhammer originates from a characteristic of modern memory technology that is pervasive in all systems, effectively managing the risk and implementing mitigations requires coordinated protections across the memory, hardware, firmware and software ecosystem.

As with other hardware security issues that arise from performance, density, and scaling tradeoffs in modern computing, Rowhammer should be approached as a risk-management problem. A system's exposure to Rowhammer is reduced through layered mitigations and coordinated engineering across the platform and memory ecosystem rather than through any single universal control.

A system’s resilience to Rowhammer-style attacks depends on protections across the memory subsystem, platform, firmware stack, and deployment environment. Even though Intel platforms may include built-in protection capabilities intended to help reduce susceptibility to Rowhammer, effective protection depends on memory vendor support, firmware configuration, system validation, and operational controls. As a result, original design manufacturers (ODMs), original equipment manufacturers (OEMs), platform owners, and providers all play important roles in reducing exposure through component selection, firmware configuration, using error correcting code (ECC) memory where appropriate, validation strategies, update practices, workload isolation, fleet management, and coordinated response processes.

This guidance provides a high-level framework to help mitigate or limit exposure to Rowhammer through a defense-in-depth approach.

Overview of Rowhammer

DRAM stores information as electrical charges in memory cells. Under certain conditions, repeatedly accessing one memory row can create disturbance effects that alter the charge in adjacent rows, potentially resulting in bit flips.

Rowhammer has been studied by the security and memory industries for several years and has driven the development of mitigations across multiple layers of the platform stack. Over time, protection mechanisms have evolved in DRAM devices, memory controllers (MCs), firmware configurations, and system software. As with other hardware security issues, practical exposure depends on the interaction of component capabilities, platform configuration, workload model, attacker access, and deployment conditions.

Many newer memory devices include protections intended to reduce susceptibility to row disturbance. Platform owners and providers should view Rowhammer resilience as a responsibility shared among the memory supplier, platform integrator, firmware provider, silicon vendor, software ecosystem, and infrastructure operator. Because Rowhammer is influenced by memory technology, platform behavior, and deployment conditions, the objective is for all stakeholders to take measures to reduce susceptibility and limit exposure to Rowhammer, rather than assume that one mitigation completely removes all risk in every configuration.

It is also important to recognize that researchers may demonstrate attack setups that use specialized lab equipment, modified system access, or physical interposers to characterize or amplify memory behavior. Such work can be useful to the industry and should be taken seriously, but findings based on such research do not automatically mean the same conditions exist in standard cloud deployments. Platform owners and providers should focus on whether their deployed platforms enable practical attacker access paths, whether fleet configurations consistently enable supported mitigations, and whether supplier qualification and monitoring processes are strong enough to manage exposure to Rowhammer at scale.

Context

Rowhammer was initially recognized as a DRAM disturbance and reliability concern before later being demonstrated to be a security issue. Over time, the industry response evolved from reliability-oriented mitigations to broader, defense-in-depth approaches spanning DRAM protections, platform capabilities, firmware settings, and validation practices. Intel has contributed to this evolution through early characterization, platform protection concepts, mitigation guidance, and customer-facing configuration recommendations. Public research has also continued to test the limits of individual mitigations, reinforcing the need for layered protections rather than reliance on any single mechanism.

Selected Historical Milestones

• 2012: Rowhammer failures on DDR3 devices are observed internally, contributing to early understanding of row disturbance behavior.
• 2013: Industry mitigations begin to emerge, initially with memory reliability in mind.
• 2013–2014: Intel develops and advances platform protection concepts such as pseudo Target Row Refresh (pTRR) to help reduce Rowhammer risk where supported.
• 2014: Public characterization research broadens industry awareness of Rowhammer behavior.
• 2015: Rowhammer is publicly demonstrated as a security threat on DDR3 devices, shifting attention from reliability alone to security implications.
• 2019: Public research demonstrates Rowhammer on DDR4 devices, including work showing that some proprietary in-DRAM mitigations may not be sufficient in all cases.
• 2020 onward: Intel customer guidance and platform recommendations increasingly emphasize layered mitigations, including options such as increased refresh rate, removal of refresh postponement, and enabling pTRR where supported.
• DDR5 generation: Newer standards and implementations introduce additional row disturbance resilience mechanisms, including refresh-management features and other evolving protections.
• Recent research: Continued public work on Rowhammer and related disturbance behaviors has shown that individual mitigations may have limitations in some circumstances, reinforcing the importance of coordinated system-level mitigation.

How Rowhammer and Mitigations Work

Rowhammer relies on repeated activations of DRAM rows beyond normal operating assumptions. Rapid repeated access to one or more aggressor rows can create electrical disturbances in adjacent victim rows. The adversary attempts to generate memory traffic that bypasses the CPU cache and stresses main memory, typically by issuing explicit cache flush instructions. If the charge in the adjacent victim row is not restored in time, disturbance effects may accumulate and eventually appear as bit flips visible to software or system-level integrity checks. See Figure 1 in the Relationship between Layers and Orders section.

Repeated activation of aggressor rows induces disturbances in an adjacent victim row, potentially causing bit flips.

loop:
read(Row 0)
read(Row 2)
evict(Row 0)
evict(Row 2)
repeat

This access pattern alternates between two aggressor rows (row 0, 2) while evicting them from cache to ensure repeated DRAM row activations. Such high-frequency activations can induce disturbances in adjacent rows, potentially leading to bit flips in a victim row (row 1).

Susceptibility can vary based on several factors across multiple system components, including:

• DRAM generation, technology, and device design
• Memory vendor implementation of reliability and disturbance protections
• Refresh policy and timing configuration
• Memory controller scheduling behavior and platform firmware settings
• Voltage, temperature, and operating margin
• Built-in mitigation enablement and correctness

Because susceptibility depends on multiple components and operating conditions, Rowhammer should not be treated as a single fixed issue with a one-size-fits-all mitigation. Correspondingly, mitigation should also be applied in multiple layers. Rowhammer is best managed through a defense-in-depth approach. No single mitigation completely eliminates Rowhammer risk; instead, protections aim to reduce the likelihood of disturbances and limit the impact of any residual errors. Platform owners and providers should evaluate exposure in the context of their platform architecture, supported memory populations, deployment environments, and system security requirements.

Layers and Orders of Mitigation

Rowhammer mitigations can be understood in two complementary ways: layers and orders. Orders describe what the defense achieves, while layers describe where the defense is implemented. Refer to Figure 2 in the Relationship between Layers and Orders section for an example of the layered mitigation concept.

Orders of Mitigation

Order 1 – Prevent Disturbance from Becoming a Visible Bit Error
These mechanisms attempt to restore or protect likely victim rows before disturbance manifests as externally visible corruption. In practice, this often includes refresh-oriented or row-protection safeguards. Refresh restores charge in DRAM cells by reopening and recharging the contents of a row.

A key challenge is determining which rows to refresh and when, as disturbance is not directly observable and must be inferred from access patterns. In practice, some implementations use heuristics or probabilistic approaches to trigger targeted refresh of nearby rows.

Order 2 – Detect, Contain, or Correct Residual Errors
These protections preserve data integrity by detecting, containing, or correcting disturbance-induced bit flips if they still occur. They do not prevent Rowhammer itself, but they reduce the likelihood that disturbance-induced effects result in observable corruption or system impact. For example, ECC may be implemented both within the DRAM device and at the system level (for example, in the memory controller).

Layers of Mitigation

Layer 1 – DRAM Device Protections

Includes in-DRAM mitigations, Target Row Refresh (TRR), other TRR-like mechanisms, refresh-management features, and on-die ECC, where present.

Layer 2 – Memory Controller and Platform Hardware Protections

Includes controller-assisted protections such as platform-managed refresh behavior (for example, pTRR,) and system-level ECC.

Layer 3 – Firmware and Platform Configuration

Includes BIOS and firmware controls that enable, configure, and tune supported protections, such as refresh-related settings and mitigation aggressiveness. Some protections expose configuration parameters that can be tuned through firmware. Firmware may also configure and lock certain security-sensitive platform settings through mechanisms such as MCHECK and related platform security controls where required by Intel® Software Guard Extensions (Intel® SGX) and Intel® Trust Domain Extensions (Intel® TDX). Refer to Supporting Intel® SGX on Multi-Package Platforms for more information. Note that these settings often involve tradeoffs among security, performance, and power and should be evaluated as part of platform qualification and validation. Some security-sensitive features, such as confidential computing, may rely on these same settings to be enabled, so those requirements should be part of configuration considerations.

Note: MCHECK is an Intel-developed firmware module that runs on each CPU following a system reset to verify platform configuration integrity and security. Once validation is complete, MCHECK initializes and locks critical security settings, including provisioning cryptographic keys that support hardware identity, data protection, bus protection, and memory protection. MCHECK performs integrity checks such as memory aliasing validation before enabling trusted execution. By establishing a root of trust and enforcing secure initialization, MCHECK provides the foundation for hardware-enforced isolation and protected computing environments. Refer to XuCode: An Innovative Technology for Implementing Complex Instruction Flows for more information.

Layer 4 – Operational and Deployment Controls
Includes DRAM selection, supported policy settings, workload isolation, domain separation, fleet consistency, monitoring, and response practices.

Note that modern operating systems (OSes) such as Linux* already reduce Rowhammer exposure by restricting access to physical memory address mappings, preventing non-privileged users from easily determining adjacent DRAM rows required for successful attacks. However, privileged users can still access physical mappings, and attackers may be able to infer adjacency using large contiguous memory allocations (for example, 2 MB or 1 GB pages) combined with architectural knowledge. Therefore, additional mitigations and validation with the memory controller’s behavior are necessary to further reduce exposure.

Relationship between Layers and Orders

Order 1 and Order 2 mechanisms may exist across multiple layers. For example, refresh-oriented protections may be implemented in the DRAM device, supported by the memory controller, and tuned through firmware settings. Likewise, error-handling protections, such as ECC, may exist both inside the DRAM device and at the system level. Operational choices influence how effective these protections are in practice.

This layered view helps platform owners and providers make informed decisions about how they design, configure, validate, and operate their systems.

A layered mitigation approach includes protections at the DRAM level, protections in the memory controller, protections in the firmware settings, and at the operational level with domain and feature configurations. All of these layers work together to collectively reduce exposure.

Defense-in-Depth Approach to Reducing Exposure

Evaluate Platform Exposure

The risk associated with Rowhammer depends in part on whether attackers can execute code locally, influence memory access patterns, operate in shared environments, or obtain physical access to the platform. Systems that execute untrusted code or host multiple tenants, including cloud platforms, may consider stronger protections, validation, monitoring, and operational controls than tightly controlled, single-purpose systems.

A holistic platform level strategy may consider:

• Whether untrusted or third-party code can run on the platform.
• Whether workloads from different trust domains share hardware resources.
• Whether the platform is intended for enterprise, cloud, client, or embedded deployment.
• Whether integrity-sensitive workloads require stronger memory protections.
• Whether physical access assumptions differ between deployment models, lab environments, and field systems.

Apply Defense-in-Depth

No single control can eliminate all exposure to Rowhammer. Stronger protection is achieved by combining platform capabilities, DRAM mitigations, firmware configuration, ECC where appropriate, validation, update discipline, monitoring, workload isolation, and coordinated supplier engagement.

Keep Platform Components Updated

Firmware and software mitigations evolve over time. Platform owners and providers should maintain current versions of BIOS/UEFI, firmware, operating system, and hypervisor components, and should incorporate memory-related security and reliability fixes as they become available.

Reassess Periodically

Exposure can change over time as hardware revisions, DRAM vendors, BIOS defaults, workloads, and deployment models change. Rowhammer resilience should be revisited during platform updates, component substitutions, qualification refreshes, fleet changes, and field issue reviews.

Roles of Validation in Defense-in-Depth

While multiple hardware and system-level mitigations exist to reduce susceptibility to Rowhammer, their effectiveness depends on correct implementation, configuration, and deployment. Validation plays a critical role in ensuring that these mechanisms operate as intended and provide the expected level of protection.

Functional Validation

The functional validation that Intel performs ensures that Rowhammer mitigation features behave as designed. For example, Intel validates that refresh management (RFM) techniques operate at the correct frequency as dictated by the memory device, and mitigation features such as TRR must activate the appropriate adjacent rows. This requires correct interpretation of memory-provided metadata, for example, stored in the Serial Presence Detect (SPD) flash or in mode registers, and proper configuration of the memory controller and firmware.

Platform and Ecosystem Validation

Validation also extends to compatibility across platforms and memory devices. System-level validation verifies that memory modules function correctly with a given platform and adhere to relevant standards. While such validation improves compatibility and baseline reliability, it does not guarantee immunity from Rowhammer effects, reinforcing the need for layered mitigations.

Defense-in-depth Validation

In addition to validating individual features, a defense-in-depth approach includes actively testing the system under Rowhammer-like access patterns. These exercises help evaluate the effectiveness of combined mitigations in realistic scenarios, improve understanding of system behavior, and identify gaps that may not be visible through functional testing alone.

Intel Platform Capabilities and Memory Subsystem

Intel platforms may include built-in protection capabilities, in addition to what exists in the JEDEC standards, intended to help reduce susceptibility to Rowhammer. For example, platform-supported mechanisms such as pTRR may provide preventative protection as part of the overall memory subsystem design.

However, effective Rowhammer mitigation is not defined by any single mechanism. Effective protections may include a combination of platform-supported features, DRAM-internal mitigations, refresh-management techniques (for example, targeted or adaptive refresh schemes), vendor-specific controls, and error correction features. These protections vary across memory generations, vendors, and platform implementations.

As a result, effective mitigation depends on the complete platform implementation. In many cases, memory vendors must support and implement the corresponding feature, and platform firmware must configure that feature for the selected memory population. The presence of a processor or controller capability alone does not guarantee protection for a given system configuration.

Common Protection Technologies

Intel implements a set of refreshment management techniques and supports JEDEC-defined refresh management features, including Refresh Management (RFM), Adaptive Refresh Management (ARFM), and Direct Refresh Management (DRFM). These mechanisms operate at different layers of the memory subsystem and are typically deployed together rather than as standalone protection.

• Pseudo Target Row Refresh (pTRR)
  • Implemented in the memory controller², pTRR extends standard refresh by performing additional pseudo-refresh cycles on rows neighboring a frequently accessed aggressor row.
  • Uses a probabilistic mechanism to determine when to trigger these additional refreshes and which neighboring rows to include, balancing security effectiveness against performance overhead.
  • Mainly deployed in DDR3 and DDR4.
• Adaptive-RFM (ARFM)
  • Adapts system-wide policy to control how much refresh budget to spend.
  • Allows platforms to be tuned to their specific security and performance requirements.
  • ARFM is orthogonal to Rowhammer and is often combined with different technologies, such as pTRR and ECC.
• Direct Refresh Management (DRFM)
  • Implemented in the memory controller to identify a hammering row and instruct DRAM to refresh victim rows adjacent to a detected aggressor row.
• Per-Row Activation Counting (PRAC)
  • Some DDR5 DRAMs implement counters for each memory row to track their activity. When the DRAM identifies a row that needs mitigation it may signal the MC to allow more time for mitigations. PRAC is supported by (recent) Intel’s memory controllers.

Applications

The mitigation mechanisms described in the Common Protection Technologies section can be understood in terms of the Orders and Layers framework defined in the Layers and Orders of Mitigation section.

These mechanisms operate either to prevent disturbance errors before they manifest (Order 1) or to detect, contain, or correct residual errors after they occur (Order 2). In addition, these mechanisms are implemented across different layers of the memory subsystem, including DRAM-internal mechanisms (Layer 1) and memory controller or platform-level protections (Layer 2).

Table 2 maps common mitigation technologies to their corresponding order of protection and implementation layer.

Note: This table focuses on hardware-level mitigation mechanisms (Layer 1 and Layer 2).

Platform owners and providers should therefore:

• Confirm which Rowhammer-related protection capabilities are supported on the target platform.
• Verify that the selected memory devices support the relevant controls.
• Ensure that BIOS/firmware features include controls for refresh management. For example, depending on the system performance requirements compared to the Rowhammer resistance requirements, choose the necessary level of protection for Adaptive Refresh Management (ARFM) or tune the blast radius³ of direct refresh management (DRFM).
• Validate protection across all supported DIMM or memory populations.
• Re-evaluate after changes in DRAM vendor, BIOS version, board revision, memory timing policy, or fleet SKUs.

Therefore, built-in platform support for Rowhammer mitigation should therefore be viewed as an enabling capability within a broader defense-in-depth strategy, not as a substitute for DRAM support, firmware enablement, platform validation, and sound operational practices.

Platform capabilities and mitigation features may evolve across product generations. Enhancements to mechanisms such as pTRR can cover more than two adjacent victim rows, although its effectiveness depends on implementation details and configuration. Error correction techniques (ECC) can improve resilience to Rowhammer with a Cryptographic Error Correction Code (Cryptographic ECC) mode that can deter online Rowhammer attacks. All these techniques and their effectiveness depend on their correct configuration and integration within the overall system.

Some mitigation features may introduce performance trade-offs depending on workload characteristics and deployment scenarios. Platform owners should evaluate these trade-offs based on their specific use cases.

Confidential Computing and Rowhammer

Because Rowhammer is a memory integrity issue that can be exploited without physical access, confidential computing (CC) implementations must consider Rowhammer as part of the broader threat landscape. 

As part of a defense-in-depth strategy, platform owners can enable additional mitigation features implemented within DRAM devices. Examples include ARFM and PRAC, which monitor and respond to high-frequency row activations that may lead to Rowhammer effects. These mechanisms are primarily controlled by the DRAM device and memory vendor and therefore operate outside the direct control of the processor and CC architecture. As a result, Intel® Trust Domain Extensions (Intel® TDX) does not rely on these features as part of its core security guarantees.

Since the introduction of Intel® TDX on platforms code named Sapphire Rapids in the Intel® Xeon® Scalable processor family, additional platform-level safeguards have been incorporated into Intel platforms. For example, Refresh Management (RFM) checks are included as part of platform behavior when requested by the memory device. In addition, on platfroms where ECC is present, ECC is a requirement for CC operation, and in future platforms, enhancements such as Cryptographic ECC⁴ further strengthen resilience against memory integrity violations. Confidential computing also relies on firmware to validate, configure and lock security-sensitive platform settings through MCHECK. Refer to the Layers of Mitigation section for more information.

While Rowhammer effects originate in the underlying memory technology and are therefore considered to be outside the formal trust boundary of confidential computing, these effects can be addressed through multiple layers of protection. These include required memory integrity protections, platform safeguards, and optional DRAM-based mitigations, which collectively reduce the likelihood and impact of such attacks.

Recommendations for Platform Owners and Providers

Select and Qualify DRAM with Rowhammer Resilience in Mind

Because effective Rowhammer protection depends on coordination between platform capabilities, DRAM support, firmware configuration, and operational deployment, memory sourcing and qualification are foundational decisions.

Platform owners and providers should:

• Work with DRAM suppliers to understand row disturbance impact and mitigation capabilities.
• Request documentation on supported protections and operating assumptions.
• Consider row disturbance resilience when selecting components and evaluating qualification criteria.
• Review any dependencies on refresh policy, controller features, or firmware configuration.
• Re-qualify when changing DRAM vendors, device revisions, DIMM populations, or fleet-qualified memory SKUs.

Where newer or better-protected DRAM options are available, platform owners should prefer these options for systems with elevated security, reliability, or multi-tenant exposure requirements.

Enable Supported Platform Mitigations

Where supported by the platform and memory configuration, ODMs, OEMs, platform owners, and providers should enable available mitigations intended to reduce Rowhammer susceptibility.

Depending on platform support and memory type, these may include:

• pTRR
• ECC and Cryptographic ECC
• Increased DRAM refresh rates
• Disabling refresh postponement
• DRAM-implemented protection features supported by the selected memory population

These settings should be carefully validated for system compatibility, performance, power, and reliability impact. Operators should avoid assuming that all mitigations are available or equally effective on all systems; supported behavior should be confirmed with the memory supplier and platform vendor. Customers with access to the Intel Resource and Design Center (RDC) can refer to Rowhammer mitigation enablement BIOS option on client and Rowhammer mitigation enablement BIOS option on server for additional information on configuration options.

Use ECC Where Appropriate

ECC can improve resilience to certain memory errors and may help reduce the impact of some disturbance-related faults. Platform owners should consider ECC-capable configurations for platforms with higher integrity, availability, or serviceability requirements.

However, ECC was primarily designed for reliability and should not be treated as a complete Rowhammer mitigation. Its effectiveness depends on the fault pattern, ECC strength, system design assumptions, and how errors manifest across devices or ranks. In particular, Rowhammer-induced fault behavior may not always align with the single-bit or single-device assumptions that some system-level ECC schemes are designed to correct efficiently.

Platform owners and providers should therefore:

• Enable ECC on supported systems where feasible.
• Understand the ECC capability and error model of the platform.
• Monitor corrected and uncorrected error events.
• Investigate abnormal error patterns across memory populations and field returns.
• Avoid relying on ECC as complete protection against all Rowhammer scenarios.

Stronger ECC may improve resilience in some cases, but ECC alone cannot replace DRAM mitigations, platform protections, firmware configuration, and validation.

Note that a 10x4 memory configuration has more storage for the correction bits than a 5x8 configuration. Hence, the ECC implemented for a 10x4 can offer increased reliability (including against Rowhammer). Intel encourages ODMs/OEMs to use such configurations where possible.

Review BIOS and Firmware Defaults

Platform firmware plays an important role in determining whether protective features are enabled and whether memory-related settings preserve sufficient operating margin.
ODMs, OEMs, platform owners, and providers should:

• Confirm that supported Rowhammer-related protections are enabled by default where product requirements allow.
• Review BIOS options affecting refresh policy and timing behavior.
• Avoid exposing unsafe memory tuning controls without clear qualification guidance.
• Validate security-relevant defaults across production BIOS releases.
• Re-evaluate memory protection settings after firmware changes, board revisions, memory supplier updates, or fleet rollout changes.

Security-sensitive and multi-tenant platforms should prioritize safe and validated defaults over aggressive performance tuning.

Avoid Unsupported Memory Overclocking or Reduced-margin Operation

Aggressive tuning of memory timing or refresh behavior can reduce system margin and may increase exposure to reliability and security issues. Systems intended for enterprise, cloud, or other sensitive uses should avoid unsupported memory configurations and should not ship or deploy with reduced-margin settings enabled by default.

If tuning knobs are exposed to customers, platform owners should document any security and reliability implications associated with these options and ensure such settings are clearly identified as being outside validated operating guidance (where applicable).

Keep BIOS Firmware OS and Hypervisor Current

As a general security best practice, system components should be kept up-to-date so that known mitigations, fixes, and configuration improvements can be applied in a timely way.

Platform owners and providers should establish processes to:

• Track relevant security and reliability advisories.
• Update BIOS/UEFI and platform firmware.
• Incorporate memory reference code updates where applicable.
• Memory reference code and firmware updates should be evaluated to ensure that memory protection mechanisms continue to operate as intended when new DIMMs are introduced
• Maintain current OS and hypervisor releases.
• Verify update mechanisms for deployed fleets and managed systems.
• Deploy mitigations consistently across similar fleet configurations.

Maintaining current components reduces exposure to known issues and helps platforms adapt as mitigations evolve. Note that Intel delivers BIOS and firmware update through the Intel Platform Update process.

Consider Deployment Environment Tenancy Model and Attacker Access

While Rowhammer is fundamentally a memory disturbance issue, practical exploitability can depend on the attacker’s ability to run code, influence memory access patterns, or gain physical access to the system. Platforms that cohost untrusted or multi-tenant workloads should therefore apply stronger operational controls and validation.

Depending on the deployment, platform owners and providers should consider:

• Separating different trust domains where feasible.
• Implementing stronger controls for shared hosting or virtualized environments.
• Issuing deployment guidance that distinguishes between trusted single-purpose and untrusted multi-tenant use cases.
• Coordinating with OS and hypervisor vendors on any software-level hardening relevant to memory allocation or isolation.
• Evaluating whether physical-access-based research setups reflect realistic attacker conditions in the deployed service model.

The practical question is not only whether a laboratory attack has been demonstrated against their deployed platforms, but also whether the conditions required for that attack are available in production cloud environments. Cloud operators should assess those differences carefully while still taking published research seriously and using it to inform validation and supplier engagement.

Monitor Memory Health and Field Signals

A proactive security and reliability posture includes monitoring for unusual memory behavior in production and field deployments.

Recommended practices include:

• Collecting ECC telemetry where supported.
• Tracking corrected and uncorrected memory error rates.
• Correlating field data with BIOS versions, DRAM vendors, DIMM revisions, temperature conditions, and platform SKUs.
• Feeding observed trends back into qualification, supplier engagement, firmware review, and cloud fleet operations.
• Monitoring for fleet-wide anomalies that may indicate a configuration or component-specific issue.

Unusual fault patterns should be investigated jointly across security, quality, platform engineering, and service operations teams.

Include Rowhammer Testing in Validation and Regression

Platform owners and providers should incorporate memory disturbance resilience into platform validation and regression processes, particularly when changing components or firmware behavior.

Validation planning should consider:

• Different DRAM vendors and revisions
• BIOS/firmware revisions
• Shipping and optional memory configurations
• Relevant thermal and voltage corners
• Long-term reliability considerations
• Post-change regression when timing, refresh, or controller policy changes are introduced
• Consistency across fleet-qualified hardware variants

Historically, row disturbance resistance has not been treated as an explicit qualification criterion in all system validation flows. Platform owners and providers should consider making Rowhammer resilience a more explicit part of memory vendor assessment, DIMM qualification, fleet qualification, and regression validation, especially for security-sensitive or multi-tenant deployments.

A repeatable qualification checklist can help ensure Rowhammer-related assumptions remain valid over time.

Operating System Configuration

Operating systems can reduce but not eliminate Rowhammer exposure by applying the following configuration principles:

• Use OS versions that restrict physical address exposure.
• Enforce least-privilege access; limit root access.
• Consider risks from large contiguous page allocations.
• Combine OS mitigations with hardware and platform mitigations.

Handling New Rowhammer Variants 

As Rowhammer research continues to evolve, new variants and attack techniques may be identified through academic research, security disclosures, or field observations. These findings may indicate potential exploitation paths, anomalous behavior, or previously uncharacterized interactions within the memory subsystem.

Such findings should be handled through a coordinated product security response. Effective mitigation depends on the full system stack, including platform configuration, OEM/ODM implementation, DRAM device behavior, and deployment environment, so an investigation and response to new Rowhammer variants can be lengthy. This typically involves collaboration across platform manufacturers, CPU providers and memory vendors.

Coordinated disclosure enables consistent reproduction, root-cause analysis, and mitigation development. Since susceptibility to Rowhammer is intrinsic to DRAM devices, effective mitigation requires coordination across the memory, platform, firmware, and software ecosystems. Intel welcomes external reports through PSIRT. Assessment of newly identified Rowhammer variants will be evaluated on a case-by-case basis. Initial analysis typically focuses on determining whether the observed behavior represents a gap or limitation in existing mitigations (including DRAM-internal protections), and whether the issue is specific to a particular memory vendor, device type, or manufacturing lot. Understanding the scope of impact is essential for determining appropriate mitigation strategies.

Any proposed mitigation should be evaluated within the context of the customer’s threat model and deployment scenario. In particular, the following considerations are important:

• • Impact on unaffected systems or configurations
• • Impact on system performance and workload behavior
• • Impact on operational cost and total cost of ownership
• • Impact on system availability (for example, whether changes require reboot or redeployment)

For platform owners and providers, it is important to approach new findings with a structured evaluation process rather than assuming immediate exposure. Systems that have followed recommended practices—such as enabling supported mitigations, maintaining current firmware and software, selecting validated memory configurations, and incorporating validation and monitoring—are generally positioned to reduce susceptibility and limit exposure to Rowhammer attacks.

References

• Rowhammer mitigation enablement BIOS option on client (RDC login required)
• Rowhammer mitigation enablement BIOS option on server (RDC login required)
• PSIRT
• Intel Platform Update
• XuCode: An Innovative Technology for Implementing Complex Instruction Flows
• Supporting Intel® SGX on Multi-Package Platforms
• Platform Memory Validation

Footnotes

1. Refer to the Common Protection Technologies section for detailed definitions of these technologies.
2. pTRR is available on Intel platforms starting with 12th Generation Intel® Core™ processors (Alder Lake) for DDR4 memory and has been extended to DDR5 memory in subsequent processor generations.
3. Blast radius is defined by how far the aggressor rows are from the victim rows and can be measured as a range of neighboring rows.
4. Cryptographic ECC extends traditional ECC by applying nonlinear cryptographic transformation to ECC metadata 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.