从行锤现象看数据背后的物理安全

JED 2026年8月号｜《数据之下的电荷》资料深读

程序拥有正确的访问权限，是否就意味着它处理的数据一定可靠？如果一次计算背后的存储状态发生变化，或者设备工作时产生的非预期信号带出信息，软件界面上的安全边界便需要更仔细地解释。

JED 2026年8月号刊登了布赖恩·尼尔森的《数据之下的电荷》。本文从行锤、GPU显存和泄密发射三个入口，讨论数字系统的物理安全条件；同时核对原刊中的时间、术语与案例适用范围。以下工程分析为资料深读与编辑解读，不构成对某一产品或部署环境的测试结论。

从软件边界看到物理实现

图1　软件中的安全承诺依赖物理实现。编辑自绘概念图；箭头表示依赖与验证关系，不表示攻击路径。

我们习惯用账户、进程、虚拟机和网络来描述计算机的安全边界。这些概念十分必要，也确实约束着正常的数据访问。但最终保存一个权限标志、一次计算结果或一段模型权重的，仍然是器件中的物理状态。软件对数据的解释建立在一个基础假设上：底层会按约定保存并交付这些状态。

只要这个假设出现偏差，上层程序即使按照原定逻辑运行，也可能处理错误的数据。这里包含两类不同问题：一类是信息通过预期接口之外的物理现象泄露出去，另一类是电气扰动使存储内容或计算过程发生变化。前者首先关系到保密性，后者首先关系到完整性，后续影响才可能扩展到系统权限与可用性。

尼尔森把这些问题放进电子战读者熟悉的电磁视角，目的在于提醒大家，数字系统不能脱离物理载体来讨论。这个联系有启发性，但也要守住分类边界：行锤现象通常从系统内部的存储访问引出电气扰动，不能因此把每次内存故障都解释成来自外部的无线电攻击。

一个比特怎样离开原来的状态

动态随机存取存储器，即DRAM，用存储单元中的电荷状态表示数据。电荷不会永远保持不变，因此器件需要刷新。对使用者来说，一次读写是离散而明确的操作；对芯片来说，它还涉及电压变化、访问线路、感应与恢复等连续物理过程。数字抽象简化了开发，却没有取消这些过程。

行锤，英文称Rowhammer，是原文的核心例子。特定存储访问活动可能使邻近单元受到扰动，最终出现比特翻转。我们在这里关心的机制是：一个单元的活动能够影响另一个单元的状态，而这种影响可能不通过软件允许的写入接口。这使可靠性问题与安全边界产生了联系。

不过，比特翻转与成功攻击之间还隔着多层条件。翻转是否发生、影响什么数据、能否被发现或纠正、是否足以改变程序行为，都取决于具体器件和系统。把“出现物理扰动”直接写成“取得任意权限”，就跳过了最关键的验证环节；反过来，认为它只是偶发硬件故障，也可能漏掉有意诱发的风险。

可以把这理解为“按地址访问”的抽象与芯片实际行为之间出现了偏差。操作系统能够规定哪个进程拥有某块内存，却不能凭一项地址权限直接消除器件内部的耦合。因此，可靠的系统边界需要硬件行为满足软件的假设。这种上下层相互依赖，是理解该问题比记住攻击名称更重要的部分。

研究证据需要保留时间坐标

原文从早期行锤研究讲到较新的中央处理器与图形处理器平台案例，试图说明问题会随硬件和防护演进继续变化。阅读这样的历史线索，最有价值的是比较研究究竟推翻了哪项原有假设，而不是把不同平台、不同设置的结果简单串成一条“所有防护都失效”的直线。

这里先校正一处原刊日期。文中把Google Project Zero公开两项行锤权限提升演示的时间写为2025年3月。Google原文发布于2015年3月9日，应按2015年理解。[2] 这相差的十年很重要：它关系到读者如何判断一个风险是刚刚发现，还是已经经过多轮研究、缓解与重新评估。

历史演示说明某些生产硬件上的物理故障能够影响软件安全边界，但演示本身不能代表全部设备。阅读论文时，我们至少要同时记住研究对象、配置条件和证明的结果。设备名称相近、内存代际相同，甚至同一产品家族，都不足以代替对实际配置的确认。

防护为何需要持续验证

原文列出了目标行刷新等多种缓解思路。目标行刷新通常简称TRR，核心想法是发现有风险的存储访问活动，并采取额外刷新等措施，降低相邻单元发生错误的机会。这种思路承认了物理扰动的存在，也说明防护往往是在有限资源下识别和处理异常活动。

