💻 computer science

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

本文提出了一种动态 Rowhammer 阈值管理机制，这是一种与防御机制无关的运行时层，它通过线性模型和防护带根据实时温度来调整 DRAM 内部的 Rowhammer 缓解阈值，在显著减少 SALT-C、PRAC 和 TRR 防御机制下安全漏洞的同时，保持了低延迟。

原作者： Aziz Alajmi, Hoeseok Yang

发布于 2026-07-15

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Aziz Alajmi, Hoeseok Yang

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下你的电脑内存（RAM）是一个巨大的、高速运转的图书馆，书本储存在一排排书架上。这里有一个名为 Rowhammer 的隐蔽故障：如果你频繁摇晃某一个特定的书架，相邻书架上的书可能会被震动，从而导致书掉落，造成数据从 0 变为 1。为了阻止这种情况，内存芯片内置了安全警卫。这些警卫会统计书架被摇晃的次数。如果计数器过高，警卫就会按下“刷新”按钮，在书掉落之前重置该书架。

问题在于，这些警卫在出厂时是根据一个单一的、固定的数值进行校准的：“如果书架被摇晃了 1,000 次，就按下按钮。”但论文指出，这个数字实际上并不是固定的。它会随着温度而变化。就像橡胶圈在受热时会变弱一样，内存书架在升温时也会变得更加脆弱。一个在 65°C 时能承受 1,000 次摇晃的书架，在 85°C 的高温下可能摇晃 760 次就会损坏。

然而，目前的警卫非常固执。即使在内存发热且变得脆弱时，它们仍然维持着 1,000 次的计数。这产生了一个“陈旧窗口”（staleness window）——这是一个危险的间隙，此时内存实际上已经开始损坏，但警卫却认为依然安全。

新的解决方案：一位聪明的、感知温度的教练

作者提出了一种新的“教练”层，它位于内存和警卫之间。这位教练并不取代警卫，它只是每隔几毫秒（称为一个 epoch）更新一次警卫的规则。

以下是这位教练的工作原理：

检查温度计： 教练读取内存的温度传感器。
进行计算： 它使用一个简单的公式来计算由于热量导致内存变得多脆弱。
增加安全缓冲： 因为内存具有一定的不可预测性（就像掷骰子一样），教练会增加一个保护带（safety guardband，即安全余量）以确保万无一失。
更新警卫： 它告诉警卫：“今天很热。不要等到摇晃 1,000 次，请在摇晃 760 次时按下刷新按钮。”

这个过程每 10 毫秒（在模拟中为 160 万个周期）发生一次，其频率足以跟上温度的变化，同时又不会拖慢计算机的速度。

模拟结果显示了什么

研究人员在计算机模拟中（而非真实的物理芯片上）测试了这个想法，使用了三种不同类型的警卫：PRAC、SALT-C 和 TRR。

PRAC（逐行计数器）： 这种警卫在热量面前最脆弱。在模拟中，当内存运行在高温 85°C 时，旧有的“固定”警卫导致了 72 次书籍掉落（违规）。新的动态教练完全解决了这个问题，将违规次数降至零。
SALT-C（协同刷新）： 在 85°C 时，这种警卫在旧设置下有 10 次违规。使用新教练后，这一数字减少到了仅 2 次（这些只是启动时的异常，可以通过“引导启动”技巧来解决）。代价是什么？计算机变得稍微慢了一点，在高热环境下平均读取延迟增加了 5.1%。然而，在较凉爽的 65°C 时，这种新方法实际上比“超安全”的静态设置快了 3.6%，因为它没有进行不必要的频繁刷新。
TRR（追踪器）： 这种警卫受限于它追踪书架的“插槽”数量。模拟显示，即使有了新教练，这种警卫仍然失败了，因为它耗尽了插槽（容量限制），而不是因为温度规则不对。在这里，教练充当了一个诊断工具，表明该警卫本身需要更多的插槽，而不仅仅是更聪明的温度规则。

局限性与未来

