管理程序是否总是忽略 CPU 微码更新？

Question

题

我知道 Vmware 管理程序至少有一个设置可以忽略来自来宾操作系统内的 CPU 微码更新（不足为奇）。

CPU 微码更新可用。来宾操作系统尝试将微代码从补丁级别 XX (YYh) 更新到补丁级别 ZZ (TTh)，但 VMware ESX 不允许从虚拟机内应用微代码补丁。微码补丁用于纠正 CPU 勘误表。如果您的 CPU 没有遇到任何问题，则可以忽略此微码补丁。否则，您可以从您的系统供应商处获得包含此微码补丁的 BIOS/固件更新，或者您的主机操作系统可能会提供一个工具来加载直接从英特尔网站获得的微码补丁。

https://kb.vmware.com/s/article/1028290

所有管理程序都是这种情况吗（如 KVM，其中提供了虚拟 Qemu CPU）还是可能有 Vmware Vsphere 的设置，其中检测到来自来宾机器的微代码更新被暂存以供管理程序微代码加载机制使用（例如当微码是真实的并且版本比安装的微码更新时）？

假设

1. 任何来宾机器都不能将微代码上传到管理程序的 CPU，除非微代码特定于虚拟化 CPU。但话又说回来，它有什么用呢？也可以更新虚拟机管理程序的代码以仅更改虚拟 CPU。

2. Spectre 需要在 Hypervisor 级别进行缓解，因此需要 Hypervisor 上传适当的 Bios 固件和/或微代码。微码无法通过来宾操作系统修复。

背景

Red Hat 撤回了与 Spectre 相关的微码更新，并且虚拟机尝试在启动期间上传微码。

2018 年 1 月 15 日星期一 Petr Oros - 1:1.17-25.4 使用正确的上游源进行还原 解决：#1533978

2018 年 1 月 12 日星期五 Petr Oros - 1:1.17-25.3 从 Intel 和 AMD 恢复微码以进行侧信道攻击解决：#1533978

microcode_ctl RPM 的更新日志

Answer 1

是的，管理程序（至少那些没有异常损坏的管理程序）将始终拒绝来自来宾（VM）的微代码更新访问。任何微码更新都必须由管理程序本身或系统固件/引导加载程序提供。

这样做的原因是最明显的：安全性。微码更新可以更改 ISA（指令集架构）的可见细节，并干扰整个系统，甚至包括使未为 ISA 更改做好准备的其他 VM 崩溃等（请参阅移除了以英特尔 TSX-NI 指令为例）。

此外，还有微代码更新级别的攻击，如果成功，将导致整个系统瘫痪。因此，一个 VM 可能会使管理程序和所有其他 VM 崩溃。有关示例，请参阅有关 Intel 微码更新的 Inertiawar 论文。

此外，虚拟机管理程序可能会向来宾公开一个不同的、有时是合成的 CPU 模型，而不是它真正运行的模型。来宾无权尝试更新此类 CPU 的微码。

因此，微码更新是一个攻击面，所有有价值的管理程序都会关闭。