필사 모드: 「x86 硬件后门」这句话的准确范围 —— 按作者写下的样子来读 rosenbridge

• 引言 —— 标题与正文之间的距离
• rosenbridge 究竟是什么
• 作者自己划下的四条边界线
• 为什么必须与 ME 或 PSP 分开来谈
• 是怎么找到的 —— 在没有文档的情况下探索指令集这个问题
• sandsifter 扫描实际会找出什么
• 方法可以一般化，发现不能
• 实务者可以从这里带走什么
• 参考资料

引言 —— 标题与正文之间的距离

有一个叫 xoreaxeaxeax/rosenbridge 的 GitHub 仓库。它的简介只有一行：「Hardware backdoors in x86 CPUs.」星标超过 2,500，并且会周期性地重新爬回社区首页。

只看这个标题就得出「我的 CPU 里有后门」的结论，是很自然的事。可要是把同一个仓库的 README 从头读到尾，情况就相当不一样了。

本文首先把那份文档从头到尾读一遍，准确地搬出作者自己划下的那条边界线。之后再来谈，这项研究里真正被一般化的东西是什么。

先把日期交代清楚。按 GitHub API，这个仓库创建于 2018 年 8 月 9 日，最后一次提交是 2018 年 10 月 12 日。这不是 2026 年的新发布，而是 2018 年的研究。 看起来是同一位作者在 2026 年 8 月新上传了其他仓库，才让整个个人主页一起被重新关注。

rosenbridge 究竟是什么

README 所描述的结构是这样的。

在主 x86 核心旁边，还藏着一个小型的非 x86 核心。这个核心由模型特定寄存器里的一个控制位来启用，之后通过一条被称为「launch-instruction」的指令切换过去。切换之后，它会接收并执行包裹在特殊格式 x86 指令里的命令，作者把这套命令集称为 DEIS（deeply embedded instruction set）。

这个核心执行的指令绕过全部内存保护与特权检查。因此 ring 3，也就是普通用户程序，可以自由读写 ring 0 的内核数据。

按理说，启用这项功能需要内核权限。可 README 写道，在某些系统上观察到它默认就是启用的。在那种情况下，没有权限的代码可以直接修改内核。

到这里为止是已确认的机制。仓库里还附带了支撑这些结论的工具：DEIS 用的汇编器、提权的概念验证、通过 MSR 关闭后门的启动脚本，以及研究中使用的那些 fuzzer。

作者自己划下的四条边界线

README 里有好几句话都在收窄这个发现的范围，值得引用。

第一，影响范围。「据信受此问题影响的只有 VIA C3 CPU。」VIA 的 C 系列面向工业自动化、POS、ATM、医疗硬件，以及部分消费级台式机与笔记本销售。

第二，世代。「此漏洞的范围是有限的。C3 之后世代的 CPU 已不再具备这项功能。」

第三，意图。 免责声明里是这么写的：VIA 的处理器以在低功耗与嵌入式设计上的出色表现著称，此处所描述的功能被认为是作为面向嵌入式市场的一项有用功能、出于善意而制作的，只是在早期部分世代中被无意地保留为启用状态。并且明确写着「不含恶意的意味」。

第四，工具的局限。 检测工具处于 alpha 状态，只应在裸机上运行，并警告它「可能让并不存在后门的系统崩溃、触发内核 panic 或者卡死」。而且关键的是，文中写道，由于这些工具是以特定处理器系列和核心为前提设计的，只要后门与被研究的形态稍有变化，就会被漏掉。

作者本人这样界定这项工作的性质：它是作为一份案例研究兼思想实验发布的，用来展示在日益复杂的处理器中后门是如何可能产生的，以及研究者与最终用户可以如何识别这类功能。

把这四点拿掉、只让标题流传出去，是让这项研究变得不准确的最常见方式。

为什么必须与 ME 或 PSP 分开来谈

README 里有一处有趣的对比。rosenbridge 与 Intel Management Engine 或 AMD Platform Security Processor 这些公开已知的 x86 协处理器完全无关，而且比任何已知的协处理器嵌得都更深。因为它不仅能访问 CPU 的全部内存，还能触及寄存器堆与执行流水线。

这个区分之所以重要，是因为威胁模型不同。

ME 和 PSP 是独立的处理器。它们运行自己的固件、访问系统内存，但并不处在主核心的执行流水线之内。相应的应对方式也随之不同：讨论的是固件版本管理、阻断网络访问，以及在部分环境中尝试将其禁用。

rosenbridge 描述的东西不一样。它是在正在执行的指令流之内切换过去，并在同一条流水线上跳过特权检查。从软件的视角看，它更接近于一条指令突然有了另一种含义。

把这两者笼统地归为「CPU 里的隐藏核心」，应对方式也会跟着一起笼统化。实际上它们是完全不同层面的问题，针对其中一个的应对，对另一个完全不起作用。

是怎么找到的 —— 在没有文档的情况下探索指令集这个问题

现在进入这项研究里真正会被一般化的部分：它是怎么找到的。

从外部去探索 x86 指令集，比想象中要难。原因有几个。

