Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 10 Jun 2022 01:29:34 -0700
From:   Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
To:     Paolo Bonzini <pbonzini@redhat.com>,
        Sean Christopherson <seanjc@google.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        Wanpeng Li <wanpengli@tencent.com>,
        Jim Mattson <jmattson@google.com>,
        Joerg Roedel <joro@8bytes.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
        tony.luck@intel.com, ak@linux.intel.com,
        "H. Peter Anvin" <hpa@zytor.com>
Cc:     kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [RFC PATCH] KVM: x86/speculation/taa: Export TAA_NO to guest when
 host is not affected
Message-ID: <5ce91cdab031ecfdc82975ae492e4804b1c862d9.1654849348.git.pawan.kumar.gupta@linux.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Precedence: bulk

On CPUs that are not affected by TSX Async Abort (TAA), some host/guest
configurations can result in guest unnecessarily report TAA
vulnerability and deploy its mitigation. Particularly when a host
exports MSR_IA32_TSX_CTRL to guests and hides TAA_NO.

Due to MSR_IA32_TSX_CTRL exported by commit 7131636e7ea5 ("KVM: x86:
Allow guests to see MSR_IA32_TSX_CTRL even if tsx=off"), a guest with
CPUID.RTM=0 and "tsx=on" cmdline parameter will try to enable TSX
feature (using the exported MSR). Although TSX won't actually be enabled
in the hardware, but the guest would think that it is. Such a guest
would then set its X86_FEATURE_RTM. Also, KVM hides MSR
IA32_ARCH_CAPABILITIES[TAA_NO] bit from guests when TSX is disabled on
host. TAA mitigation selection in guest then sees X86_FEATURE_RTM=1 and
TAA_NO=0, and deploys "Clear CPU buffers" mitigation.

Export TAA_NO to guests when host is not affected by TAA to ensure that
guest doesn't deploy TAA mitigation unnecessarily.

Fixes: c11f83e0626b ("KVM: vmx: implement MSR_IA32_TSX_CTRL disable RTM functionality")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215969
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
I am not sure if exporting TAA_NO would affect migration pools and if
this is a sane thing to do. Any feedback on same is highly appreciated.

 arch/x86/kvm/x86.c | 19 +------------------
 1 file changed, 1 insertion(+), 18 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index e9473c7c7390..1d14b5f82edc 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1595,25 +1595,8 @@ static u64 kvm_get_arch_capabilities(void)
 		data |= ARCH_CAP_SSB_NO;
 	if (!boot_cpu_has_bug(X86_BUG_MDS))
 		data |= ARCH_CAP_MDS_NO;
-
-	if (!boot_cpu_has(X86_FEATURE_RTM)) {
-		/*
-		 * If RTM=0 because the kernel has disabled TSX, the host might
-		 * have TAA_NO or TSX_CTRL.  Clear TAA_NO (the guest sees RTM=0
-		 * and therefore knows that there cannot be TAA) but keep
-		 * TSX_CTRL: some buggy userspaces leave it set on tsx=on hosts,
-		 * and we want to allow migrating those guests to tsx=off hosts.
-		 */
-		data &= ~ARCH_CAP_TAA_NO;
-	} else if (!boot_cpu_has_bug(X86_BUG_TAA)) {
+	if (!boot_cpu_has_bug(X86_BUG_TAA))
 		data |= ARCH_CAP_TAA_NO;
-	} else {
-		/*
-		 * Nothing to do here; we emulate TSX_CTRL if present on the
-		 * host so the guest can choose between disabling TSX or
-		 * using VERW to clear CPU buffers.
-		 */
-	}
 
 	return data;
 }

base-commit: f2906aa863381afb0015a9eb7fefad885d4e5a56
-- 
2.35.3