困难在于，保护机制依据某种内部模型工作，而实际访问活动与器件行为可能比模型更复杂。后续研究找到保护覆盖不到的情况，说明原有的判断规则或实现需要修正。它不能自动证明这项机制在任何条件下都毫无价值，也不能证明所有采用相同缩写的产品具有完全相同的内部实现。

对工程团队来说，“支持某项防护”与“在当前配置下覆盖当前威胁”是两种不同陈述。前者是功能说明，后者需要厂商公告、配置记录和适用范围共同支撑。只问芯片属于哪一代，得到的信息还不够；同样，只看到一项绕过研究就宣布整条产品路线失去意义，也会妨碍合理的风险排序。

刷新也有工程成本。更积极地维持存储状态，意味着要在器件活动、功耗和可用访问时间之间做平衡，具体影响随实现而变。因此，不能脱离厂商支持范围，把“刷新越多越安全”当作无限适用的调节原则。合理的保护应有适用条件，也应说明系统承担了什么代价。

DDR5案例的正确读法

原文重点介绍了Phoenix研究，并用很醒目的时间数字描述演示结果。公开研究材料说明，研究者在所测试的15条SK海力士DDR5内存模组上观察到了相关问题。[3] 这项结果足以反驳“换用DDR5便自然排除了行锤风险”的想当然判断，但其证据边界仍然是研究中的样品、平台和实验条件。

从一组样品上的成功演示，走到某台服务器的实际风险评估，还要补充器件信息、固件版本、防护状态与业务暴露条件。演示耗时可以帮助理解研究成果，却不应被当作任何机器都会遵循的攻击计时器。省略条件后只保留醒目的数字，会把实验事实变成无法兑现的普遍预测。

同样，某项测试没有观察到错误，也不是器件永远不会出错的证明。它说明在已覆盖的条件下没有得到该结果。我们需要的是可以追溯的覆盖范围，而不是“测过了”三个字。正面结果和负面结果都应配套说明测试对象，这一点对厂商验收、科研阅读和日常运维同样适用。

GPU与模型完整性

GPU是图形处理器，也是许多人工智能计算的执行平台。GPUHammer研究把行锤问题带到了特定GPU显存环境。研究团队在NVIDIA A6000及其GDDR6显存上展示了概念验证，特定条件下的比特翻转使所测试模型的准确率显著下降。[4] 原文用“assurance”描述这一指标，导读采用研究材料中的“准确率”，避免把它误解成一般性的安全保证。

这项研究令人关注，是因为模型参数与中间数据同样依赖硬件存储。模型文件正确、训练过程合规，并不单独保证每一次运行都使用了正确的数据状态。但“一个比特可能很重要”也不能扩写成“任意一个比特都会毁掉任何模型”。数据的位置、数值表示、使用方式与容错能力不同，后果可能相差很大。

从防御角度，我们更应关注异常是否可见。程序继续返回格式正常的结果，并不证明内容正确；出现一次输出异常，也不证明遭遇了硬件攻击。业务指标、输入变化、软件版本和硬件告警需要一起检查。原文关于人工智能的提醒，应落在运行完整性的证据上，而不是用一个实验结果替代对全部人工智能系统的判断。

对于使用人工智能处理技术资料的团队，可以把运行完整性理解为质量链的一环：输入材料、模型版本、软件环境和执行硬件共同影响输出。每一环都需要有自己的核对方法。重新运行得到相同结果只能提供某一方面的线索，不能单凭这一点就证明数据从存储到计算的每个环节都没有问题。

纠错能力必须落实到层级

纠错码通常简称ECC。讨论它时，首先要说明保护发生在哪里。器件内部的片上纠错与系统级纠错覆盖的环节、可见信息和部署方式并不相同。只看到规格表中出现“ECC”三个字，就断言整条数据路径受到同等保护，容易把不同层级的能力混为一谈。

NVIDIA针对GPUHammer的2025年安全说明指出，启用系统级ECC能够缓解该研究所演示的问题，并区分了片上ECC与系统级ECC。[5] 因此，不能把其他平台上的某些纠错绕过研究直接移植到这个案例，得出“厂商建议必然无效”的结论。这里需要保留具体平台、具体设置与具体问题之间的对应关系。

工程取舍则是另一层问题。纠错、防护和监测可能伴随容量、性能、成本或运维复杂度的变化，实际代价需要以平台资料与测量为准。把保护功能关闭后得到的吞吐率，与开启保护后的系统承诺放在一起比较，评价对象就已经变了。采购和验收应记录功能是否启用，而不只记录硬件是否具备这项功能。