论文非常明确地说明了它目前尚未完成的工作。这些结果来自模拟，而非真实的物理芯片。最大的缺失环节是：直接测量导致比特损坏的“第一次摇晃”是如何随温度变化的。作者假设这是一种线性关系（就像图表上的直线），这是基于现有数据的，但他们承认在将其应用于现实世界之前，需要在真实的硅片上进行验证。

此外，为了让这套方案在真实计算机上运行，计算机的主处理器（host）需要被允许写入内存内部的“规则书”。目前，标准并不允许处理器如此轻松地进行操作。作者提出了两条路径：要么行业更新标准以允许这样做，要么内存芯片本身利用其内置的温度计在内部完成计算。

核心结论

这篇论文并没有发明一种阻止 Rowhammer 攻击的新方法。相反，它发明了一种让现有防御机制变得更聪明的方法。通过意识到热量会让内存变得脆弱并实时调整安全规则，系统可以在不降低速度的情况下，防止数据从书架上掉落。它将一个“设定好就不管”的保安，变成了一个“观察天气并随时调整”的保安。

在模拟中，这种方法成功地为 PRAC 和 SALT-C 防御机制关闭了安全缺口，证明了仅仅通过一点数学计算和一个温度传感器，就能在保护数字图书馆安全方面发挥巨大作用。

技术摘要：动态 Rowhammer 阈值管理

问题陈述
Rowhammer 漏洞的特征在于 Rowhammer 阈值（ $T_{RHD}$ ）——即诱发位翻转所需的最小行激活次数——随着每一代 DRAM 的演进而不断加剧，从 2014 年的约 139K 降至现代 DDR4 的 4.8K 以下，并针对 DDR5 的亚 1K 水平。当前的 DRAM 内防御机制（如目标行刷新 [TRR]、每行激活计数 [PRAC] 和 SALT-C）通过追踪激活次数并在超过固定阈值时刷新受害者行来缓解此问题。

然而，这些防御机制在制造时使用静态的 $T_{RHD}$ 值进行参数化。这造成了一个关键的“阈值陈旧性”（threshold staleness）漏洞，因为真实的 $T_{RHD}$ 会随运行时运行条件（尤其是温度）发生显著变化。来自 SpyHammer [6] 的聚合数据表明，位错误率（BER）与温度（50–95°C）呈近线性相关，导致模组内的 BER 跨度高达 3.3 倍。此外，VRD [7] 表明阈值会随时间发生随机波动。因此，针对标称 65°C 环境校准的防御机制在系统在高温度（例如 85°C）下运行时，可能会出现隐形的缓解不足，从而创造出一个配置的阈值对于实际物理条件而言过于宽松的可利用窗口。

方法论
作者提出了动态 Rowhammer 阈值管理，这是一个与防御机制无关的运行时层，旨在为现有的基于计数器的防御机制进行功能补强。该层并非一种新的防御机制，而是根据观测到的温度，每轮（epoch，默认 10 ms）为每种防御机制动态重新配置阈值参数。

该方法由三个部分组成：

动态 $T_{RHD}$ 模型： 有效阈值（ $T_{RHDeff}$ $T_{R H D e f f}$ ）计算如下：
$T_{RHDeff}(t) = T_{RHDinit} \cdot f_{temp}(T) \cdot g$
- 温度因子 ( $f_{temp}$ )： 源自 SpyHammer [6] 数据的线性回归，用于模拟 $T_{RHD}$ 随温度上升而退化的过程。该模型通过基于制造商 ID (MID) 的查找表来处理厂商特定的差异（例如三星的反向符号）。
- 保护带 ( $g$ )： 一个乘性降额因子（经验设定为 0.9），用于解释无法被人口平均温度模型捕捉到的随机时间波动（VRD [7]）和逐行离散性。
每轮更新程序： 控制器从 SPD 端传感器（DDR4）或 SPD-Hub 传感器（DDR5）采样温度，计算 $T_{RHDeff}$ ，并将该值投影到当前活跃防御机制的具体阈值变量上。
阈值投影： 该层将计算出的 $T_{RHDeff}$ $T_{R H D e f f}$ 映射到每种防御机制的具体安全契约中：
- SALT-C： 重新计算每分钟激活次数（APM）参数，以确保最大激活次数（$MaxACT$）保持在退化的物理阈值之下。
- PRAC： 通过从 $T_{RHDeff}$ 中减去 ABO 宽限预算来调整每行警报阈值（ $ATH_{PRAC}$ ）。
- TRR： 将固定的深度追踪器阈值调整为 $T_{RHDeff}/2$ 。

