Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp2940703imb; Mon, 4 Mar 2019 19:04:24 -0800 (PST) X-Google-Smtp-Source: APXvYqwDicwgCQR+eRZkR1aBxftm+gtmcm//H1CDVw+xbPekxDlpuEMRFB5EiNru8Y33+z370dB2 X-Received: by 2002:a17:902:bf01:: with SMTP id bi1mr6022281plb.252.1551755064408; Mon, 04 Mar 2019 19:04:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551755064; cv=none; d=google.com; s=arc-20160816; b=BDtjafzqsWibhOAZGLgZxTZcPYjulQMw2/Gq+V2uf2+6LTHrbAgtKI2Wj4fuPvQZvu KLOG9ZY/zFDzrxAWKxwu2t1Urz1dPzUKb1yVLp3lcbEprdHjAaTxrSVeqH+Mlw1upAnL cmySGTyDIaWePXHxa2ImopW9CJxxSfjinrtTbfm+N0KWON+YDRpsUgZM+HebFeEvYiqU XPO8+455SW82+rbJXspxcxWCmGbAZNeAPlwUtALVMIMLWDM7Bk3n9Tc6TuYXpqwtsc+Q wpQQrlSkNHwCMly5LJCbfrxiwmQtWKYQhkh1ru6z7D0hPUx956hxQ+tXmGQu117HhNLH 7zYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=20n5rv4cfadtMbDKK2lDKIBW0H6K+9WIDRbkTNCfJ4E=; b=GmKO7SUmieG/XCj453XYtpTeQZEhdfR9PYM98iv14ZckSxvygMwaEHUT1KxnXFkPsm x5f/nqjjF7RBf+HggIj4u5UYB5F2LPIMMiVzEENJSMeB+RxYphjgyYVMVJF2pfO/a0Uy lxiQ4FMJYs2rbvu9YHQCYPfffkwTKQ2xA9L+Hp25QS64idqu0TmcyrM8opQoSu4oKYJB 038bjEx9CCaH12RMBcdKU0U/NtVci2EKj4fN8UilqpkxMc5/6bk2MIYP21B1vY5I0PAa +S9Yq2gJCgklZKuxa83vWKBWnp0U+gWZ+deNuu41JMb1UbRktPbOPaOUOmIAkFGzsLXy xq+g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n16si7067149pgj.27.2019.03.04.19.04.09; Mon, 04 Mar 2019 19:04:24 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726968AbfCEDCO (ORCPT + 99 others); Mon, 4 Mar 2019 22:02:14 -0500 Received: from mga01.intel.com ([192.55.52.88]:20809 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726522AbfCEDCO (ORCPT ); Mon, 4 Mar 2019 22:02:14 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Mar 2019 19:02:13 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,442,1544515200"; d="scan'208";a="121008068" Received: from local-michael-cet-test.sh.intel.com (HELO localhost) ([10.239.159.128]) by orsmga006.jf.intel.com with ESMTP; 04 Mar 2019 19:02:09 -0800 Date: Mon, 4 Mar 2019 17:56:40 +0800 From: Yang Weijiang To: Sean Christopherson 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 , wei.w.wang@intel.com, weijiang.yang@inte.com Subject: Re: [PATCH v3 6/8] KVM:VMX: Load Guest CET via VMCS when CET is enabled in Guest Message-ID: <20190304095640.GA3576@local-michael-cet-test.sh.intel.com> References: <20190225132716.6982-1-weijiang.yang@intel.com> <20190225132716.6982-7-weijiang.yang@intel.com> <20190228161715.GF6166@linux.intel.com> <20190228083844.GC12006@local-michael-cet-test.sh.intel.com> <20190301145819.GC22584@linux.intel.com> <20190303122608.GA32013@local-michael-cet-test.sh.intel.com> <20190304184307.GC17120@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190304184307.GC17120@linux.intel.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 04, 2019 at 10:43:07AM -0800, Sean Christopherson wrote: > 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 > > > > > > Signed-off-by: Yang Weijiang > > > > > > --- > > > > > > 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 > > > > > > #include > > > > > > #include > > > > > > +#include > > > > > > > > > > > > #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. Cannot agree with you more! This is some design limitation, but from my point of view, once vmm exposes CET capability to guest via CPUID, it grants the guest kernel freedom to choose which features to be enabled, we don't need to add extra constraints on the usage.