From: Tom Lendacky <thomas.lendacky@amd.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>,
Alexey Kardashevskiy <aik@amd.com>
Subject: Re: [PATCH 02/10] KVM: SVM: Don't rely on DebugSwap to restore host DR0..DR3
Date: Mon, 24 Feb 2025 14:32:07 -0600 [thread overview]
Message-ID: <7794af2d-b3c2-e1f2-6a55-ecd58a1fcc77@amd.com> (raw)
In-Reply-To: <20250219012705.1495231-3-seanjc@google.com>
On 2/18/25 19:26, Sean Christopherson wrote:
> 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.
>
> Signed-off-by: Sean Christopherson <seanjc@google.com>
See comment below about the Type-A vs Type-B thing, but functionally:
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.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 e3606d072735..6c6d45e13858 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 both
> - * saves and loads debug registers (Type-A). 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",
> - * and so KVM must save DRs if DebugSwap is supported to prevent DRs
> - * from being clobbered by a misbehaving guest.
> + * saves and loads debug registers (Type-A). Sadly, KVM can't prevent
This mention of Type-A was bothering me, so I did some investigation on
this. If DebugSwap (DebugVirtualization in the latest APM) is
disabled/unsupported, DR0-3 and DR0-3 Mask registers are left alone and
the guest sees the host values, they are not fully restored and fully
saved. When DebugVirtualization is enabled, at that point the registers
become Type-B.
I'm not sure whether it is best to update the comment here or in the
first patch.
Thanks,
Tom
> + * 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);
next prev parent reply other threads:[~2025-02-24 20:32 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-19 1:26 [PATCH 00/10] KVM: SVM: Attempt to cleanup SEV_FEATURES Sean Christopherson
2025-02-19 1:26 ` [PATCH 01/10] KVM: SVM: Save host DR masks but NOT DRs on CPUs with DebugSwap Sean Christopherson
2025-02-24 19:38 ` Tom Lendacky
2025-02-25 2:22 ` Kim Phillips
2025-02-25 14:12 ` Tom Lendacky
2025-02-19 1:26 ` [PATCH 02/10] KVM: SVM: Don't rely on DebugSwap to restore host DR0..DR3 Sean Christopherson
2025-02-24 20:32 ` Tom Lendacky [this message]
2025-02-24 22:32 ` Sean Christopherson
2025-02-19 1:26 ` [PATCH 03/10] KVM: SVM: Terminate the VM if a SEV-ES+ guest is run with an invalid VMSA Sean Christopherson
2025-02-24 21:03 ` Tom Lendacky
2025-02-24 22:55 ` Sean Christopherson
2025-02-24 23:55 ` Tom Lendacky
2025-02-25 0:54 ` Sean Christopherson
2025-02-25 1:20 ` Sean Christopherson
2025-02-25 14:42 ` Tom Lendacky
2025-02-19 1:26 ` [PATCH 04/10] KVM: SVM: Don't change target vCPU state on AP Creation VMGEXIT error Sean Christopherson
2025-02-24 21:31 ` Tom Lendacky
2025-02-19 1:27 ` [PATCH 05/10] KVM: SVM: Require AP's "requested" SEV_FEATURES to match KVM's view Sean Christopherson
2025-02-24 21:46 ` Tom Lendacky
2025-02-19 1:27 ` [PATCH 06/10] KVM: SVM: Simplify request+kick logic in SNP AP Creation handling Sean Christopherson
2025-02-19 6:19 ` Gupta, Pankaj
2025-02-24 21:48 ` Tom Lendacky
2025-02-19 1:27 ` [PATCH 07/10] KVM: SVM: Use guard(mutex) to simplify SNP AP Creation error handling Sean Christopherson
2025-02-24 21:49 ` Tom Lendacky
2025-02-19 1:27 ` [PATCH 08/10] KVM: SVM: Mark VMCB dirty before processing incoming snp_vmsa_gpa Sean Christopherson
2025-02-24 21:58 ` Tom Lendacky
2025-02-19 1:27 ` [PATCH 09/10] KVM: SVM: Use guard(mutex) to simplify SNP vCPU state updates Sean Christopherson
2025-02-24 22:57 ` Tom Lendacky
2025-02-19 1:27 ` [PATCH 10/10] KVM: SVM: Invalidate "next" SNP VMSA GPA even on failure Sean Christopherson
2025-02-25 0:00 ` Tom Lendacky
2025-02-20 22:51 ` [PATCH 00/10] KVM: SVM: Attempt to cleanup SEV_FEATURES Tom Lendacky
2025-02-25 0:02 ` Tom Lendacky
2025-02-25 2:21 ` Kim Phillips
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=7794af2d-b3c2-e1f2-6a55-ecd58a1fcc77@amd.com \
--to=thomas.lendacky@amd.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=pbonzini@redhat.com \
--cc=seanjc@google.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