From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Yang Weijiang <weijiang.yang@intel.com>
Cc: pbonzini@redhat.com, rkrcmar@redhat.com, jmattson@google.com,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
mst@redhat.com, yu-cheng.yu@intel.com,
Zhang Yi Z <yi.z.zhang@linux.intel.com>
Subject: Re: [PATCH v3 6/8] KVM:VMX: Load Guest CET via VMCS when CET is enabled in Guest
Date: Mon, 4 Mar 2019 10:43:07 -0800 [thread overview]
Message-ID: <20190304184307.GC17120@linux.intel.com> (raw)
In-Reply-To: <20190303122608.GA32013@local-michael-cet-test.sh.intel.com>
On Sun, Mar 03, 2019 at 08:26:08PM +0800, Yang Weijiang wrote:
> On Fri, Mar 01, 2019 at 06:58:19AM -0800, Sean Christopherson wrote:
> > On Thu, Feb 28, 2019 at 04:38:44PM +0800, Yang Weijiang wrote:
> > > On Thu, Feb 28, 2019 at 08:17:15AM -0800, Sean Christopherson wrote:
> > > > On Mon, Feb 25, 2019 at 09:27:14PM +0800, Yang Weijiang 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 available.
> > > > >
> > > > > 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.c | 32 ++++++++++++++++++++++++++++++++
> > > > > 1 file changed, 32 insertions(+)
> > > > >
> > > > > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> > > > > index 89ee086e1729..d32cee9ee079 100644
> > > > > --- a/arch/x86/kvm/vmx.c
> > > > > +++ b/arch/x86/kvm/vmx.c
> > > > > @@ -55,6 +55,7 @@
> > > > > #include <asm/mmu_context.h>
> > > > > #include <asm/spec-ctrl.h>
> > > > > #include <asm/mshyperv.h>
> > > > > +#include <asm/cet.h>
> > > > >
> > > > > #include "trace.h"
> > > > > #include "pmu.h"
> > > > > @@ -4065,6 +4066,20 @@ static inline bool vmx_feature_control_msr_valid(struct kvm_vcpu *vcpu,
> > > > > return !(val & ~valid_bits);
> > > > > }
> > > > >
> > > > > +static int vmx_guest_cet_cap(struct kvm_vcpu *vcpu)
> > > > > +{
> > > > > + u32 eax, ebx, ecx, edx;
> > > > > +
> > > > > + /*
> > > > > + * Guest CET can work as long as HW supports the feature, independent
> > > > > + * to Host SW enabling status.
> > > > > + */
> > > > > + cpuid_count(7, 0, &eax, &ebx, &ecx, &edx);
> > > > > +
> > > > > + return ((ecx & bit(X86_FEATURE_SHSTK)) |
> > > > > + (edx & bit(X86_FEATURE_IBT))) ? 1 : 0;
> > > >
> > > > Given the holes in the (current) architecture/spec, I think KVM has to
> > > > require both features to be supported in the guest to allow CR4.CET to
> > > > be enabled.
> > > The reason why I use a "OR" here is to keep CET enabling control the
> > > same as that on host, right now on host, users can select to enable SHSTK or IBT
> > > feature by disabling the unexpected one. It's free to select SHSTK & IBT
> > > or SHSTK | IBT.
> >
> > Which is not the same as SHSTK != IBT in *hardware*, which is effectively
> > what this is allowing for the guest. The problem is that the architecture
> > doesn't cleanly separate the two features, i.e. we'd have a virtualization
> > hole where the guest could touch state for a disabled feature.
> >
> > Regardless, the guest would still be able to selectively enable each CET
> > feature, it would just never see a model where SHSTK != IBT.
> Hi, Sean,
> I'd like to understand your concerns. From my point of view, e.g.,
> when only IBT is enabled, PL3_SSP MSR would be unnecessrily exposed,
> this is the design "limitation", but PL3_SSP keeps 0 if SHSTK is not
> configured. Could you detail your concerns?
In your approach, IA32_{S,U}_CET can be written if SHSTK or IBT is exposed
to the guest. If only SHSTK is exposed, a devious guest can still use IBT
because it can set CR4.CET as well as the enable bits in IA32_{S,U}_CET.
Preventing the guest from using IBT in this scenario is infeasible as it
would require trapping and emulating the XSAVE as well as the relevent CET
MSRs.
next prev parent reply other threads:[~2019-03-04 18:43 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-25 13:27 [PATCH v3 0/8] This patch-set is to enable Guest CET support Yang Weijiang
2019-02-25 13:27 ` [PATCH v3 1/8] KVM:VMX: Define CET VMCS fields and bits Yang Weijiang
2019-02-26 19:31 ` Jim Mattson
2019-02-26 7:52 ` Yang Weijiang
2019-02-28 15:53 ` Sean Christopherson
2019-02-28 9:51 ` Yang Weijiang
2019-02-25 13:27 ` [PATCH v3 2/8] KVM:CPUID: Define CET CPUID bits and CR4.CET master enable bit Yang Weijiang
2019-02-26 19:48 ` Jim Mattson
2019-02-26 7:57 ` Yang Weijiang
2019-03-01 2:15 ` Xiaoyao Li
2019-02-28 16:04 ` Sean Christopherson
2019-02-28 8:10 ` Yang Weijiang
2019-02-25 13:27 ` [PATCH v3 3/8] KVM:CPUID: Add CPUID support for Guest CET Yang Weijiang
2019-02-28 15:59 ` Sean Christopherson
2019-02-28 8:28 ` Yang Weijiang
2019-03-01 14:53 ` Sean Christopherson
2019-03-03 9:36 ` Yang Weijiang
2019-03-04 18:28 ` Sean Christopherson
2019-03-04 12:17 ` Yang Weijiang
2019-03-04 18:47 ` Sean Christopherson
2019-03-04 10:01 ` Yang Weijiang
2019-03-04 18:54 ` Sean Christopherson
2019-03-04 10:11 ` Yang Weijiang
2019-03-08 11:32 ` Paolo Bonzini
2019-03-10 12:18 ` Yang Weijiang
2019-02-25 13:27 ` [PATCH v3 4/8] KVM:CPUID: Fix xsaves area size calculation for CPUID.(EAX=0xD,ECX=1) Yang Weijiang
2019-02-25 13:27 ` [PATCH v3 5/8] KVM:VMX: Pass through host CET related MSRs to Guest Yang Weijiang
2019-03-04 18:53 ` Sean Christopherson
2019-03-04 10:07 ` Yang Weijiang
2019-03-05 3:21 ` Sean Christopherson
2019-02-25 13:27 ` [PATCH v3 6/8] KVM:VMX: Load Guest CET via VMCS when CET is enabled in Guest Yang Weijiang
2019-02-28 16:17 ` Sean Christopherson
2019-02-28 8:38 ` Yang Weijiang
2019-03-01 14:58 ` Sean Christopherson
2019-03-03 12:26 ` Yang Weijiang
2019-03-04 18:43 ` Sean Christopherson [this message]
2019-03-04 9:56 ` Yang Weijiang
2019-03-05 3:12 ` Sean Christopherson
2019-03-04 12:36 ` Yang Weijiang
2019-03-08 16:28 ` Sean Christopherson
2019-03-08 16:36 ` Paolo Bonzini
2019-02-25 13:27 ` [PATCH v3 7/8] KVM:X86: Add XSS bit 11 and 12 support for CET xsaves/xrstors Yang Weijiang
2019-02-28 16:25 ` Sean Christopherson
2019-02-28 8:44 ` Yang Weijiang
2019-03-08 11:32 ` Paolo Bonzini
2019-03-10 12:20 ` Yang Weijiang
2019-03-10 13:35 ` Yang Weijiang
2019-03-11 15:32 ` Paolo Bonzini
2019-03-12 14:30 ` Yang Weijiang
2019-03-08 10:49 ` Paolo Bonzini
2019-03-11 1:29 ` Kang, Luwei
2019-02-25 13:27 ` [PATCH v3 8/8] KVM:X86: Add user-space read/write interface for CET MSRs Yang Weijiang
2019-02-28 16:32 ` Sean Christopherson
2019-02-28 9:41 ` Yang Weijiang
2019-03-08 17:30 ` Sean Christopherson
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=20190304184307.GC17120@linux.intel.com \
--to=sean.j.christopherson@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=weijiang.yang@intel.com \
--cc=yi.z.zhang@linux.intel.com \
--cc=yu-cheng.yu@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).