我知道Vmware管理程序至少有一个设置来忽略来宾操作系统内的cpu微码更新(毫不奇怪).
cpu microcode update available. The guest OS tried to update the
microcode from patch level XX (YYh) to patch level ZZ (TTh),but
VMware ESX does not allow microcode patches to be applied from within
a virtual machine. microcode patches are used to correct cpu errata.
If you are not experiencing any problems with your cpu,you can ignore
this microcode patch. Otherwise,you may be able to obtain a
BIOS/firmware update which includes this microcode patch from your
system vendor,or your host OS may provide a facility for loading
microcode patches obtained directly from the Intel web site.
https://kb.vmware.com/s/article/1028290
这是所有虚拟机管理程序(如KVM,虚拟Qemu cpu出现的情况)的情况,或者可能是Vmware Vsphere的设置,其中来自客户机的检测到的微代码更新被分阶段用于管理程序微码加载机制(例如当微码是真实的并且版本比安装的微码更新时)？
假设
>除非微码特定于虚拟化cpu,否则任何客户机都不能将微码上传到管理程序的cpu.但话说回来,它会有什么用处？管理程序的代码也可以更新为只更改虚拟cpu.
>幽灵需要在虚拟机管理程序级别上进行缓解,因此需要通过虚拟机管理程序进行适当的Bios固件和/或微代码上传.微码无法通过客户操作系统修复.
背景
Red Hat撤回了与Spectre相关的微码更新,虚拟机尝试在启动时上传微码.
Mon Jan 15 2018 Petr Oros – 1:1.17-25.4
Use right upstream source for revert
Resolves: #1533978Fri Jan 12 2018 Petr Oros – 1:1.17-25.3
Revert microcode from Intel and AMD for Side Channel attack
Resolves: #1533978
更改了microcode_ctl RPM的日志
解决方法
其中最明显的原因是：安全性.微码更新可以改变ISA(指令集架构)的可见细节,并干扰整个系统,直至并包括崩溃未准备好进行ISA更改的其他VM等(请参阅删除了该更改的英特尔TSX微码修复英特尔TSX-NI指令示例).
此外,还有微代码更新级别的攻击,这些攻击在成功时会导致整个系统崩溃.因此,一个VM可能会使管理程序和所有其他VM崩溃.有关示例,请参阅有关英特尔微码更新的惯性报纸.
此外,虚拟机管理程序可能会向客户端公开一个与其实际运行的cpu模型不同的,有时是合成的cpu模型.客户没有尝试更新这种cpu的微码的业务.
