On 7/20/2023 3:41 AM, Sean Christopherson wrote:
[...]
My understanding is that PL[0-2]_SSP are used only on transitions to the
corresponding privilege level from a *different* privilege level. That means
KVM should be able to utilize the user_return_msr framework to load the host
values. Though if Linux ever supports SSS, I'm guessing the core kernel will
have some sort of mechanism to defer loading MSR_IA32_PL0_SSP until an exit to
userspace, e.g. to avoid having to write PL0_SSP, which will presumably be
per-task, on every context switch.
But note my original wording: **If that's necessary**
Thanks!
I think host SSS enabling won't happen in short-term, handling the guest
supervisor
states in KVM side is doable.
If nothing in the host ever consumes those MSRs, i.e. if SSS is NOT enabled in
IA32_S_CET, then running host stuff with guest values should be ok. KVM only
needs to guarantee that it doesn't leak values between guests. But that should
Just Work, e.g. KVM should load the new vCPU's values if SHSTK is exposed to the
guest, and intercept (to inject #GP) if SHSTK is not exposed to the guest.
Yes, these handling have been covered by the new version.
And regardless of what the mechanism ends up managing SSP MSRs, it should only
ever touch PL0_SSP, because Linux never runs anything at CPL1 or CPL2, i.e. will
never consume PL{1,2}_SSP.
Am I missing something?
I think, guest PL{0,1,2}_SSP can be handled as a bundle to make the
handling easy(instead of handling each
separately) because guest can be non-Linux systems, as you said before
they could even be used as scratch registers.
But for host side as it's Linux, I can omit reloading/resetting host
PL{1,2}_SSP when vCPU thread is preempted.
I will post new version to community if above is minor divergence.
