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 <[email protected]> > > > Signed-off-by: Yang Weijiang <[email protected]> > > > --- > > > 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.
