From: Yang Weijiang <weijiang.yang@intel.com>
To: Jim Mattson <jmattson@google.com>
Cc: "Yang Weijiang" <weijiang.yang@intel.com>,
"kvm list" <kvm@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Sean Christopherson" <sean.j.christopherson@intel.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Radim Krčmář" <rkrcmar@redhat.com>
Subject: Re: [PATCH v7 4/7] KVM: VMX: Load Guest CET via VMCS when CET is enabled in Guest
Date: Wed, 9 Oct 2019 14:43:39 +0800 [thread overview]
Message-ID: <20191009064339.GC27851@local-michael-cet-test> (raw)
In-Reply-To: <CALMp9eS1V2fRcwogcEkHonvVAgfc9dU=7A4V-D0Rcoc=v82VAw@mail.gmail.com>
On Wed, Oct 02, 2019 at 11:54:26AM -0700, Jim Mattson wrote:
> On Thu, Sep 26, 2019 at 7:17 PM Yang Weijiang <weijiang.yang@intel.com> wrote:
> >
> > "Load Guest CET state" bit controls whether Guest CET states
> > will be loaded at Guest entry. Before doing that, KVM needs
> > to check if CPU CET feature is enabled on host and available
> > to Guest.
> >
> > Note: SHSTK and IBT features share one control MSR:
> > MSR_IA32_{U,S}_CET, which means it's difficult to hide
> > one feature from another in the case of SHSTK != IBT,
> > after discussed in community, it's agreed to allow Guest
> > control two features independently as it won't introduce
> > security hole.
> >
> > Co-developed-by: Zhang Yi Z <yi.z.zhang@linux.intel.com>
> > Signed-off-by: Zhang Yi Z <yi.z.zhang@linux.intel.com>
> > 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 f720baa7a9ba..ba1a83d11e69 100644
> > --- a/arch/x86/kvm/vmx/vmx.c
> > +++ b/arch/x86/kvm/vmx/vmx.c
> > @@ -44,6 +44,7 @@
> > #include <asm/spec-ctrl.h>
> > #include <asm/virtext.h>
> > #include <asm/vmx.h>
> > +#include <asm/cet.h>
> >
> > #include "capabilities.h"
> > #include "cpuid.h"
> > @@ -2918,6 +2919,37 @@ void vmx_set_cr3(struct kvm_vcpu *vcpu, unsigned long cr3)
> > vmcs_writel(GUEST_CR3, guest_cr3);
> > }
> >
> > +static int set_cet_bit(struct kvm_vcpu *vcpu, unsigned long cr4)
>
> Nit: This function does not appear to set CR4.CET, as the name would imply.
>
OK, will change it, thank you!
> > +{
> > + struct vcpu_vmx *vmx = to_vmx(vcpu);
> > + const u64 cet_bits = XFEATURE_MASK_CET_USER | XFEATURE_MASK_CET_KERNEL;
> > + bool cet_xss = vmx_xsaves_supported() &&
> > + (kvm_supported_xss() & cet_bits);
> > + bool cet_cpuid = guest_cpuid_has(vcpu, X86_FEATURE_SHSTK) ||
> > + guest_cpuid_has(vcpu, X86_FEATURE_IBT);
> > + bool cet_on = !!(cr4 & X86_CR4_CET);
> > +
> > + if (cet_on && vmx->nested.vmxon)
> > + return 1;
>
> This constraint doesn't appear to be architected. Also, this prevents
> enabling CR4.CET when in VMX operation, but what about the other way
> around (i.e. entering VMX operation with CR4.CET enabled)?
>
Yes, will think more for nested case in next release.
> > + if (cet_on && !cpu_x86_cet_enabled())
> > + return 1;
>
> This seems odd. Why is kernel support for (SHSTK or IBT) required for
> the guest to use (SHSTK or IBT)? If there's a constraint, shouldn't it
> be 1:1? (i.e. kernel support for SHSTK is required for the guest to
> use SHSTK and kernel support for IBT is required for the guest to use
> IBT?) Either way, enforcement of this constraint seems late, here,
> when the guest is trying to set CR4 to a value that, per the guest
> CPUID information, should be legal. Shouldn't this constraint be
> applied when setting the guest CPUID information, disallowing the
> enumeration of SHSTK and/or IBT support on a platform where these
> features are unavailable or disabled in the kernel?
>
In KVM do_cpuid_7_mask(), SHSTK/IBT flags are emulated with
cpuid(0x7,0), there in cpuid_mask(), it'll enforce the check against
host kernel CET status,
and host boot_cpu_data.x86_capability[X86_FEATURE_SHSTK/IBT] will be cleared
during host boot up if the feature is disabled or unavailable.
You may check the kernel CET patch.
Rgarding the 1:1 check, I'll add more strict check in next version,
thanks!
> > + if (cet_on && !cet_xss)
> > + return 1;
>
> Again, this constraint seems like it's being applied too late.
> Returning 1 here will result in the guest's MOV-to-CR4 raising #GP,
> even though there is no architected reason for it to do so.
>
see above.
> > + if (cet_on && !cet_cpuid)
> > + return 1;
>
> What about the constraint that CR4.CET can't be set when CR0.WP is
> clear? (And the reverse needs to be handled in vmx_set_cr0).
>
OK, will check this case, thank you!
> > + if (cet_on)
> > + vmcs_set_bits(VM_ENTRY_CONTROLS,
> > + VM_ENTRY_LOAD_GUEST_CET_STATE);
>
> Have we ensured that this VM-entry control is supported on the platform?
>
If all the checks pass, is it enought to ensure the control bit supported?
> > + else
> > + vmcs_clear_bits(VM_ENTRY_CONTROLS,
> > + VM_ENTRY_LOAD_GUEST_CET_STATE);
> > + return 0;
> > +}
> > +
> > int vmx_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
> > {
> > struct vcpu_vmx *vmx = to_vmx(vcpu);
> > @@ -2958,6 +2990,9 @@ int vmx_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
> > return 1;
> > }
> >
> > + if (set_cet_bit(vcpu, cr4))
> > + return 1;
> > +
> > if (vmx->nested.vmxon && !nested_cr4_valid(vcpu, cr4))
> > return 1;
> >
> > --
> > 2.17.2
> >
next prev parent reply other threads:[~2019-10-09 6:41 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-27 2:19 [PATCH v7 0/7] Introduce support for Guest CET feature Yang Weijiang
2019-09-27 2:19 ` [PATCH v7 1/7] KVM: CPUID: Fix IA32_XSS support in CPUID(0xd,i) enumeration Yang Weijiang
2019-10-02 17:26 ` Jim Mattson
2019-10-08 8:30 ` Yang Weijiang
2019-10-17 19:46 ` Sean Christopherson
2019-10-18 1:28 ` Yang Weijiang
2019-10-22 19:46 ` Sean Christopherson
2019-10-23 1:16 ` Yang Weijiang
2019-09-27 2:19 ` [PATCH v7 2/7] kvm: vmx: Define CET VMCS fields and CPUID flags Yang Weijiang
2019-10-02 18:04 ` Jim Mattson
2019-10-09 5:56 ` Yang Weijiang
2019-09-27 2:19 ` [PATCH v7 3/7] KVM: VMX: Pass through CET related MSRs to Guest Yang Weijiang
2019-10-02 18:18 ` Jim Mattson
2019-10-09 6:15 ` Yang Weijiang
2019-10-10 19:04 ` Jim Mattson
2019-10-11 1:51 ` Yang Weijiang
2019-10-17 20:04 ` Sean Christopherson
2019-10-18 1:31 ` Yang Weijiang
2019-09-27 2:19 ` [PATCH v7 4/7] KVM: VMX: Load Guest CET via VMCS when CET is enabled in Guest Yang Weijiang
2019-10-02 18:54 ` Jim Mattson
2019-10-09 6:43 ` Yang Weijiang [this message]
2019-10-09 23:08 ` Jim Mattson
2019-10-10 1:30 ` Yang Weijiang
2019-10-10 23:44 ` Jim Mattson
2019-10-11 1:43 ` Yang Weijiang
2019-09-27 2:19 ` [PATCH v7 5/7] kvm: x86: Add CET CR4 bit and XSS support Yang Weijiang
2019-10-02 19:05 ` Jim Mattson
2019-10-17 19:56 ` Sean Christopherson
2019-10-18 1:58 ` Yang Weijiang
2019-10-22 20:13 ` Sean Christopherson
2019-10-23 1:19 ` Yang Weijiang
2019-09-27 2:19 ` [PATCH v7 6/7] KVM: x86: Load Guest fpu state when accessing MSRs managed by XSAVES Yang Weijiang
2019-10-02 19:56 ` Jim Mattson
2019-10-09 6:46 ` Yang Weijiang
2019-09-27 2:19 ` [PATCH v7 7/7] KVM: x86: Add user-space access interface for CET MSRs Yang Weijiang
2019-10-02 20:57 ` Jim Mattson
2019-10-09 6:56 ` Yang Weijiang
2019-10-17 19:58 ` Sean Christopherson
2019-10-18 1:32 ` Yang Weijiang
2019-10-02 22:40 ` [PATCH v7 0/7] Introduce support for Guest CET feature Jim Mattson
2019-10-03 13:01 ` Yang Weijiang
2019-10-03 16:33 ` Jim Mattson
2019-10-08 8:50 ` 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=20191009064339.GC27851@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=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=sean.j.christopherson@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;
as well as URLs for NNTP newsgroup(s).