Messages in this thread | | | Date | Thu, 27 Jul 2023 11:48:27 +0800 | Subject | Re: [PATCH v4 14/20] KVM:VMX: Set up interception for CET MSRs | From | "Yang, Weijiang" <> |
| |
On 7/26/2023 4:30 PM, Chao Gao wrote: > On Thu, Jul 20, 2023 at 11:03:46PM -0400, Yang Weijiang wrote: >> Pass through CET MSRs when the associated feature is enabled. >> Shadow Stack feature requires all the CET MSRs to make it >> architectural support in guest. IBT feature only depends on >> MSR_IA32_U_CET and MSR_IA32_S_CET to enable both user and >> supervisor IBT. > If a guest supports SHSTK only, KVM has no way to prevent guest from > enabling IBT because the U/S_CET are pass-thru'd. it is a problem.
Yes, this is a CET architectural defect when only SHSTK is enabled. But it shouldn't
bring issues, right? I will highlight it in commit log.
> > I am wondering if it is necessary to pass-thru U/S_CET MSRs. Probably > the answer is yes at least for U_CET MSR because the MSR is per-task.
Agree, also xsaves/xrstors in guest could fail if they're not pass-thrued.
> >> Signed-off-by: Yang Weijiang <weijiang.yang@intel.com> >> --- >> arch/x86/kvm/vmx/vmx.c | 35 +++++++++++++++++++++++++++++++++++ >> 1 file changed, 35 insertions(+) >> >> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c >> index b29817ec6f2e..85cb7e748a89 100644 >> --- a/arch/x86/kvm/vmx/vmx.c >> +++ b/arch/x86/kvm/vmx/vmx.c >> @@ -709,6 +709,10 @@ static bool is_valid_passthrough_msr(u32 msr) >> case MSR_LBR_CORE_TO ... MSR_LBR_CORE_TO + 8: >> /* LBR MSRs. These are handled in vmx_update_intercept_for_lbr_msrs() */ >> return true; >> + case MSR_IA32_U_CET: >> + case MSR_IA32_S_CET: >> + case MSR_IA32_PL0_SSP ... MSR_IA32_INT_SSP_TAB: >> + return true; >> } >> >> r = possible_passthrough_msr_slot(msr) != -ENOENT; >> @@ -7758,6 +7762,34 @@ static void update_intel_pt_cfg(struct kvm_vcpu *vcpu) >> vmx->pt_desc.ctl_bitmask &= ~(0xfULL << (32 + i * 4)); >> } >> >> +static void vmx_update_intercept_for_cet_msr(struct kvm_vcpu *vcpu) >> +{ >> + if (guest_can_use(vcpu, X86_FEATURE_SHSTK)) { >> + vmx_set_intercept_for_msr(vcpu, MSR_IA32_U_CET, >> + MSR_TYPE_RW, false); >> + vmx_set_intercept_for_msr(vcpu, MSR_IA32_S_CET, >> + MSR_TYPE_RW, false); >> + vmx_set_intercept_for_msr(vcpu, MSR_IA32_PL0_SSP, >> + MSR_TYPE_RW, false); >> + vmx_set_intercept_for_msr(vcpu, MSR_IA32_PL1_SSP, >> + MSR_TYPE_RW, false); >> + vmx_set_intercept_for_msr(vcpu, MSR_IA32_PL2_SSP, >> + MSR_TYPE_RW, false); >> + vmx_set_intercept_for_msr(vcpu, MSR_IA32_PL3_SSP, >> + MSR_TYPE_RW, false); >> + vmx_set_intercept_for_msr(vcpu, MSR_IA32_INT_SSP_TAB, >> + MSR_TYPE_RW, false); >> + return; >> + } >> + >> + if (guest_can_use(vcpu, X86_FEATURE_IBT)) { >> + vmx_set_intercept_for_msr(vcpu, MSR_IA32_U_CET, >> + MSR_TYPE_RW, false); >> + vmx_set_intercept_for_msr(vcpu, MSR_IA32_S_CET, >> + MSR_TYPE_RW, false); >> + } > This is incorrect. see > > https://lore.kernel.org/all/ZJYzPn7ipYfO0fLZ@google.com/
Yes, will add the lost counterpart, thanks!
> >> +} >> + >> static void vmx_vcpu_after_set_cpuid(struct kvm_vcpu *vcpu) >> { >> struct vcpu_vmx *vmx = to_vmx(vcpu); >> @@ -7825,6 +7857,9 @@ static void vmx_vcpu_after_set_cpuid(struct kvm_vcpu *vcpu) >> >> /* Refresh #PF interception to account for MAXPHYADDR changes. */ >> vmx_update_exception_bitmap(vcpu); >> + >> + if (kvm_is_cet_supported()) > Nit: this check is not necessary. here isn't a hot path. and if > kvm_is_cet_supported() is false, guest_can_use(., X86_FEATURE_SHSTK/IBT) > should be false.
Yes, I think it can be removed.
> >> + vmx_update_intercept_for_cet_msr(vcpu); >> } >> >> static u64 vmx_get_perf_capabilities(void) >> -- >> 2.27.0 >>
| |