On Fri, Jun 09, 2023, Rick P Edgecombe wrote: > On Fri, 2023-06-09 at 10:34 -0500, John Allen wrote: > > > Is setting XFEATURE_MASK_CET_KERNEL here ok? The host kernel will not > > > support XFEATURE_MASK_CET_KERNEL. I guess after this there is a small > > > window of time where host IA32_XSS could have non-host supported > > > supervisor state. > > > > > > Sort of separately, how does SVM work with respect to saving and > > > restoring guest supervisor CET state (I mean the CET_S stuff)? > > > > Apart from a minor exception involving SEV-ES, we are piggybacking on the > > state saving/restoring in Yang Weijiang's x86/VMX series. So by inspection, > > it looks like guest supervisor support is broken as the supervisor XSAVES > > state and MSRs are not included in that series. I currently don't have a > > way to test this case, but I think there are operating systems that support > > it. I'll work on getting a guest set up that can actually test this and > > hopefully have working guest supervisor support in the next version of the > > series. > > Hmm, interesting. VMX has some separate non-xsaves thing to save and > restore the guests supervisor CET state, so Weijiang's series doesn't > use the xsaves supervisor CET support. Heh, that and Weijiang's series is a wee bit incomplete. > Also, since the host might have CR4.CET set for its own reasons, if the host > handled an exit with the the guests MSR_IA32_S_CET set it could suddenly be > subjected to CET enforcement that it doesn't expect. Waiting to restore it > until returning to the guest is too late. > > At least that's the reasoning on the VMX side as I understand it The APM doesn't come right out and say it, but I assume/hope that S_CET is saved on VMRUN and loaded on #VMEXIT, i.e. is the same as VMX for all intents and purposes. The host save state definitely has a field for S_CET, and VMRUN documents that the guest values are loaded, I just can't find anything in the APM that explicitly states how host S_CET and friends are handled. E.g. in theory, they could have been shoved into VMSAVE+VMLOAD, though I very much doubt that's the case. John?