还要区分纠正错误、报告错误和根本没有观察到错误。一个事件被纠正，意味着某种机制发挥了作用；出现无法纠正的事件，则需要按平台规定处理。缺少告警可能源于没有出错，也可能与观测覆盖有关。评估时应了解告警代表什么，不应把一个安静的仪表盘直接当作完整性的证明。

泄密发射关注信息向外流动

图2　泄密发射与物理故障对应不同的首要安全目标。编辑自绘概念图；两类后果可能交织，不能仅凭异常表现进行归因。

接下来，原文把视角从内存扰动扩展到TEMPEST相关防护，即围绕信息处理设备泄密发射开展的研究与控制。NIST术语表对泄密发射的定义强调：非有意产生的信号经过截获和分析后，可能暴露系统传输、接收或处理的信息。[6] 关键在于信号与信息之间的关系，并非一切电磁辐射都具有同样的泄密价值。

对通信和雷达工程师来说，设备产生杂散、线路之间存在耦合并不陌生。但是，从“能够测到某种信号”到“能够恢复有用信息”，中间还有信噪比、环境、设备结构与信息关联等条件。原刊罗列的公开演示有助于说明研究方向，不宜把不同年代、不同设备的距离或器材成本拼成一套通用能力指标。

这也解释了保密性与抗干扰能力为何不能完全互相替代。设备工作正常，仍可能存在信息泄露；设备受到干扰而出错，也不一定泄露了原来的信息。在需求讨论中，先把要防止的后果说清楚，后续才知道是在评估非预期信息通道，还是评估计算和存储是否维持正确状态。

电磁兼容设计与信息保密防护也有相互联系但不完全相同的目标。前者通常关注设备之间能否按规定共存和正常工作，后者还关心非预期信号是否与敏感信息关联。某项电磁兼容测试合格，应按该测试的项目和限值解释，不能被扩写成对一切泄密风险的认证。

隔离不能只画在网络拓扑上

原文引用红黑隔离概念，提醒读者注意不同信息域在物理实现上的关系。NIST术语表中的RED/BLACK概念，涉及处理机密明文信息的电路、部件、设备和系统，与处理非机密信息的相应设施之间的分离。[7] 它讨论的是电信号及其载体，因而会触及布线、设备配置与安装环境。

原刊给出了统一的三英尺间距说法，这里不把它当成可直接套用的通用工程要求。真实项目应依据适用的规范、设备认证条件和安装设计确定措施。单一距离不能代替对耦合路径、屏蔽、滤波与系统边界的整体判断；把一个背景条件不明的数值写进项目要求，可能制造虚假的确定感。

对一般读者，较有用的启发是审视边界在哪里实现。网络图中的两台设备没有连线，只能说明图上没有定义逻辑连接，不能证明任何物理影响都已被排除。相应地，也不能因为设备摆得近，就推断其间必然存在可用的信息通道。识别潜在路径与证明路径可被利用，是两项需要不同证据的工作。

共享计算中的责任接口

原文把虚拟化、容器和共享GPU放在同一讨论背景下，原因是这些使用方式可能让不同工作负载依赖同一批物理资源。逻辑隔离负责规定资源如何分配、谁可以访问什么；硬件及其防护机制则负责支撑这些约定。两者共同构成实际边界，其中一层的承诺不能自动证明另一层已经得到验证。

但“共享硬件”并不等于“任何租户都能跨越隔离”。具体风险还取决于硬件是否存在相关弱点、工作负载能获得何种资源，以及平台采用了哪些约束和缓解。把这些条件删除，会将需要专业评估的风险写成云平台的必然属性，也无法帮助用户比较不同服务的实际保护能力。

企业能够向服务方提出的是可回答的问题：相关公告是否覆盖所用平台，保护功能由谁配置，异常由谁监测，硬件更换或固件变更怎样通知使用者。用户未必能直接观察底层器件，所以责任与证据的交接尤其重要。采购文件中的安全名词，应能对应到服务能力和可核对的维护记录。

责任交接最好对应具体状态。服务方提供了保护能力，使用方是否选择了相应配置；硬件发生维护更换后，原有设置是否仍然成立；异常通知到达后，谁决定暂停或复核业务。把这些接口写清，比笼统要求“保障物理安全”更容易验收，也更容易在出现问题时追溯实际条件。

算法安全与实现安全

原刊还把物理故障与密码实现联系起来，用于说明数学设计之外仍有实现问题。这里最需要区分的是两种判断：算法在既定计算模型和假设下是否安全，承载算法的具体设备是否正确执行并妥善保护中间状态。后者发生问题，并不能不加说明地改写成前者的数学基础已经被推翻。

