All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yan Zhao <yan.y.zhao@intel.com>
To: Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>, <kvm@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, Kai Huang <kai.huang@intel.com>,
	Rick Edgecombe <rick.p.edgecombe@intel.com>,
	Sashiko Bot <sashiko-bot@kernel.org>
Subject: Re: [PATCH 4/4] KVM: x86/mmu: Add sanity check to detect stale page faults in "map private PFN"
Date: Tue, 11 Aug 2026 14:40:50 +0800	[thread overview]
Message-ID: <anrD8nI8RfYoNvbf@yzhao56-desk.sh.intel.com> (raw)
In-Reply-To: <anpr/H5Hxw1EMkTj@yzhao56-desk.sh.intel.com>

On Tue, Aug 11, 2026 at 08:25:32AM +0800, Yan Zhao wrote:
> On Thu, Aug 06, 2026 at 02:40:50PM -0700, Sean Christopherson wrote:
> > Harden the "map private PFN" flow against potentially-fatal bugs or future
> > KVM changes by checking for a stale "fault" prior to actually mapping the
> > PFN into the guest.  While it should be impossible for the "page fault" to
> > become stale, the sanity check is cheap, whereas a broken assumption would
> > have a high probability of leading to a guest-expoitable use-after-free.
> > 
> > Snapshot the invalidation sequence after acquiring mmu_lock to avoid false
> > positives, even though doing so completely voids anys and all protection
> > against unexpected invalidations.  Pretty much the entire point of
> > kvm_tdp_mmu_map_private_pfn() is that it allows mapping a PFN that was
> > gifted by the caller, i.e. the caller would have to mess up its one and
> > only responsibility.
> > 
> > Signed-off-by: Sean Christopherson <seanjc@google.com>
> > ---
> >  arch/x86/kvm/mmu/mmu.c | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> > 
> > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> > index 379f570ef04f..76e3cd717324 100644
> > --- a/arch/x86/kvm/mmu/mmu.c
> > +++ b/arch/x86/kvm/mmu/mmu.c
> > @@ -5210,6 +5210,16 @@ int kvm_tdp_mmu_map_private_pfn(struct kvm_vcpu *vcpu, gfn_t gfn, kvm_pfn_t pfn)
> >  		 */
> >  		WARN_ON_ONCE(kvm_test_request(KVM_REQ_MMU_FREE_OBSOLETE_ROOTS, vcpu));
> >  
> > +		/*
> > +		 * Snapshot the invalidation sequence counter after acquiring
> > +		 * mmu_lock, as guest_memfd guarantees the validity of the pfn,
> > +		 * i.e. any concurrent invalidations are guaranteed to be
> > +		 * irrelevant.
> > +		 */
> > +		fault.mmu_seq = vcpu->kvm->mmu_invalidate_seq;
> Could you explain more about the conditions under which a fault is stale while
> guest_memfd guarantees the validity of the pfn?
> 
> Given that kvm_tdp_mmu_map_private_pfn() already asserts holding slots_lock and
> invalidate_lock, I can't think of one. If we add the sanity check because it's
> cheap, why don't we save fault.mmu_seq before getting the pfn to guard against
> stale pfn as well?
> 
> > +		if (is_page_fault_stale(vcpu, &fault))
is_page_fault_stale() gets sp from vcpu->arch.mmu->root.hpa:
"struct kvm_mmu_page *sp = root_to_sp(vcpu->arch.mmu->root.hpa);".

For TDX, sp should be from vcpu->arch.mmu->mirror_root_hpa?

> > +			continue;
> > +
> >  		r = kvm_tdp_mmu_map(vcpu, &fault);
> >  	} while (r == RET_PF_RETRY);
> >

  reply	other threads:[~2026-08-11  7:21 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-06 21:40 [PATCH 0/4] KVM: x86/mmu: Fix pre-fault and map private loops Sean Christopherson
2026-08-06 21:40 ` [PATCH 1/4] KVM: x86/mmu: Reload MMU on *every* page pre-fault attempt/iteration Sean Christopherson
2026-08-07  8:58   ` Huang, Kai
2026-08-07 19:04   ` Edgecombe, Rick P
2026-08-07 19:11     ` Sean Christopherson
2026-08-06 21:40 ` [PATCH 2/4] KVM: x86/mmu: Harden "map private PFN" against unexpected root invalidation Sean Christopherson
2026-08-06 22:14   ` sashiko-bot
2026-08-06 22:21     ` Sean Christopherson
2026-08-07 20:26   ` Edgecombe, Rick P
2026-08-07 22:18     ` Sean Christopherson
2026-08-10 20:01       ` Edgecombe, Rick P
2026-08-11  7:01   ` Yan Zhao
2026-08-11 17:07     ` Sean Christopherson
2026-08-06 21:40 ` [PATCH 3/4] KVM: x86/mmu: Top-up memory caches when retrying "map private PFN" Sean Christopherson
2026-08-06 21:56   ` sashiko-bot
2026-08-06 22:07     ` Sean Christopherson
2026-08-07 20:38   ` Edgecombe, Rick P
2026-08-07 22:13     ` Sean Christopherson
2026-08-10 20:37       ` Edgecombe, Rick P
2026-08-10 20:43         ` Sean Christopherson
2026-08-06 21:40 ` [PATCH 4/4] KVM: x86/mmu: Add sanity check to detect stale page faults in " Sean Christopherson
2026-08-06 21:54   ` sashiko-bot
2026-08-06 22:12     ` Sean Christopherson
2026-08-11  0:25   ` Yan Zhao
2026-08-11  6:40     ` Yan Zhao [this message]
2026-08-11 17:12     ` 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=anrD8nI8RfYoNvbf@yzhao56-desk.sh.intel.com \
    --to=yan.y.zhao@intel.com \
    --cc=kai.huang@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rick.p.edgecombe@intel.com \
    --cc=sashiko-bot@kernel.org \
    --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 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.