From: Yang Weijiang <weijiang.yang@intel.com>
To: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Yang Weijiang <weijiang.yang@intel.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
pbonzini@redhat.com, jmattson@google.com,
yu.c.zhang@linux.intel.com
Subject: Re: [PATCH v11 3/9] KVM: VMX: Set host/guest CET states for vmexit/vmentry
Date: Fri, 24 Apr 2020 22:35:10 +0800 [thread overview]
Message-ID: <20200424143510.GH24039@local-michael-cet-test> (raw)
In-Reply-To: <20200423171741.GH17824@linux.intel.com>
On Thu, Apr 23, 2020 at 10:17:41AM -0700, Sean Christopherson wrote:
> On Thu, Mar 26, 2020 at 04:18:40PM +0800, Yang Weijiang wrote:
> > "Load {guest,host} CET state" bit controls whether guest/host
> > CET states will be loaded at VM entry/exit.
> > Set default host kernel CET states to 0s in VMCS to avoid guest
> > CET states leakage. When CR4.CET is cleared due to guest mode
> > change, make guest CET states invalid in VMCS, this can happen,
> > e.g., guest reboot.
> >
> > Signed-off-by: Yang Weijiang <weijiang.yang@intel.com>
> > ---
> > arch/x86/kvm/vmx/capabilities.h | 10 ++++++
> > arch/x86/kvm/vmx/vmx.c | 56 +++++++++++++++++++++++++++++++--
> > 2 files changed, 63 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/kvm/vmx/capabilities.h b/arch/x86/kvm/vmx/capabilities.h
> > index 8903475f751e..565340352260 100644
> > --- a/arch/x86/kvm/vmx/capabilities.h
> > +++ b/arch/x86/kvm/vmx/capabilities.h
> > @@ -107,6 +107,16 @@ static inline bool cpu_has_vmx_mpx(void)
> > (vmcs_config.vmentry_ctrl & VM_ENTRY_LOAD_BNDCFGS);
> > }
> >
> > +static inline bool cpu_has_cet_guest_load_ctrl(void)
> > +{
> > + return (vmcs_config.vmentry_ctrl & VM_ENTRY_LOAD_GUEST_CET_STATE);
> > +}
> > +
> > +static inline bool cpu_has_cet_host_load_ctrl(void)
> > +{
> > + return (vmcs_config.vmexit_ctrl & VM_EXIT_LOAD_HOST_CET_STATE);
> > +}
>
> We should bundle these together, same as we do for PERF_GLOBAL_CTRL. Not
> just for code clarity, but also for functionality, e.g. if KVM ends up on a
> frankenstein CPU with VM_ENTRY_LOAD_CET_STATE and !VM_EXIT_LOAD_CET_STATE
> then KVM will end up running with guest state. This is also an argument
> for not qualifying the control names with GUEST vs. HOST.
Cannot agree with you more! Thank you!
Will fix them.
> > +
> > static inline bool cpu_has_vmx_tpr_shadow(void)
> > {
> > int vmx_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
> > {
> > struct vcpu_vmx *vmx = to_vmx(vcpu);
> > @@ -3110,6 +3119,12 @@ int vmx_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
> > hw_cr4 &= ~(X86_CR4_SMEP | X86_CR4_SMAP | X86_CR4_PKE);
> > }
> >
> > + if (!(hw_cr4 & X86_CR4_CET) && is_cet_supported(vcpu)) {
> > + vmcs_writel(GUEST_SSP, 0);
> > + vmcs_writel(GUEST_S_CET, 0);
> > + vmcs_writel(GUEST_INTR_SSP_TABLE, 0);
>
> Can't we simply toggle the VM_{ENTRY,EXIT}_LOAD controls? If CR4.CET=0 in
> the guest, then presumably keeping host state loaded is ok? I.e. won't
> leak host information to the guest.
>
Yes, it's doable, let me change it.
> > + }
> > +
> > vmcs_writel(CR4_READ_SHADOW, cr4);
> > vmcs_writel(GUEST_CR4, hw_cr4);
> > return 0;
> > @@ -3939,6 +3954,12 @@ void vmx_set_constant_host_state(struct vcpu_vmx *vmx)
> >
> > if (cpu_has_load_ia32_efer())
> > vmcs_write64(HOST_IA32_EFER, host_efer);
> > +
> > + if (cpu_has_cet_host_load_ctrl()) {
> > + vmcs_writel(HOST_S_CET, 0);
> > + vmcs_writel(HOST_INTR_SSP_TABLE, 0);
> > + vmcs_writel(HOST_SSP, 0);
>
> This is unnecessary, the VMCS is zeroed on allocation.
>
> And IIUC, this is only correct because the main shadow stack enabling only
> adds user support. Assuming that's correct, (a) it absolutely needs to be
> called out in the changelog and (b) KVM needs a WARN in hardware_setup() to
> guard against kernel shadow stack support being added without updating KVM,
> e.g. something this (not sure the MSRs are correct):
>
> if (boot_cpu_has(X86_FEATURE_IBT) || boot_cpu_has(X86_FEATURE_SHSTK)) {
> rdmsrl(MSR_IA32_S_CET, cet_msr);
> WARN_ONCE(cet_msr, "KVM: S_CET in host will be lost");
>
> }
> if (boot_cpu_has(X86_FEATURE_SHSTK)) {
> rdmsrl(MSR_IA32_PL0_SSP, cet_msr);
> WARN_ONCE(cet_msr, "KVM: PL0_SPP in host will be lost");
> }
>
Yes, just wanted to make host CET stuffs invalid before kernel mode
CET is available. OK, will follow your advice, thanks!
> > + }
> > }
> > /*
> > @@ -7140,8 +7175,23 @@ static void vmx_cpuid_update(struct kvm_vcpu *vcpu)
> > }
> >
> > if (guest_cpuid_has(vcpu, X86_FEATURE_SHSTK) ||
> > - guest_cpuid_has(vcpu, X86_FEATURE_IBT))
> > + guest_cpuid_has(vcpu, X86_FEATURE_IBT)) {
> > vmx_update_intercept_for_cet_msr(vcpu);
> > +
> > + if (cpu_has_cet_guest_load_ctrl() && is_cet_supported(vcpu))
> > + vm_entry_controls_setbit(to_vmx(vcpu),
> > + VM_ENTRY_LOAD_GUEST_CET_STATE);
> > + else
> > + vm_entry_controls_clearbit(to_vmx(vcpu),
> > + VM_ENTRY_LOAD_GUEST_CET_STATE);
> > +
> > + if (cpu_has_cet_host_load_ctrl() && is_cet_supported(vcpu))
> > + vm_exit_controls_setbit(to_vmx(vcpu),
> > + VM_EXIT_LOAD_HOST_CET_STATE);
> > + else
> > + vm_exit_controls_clearbit(to_vmx(vcpu),
> > + VM_EXIT_LOAD_HOST_CET_STATE);
>
> As above, I think this can be done in vmx_set_cr4().
>
Hmm, it's in vmx_set_cr4() in early versions, OK, will move them back.
> > + }
> > }
> >
> > static __init void vmx_set_cpu_caps(void)
> > --
> > 2.17.2
> >
next prev parent reply other threads:[~2020-04-24 14:33 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-26 8:18 [PATCH v11 0/9] Introduce support for guest CET feature Yang Weijiang
2020-03-26 8:18 ` [PATCH v11 1/9] KVM: VMX: Introduce CET VMX fields and flags Yang Weijiang
2020-04-23 16:07 ` Sean Christopherson
2020-04-24 13:39 ` Yang Weijiang
2020-04-23 16:39 ` Sean Christopherson
2020-04-24 13:44 ` Yang Weijiang
2020-03-26 8:18 ` [PATCH v11 2/9] KVM: VMX: Set guest CET MSRs per KVM and host configuration Yang Weijiang
2020-04-23 16:27 ` Sean Christopherson
2020-04-24 14:07 ` Yang Weijiang
2020-04-24 14:55 ` Sean Christopherson
2020-04-25 9:14 ` Yang Weijiang
2020-04-25 13:26 ` Paolo Bonzini
2020-04-26 15:26 ` Yang Weijiang
2020-03-26 8:18 ` [PATCH v11 3/9] KVM: VMX: Set host/guest CET states for vmexit/vmentry Yang Weijiang
2020-04-01 2:23 ` kbuild test robot
2020-04-23 17:17 ` Sean Christopherson
2020-04-24 14:35 ` Yang Weijiang [this message]
2020-04-24 14:49 ` Sean Christopherson
2020-04-25 9:20 ` Yang Weijiang
2020-04-27 17:04 ` Sean Christopherson
2020-04-27 17:56 ` Sean Christopherson
2020-03-26 8:18 ` [PATCH v11 4/9] KVM: VMX: Check CET dependencies on CR settings Yang Weijiang
2020-04-23 17:20 ` Sean Christopherson
2020-04-24 14:36 ` Yang Weijiang
2020-03-26 8:18 ` [PATCH v11 5/9] KVM: X86: Refresh CPUID once guest XSS MSR changes Yang Weijiang
2020-04-23 17:34 ` Sean Christopherson
2020-04-24 14:47 ` Yang Weijiang
2020-04-25 13:19 ` Paolo Bonzini
2020-04-26 15:01 ` Yang Weijiang
2020-03-26 8:18 ` [PATCH v11 6/9] KVM: X86: Load guest fpu state when access MSRs managed by XSAVES Yang Weijiang
2020-03-26 8:18 ` [PATCH v11 7/9] KVM: X86: Add userspace access interface for CET MSRs Yang Weijiang
2020-03-28 7:40 ` kbuild test robot
2020-04-23 18:14 ` Sean Christopherson
2020-04-24 15:02 ` Yang Weijiang
2020-04-24 15:10 ` Sean Christopherson
2020-04-25 9:28 ` Yang Weijiang
2020-04-25 15:31 ` Paolo Bonzini
2020-04-26 15:23 ` Yang Weijiang
2020-04-27 14:04 ` Paolo Bonzini
2020-04-28 13:41 ` Yang Weijiang
2020-03-26 8:18 ` [PATCH v11 8/9] KVM: VMX: Enable CET support for nested VM Yang Weijiang
2020-04-23 18:29 ` Sean Christopherson
2020-04-24 15:24 ` Yang Weijiang
2020-03-26 8:18 ` [PATCH v11 9/9] KVM: X86: Set CET feature bits for CPUID enumeration Yang Weijiang
2020-03-27 4:41 ` kbuild test robot
2020-04-23 16:56 ` Sean Christopherson
2020-04-24 14:17 ` Yang Weijiang
2020-04-23 16:58 ` Sean Christopherson
2020-04-24 14:23 ` Yang Weijiang
2020-03-26 8:18 ` [kvm-unit-tests PATCH] x86: Add tests for user-mode CET Yang Weijiang
2020-04-23 15:51 ` [PATCH v11 0/9] Introduce support for guest CET feature Sean Christopherson
2020-04-24 13:31 ` Yang Weijiang
2020-04-23 16:03 ` Sean Christopherson
2020-04-24 13:34 ` Yang Weijiang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200424143510.GH24039@local-michael-cet-test \
--to=weijiang.yang@intel.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=sean.j.christopherson@intel.com \
--cc=yu.c.zhang@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox