挖深网络安全的兔子洞：CPU 微码补丁管理

作者：Sender Su 来源：本站原创发布日期：2024-11-13 最后修改日期：2024-11-13

网络安全的具体实践，就如爱丽丝梦游仙境的兔子洞，深不可测。

因为安全无死角嘛。

最近的一件事把这个兔子洞又往下挖深了：

旧版本的 CPU 微码应该被明确视为漏洞看待。

笔者：国际注册信息系统审计师、软考系统分析师、软件工程硕士

其实笔者所见，别说 CPU 微码这么深入的事情了，就 BIOS 更新，实际都不是每个单位的网管都会主动去做的。

除非是被漏扫明确指出在用的版本有漏洞，还要叠加上过不了等保测评或者攻防演练在即这样的契机。

笔者长期强调网络安全防守重点要落在实践，管理框架只是框架，脱离了具体实践就毫无意义。偏偏管理框架就是抽象的，无法巨细无遗地指出要做的事情，尤其是对于未来的事情，需要执行人具备前瞻性和敏感性，才能合理地及早布局。

起因：使用旧版本微码等于存在风险

言归正传。事情是来自于 Linux Kernel 邮件列表：

https://lore.kernel.org/lkml/20241107170630.2A92B8D3@davehans-spike.ostc.intel.com/

由英特尔工程师 Dave Hansen 向 Linux Kernel 提交了一项补丁并注明是 RFC（Reference For Comment），为开展讨论供参考之用。

Dave 在邮件中提出，现今的环境，已经不能认为 CPU 在使用旧版本微码的系统是安全的，因此旧版本 CPU 微码应该按漏洞看待：

You can't practically run old microcode and consider a system secure these days. So, let's call old microcode what it is: a vulnerability.

从管理角度，这句话意味着所有网络安全的风险管理和缓解措施都应该施加到 CPU 微码上。读者可以考虑一下自己当前的网络安全管理措施是否明确地细化到达了 CPU 微码版本管理这个层次。

Dave 提出应该在 Linux 内核代码中维护一份简单的微码版本清单，格式上包括版本、日期和 Intel 自己的 CPU 微码 GIT REPO 提交时产生的校验和。很显然这些信息只有 Intel 自己能拿出来。

Dave 认为，这样简单的一份版本清单，不需要提及具体修复了什么问题，可以最小化这件事在 Kernel 代码中的复杂度和可能产生的泛化影响。

而且，这份清单只针对可以在操作系统引导时加载的微码更新，这样就可以解决一个问题：

操作系统可以判断究竟 BIOS 已经加载的微码更新和自己手头的微码更新哪个才是最新，从而避免混乱。

刚好这就是笔者一直以来的困惑：并不是所有的微码更新都会涉及到漏洞，很多是属于提高性能和稳定性之类的补丁，厂家不会给出说明，甚至发微码更新补丁都是静悄悄的，不去刷网页都不知道。

但这事情又典型的政出多头：CPU 厂商、服务器厂商以及操作系统厂商（社区）都会释出微码更新补丁，究竟哪个才是最新，究竟已部署的是否最新，都需要自己动手小心跟踪维持记录，不然就是糊涂账。

自己动手还因为，笔者没见到有哪个厂商的资产安全管理有做到微码版本这么深入的层次。所以这些做产品的人究竟有没有真正的网络安全管理经验是尚未可知。也可能是笔者孤陋寡闻，如果读者知道，欢迎留言指出。

不过这事情也还没那么简单，Dave 说 Intel 迄今都尚未发布过正式的 CPU 微码版本清单（所以我上面说，自己做跟踪的工作量有多大！），除非 Intel 主动做，否则这是 Linux Kernel 现在能做到的最好的方式。

其实我看 Dave 隐含的意思是，如果这补丁的做法被接纳，就不仅是 the best can do 了，实际是倒逼 Intel/AMD 等 CPU 厂商在自家产品的安全问题上不再拖拖拉拉和遮遮掩掩。

从补丁反向观察问题

具体地看看这个补丁邮件[1]。补丁主要是提出修改 intel-ucode-defs.h 头文件增加定义清单，修改了 cpufeatures.h 头文件新增：

X86_BUG_OLD_MICROCODE

宏定义标记，以及其他一些代码修改，最终实现从内核通过接口：

/sys/devices/system/cpu/vulnerabilities/old_microcode

暴露 CPU 是否在运行旧版本微码的情况。

值得一提的是在新增的 X86_BUG_OLD_MICROCODE 宏定义之上的 X86_BUG_DIV0、X86_BUG_RFDS 和 X86_BUG_BHI 这三个宏定义：

+++ b/arch/x86/include/asm/cpufeatures.h    2024-11-06 07:51:07.372536037 -0800
@@ -525,4 +525,5 @@
 #define X86_BUG_DIV0            X86_BUG(1*32 + 1) /* "div0" AMD DIV0 speculation bug */
 #define X86_BUG_RFDS            X86_BUG(1*32 + 2) /* "rfds" CPU is vulnerable to Register File Data Sampling */
 #define X86_BUG_BHI            X86_BUG(1*32 + 3) /* "bhi" CPU is affected by Branch History Injection */
+#define X86_BUG_OLD_MICROCODE        X86_BUG(1*32 + 4) /* "old_microcode" CPU has old microcode, it is surely vulnerable to something */
 #endif /* _ASM_X86_CPUFEATURES_H */

它们代表了三个都是通过 CPU 微码更新解决的 CPU 漏洞。

比如 X86_BUG_DIV0，这是2023年的事，AMD ZEN 1~4 CPU 的漏洞，在多线程环境下处理除以0时处置不当导致数据泄露[2]。

X86_BUG_RFDS，是大半年前即2024年3月的事，属于 Intel Atom CPU 的漏洞，逻辑处理器寄存器曾经存放的值有可能被跨线程盗取[3]。

X86_BUG_BHI，是2022年时炒得沸沸扬扬的 Spectre 漏洞的衍生漏洞，CPU 的间接分支预测有可能导致线程之间出现可打破隔离限制访问数据的机会窗口[4]。

最近几年，可能是因为 Intel 要踩爆牙膏和 AMD 竞争的原因，Intel 的 CPU 多次爆出存在漏洞（当然 AMD 也有），最终使得 Intel 完全放弃了超线程技术。

就这些漏洞的历史情况，足以说明 CPU 微码补丁更新应和BIOS补丁更新、操作系统补丁更新等其他补丁管理区别对待。

补丁的复杂性和非技术因素

由于 Dave 给出的只是用于开启讨论模式的参考补丁，可见这个提议不会马上和直接地被接纳合并到 Kernel 源代码中。内核构建工程师兼 Xen 的维护者 Andrew Cooper [5]最快回复了邮件，指出了几个问题，概括起来就是：

1、CPU 微码版本的清单一旦建立就需要维持，避免过时且能使发行版也持续地维护这个清单的向后移植（backport），所以至少还得加个日期在表头。（复杂性+1）

2、虽然是RFC性质的代码补丁，但应该设计得更强壮些才拿出来讨论。这个理念之前 Linus 也说过，完全不成熟的就不要拿出来浪费时间。

3、这个想法会导致要管理 CPU 的生命周期，因为即使已经是最新微码，但 CPU 已经终结了生命周期，那也是不安全。（复杂性+1）

4、如果是在虚拟机运行，宿主管理软件会告诉虚拟机微码版本是 0x7fffffff，也就是无意义的值，所以要增加相应的处置和提示。（复杂性+1）