Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp2944961imb; Mon, 4 Mar 2019 19:12:39 -0800 (PST) X-Google-Smtp-Source: APXvYqyFy/ZcLy5XAaaHGrPxUjEcFxfyDrZ1dQIn4R8NtmD5u6CsxQAPb+lvyNvCPIU009u61s1Z X-Received: by 2002:a63:4607:: with SMTP id t7mr6109578pga.306.1551755559272; Mon, 04 Mar 2019 19:12:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551755559; cv=none; d=google.com; s=arc-20160816; b=wjxgVi/GazdwroCVCg/WqUN3HyHISYP87VlAae8KTIfXKf5Oq7eoM91ZAp4AeiIJub QPJp0uSVert5tSRmQeIOPie85jL1p5DA25t5+PP0V+7h87cG3kYp5B1h4/AtiZGo5n9Q SY9jaJqNynFCHd8YAgoF8VbtADNA6y5hdbdxFBYGcaQftEQWpDQT9oZzdk9D7JExLkBz SQCfI2Bmp2DT+iLLSca71tJNoyWOc0zctCfeemXBrOx56AcyH9BQM7nzZ9DuYQkpFXdz ddWi26J90ERg1/QIypXMPAorKfO+LZvTAdG+HVVwiv0B7SJnDZQRyseF1/fp0WBPVwbb ArZA== 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=8VvxPUOPkmBYtbjpHs53kGRQ4I6IdESzx7TKiRga8Tk=; b=auo0RZw4qukiQlslEWpG07+Nz1khczATgMpqXeQvKb/nBdVQuCEc1Pvb4SkEyZpIEo a9/+weKK+8reIiab25c8P4PHxRMgY5wabZfc6drGsqfR5fNglH2Sj0PLbZX9yrc9QP09 +5iq7qh+9a19Z+TdYwqOKj89mwdEzhgHpixdewd9LoNs8mjHAjH7aYWvum+RPs5pXCc/ 1g0cv/fhkvGui4h3pFDCSbJ0A1T5uEU4VNLyCLNY6ixbixKKSKbHIO+HRoytUIm4Hyeu WK/u8mGpdaHOMgYttufHNs99Q87nYhNMG5iPY1EC1d8dwJolTOUtZqeEsVyDz+2A2reA FVjg== 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 t18si6799093pgh.89.2019.03.04.19.12.23; Mon, 04 Mar 2019 19:12:39 -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 S1726938AbfCEDMD (ORCPT + 99 others); Mon, 4 Mar 2019 22:12:03 -0500 Received: from mga05.intel.com ([192.55.52.43]:30000 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726522AbfCEDMD (ORCPT ); Mon, 4 Mar 2019 22:12:03 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Mar 2019 19:12:02 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,442,1544515200"; d="scan'208";a="304412221" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.181]) by orsmga005.jf.intel.com with ESMTP; 04 Mar 2019 19:12:02 -0800 Date: Mon, 4 Mar 2019 19:12:02 -0800 From: Sean Christopherson To: Yang Weijiang 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: <20190305031202.GI17120@linux.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> <20190304095640.GA3576@local-michael-cet-test.sh.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190304095640.GA3576@local-michael-cet-test.sh.intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) 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 05:56:40PM +0800, Yang Weijiang wrote: > 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. But if KVM allows SHSTK and IBT to be toggled independently then the VMM has only exposed SHSTK or IBT, not CET as whole. Even if SHSTK and IBT are bundled together the guest still has to opt-in to enabling each feature. I don't see what we gain by pretending that SHSTK/IBT can be individually exposed to the guest, and on the flip side doing so creates a virtualization hole.