From: Sean Christopherson <seanjc@google.com>
To: Kyle Zeng <kylebot@openai.com>
Cc: sashiko-reviews@lists.linux.dev, kvm@vger.kernel.org
Subject: Re: [PATCH v3] KVM: x86: Restrict saved GPA writes to hardware write faults
Date: Wed, 16 Sep 2026 12:13:51 -0700 [thread overview]
Message-ID: <aqrqb-lz2f0gCwuF@google.com> (raw)
In-Reply-To: <aqnNAsGF_iUQsVX1@com-75606>
On Tue, Sep 15, 2026, Kyle Zeng wrote:
> On Tue, Sep 15, 2026 at 10:41:03PM +0000, sashiko-bot@kernel.org wrote:
> > > @@ -6454,7 +6456,18 @@ int x86_emulate_instruction(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa,
> > >
> > > /* With shadow page tables, cr2 contains a GVA or nGPA. */
> > > if (vcpu->arch.mmu->root_role.direct) {
> > > - ctxt->gpa_available = true;
> > > + ctxt->gpa_access = ACC_READ_MASK;
> > > + /*
> > > + * Always allow writes for SEV guests, as the guest's
> > > + * page tables are encrypted, i.e. KVM can't walk the
> > > + * guest's page tables and so must always use the GPA
> > > + * from the initial fault. Restricting use of the GPA
> > > + * to the access type that faulted would prevent KVM
> > > + * from emulating RMW operations for SEV guests.
> > > + */
> > > + if ((emulation_type & EMULTYPE_PF_WRITE) ||
> > > + (cpu_feature_enabled(X86_FEATURE_SVM) && is_sev_guest(vcpu)))
> >
> > [Severity: High]
> > Could this lead to an out-of-bounds read and type confusion?
...
> Is there a configuration that gets past the initialization checks and
> demonstrates an incorrect access? I'd like to establish that before
> treating this as a functional issue.
Eh, doesn't matter, my suggestion was terrible. I forgot that is_sev_guest()
needs to check embedded data; I was thinking of TDX and SNP VMs, which have
dedicated VM types.
I think the right way to handle this is to track if a VM has protected page
tables. That'd also help communicate/document why KVM has this weird behavior.
Untested...
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 30ffaa65f589..90c950c12900 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1166,6 +1166,7 @@ struct kvm_arch {
u8 mmu_valid_gen;
u8 vm_type;
bool has_private_mem;
+ bool has_protected_page_tables;
bool has_protected_state;
bool has_protected_eoi;
bool has_protected_pmu;
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index b56c39c53c98..7f544658b1cc 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -2955,6 +2955,7 @@ void sev_vm_init(struct kvm *kvm)
kvm->arch.has_protected_state = true;
fallthrough;
case KVM_X86_SEV_VM:
+ kvm->arch.has_protected_page_tables = true;
kvm->arch.pre_fault_allowed = !kvm->arch.has_private_mem;
to_kvm_sev_info(kvm)->need_init = true;
break;
diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
index 014545c1839b..35022f308e06 100644
--- a/arch/x86/kvm/vmx/tdx.c
+++ b/arch/x86/kvm/vmx/tdx.c
@@ -616,6 +616,7 @@ int tdx_vm_init(struct kvm *kvm)
{
struct kvm_tdx *kvm_tdx = to_kvm_tdx(kvm);
+ kvm->arch.has_protected_page_tables = true;
kvm->arch.has_protected_state = true;
/*
* TDX Module doesn't allow the hypervisor to modify the EOI-bitmap,
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index f36b952624c8..7e5e2e587086 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -33,7 +33,6 @@
#include "lapic.h"
#include "xen.h"
#include "smm.h"
-#include "svm/svm.h"
#include <linux/clocksource.h>
#include <linux/timekeeping.h>
@@ -6412,15 +6411,14 @@ int x86_emulate_instruction(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa,
if (vcpu->arch.mmu->root_role.direct) {
ctxt->gpa_access = ACC_READ_MASK;
/*
- * Always allow writes for SEV guests, as the guest's
- * page tables are encrypted, i.e. KVM can't walk the
- * guest's page tables and so must always use the GPA
- * from the initial fault. Restricting use of the GPA
- * to the access type that faulted would prevent KVM
- * from emulating RMW operations for SEV guests.
+ * Always allow writes for guests with protected page
+ * tables, as KVM can't walk the guest's page tables,
+ * i.e. KVM can't get the RMW protections for a given
+ * GVA to see if the write side of a RMW operation
+ * should be allowed.
*/
if ((emulation_type & EMULTYPE_PF_WRITE) ||
- (cpu_feature_enabled(X86_FEATURE_SVM) && is_sev_guest(vcpu)))
+ vcpu->kvm->arch.has_protected_page_tables)
ctxt->gpa_access |= ACC_WRITE_MASK;
ctxt->gpa_val = cr2_or_gpa;
}
next prev parent reply other threads:[~2026-09-16 19:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-15 22:26 [PATCH v3] KVM: x86: Restrict saved GPA writes to hardware write faults Kyle Zeng
2026-09-15 22:41 ` sashiko-bot
2026-09-15 22:56 ` Kyle Zeng
2026-09-16 19:13 ` Sean Christopherson [this message]
2026-09-18 3:33 ` Kyle Zeng
2026-09-16 19:16 ` 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=aqrqb-lz2f0gCwuF@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=kylebot@openai.com \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.