问题
我知道 Vmware 虚拟机管理程序至少有一个设置可以忽略来自客户操作系统的 CPU 微码更新（这并不奇怪）。
CPU 微码更新可用。客户操作系统尝试将微码从补丁级别 XX (YYh) 更新到补丁级别 ZZ (TTh)，但 VMware ESX 不允许在虚拟机内应用微码补丁。微码补丁用于纠正 CPU 错误。如果您的 CPU 没有遇到任何问题，则可以忽略此微码补丁。否则，您可以从系统供应商处获取包含此微码补丁的 BIOS/固件更新，或者您的主机操作系统可能提供加载直接从 Intel 网站获取的微码补丁的工具。
https://kb.vmware.com/s/article/1028290
所有虚拟机管理程序（例如 KVM，其中显示虚拟 Qemu CPU）都是这种情况吗？或者 Vmware Vsphere 是否有一个设置，其中从客户机检测到的微码更新被分阶段提供给虚拟机管理程序微码加载机制使用（例如，当微码是真实的并且版本比已安装的微码更新时）？
假设
除非微码是特定于虚拟化 CPU 的，否则任何客户机都不能将微码上传到虚拟机管理程序的 CPU。但话又说回来，这有什么用呢？虚拟机管理程序的代码也可以更新，以仅更改虚拟 CPU。
Spectre 需要在虚拟机管理程序级别进行缓解，因此需要虚拟机管理程序提供适当的 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 恢复英特尔和 AMD 的微代码以应对侧信道攻击 解决方案：#1533978
microcode_ctl RPM 的变更日志
答案1
是的，虚拟机管理程序（至少是没有出现异常故障的虚拟机管理程序）将总是拒绝来自客户机 (VM) 的微代码更新访问。任何微代码更新都必须由虚拟机管理程序本身或系统固件/引导加载程序提供。
原因显而易见：安全。微代码更新可以更改 ISA（指令集架构）的可见细节，并扰乱整个系统，甚至导致其他未准备好应对 ISA 更改的虚拟机崩溃等（请参阅删除了 Intel TSX-NI 指令的 Intel TSX 微代码修复程序作为示例）。
此外，还有微代码更新级别的攻击，这些攻击一旦成功，将导致整个系统崩溃。因此，一个虚拟机可能会导致虚拟机管理程序和所有其他虚拟机崩溃。有关示例，请参阅 Inertiawar 论文中的英特尔微代码更新。
此外，虚拟机管理程序可能会向客户机公开与其实际运行的 CPU 模型不同的（有时是合成的）CPU 模型。客户机无权尝试更新此类 CPU 的微码。
因此，微码更新是一个攻击面，所有有价值的虚拟机管理程序都会关闭。