例如，某个实现受到异常数据或故障影响，可能改变它原本应执行的计算。这提醒开发者与系统集成者关注执行环境，却不能据此把整个密码家族概括为“不再安全”。同样，算法能够抵抗某一类计算威胁，也不是对存储错误、泄漏与所有物理扰动的一份总保证书。

这种区分适用于比密码更广的场景。数字信号处理算法的推导成立，不意味着输入一定正确；模型的离线验证通过，不意味着运行期状态永远可靠。工程人员需要把“方法本身的条件”与“实现满足这些条件的证据”分别列清，再检查两者是否在同一配置与同一时间范围内成立。

把风险写成可以核查的事项

如果把原文压缩成一张工程问题单，第一项应是设备与配置的可识别性。只有知道自己使用的是什么、当前启用了什么、受哪份公告约束，后续评估才有对象。相同采购名称下的器件或配置发生变化后，沿用旧结论也需要重新确认，而不是把一次验收结果视为永久属性。

第二项是保护目标。涉及完整性时，应说明希望发现或纠正哪类异常，以及异常出现后业务怎样处理；涉及保密性时，应说明哪些信息域需要隔离、哪些设备和线路属于边界。这样，软件、硬件、运维与设施人员才能讨论同一个对象，而不是分别拿出一份看似完整却互不衔接的检查表。

第三项是验证与变更之间的关系。更新固件、替换内存、调整虚拟化配置或移动设备，都可能改变原先依赖的条件。这里不需要预设每次变化都会产生漏洞，但应明确哪些变化会触发复核，以及谁负责保存依据。安全结论和工程图纸一样，都需要版本，而不能只留下一句“已完成加固”。

异常归因需要多种证据

原文强调，有意诱发的比特错误可能与普通硬件故障表现相似。这个提醒对事件响应很有价值：发现数据损坏时，不宜只在应用程序层面寻找原因。但相似表现同时意味着归因困难，不能把一次纠错告警、一次程序崩溃或一次模型输出偏差直接认定为外部行动。

较稳妥的做法，是把硬件事件、工作负载变化、配置变更与业务异常放在同一时间线上，先确认事实是否相关，再讨论可能的原因。出现错误的频率和环境是否改变，能否在维护条件下复现，厂商是否已有对应公告，这些线索比先选定一个吸引人的攻击名称更能推动问题解决。

对于原刊关于秘密行动的推测，导读也应停在证据能支持的位置。公开资料没有记录某类行动，不足以证明它从未发生；同样，这种缺乏记录也不能用来证明它正在普遍发生。把已公开验证的技术能力、合理的风险推断和未经证实的使用情况分开，才能保持讨论的专业性。

让物理条件进入系统承诺

这篇文章真正适合带回项目评审的，是一个跨专业的检查习惯：当系统承诺数据隔离、结果正确或信息保密时，追问这项承诺依赖哪些物理条件。答案可能涉及内存保护，也可能涉及安装环境、运行配置和维护责任；它通常不会只藏在某一个安全软件的功能清单中。

防护强度仍需围绕业务后果和威胁条件选择。对某些任务，已有的厂商缓解、告警和规范维护能够构成合理基础；对更敏感的环境，则可能需要更明确的资源隔离和专业物理安全评估。判断应由证据和需求推动，既不把研究演示忽略成学术趣闻，也不把它放大成所有系统都已失守。

数据以数字形式被理解，以物理状态被保存和传递。把这两句话同时放进工程讨论，才能读懂《数据之下的电荷》的价值，也能识别其中需要校正或限定的表述。下一次检查安全边界时，除了画清账户与网络，也把承载边界的器件、配置和验证依据写清楚。

资料来源与说明

[1] Bryan Neilson. The Charge Beneath Your Data. JED，2026年8月号，第29—32页。本文主来源；原刊无配图，本文两图为编辑自绘。

[2] Google Project Zero. Exploiting the DRAM rowhammer bug to gain kernel privileges，2015年3月9日。用于核对原刊误写的发布日期。

[3] ETH Zurich COMSEC. Phoenix: Rowhammer Attacks on DDR5 with Self-Correcting Synchronization，2025年研究项目材料。用于核对受测样品范围。

[4] University of Toronto. GPUHammer研究项目与论文说明，USENIX Security 2025。用于核对平台、准确率指标及概念验证条件。

[5] NVIDIA. Security Notice: RowHammer，2025年7月10日发布。用于核对系统级ECC缓解建议与纠错层级。

[6] NIST CSRC Glossary. Compromising emanations术语条目；来源标注CNSSI 4009-2022。

[7] NIST CSRC Glossary. RED/BLACK concept术语条目；来源标注CNSSI 4009-2022。外部资料核验日期：2026年9月19日。