x86 CPU 里真的有硬件后门：10 个要点看懂 rosenbridge
x86 CPU 里真的有硬件后门：10 个要点看懂 rosenbridge
"这个后门允许 ring 3（用户态）代码绕过处理器保护，自由读写 ring 0（内核）数据。" —— project:rosenbridge README
八年前的今天，2018 年 8 月 9 日，Christopher Domas 在 GitHub 上推了一个仓库的第一次提交，标题只有一行：Hardware backdoors in x86 CPUs。
那一周他在 Black Hat 上讲了同一件事。八年过去，这个仓库还在，2500 多颗星，README 一个字没改。它至今仍是唯一一个被完整公开、可复现、附带检测和关闭工具的 x86 硬件后门。
这篇文章把它拆开讲清楚：后门具体长什么样、三行汇编怎么捅穿内核、它影响谁、为什么它跟 Spectre 是两个物种、以及为什么它根本没有真正的补丁。
最后一条留给同一周的另一条新闻 —— x86 刚刚在能效上做了一件八年前没人相信的事。
先说结论：这件事比标题小得多，也比标题可怕得多。
1. 后门是真的，但它不在你的 Intel 上
"据信只有 VIA C3 CPU 受此问题影响。"
先把最容易被标题党糟蹋的一句话放在最前面。
rosenbridge 影响的是 VIA C3，一颗 2000 年代初期的 x86 兼容处理器。不是 Intel，不是 AMD，也不是所有 x86。README 还补了一句：C3 之后的世代已经不再包含这个特性。
所以如果你现在打开任务管理器看到 Core 或 Ryzen，这件事跟你手上这台机器没有直接关系。
My take: 但"跟你没关系"和"不重要"是两回事。rosenbridge 的价值从来不是它的影响面，而是它证明了一件此前只停留在推测里的事 —— 一颗量产、上市、卖了几百万片的 x86 处理器，确实可以在没有任何公开文档的情况下，带着一条通往内核的暗门出厂。 从"理论上可能"到"这是它的 MSR 地址"，这中间隔着的就是这个仓库。
2. 它不是 bug，是第二颗 CPU
"rosenbridge 后门是一颗嵌在主 x86 核旁边的、小型的非 x86 核心。"
这是整件事最容易被读漏的一句，也是它跟 Spectre/Meltdown 的分水岭。
Spectre 和 Meltdown 是优化的副作用。分支预测和乱序执行本身是正当设计，只是没人想到能从缓存时序里把秘密捞出来。那是设计缺陷，是"我们没想到"。
rosenbridge 不是。它是一颗被有意加进去的、独立的、指令集完全不同的 RISC 核，和 x86 核并排躺在同一块硅上。它有自己的一套指令，Domas 管它叫 deeply embedded instruction set（DEIS）。它不是失误的产物，它是一个功能。
My take: 分类学在这里不是学术洁癖。缺陷可以靠更谨慎的设计消除，功能不行 —— 功能是有人要它在那儿。这两者的修复路径、责任归属、以及你该有的信任姿态，完全不同。
3. 三行汇编，捅穿 ring 0
技术细节比传闻精确得多，全部在仓库源码里，可以逐字核对：
第一步 —— 开锁。 MSR 0x1107 的 bit 0。往这个位写 1，暗门解锁：
#define BACKDOOR_MSR 0x00001107
#define BACKDOOR_TOGGLE 0x00000001
第二步 —— 启动。 一条没有出现在任何 x86 手册里的两字节指令 0f 3f：
movl $_bridge, %eax
.byte 0x0f, 0x3f
eax 里放的是要交给隐藏核执行的命令地址，0f 3f 是那声"开门"。
第三步 —— 执行。 隐藏核接过命令，绕过全部内存保护和权限检查。
就这些。没有堆喷，没有 ROP 链，没有竞态窗口。三行。
My take: 大多数内核提权漏洞是一场需要精确编排的杂技。这个不是。这个更像用钥匙开门 —— 因为它本来就是一把钥匙。
4. 最要命的一句：某些系统上默认是开的
"虽然后门通常处于禁用状态（需要 ring 0 权限才能启用），但我们发现在某些系统上它是默认启用的。"
README 里这句话用了斜体强调，理由充分。
理论上第一步（写 MSR）需要内核权限，那这个后门就只是"已经拿到内核权限的人再拿一次内核权限"，价值有限。但在某些出厂机器上，那个位本来就是 1。
意思是：任意一段无权限的用户态代码，跳过第一步，直接执行第二步，就能改写内核。
My take: 安全模型里最贵的不是墙有多厚，而是门有没有被人顺手别上一块砖。这不是"后门存在"的问题，这是"后门开着"的问题 —— 前者是能力，后者是事故。
5. 它比 ME 和 PSP 藏得更深
"它与 x86 CPU 上其他公开已知的协处理器（如管理引擎或平台安全处理器）完全不同；它嵌入得比任何已知协处理器都更深 —— 它不仅能访问 CPU 的全部内存，还能访问其寄存器文件和执行流水线。"
Intel ME 和 AMD PSP 已经够让人不舒服了：一颗你关不掉、看不见、跑着自己固件的小核。但它们至少是旁边的芯片 —— 通过总线访问内存，边界清晰。
rosenbridge 在里面。寄存器文件和执行流水线都在它的射程内。这不是一个能偷看你内存的邻居，这是一个能改写你思考过程的东西。
My take: 这句话是整个 README 里最该被记住的技术判断。它重新定义了"最深的信任边界在哪"这个问题的答案 —— 不在操作系统，不在 hypervisor，不在固件，而在你根本无从检视的那一层。
6. 它是被穷举出来的
后门本身很惊人，但方法论更值钱。
Domas 用的是他自己写的 sandsifter —— 一个 x86 指令模糊测试器。思路粗暴但有效：穷举指令空间，把每一种字节组合都喂给 CPU，看哪些不该存在的东西居然执行了。
仓库里还有配套的一整条流水线：wrap（精简版 fuzzer，专门找那条通往隐藏核的桥接指令）、kern（监控内核内存和寄存器的变化）、proc（从 fuzzing 日志里归类 DEIS 指令的行为）、manager（把 fuzzing 任务分发到一整个机器集群）。
隐藏指令不会自己招供。你只能靠"执行了几百万条垃圾字节，然后看谁的内核动了"来把它逼出来。
My take: 这才是这个项目留给行业的真正遗产。结论是一颗停产的老 CPU，方法是任何人都可以对任何 CPU 重跑一遍。README 自己也这么说：这是"更深层处理器漏洞研究的起点"。
7. 作者自己说：这不是恶意
"VIA 处理器以低功耗和优秀的嵌入式设计著称；我们相信所描述的功能是出于善意创建的、面向嵌入式市场的有用特性，只是在某些早期世代的处理器上被无意地保留为启用状态。不暗示任何恶意。"
这段免责声明经常被跳过，但它其实是全文最有信息量的部分之一。
Domas 的判断是：这大概率不是间谍机关的杰作，而是一个给嵌入式客户用的调试/优化特性，出厂时忘了关。
My take: 这个解释比阴谋论更让人不安，不是更少。因为阴谋需要动机、需要授权、需要有人签字；而"忘了关"只需要一个人在流片前漏掉一行。前者稀有，后者每天都在发生。你不需要一个坏人来得到一个硬件后门，你只需要一条足够长的产品线和一次足够普通的疏忽。
8. 受影响的机器，可能还在你楼下运行
README 里那句关于市场定位的话值得逐字读：
"C 系列处理器主要面向工业自动化、POS 终端、ATM 和医疗设备硬件，以及各类消费级台式机和笔记本电脑。"
看这个清单。工控、收银、取款机、医疗。这四类设备有一个共同点：服役周期极长。消费级笔记本三五年就换了，一台 ATM 或者一条产线的控制器跑十五到二十年是常态。
VIA C3 是 2000 年代的产品。后续世代已经移除了这个特性。但"新芯片没有"从来不等于"旧机器不在跑"。
My take: 这是硬件安全和软件安全最本质的时间尺度差异。一个软件 CVE 的生命周期以月计，一个硅上的问题以十年计 —— 而且不随你打不打补丁而改变，只随设备报废而结束。
9. 硬件后门没有真正的补丁
仓库里提供了修复方案：在启动早期跑一个脚本，把 MSR 0x1107 的那个位清零、锁上。
但 README 紧接着写了这句：
"注意，即便如此，拥有内核级访问权限的攻击者仍然可以重新启用该后门。"
这就是硬件后门的天花板。你能做的只是在每次开机时把门重新关上。门本身还在墙里，铰链还在，钥匙孔还在。任何一次拿到内核权限的人，都可以再把它拧开。
而且 README 还诚实地标注了检测工具的局限：它处于 alpha 状态，必须在裸机上跑（虚拟机里不行），在没有后门的系统上可能导致崩溃、panic 或死机；更关键的是 —— 如果后门相比被研究的形态哪怕有一点改动，工具就会漏掉它。
My take: "打了补丁"在这里是一个语言陷阱。软件补丁是把洞补上，硬件"补丁"是每天早上去检查一下门锁没被人拧开。这两件事叫同一个名字，但它们提供的保证完全不在一个量级。
10. 同一周的另一半故事：x86 刚刚在能效上翻了盘
八年后的这一周，x86 还上了另一条新闻，方向完全相反。
Jeff Geerling 用 HPL Linpack（就是 Top500 超算榜用的那个基准）实测了两台笔记本，Hackaday 转载时用了一个不太克制的标题：
"标题叫《Intel 刚刚追平了 Apple Silicon。认真的。》……但正如我们对 Jeff 的预期，他把 MacBook Neo 和戴尔最新 XPS 13 的基准数据都放上了 GitHub 来支撑这个说法。"
数字在这儿：
| 机器 | 性能 | 功耗 | 能效 |
|---|---|---|---|
| MacBook Neo | 57.012 Gflops | 10.6W | 5.38 Gflops/W |
| Dell XPS 13（Core 5 320） | 127.91 Gflops | 20.6W | 6.21 Gflops/W |
x86 这台不但赢了，还赢了 M4 和 M3 的 Mac Studio，只输给 M4 Mac Mini 的 7.57 Gflops/W。空闲和网页浏览这种低负载场景下，两台机器的功耗也是一口一口地咬得死死的。
Hackaday 的评论一针见血：
"有些人这几年一直在说，ARM 在功耗上的观测优势更多来自芯片本身而不是指令集架构，而戴尔这颗 Core 5 320 看起来证明了他们在 x86 上是对的。"
My take: 把这两件事并排放，才是这篇文章真正想说的。信任和能效是两条独立的曲线，而且它们都不由指令集决定。 x86 不因为 rosenbridge 就"天生不安全"（那是一颗特定厂商的特定老芯片），ARM 也不因为架构就"天生省电"（省电来自具体实现和制程）。架构从来不是宿命，实现才是。
用一个八年前的、只影响某一代 VIA 芯片的后门去论证"x86 完了"，和用一台戴尔的 Linpack 成绩去论证"ARM 完了"，是同一种偷懒。
所以你该做什么
按你的角色分三档，别搞混：
普通开发者 / 用户 —— 什么都不用做。 你的 Intel 或 AMD 机器不受 rosenbridge 影响。真要担心 CPU 安全，Spectre 系列的缓解措施和及时的微码更新，实际收益比这个高几个数量级。
做安全敏感产品的 —— 关注型号和供应链。 如果你的产品跑在嵌入式 x86 上，或者你在采购工控、POS、医疗设备，先确认 CPU 型号。老 VIA C3 平台在这些行业的存量比大多数人以为的多。确认受影响就上开机锁定脚本，但要明白它只是缓解不是根治（见第 9 点）。
做威胁模型的 —— 把边界往下挪一层。 rosenbridge 的真正教训是：如果你的模型止步于"假设 CPU 忠实执行指令"，那你的模型有一个没有标注的公理。这个公理至少被证伪过一次。要不要为它付出成本（可审计的硬件、多架构冗余、不信任单一供应链）是个成本收益判断 —— 但那应该是个决策，不是个盲区。
最后
rosenbridge 最有价值的地方，不是它找到了什么，而是它证明了这类东西是可以被找到的。
在它之前，"CPU 里可能藏着东西"是一句只能在会议茶歇时压低声音说的话 —— 无法证伪，因此也无法讨论。在它之后，这句话有了 MSR 地址、有了两字节的指令编码、有了可以 clone 下来自己跑的检测工具，还有一整套可以对着任何一颗芯片重来一遍的 fuzzing 流水线。
能被检测的东西，才是能被治理的东西。 一个开源仓库把一个都市传说变成了一个工程问题 —— 这件事本身，比它找到的那颗老 CPU 重要得多。
技术细节来源：project:rosenbridge，Christopher Domas（@xoreaxeaxeax），https://github.com/xoreaxeaxeax/rosenbridge 能效数据来源：Hackaday，2026 年 8 月 8 日，基于 Jeff Geerling 的 HPL Linpack 实测