[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52ea8386-8652-dd91-23de-9d35781cb131@amd.com>
Date: Mon, 26 Jun 2023 10:57:12 -0500
From: Tom Lendacky <thomas.lendacky@....com>
To: Sean Christopherson <seanjc@...gle.com>,
Rick P Edgecombe <rick.p.edgecombe@...el.com>
Cc: "john.allen@....com" <john.allen@....com>,
Weijiang Yang <weijiang.yang@...el.com>,
"bp@...en8.de" <bp@...en8.de>, "x86@...nel.org" <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>
Subject: Re: [RFC PATCH v2 6/6] KVM: SVM: Add CET features to supported_xss
On 6/23/23 17:18, Sean Christopherson wrote:
> 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.
Yes, the host value is saved/restored on VMRUN/#VMEXIT. Anything that is
in the VMCB Save Area (the non-SEV-ES save area) is fully virtualized
(unless noted otherwise) and doesn't require special processing to
save/restore the host values.
S_CET is list in the SVM/SEV VMCB save area. Similarly, for
SEV-ES/SEV-SNP, S_CET is swap type A and is saved/restored on VMRUN/#VMEXIT.
Thanks,
Tom
>
> John?
Powered by blists - more mailing lists