On Wed, Sep 18, 2024, Xin Li wrote:
MSR_IA32_FRED_SSP0 is an alias of the CET MSR_IA32_PL0_SSP and likely to be used in the same way as FRED RSP0, i.e., host FRED SSP0 _should_ be restored in arch_exit_to_user_mode_prepare(). However as of today Linux has no plan to utilize kernel shadow stack thus no one cares host FRED SSP0 (no?). But lets say anyway it is host's responsibility to manage host FRED SSP0, then KVM only needs to take care of guest FRED SSP0 (just like how KVM should handle guest FRED RSP0) even before the supervisor shadow stack feature is advertised to guest.
Heh, I'm not sure what your question is, or if there even is a question. KVM needs to context switch FRED SSP0 if FRED is exposed to the guest, but presumably that will be done through XSAVE state? If that's the long term plan, I would prefer to focus on merging CET virtualization first, and then land FRED virtualization on top so that KVM doesn't have to carry intermediate code to deal with the aliased MSR.
You mean the following patch set, right?
Yep, and presumably the KVM support as well:
https://lore.kernel.org/all/20240219074733.122080-1-weijiang.yang@intel.com
https://lore.kernel.org/kvm/20240531090331.13713-1-weijiang.yang@intel.com/
...
Ugh, but what happens if a CPU (or the host kernel) supports FRED but not CET SS? Or is that effectively an illegal combination?
The FRED Spec says:
IA32_FRED_SSP1, IA32_FRED_SSP2, and IA32_FRED_SSP3 (MSR indices 1D1H– 1D3H). Together with the existing MSR IA32_PL0_SSP (MSR index 6A4H), these are the FRED SSP MSRs.
The FRED SSP MSRs are supported by any processor that enumerates CPUID.(EAX=7,ECX=1):EAX.FRED[bit 17] as 1. If such a processor does not support CET, FRED transitions will not use the MSRs (because shadow stacks are not enabled), but the MSRs would still be accessible using RDMSR and WRMSR.
So they are independent, just that FRED SSP MSRs are NOT used if supervisor shadow stacks are not enabled (obviously Qemu can be configured to not advertise CET but FRED).
When FRED is advertised to a guest, KVM should allow FRED SSP MSRs accesses through disabling FRED SSP MSRs interception no matter whether supervisor shadow stacks are enabled or not.
KVM doesn't necessarily need to disabling MSR interception, e.g. if the expectation is that the guest will rarely/never access the MSRs when CET is unsupported, then we're likely better off going with a trap-and-emulate model. KVM needs to emulate RDMSR and WRMSR no matter what, e.g. in case the guest triggers a WRMSR when KVM is emulating, and so that userspace can get/set MSR values.
And this means that yes, FRED virtualization needs to land after CET virtualization, otherwise managing the conflicts/dependencies will be a nightmare.