public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	 Naveen N Rao <naveen@kernel.org>,
	Kim Phillips <kim.phillips@amd.com>,
	 Tom Lendacky <thomas.lendacky@amd.com>,
	Alexey Kardashevskiy <aik@amd.com>,
	 Pankaj Gupta <pankaj.gupta@amd.com>
Subject: [PATCH v2 02/10] KVM: SVM: Don't rely on DebugSwap to restore host DR0..DR3
Date: Wed, 26 Feb 2025 17:25:33 -0800	[thread overview]
Message-ID: <20250227012541.3234589-3-seanjc@google.com> (raw)
In-Reply-To: <20250227012541.3234589-1-seanjc@google.com>

Never rely on the CPU to restore/load host DR0..DR3 values, even if the
CPU supports DebugSwap, as there are no guarantees that SNP guests will
actually enable DebugSwap on APs.  E.g. if KVM were to rely on the CPU to
load DR0..DR3 and skipped them during hw_breakpoint_restore(), KVM would
run with clobbered-to-zero DRs if an SNP guest created APs without
DebugSwap enabled.

Update the comment to explain the dangers, and hopefully prevent breaking
KVM in the future.

Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kvm/svm/sev.c | 21 ++++++++++++---------
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 5c3d8618b722..719cd48330f1 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -4594,18 +4594,21 @@ void sev_es_prepare_switch_to_guest(struct vcpu_svm *svm, struct sev_es_save_are
 	/*
 	 * If DebugSwap is enabled, debug registers are loaded but NOT saved by
 	 * the CPU (Type-B). If DebugSwap is disabled/unsupported, the CPU does
-	 * not save or load debug registers.  Sadly, on CPUs without
-	 * ALLOWED_SEV_FEATURES, KVM can't prevent SNP guests from enabling
-	 * DebugSwap on secondary vCPUs without KVM's knowledge via "AP Create".
-	 * Save all registers if DebugSwap is supported to prevent host state
-	 * from being clobbered by a misbehaving guest.
+	 * not save or load debug registers.  Sadly, KVM can't prevent SNP
+	 * guests from lying about DebugSwap on secondary vCPUs, i.e. the
+	 * SEV_FEATURES provided at "AP Create" isn't guaranteed to match what
+	 * the guest has actually enabled (or not!) in the VMSA.
+	 *
+	 * If DebugSwap is *possible*, save the masks so that they're restored
+	 * if the guest enables DebugSwap.  But for the DRs themselves, do NOT
+	 * rely on the CPU to restore the host values; KVM will restore them as
+	 * needed in common code, via hw_breakpoint_restore().  Note, KVM does
+	 * NOT support virtualizing Breakpoint Extensions, i.e. the mask MSRs
+	 * don't need to be restored per se, KVM just needs to ensure they are
+	 * loaded with the correct values *if* the CPU writes the MSRs.
 	 */
 	if (sev_vcpu_has_debug_swap(svm) ||
 	    (sev_snp_guest(kvm) && cpu_feature_enabled(X86_FEATURE_DEBUG_SWAP))) {
-		hostsa->dr0 = native_get_debugreg(0);
-		hostsa->dr1 = native_get_debugreg(1);
-		hostsa->dr2 = native_get_debugreg(2);
-		hostsa->dr3 = native_get_debugreg(3);
 		hostsa->dr0_addr_mask = amd_get_dr_addr_mask(0);
 		hostsa->dr1_addr_mask = amd_get_dr_addr_mask(1);
 		hostsa->dr2_addr_mask = amd_get_dr_addr_mask(2);
-- 
2.48.1.711.g2feabab25a-goog


  parent reply	other threads:[~2025-02-27  1:25 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-27  1:25 [PATCH v2 00/10] KVM: SVM: Attempt to cleanup SEV_FEATURES Sean Christopherson
2025-02-27  1:25 ` [PATCH v2 01/10] KVM: SVM: Save host DR masks on CPUs with DebugSwap Sean Christopherson
2025-02-27  1:25 ` Sean Christopherson [this message]
2025-02-27  1:25 ` [PATCH v2 03/10] KVM: SVM: Refuse to attempt VRMUN if an SEV-ES+ guest has an invalid VMSA Sean Christopherson
2025-02-27 16:03   ` Tom Lendacky
2025-02-27 16:56   ` Gupta, Pankaj
2025-02-27  1:25 ` [PATCH v2 04/10] KVM: SVM: Don't change target vCPU state on AP Creation VMGEXIT error Sean Christopherson
2025-02-27 10:25   ` Gupta, Pankaj
2025-02-27  1:25 ` [PATCH v2 05/10] KVM: SVM: Require AP's "requested" SEV_FEATURES to match KVM's view Sean Christopherson
2025-02-27  7:12   ` Gupta, Pankaj
2025-02-27 14:33     ` Sean Christopherson
2025-02-27 15:18       ` Gupta, Pankaj
2025-02-27 15:42         ` Sean Christopherson
2025-02-27  1:25 ` [PATCH v2 06/10] KVM: SVM: Simplify request+kick logic in SNP AP Creation handling Sean Christopherson
2025-02-27  1:25 ` [PATCH v2 07/10] KVM: SVM: Use guard(mutex) to simplify SNP AP Creation error handling Sean Christopherson
2025-02-27 16:51   ` Gupta, Pankaj
2025-02-27  1:25 ` [PATCH v2 08/10] KVM: SVM: Mark VMCB dirty before processing incoming snp_vmsa_gpa Sean Christopherson
2025-02-27  1:25 ` [PATCH v2 09/10] KVM: SVM: Use guard(mutex) to simplify SNP vCPU state updates Sean Christopherson
2025-02-27  1:25 ` [PATCH v2 10/10] KVM: SVM: Invalidate "next" SNP VMSA GPA even on failure Sean Christopherson
2025-03-05  1:05 ` [PATCH v2 00/10] KVM: SVM: Attempt to cleanup SEV_FEATURES Sean Christopherson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250227012541.3234589-3-seanjc@google.com \
    --to=seanjc@google.com \
    --cc=aik@amd.com \
    --cc=kim.phillips@amd.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=naveen@kernel.org \
    --cc=pankaj.gupta@amd.com \
    --cc=pbonzini@redhat.com \
    --cc=thomas.lendacky@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox