| Message ID | 20231010200220.897953-6-john.allen@amd.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | SVM guest shadow stack support | expand |
On Tue, 2023-10-10 at 20:02 +0000, John Allen wrote: > When running as an SEV-ES guest, the PL0_SSP, PL1_SSP, PL2_SSP, PL3_SSP, > and U_CET fields in the VMCB save area are type B, meaning the host > state is automatically loaded on a VMEXIT, but is not saved on a VMRUN. > The other shadow stack MSRs, S_CET, SSP, and ISST_ADDR are type A, > meaning they are loaded on VMEXIT and saved on VMRUN. PL0_SSP, PL1_SSP, > and PL2_SSP are currently unused. Manually save the other type B host > MSR values before VMRUN. > > Signed-off-by: John Allen <john.allen@amd.com> > --- > arch/x86/kvm/svm/sev.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c > index b9a0a939d59f..bb4b18baa6f7 100644 > --- a/arch/x86/kvm/svm/sev.c > +++ b/arch/x86/kvm/svm/sev.c > @@ -3098,6 +3098,15 @@ void sev_es_prepare_switch_to_guest(struct sev_es_save_area *hostsa) > hostsa->dr2_addr_mask = amd_get_dr_addr_mask(2); > hostsa->dr3_addr_mask = amd_get_dr_addr_mask(3); > } > + > + if (boot_cpu_has(X86_FEATURE_SHSTK)) { > + /* > + * MSR_IA32_U_CET and MSR_IA32_PL3_SSP are restored on VMEXIT, > + * save the current host values. > + */ > + rdmsrl(MSR_IA32_U_CET, hostsa->u_cet); > + rdmsrl(MSR_IA32_PL3_SSP, hostsa->pl3_ssp); > + } > } Do we actually need this patch? Host FPU state is not encrypted, and as far as I understood from the common CET patch series, that on return to userspace these msrs will be restored. Best regards, Maxim Levitsky PS: AMD's APM is silent on how 'S_CET, SSP, and ISST_ADDR' are saved/restored for non encrypted guests. Are they also type A? Can the VMSA table be trusted in general to provide the same swap type as for the non encrypted guests? > > void sev_vcpu_deliver_sipi_vector(struct kvm_vcpu *vcpu, u8 vector)
On Thu, Nov 02, 2023 at 08:07:20PM +0200, Maxim Levitsky wrote: > On Tue, 2023-10-10 at 20:02 +0000, John Allen wrote: > > When running as an SEV-ES guest, the PL0_SSP, PL1_SSP, PL2_SSP, PL3_SSP, > > and U_CET fields in the VMCB save area are type B, meaning the host > > state is automatically loaded on a VMEXIT, but is not saved on a VMRUN. > > The other shadow stack MSRs, S_CET, SSP, and ISST_ADDR are type A, > > meaning they are loaded on VMEXIT and saved on VMRUN. PL0_SSP, PL1_SSP, > > and PL2_SSP are currently unused. Manually save the other type B host > > MSR values before VMRUN. > > > > Signed-off-by: John Allen <john.allen@amd.com> > > --- > > arch/x86/kvm/svm/sev.c | 9 +++++++++ > > 1 file changed, 9 insertions(+) > > > > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c > > index b9a0a939d59f..bb4b18baa6f7 100644 > > --- a/arch/x86/kvm/svm/sev.c > > +++ b/arch/x86/kvm/svm/sev.c > > @@ -3098,6 +3098,15 @@ void sev_es_prepare_switch_to_guest(struct sev_es_save_area *hostsa) > > hostsa->dr2_addr_mask = amd_get_dr_addr_mask(2); > > hostsa->dr3_addr_mask = amd_get_dr_addr_mask(3); > > } > > + > > + if (boot_cpu_has(X86_FEATURE_SHSTK)) { > > + /* > > + * MSR_IA32_U_CET and MSR_IA32_PL3_SSP are restored on VMEXIT, > > + * save the current host values. > > + */ > > + rdmsrl(MSR_IA32_U_CET, hostsa->u_cet); > > + rdmsrl(MSR_IA32_PL3_SSP, hostsa->pl3_ssp); > > + } > > } > > > Do we actually need this patch? > > Host FPU state is not encrypted, and as far as I understood from the common CET patch series, > that on return to userspace these msrs will be restored. Hi Maxim, I think you're right on this. My next version omits the patch and testing seems to confirm that it's not needed. > > Best regards, > Maxim Levitsky > > > PS: AMD's APM is silent on how 'S_CET, SSP, and ISST_ADDR' are saved/restored for non encrypted guests. > Are they also type A? > > Can the VMSA table be trusted in general to provide the same swap type as for the non encrypted guests? From what I gather, for a non-SEV-ES guest using the save area that is part of the VMCB as opposed to the separate VMCB/VMSA for SEV-ES and SEV-SNP, anything listed in that save area will effectively be swap type A. Does that answer your question? Thanks, John > > > > > > void sev_vcpu_deliver_sipi_vector(struct kvm_vcpu *vcpu, u8 vector) > >
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index b9a0a939d59f..bb4b18baa6f7 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -3098,6 +3098,15 @@ void sev_es_prepare_switch_to_guest(struct sev_es_save_area *hostsa) hostsa->dr2_addr_mask = amd_get_dr_addr_mask(2); hostsa->dr3_addr_mask = amd_get_dr_addr_mask(3); } + + if (boot_cpu_has(X86_FEATURE_SHSTK)) { + /* + * MSR_IA32_U_CET and MSR_IA32_PL3_SSP are restored on VMEXIT, + * save the current host values. + */ + rdmsrl(MSR_IA32_U_CET, hostsa->u_cet); + rdmsrl(MSR_IA32_PL3_SSP, hostsa->pl3_ssp); + } } void sev_vcpu_deliver_sipi_vector(struct kvm_vcpu *vcpu, u8 vector)
When running as an SEV-ES guest, the PL0_SSP, PL1_SSP, PL2_SSP, PL3_SSP, and U_CET fields in the VMCB save area are type B, meaning the host state is automatically loaded on a VMEXIT, but is not saved on a VMRUN. The other shadow stack MSRs, S_CET, SSP, and ISST_ADDR are type A, meaning they are loaded on VMEXIT and saved on VMRUN. PL0_SSP, PL1_SSP, and PL2_SSP are currently unused. Manually save the other type B host MSR values before VMRUN. Signed-off-by: John Allen <john.allen@amd.com> --- arch/x86/kvm/svm/sev.c | 9 +++++++++ 1 file changed, 9 insertions(+)