linux-kernel - [RFC PATCH] KVM: x86/speculation/taa: Export TAA

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <5ce91cdab031ecfdc82975ae492e4804b1c862d9.1654849348.git.pawan.kumar.gupta@linux.intel.com>
Date:   Fri, 10 Jun 2022 01:29:34 -0700
From:   Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
To:     Paolo Bonzini <pbonzini@...hat.com>,
        Sean Christopherson <seanjc@...gle.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
        tony.luck@...el.com, ak@...ux.intel.com,
        "H. Peter Anvin" <hpa@...or.com>
Cc:     kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [RFC PATCH] KVM: x86/speculation/taa: Export TAA_NO to guest when
 host is not affected

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@...ux.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