linux-kernel - [PATCH 1/5] KVM: SVM: Serialize updates to global OS-Visible Workarounds variables

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251113231420.1695919-2-seanjc@google.com>
Date: Thu, 13 Nov 2025 15:14:16 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Sean Christopherson <seanjc@...gle.com>, Paolo Bonzini <pbonzini@...hat.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [PATCH 1/5] KVM: SVM: Serialize updates to global OS-Visible
 Workarounds variables

Guard writes to the global osvw_status and osvw_len variables with a
spinlock to ensure enabling virtualization on multiple CPUs in parallel
doesn't effectively drop any writes due to writing back stale data.  Don't
bother taking the lock when the boot CPU doesn't support the feature, as
that check is constant for all CPUs, i.e. racing writes will always write
the same value (zero).

Note, the bug was inadvertently "fixed" by commit 9a798b1337af ("KVM:
Register cpuhp and syscore callbacks when enabling hardware"), which
effectively serialized calls to enable virtualization due to how the cpuhp
framework "brings up" CPU.  But KVM shouldn't rely on the mechanics of
cphup to provide serialization.

Signed-off-by: Sean Christopherson <seanjc@...gle.com>
---
 arch/x86/kvm/svm/svm.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index fc42bcdbb520..5612e46e481c 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -77,6 +77,7 @@ static bool erratum_383_found __read_mostly;
  * are published and we know what the new status bits are
  */
 static uint64_t osvw_len = 4, osvw_status;
+static DEFINE_SPINLOCK(osvw_lock);

 static DEFINE_PER_CPU(u64, current_tsc_ratio);

@@ -554,16 +555,19 @@ static int svm_enable_virtualization_cpu(void)
 		if (!err)
 			err = native_read_msr_safe(MSR_AMD64_OSVW_STATUS, &status);

-		if (err)
+		guard(spinlock)(&osvw_lock);
+
+		if (err) {
 			osvw_status = osvw_len = 0;
-		else {
+		} else {
 			if (len < osvw_len)
 				osvw_len = len;
 			osvw_status |= status;
 			osvw_status &= (1ULL << osvw_len) - 1;
 		}
-	} else
+	} else {
 		osvw_status = osvw_len = 0;
+	}

 	svm_init_erratum_383();

-- 
2.52.0.rc1.455.g30608eb744-goog