All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: sashiko-reviews@lists.linux.dev
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH 2/2] KVM: nVMX: Don't use vmcs01.GUEST_CR3 to snapshot L1's CR3 when EPT is disabled
Date: Wed, 3 Jun 2026 15:57:12 -0700	[thread overview]
Message-ID: <aiCxSL0rEkUFTW06@google.com> (raw)
In-Reply-To: <20260603225013.99E151F00893@smtp.kernel.org>

On Wed, Jun 03, 2026, sashiko-bot@kernel.org wrote:
> > diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
> > --- a/arch/x86/kvm/vmx/nested.c
> > +++ b/arch/x86/kvm/vmx/nested.c
> > @@ -3651,19 +3651,14 @@ enum nvmx_vmentry_status nested_vmx_enter_non_root_mode(struct kvm_vcpu *vcpu,
> >  				    &vmx->nested.pre_vmenter_ssp_tbl);
> >  
> >  	/*
> > -	 * Overwrite vmcs01.GUEST_CR3 with L1's CR3 if EPT is disabled.  In the
> > -	 * event of a "late" VM-Fail, i.e. a VM-Fail detected by hardware but
> > -	 * not KVM, KVM must unwind its software model to the pre-VM-Entry host
> > -	 * state.  When EPT is disabled, GUEST_CR3 holds KVM's shadow CR3, not
> > -	 * L1's "real" CR3, which causes nested_vmx_restore_host_state() to
> > -	 * corrupt vcpu->arch.cr3.  Stuffing vmcs01.GUEST_CR3 results in the
> > -	 * unwind naturally setting arch.cr3 to the correct value.  Smashing
> > -	 * vmcs01.GUEST_CR3 is safe because nested VM-Exits, and the unwind,
> > -	 * reset KVM's MMU, i.e. vmcs01.GUEST_CR3 is guaranteed to be
> > -	 * overwritten with a shadow CR3 prior to re-entering L1.
> > +	 * Stash L1's CR3, so that in the event of a "late" VM-Fail, i.e. a
> > +	 * VM-Fail detected by hardware but not KVM, KVM can unwind its
> > +	 * software model to the pre-VM-Entry host state.  When EPT is
> > +	 * disabled, GUEST_CR3 holds KVM's shadow CR3, not L1's "real" CR3,
> > +	 * and so simply restoring from vmcs01.GUEST_CR3 would corrupt
> > +	 * vcpu->arch.cr3.
> >  	 */
> > -	if (!enable_ept)
> > -		vmcs_writel(GUEST_CR3, vcpu->arch.cr3);
> > +	vmx->nested.pre_vmenter_cr3 = vcpu->arch.cr3;
> 
> [Severity: High]
> Does directly reading vcpu->arch.cr3 here capture a stale value when EPT is
> enabled?
> 
> Because KVM does not intercept L1 CR3 writes when EPT is enabled, L1 can
> update its CR3 without KVM immediately tracking it. On VM-Exit (such as for
> VMLAUNCH), KVM invalidates the CR3 register cache by clearing the
> VCPU_REG_CR3 availability bit.
> 
> If nested_vmx_enter_non_root_mode() directly assigns vmx->nested.pre_vmenter_cr3
> from vcpu->arch.cr3 instead of using kvm_read_cr3(vcpu), it seems this would
> bypass the cache refresh and stash a stale CR3 value.

Gah, yes.

  reply	other threads:[~2026-06-03 22:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-03 22:34 [PATCH 0/2] KVM: nVMX: Fix ept=n bugs where KVM runs L2 with guest CR3 Sean Christopherson
2026-06-03 22:34 ` [PATCH 1/2] KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into "normal" checks Sean Christopherson
2026-06-03 22:34 ` [PATCH 2/2] KVM: nVMX: Don't use vmcs01.GUEST_CR3 to snapshot L1's CR3 when EPT is disabled Sean Christopherson
2026-06-03 22:50   ` sashiko-bot
2026-06-03 22:57     ` Sean Christopherson [this message]
2026-06-04  6:23 ` [PATCH 0/2] KVM: nVMX: Fix ept=n bugs where KVM runs L2 with guest CR3 Jim Mattson
2026-06-04 13:15   ` Sean Christopherson
2026-06-04 14:13     ` Jim Mattson

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=aiCxSL0rEkUFTW06@google.com \
    --to=seanjc@google.com \
    --cc=kvm@vger.kernel.org \
    --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.