On Fri, Apr 14, 2023 at 05:51:43PM +0800, Binbin Wu wrote:
On 4/14/2023 2:25 PM, Chao Gao wrote:
Changes since RFC v1:
- add two kselftests (patch 10-11)
- set virtual MSRs also on APs [Pawan]
- enable "virtualize IA32_SPEC_CTRL" for L2 to prevent L2 from changing some bits of IA32_SPEC_CTRL (patch 4)
- other misc cleanup and cosmetic changes
RFC v1: https://lore.kernel.org/lkml/20221210160046.2608762-1-chen.zhang@intel.com/
This series introduces "virtualize IA32_SPEC_CTRL" support. Here are introduction and use cases of this new feature.
### Virtualize IA32_SPEC_CTRL
"Virtualize IA32_SPEC_CTRL" [1] is a new VMX feature on Intel CPUs. This feature allows VMM to lock some bits of IA32_SPEC_CTRL MSR even when the MSR is pass-thru'd to a guest.
### Use cases of "virtualize IA32_SPEC_CTRL" [2]
Software mitigations like Retpoline and software BHB-clearing sequence depend on CPU microarchitectures. And guest cannot know exactly the underlying microarchitecture. When a guest is migrated between processors of different microarchitectures, software mitigations which work perfectly on previous microachitecture may be not effective on the new one. To fix the problem, some hardware mitigations should be used in conjunction with software mitigations.
So even the hardware mitigations are enabled, the software mitigations are still needed, right?
Retpoline mitigation is not fully effective when RET can take prediction from an alternate predictor. Newer hardware provides a way to disable this behavior (using RRSBA_DIS_S bit in MSR SPEC_CTRL).
eIBRS is the preferred way to mitigate BTI, but for some reason when a guest has deployed retpoline, VMM can make it more effective by deploying the relevant hardware control. That is why the above text says:
"... hardware mitigations should be used in conjunction with software mitigations."