指令是变长的。有 1 字节的，也有 15 字节的。所以「把所有指令列举出来」这个要求没有标准答案。字节组合的空间是天文数字，也不可能硬着头皮穷举。

未文档化的指令按定义就没有可查的表。反汇编器是以手册为依据做出来的，所以对手册里没有的东西，反汇编器同样一无所知。

而且执行了错误的字节，程序就会死掉，或者系统卡住。

作者的工具 sandsifter 解的就是这个问题。用 README 的说法，它「通过系统性地生成机器码来搜索处理器的指令集，并在执行过程中监视异常，从而审计 x86 处理器中隐藏的指令与硬件缺陷」。

核心在于寻找不一致。把处理器实际的解释方式与参照用反汇编器的解释方式作比较，收集两个答案分歧的地方。这不是靠人读手册去猜，而是自动收集两台机器之间的意见分歧。

sandsifter 扫描实际会找出什么

这个工具对结果的描述相当务实，值得引用。

基础审计是这样运行的。

sudo ./sifter.py --unk --dis --len --sync --tick -- -P1 -t

按 README 的说法，一次扫描视处理器的速度与复杂度而定，需要几小时到几天。跑完之后再运行汇总工具。

./summarize.py data/log

而重要的是这里，README 写道：「通常在你的处理器上会发现数以百万计的未文档化指令，但它们大体上会归入少数几个组。」

意思是不必被「数百万」这个数字吓到。汇总工具会把异常现象聚成组，然后尝试把它们分成三类。

• 软件缺陷 —— 虚拟机监视器或反汇编器的缺陷
• 硬件缺陷 —— CPU 自身的缺陷
• 未文档化指令 —— 处理器中确实存在、但厂商不予承认的指令

README 也明确写到，有些情况自动分类很困难，可能需要人工分析。

成果清单也原样搬过来。文中写道，这个工具找到了「来自所有主要厂商的秘密处理器指令，广泛存在于反汇编器、汇编器与模拟器中的软件缺陷，企业级虚拟机监视器中的缺陷，以及 x86 芯片中良性的和安全上至关重要的硬件缺陷」。

方法可以一般化，发现不能

把这两句并排放在一起，就清楚该如何对待这项研究了。

发现是窄的。 VIA C3、2018 年、之后的世代没有、推定不含恶意。今天你的笔记本或服务器 CPU 里存在这东西的可能性实际上为零。如果你还在运行装着 VIA C3 的工业设备，那另当别论，但那种情况下它多半因为别的理由也早该换掉了。

方法是宽的。「面对没有文档的接口时，摆上两个独立的解释器，自动收集它们意见分歧的地方」这套路子，并不只用在处理器上。

同样的结构也适用于这些地方。

• 找出两个解析器对同一份输入解释不同的地方（这是请求走私与反序列化漏洞的源头）
• 找出客户端与服务端对同一条协议消息解释不同的地方
• 找出编译器与解释器对同一份源码处理不同的地方
• 用同一份输入运行两个不同实现并比较结果的差分模糊测试总体

近期的例子是用 Rust 重新实现 PostgreSQL 的 pgrust 项目。它用同一份输入分别运行原版与重新实现，找出行为分歧的地方，而据仓库文档所述，在这个过程中甚至发现了原版 PostgreSQL 那边的缺陷。有一个参考实现，就等于有一个免费的 oracle，而这在模糊测试里是最值钱的资产。

实务者可以从这里带走什么

归纳一下。

第一，仓库简介与 README 正文的范围可能不同。 在安全研究里，标题讲的是发现的范畴，正文讲的是发现的范围。引用的时候，应该引用正文。

第二，不要把研究者本人加上的限定删掉。 rosenbridge 的免责声明，是作者亲手写下的「不含恶意的意味」。把这句话去掉再去引用，等于替研究者说了他没说过的话。

第三，把工具的检测局限一并读进去。 rosenbridge 的检测工具明确写着「只要与被研究的形态稍有变化就会漏掉」。这不是这个工具独有的问题，而是基于特征签名的检测的普遍性质。你在用的扫描器也有同样的局限，只是它通常不会这么写出来。

第四，确认缓解措施的有效范围。 README 在提供那份「启动时操作 MSR 关闭后门」的脚本的同时写道：「即便应用了它，拥有内核权限的攻击者仍然可以把它重新打开。」大多数缓解措施都是这个形状：它们只在特定的攻击者能力之下有效，超出那个能力就失效。如果你不知道它在哪种威胁模型下有效，也就无从知道它对你是否有效。

硬件信任是一个真实的问题，而这类研究把这个问题变成了可以讨论的形式。也正因如此，它更值得被准确地引用。

参考资料

• xoreaxeaxeax/rosenbridge — GitHub（2018 年 8 月创建，2018 年 10 月最后一次提交。正文中的引用全部搬自 README）
• xoreaxeaxeax/sandsifter — the x86 processor fuzzer
• Breaking the x86 ISA — Christopher Domas 白皮书（位于 sandsifter 仓库内）

rosenbridge 的检测工具与 sandsifter 的扫描，我都没有亲自运行过。这两个工具都要求在裸机上执行，并且都警告可能让系统卡死。正文中关于运行机制的说明，全部来自仓库文档中所写的内容。