至关重要的是，该层仅会收紧阈值（绝不放宽），从而保证了底层防御机制的正确性论证。

核心贡献

一种与防御无关的运行时层： 一种将阈值参数与静态制造常数解耦的机制，使其能够适应运行时热条件，而无需修改核心防御逻辑。
统一评估框架： 使用“解耦预言机”（decoupled oracle）对三种不同的防御架构（SALT-C、PRAC、TRR）进行评估。该预言机通过按随机因子 $\delta \sim N(1, \sigma)$ 对每个 DIMM 的物理 $T_{RHD}$ 进行缩放，以打破模型的自洽性，确保评估测试的是防御机制处理现实世界变异的能力，而非仅仅是其内部假设。
硬件可行性分析： 论文概述了两条部署路径：一种是需要 JEDEC 标准更新的主机端实现（暴露每 bank 阈值寄存器）；另一种是利用现有的内部热传感器和 ROM 表进行的片上实现，从而避免引入新的主机可写寄存器。

结果
评估使用包含双侧 Rowhammer 轨迹（60 兆次激活）的 DRAMSim3 在 7M 个周期内进行。

PRAC： 在 85°C 下，标称静态配置（校准于 65°C）遭受了 72 次违规。动态层将此减少到了 0 次违规（当 $\sigma=0$ 时）。即使存在随机方差（ $\sigma=0.10$ ），带有保护带（ $g=0.9$ ）的动态层也将违规次数从 38.4 次（当 $g=1.0$ 时）降低至 9.6 次。
SALT-C： 在 85°C 下，标称静态配置有 10 次违规。动态层将其减少至 2 次（归因于第一轮瞬态），通过使用基于初始温度设置种子（seed）的引导策略，违规次数降至 0。动态运行在 85°C 下的延迟成本为标称静态配置的 5.1%，但比在 65°C 下使用最坏情况静态配置（校准于 85°C）的成本低 3.6%。
TRR： 该层主要作为 TRR 的诊断工具。在较小的追踪器深度（ $K=4$ ）下，TRR 受到容量限制（驱逐）的影响，无论如何校准都会导致高违规计数。只有当追踪器深度增加时（ $K \ge 16$ ），该层才变得有效。
开销： 计算成本微乎其微（计算耗时 < 1 ns）。主要的成本是向每 bank 寄存器写入新阈值所需的内存带宽，估计为每 10 ms 轮次约 260 ns（占 DRAM 带宽的 0.003%）。

意义与主张
论文声称，动态 Rowhammer 阈值管理弥补了使静态防御在高温运行环境下变得脆弱的“热失真”差距。它证明了通过一个薄的运行时层，可以在不要求重新设计 DRAM 架构或防御算法本身的情况下，追溯性地修复现有基于计数器防御机制的参数化问题。

作者明确指出了局限性：

结果是基于模拟的；在部署前需要对 $HC_{first}$ （首次位翻转激活计数）随温度变化的特性进行硅片级表征。
线性温度模型源自 DDR4 数据，由于工艺变化，可能需要重新拟合才能推广到 DDR5。
该方法假设观测到的温度反映了实际的单元温度，因此在面对传感器欺骗或热操纵攻击时仍显脆弱，尽管片上传感器实现可以减轻这一问题。
该层并不解决非计数器类防御（如行交换）或特定的攻击模式（如 Blacksmith 或 ZenHammer），但预计它是与这些攻击正交的。

最终，这项工作定位为一种必要的运行时管理层，而非一种全新的防御手段，旨在确保基于计数器的防御参数在动态热条件下依然有效。

新的解决方案：一位聪明的、感知温度的教练

模拟结果显示了什么

局限性与未来

核心结论

技术摘要：动态 Rowhammer 阈值管理

类似论文