CPU 一直都不是完全可靠的，自问世以来就一直存在出现错误的风险。这些风险不仅来源于设计上的一些疏忽，也源于环境条件和会产生故障的物理系统。但这些错误往往很少见，如果系统按预期运行，则只有极少部分计算会出现错误。大多数情况下，计算机芯片被视为值得信赖的。
然而，最近谷歌和 Facebook 两大公司频繁检测到 CPU 出现一些「不当行为」，以至于他们正在敦促技术合作公司找到找出这些错误并补救的方法。
谷歌工程师 Peter Hochschild 在近日刚刚举办的 HotOS 2021 上说道：「生产团队抱怨『机器破坏数据』的情况越来越多。」他表示：「这些机器被指控破坏了多个不同的、稳定的、调试良好的大型应用程序。机器都被各个独立团队反复指责，并且这些指控是可信的。但传统的诊断方法没有发现它们有任何问题。」
开发者们更深入地查看了所涉及的代码和来自相关机器的操作遥测，谷歌工程师开始怀疑是硬件存在问题。他们调查发现硬件错误的发生率高于预期，这些问题在安装后很长时间内偶尔会出现，并且出现在特定的单个 CPU 内核上，而不是整个芯片或一系列部件上。
谷歌的研究人员检查了这些静默损坏执行错误 (corrupt execution error，CEE) 后得出结论：这些错误应该归咎于「易变的内核（mercurial core）」——CPU 在一些情况下偶尔会以一种无法预测的方式出现计算错误。
这些错误不是因为像 M1 芯片一样的架构设计失误，而且在制造测试期间也没有检测到这些问题。相反，谷歌工程师认为，之所以会出现错误，是因为我们已经将半导体制造推向了故障变得更加频繁的地步，而我们缺乏提前识别故障的工具。
在一篇名为《Cores that don’t count》的论文中，Hochschild 及其同事列举了计算机内核的不可靠性现在才受到关注的几个原因，包括大型服务器机群能够让罕见问题更加明显、开发者们近来才更加关注整体可靠性和降低软件错误率的相关改进。
论文地址：
https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s01-hochschild.pdf
但该研究表示有一个更根本的原因：「越来越小的特征尺寸越来越接近 CMOS 缩放的极限，并且架构设计的复杂性也在不断增加。」并指出现有的验证方法并不适用于发现偶尔出现的缺陷或部署后物理损坏的结果。
我们习惯于将计算机视为故障停止装置，尤其是执行指令的内核，而大多数系统软件都依赖于这种假设。随着芯片制造朝着更小的特征尺寸和更精细的计算结构发展，并且随着引入新的复杂指令集以提高性能，我们发现了在制造测试期间没有检测到的计算错误。这些缺陷不能总是通过微代码更新等技术来缓解，并且这些缺陷可能与处理器内的特定组件有关，允许小型代码更改可能会影响可靠性。更糟糕的是，这些错误通常是悄无声息的——唯一的变现就是出现计算错误。
这种「易变」的内核极为罕见，但在大量服务器中，我们则可以观察到它们造成的中断，甚至足以将它们视为一个明显的问题。这意味着需要硬件设计人员、处理器供应商和系统软件架构师之间合作解决这种缺陷问题。
此外，谷歌的研究者提出了一些缓解该问题的方法，例如识别和去除「易变」内核。
「易变」内核的识别具有挑战性，因为「易变」内核可能导致故障和数据损坏、而不当的识别可能会导致良好内核的浪费，并且识别过程的成本也很高。该研究对「易变」内核的识别过程进行了分类，包括：
自动化与人工；
部署前与部署后；
线下 vs. 线上；
基础设施级别与应用级别。
不过，识别和去除「易变」内核并不总是能避免影响应用程序，并且识别可能不是完美的。因此谷歌的研究者提议设计能够容忍 CEE 且没有过多开销的软件？这将从以下几点出发：
对特定于应用的机制施加一些负担，应用「端到端 Argument」设计思想，这种思想指出正确性通常最好是在端点而非较低级别的基础设施中进行检查。
系统应该支持高效的检查点，通过在不同的内核上重新启动，以将失败的计算重新恢复。
使用面向应用的成本高效检测方法来决定是继续通过检查点还是重试。例如，在提交之前计算数据库记录的不变量以确认机器是否损坏了数据。
Facebook 也发现了同样的问题
无独有偶，Facebook 也注意到了这些错误。今年 2 月，Facebook 发表了一篇名为《 Silent Data Corruptions at Scale 》的论文，论文中写到，与之前观察到的数据中心相比，静默数据损坏（SDC）正在成为一种更加普遍的现象。SDC 不能通过中央处理单元（CPU）中的错误报告机制捕获，因此无法在硬件级别上进行跟踪。但是，数据损坏在整个堆栈中传播，并表现为应用程序级问题。这些类型的错误可能导致数据丢失，并且可能需要数月的调试工程时间。
在本文中，研究者描述了导致 SDC 的硅制造过程中常见的缺陷类型。讨论了一个数据中心应用程序中静默数据损坏的真实示例。并提供了一个调试案例，以通过案例研究来跟踪 CPU 中的根本原因和对错误指令进行分类，以举例说明如何调试此类错误。研究者提供了缓解措施的高级概述，以减少大型生产团队中无提示数据损坏的风险。
论文虽然提出了缓解策略，但没有解决根本原因。
论文地址：
https://engineering.fb.com/2021/02/23/data-infrastructure/silent-data-corruption/
图 2 以图形形式显示了数据库的损坏和链接。
图 3 提供了一个高级调试流程，用于追踪导致根本原因的静默错误。损坏也会影响非零的计算。例如，在被识别为有缺陷的机器上执行了以下不正确的计算。研究发现计算会影响特定数据值的正负幂，并且在某些情况下，结果应该为零时却非零。以不同的精度获得了不正确的值。
错误示例
在谷歌的研究人员看来，Facebook 发现了静默错误，但是找出错误原因并解决它，还需要进一步的工作。
不正常的内核带来的风险不仅包括崩溃（现有的错误处理故障停止模型可以适应这种情况），还涉及错误计算和数据丢失，这些问题可能被忽视，带来风险。
Hochschild 讲述了一个例子，「我们的一个 mercurial cores 破坏了加密，只有它才能解密自己错误加密的内容。」谷歌的研究人员以「商业原因」拒绝透露其数据中心检测到的 CEE 率，但他们提供了一个大致的数字，即大约是每几千台机器有几个 mercurial cores，与 Facebook 报告的比率类似。
理想情况下，谷歌希望看到自动识别 mercurial cores 的方法，并建议在芯片的整个生产周期中进行 CPU 测试，而不是仅仅依赖于部署前的老化测试。目前，谷歌依赖于人工驱动的内核完整性审查，但这种方式并不是特别准确，识别可疑内核的工具和技术仍在进行中。
谷歌的研究人员解释说，「根据我们最近的经验，通过人工驱动审查发现的可疑性错误，大约有一半是被证实的，我们必须通过进一步的测试 (通常是在首先开发一种新的自动测试之后) 来提取『证据』」。另一半是虚假指控和有限的可复现性。
