Dynamic Rowhammer Threshold Management:Temperature-Aware Threshold Degradation for In-DRAM Defenses

Technical Summary: Dynamic Rowhammer Threshold Management

Problem Statement
The Rowhammer vulnerability, characterized by the Rowhammer Threshold ($T_{RHD}$)—the minimum number of row activations required to induce a bit flip—has intensified with each DRAM generation, dropping from ~139K in 2014 to below 4.8K in modern DDR4 and targeting sub-1K for DDR5. Current in-DRAM defenses (Target Row Refresh [TRR], Per-Row Activation Counting [PRAC], and SALT-C) mitigate this by tracking activations and refreshing victims when a fixed threshold is exceeded.

However, these defenses are parameterized at manufacture time using a static $T_{RHD}$ value. This creates a critical "threshold staleness" vulnerability because the true $T_{RHD}$ varies significantly with runtime operating conditions, particularly temperature. Aggregated data from SpyHammer [6] indicates a near-linear dependence of Bit Error Rate (BER) on temperature (50–95°C), resulting in up to a 3.3× span in within-module BER. Furthermore, VRD [7] demonstrates that thresholds fluctuate stochastically over time. Consequently, a defense calibrated for a nominal 65°C environment may silently under-mitigate when the system operates at higher temperatures (e.g., 85°C), creating an exploitable window where the configured threshold is too loose for the actual physical conditions.

Methodology
The authors propose Dynamic Rowhammer Threshold Management, a defense-agnostic runtime layer that retrofits existing counter-based defenses. Instead of a new defense mechanism, this layer dynamically re-sources the threshold parameter for each defense once per epoch (default 10 ms) based on observed temperature.

The methodology consists of three components:

1. Dynamic $T_{RHD}$ Model: The effective threshold ($T_{RHDeff}$) is calculated as:
   $$T_{RHDeff}(t) = T_{RHDinit} \cdot f_{temp}(T) \cdot g$$
   • Temperature Factor ($f_{temp}$): Derived from a linear regression of SpyHammer [6] data, modeling the degradation of $T_{RHD}$ as temperature rises. The model handles vendor-specific variations (e.g., Samsung's inverted sign) via a lookup table based on the Manufacturer ID (MID).
   • Guardband ($g$): A multiplicative derating factor (empirically set to 0.9) to account for stochastic temporal variations (VRD [7]) and per-row dispersion not captured by the population-mean temperature model.
2. Per-Epoch Update Procedure: The controller samples the temperature from SPD-side sensors (DDR4) or SPD-Hub sensors (DDR5), computes $T_{RHDeff}$, and projects this value onto the specific threshold variable of the active defense.
3. Threshold Projection: The layer maps the computed $T_{RHDeff}$ to the specific security contract of each defense:
   • SALT-C: Recalculates the Activation Per Minute (APM) parameter to ensure the maximum activations ($MaxACT$) remain below the degraded physical threshold.
   • PRAC: Adjusts the per-row alert threshold ($ATH_{PRAC}$) by subtracting the ABO grace budget from $T_{RHDeff}$.
   • TRR: Adjusts the fixed-depth tracker threshold to $T_{RHDeff}/2$.

Crucially, the layer only ever tightens the threshold (never relaxes it), preserving the correctness arguments of the underlying defenses.

Key Contributions

1. A Defense-Agnostic Runtime Layer: A mechanism that decouples the threshold parameter from the static manufacturing constant, allowing it to adapt to runtime thermal conditions without modifying the core defense logic.
2. Unified Evaluation Framework: An evaluation across three distinct defense architectures (SALT-C, PRAC, TRR) using a "decoupled oracle." This oracle scales the physical $T_{RHD}$ per-DIMM by a stochastic factor $\delta \sim N(1, \sigma)$ to break model self-consistency, ensuring that the evaluation tests the defense's ability to handle real-world variance rather than just the model's internal assumptions.
3. Hardware Feasibility Analysis: The paper outlines two deployment paths: a host-side implementation requiring JEDEC standard updates (exposing per-bank threshold registers) and an on-die implementation using existing internal thermal sensors and ROM tables, avoiding new host-writable registers.

Results
The evaluation was conducted using DRAMSim3 with a double-sided Rowhammer trace (600K activations) across 7M cycles.

• PRAC: The nominal-static configuration (calibrated at 65°C) suffered 72 breaches at 85°C. The Dynamic layer reduced this to 0 breaches at $\sigma=0$. Even with stochastic variance ($\sigma=0.10$), the Dynamic layer with a guardband ($g=0.9$) reduced breaches from 38.4 (at $g=1.0$) to 9.6.
• SALT-C: The nominal-static configuration had 10 breaches at 85°C. The Dynamic layer reduced this to 2 breaches (attributed to first-epoch transients), which were eliminated to 0 using a bootstrap policy that seeds the threshold based on the initial temperature. Dynamic operation incurred a latency cost of 5.1% at 85°C compared to nominal-static but was 3.6% cheaper than a worst-case static configuration (calibrated for 85°C) at 65°C.
• TRR: The layer acted primarily as a diagnostic tool for TRR. At a small tracker depth ($K=4$), TRR suffered from capacity limits (evictions) rather than threshold staleness, resulting in high breach counts regardless of calibration. The layer only became effective when the tracker depth was increased ($K \ge 16$).
• Overhead: The computational cost is negligible (<1 ns for calculation). The dominant cost is the memory bandwidth required to write new thresholds to per-bank registers, estimated at ~260 ns per 10 ms epoch (0.003% of DRAM bandwidth).

Significance and Claims
The paper claims that Dynamic Rowhammer Threshold Management closes the "thermal-staleness" gap that renders static defenses vulnerable in hot operating environments. It demonstrates that a thin runtime layer can retroactively fix the parameterization of existing defenses without requiring a fundamental redesign of the DRAM architecture or the defense algorithms themselves.

The authors explicitly state limitations:

• The results are simulation-based; on-silicon characterization of $HC_{first}$ (activation count for first bit flip) vs. temperature is required for deployment.
• The linear temperature model is derived from DDR4 data and may not generalize to DDR5 without refitting due to process changes.
• The approach assumes the observed temperature reflects the actual cell temperature, leaving it vulnerable to sensor spoofing or thermal manipulation attacks, though an on-die sensor implementation mitigates this.
• The layer does not address non-counter-based defenses (e.g., row-swap) or specific attack patterns like Blacksmith or ZenHammer, though it is expected to be orthogonal to them.

Ultimately, the work positions itself not as a new defense, but as a necessary runtime management layer that ensures the parameters of counter-based defenses remain valid under dynamic thermal conditions.