Re: [PATCH v2] KVM: x86/mmu: Write-protect tracked GFNs in all address spaces

[Jinu Kim]

Thanks. After considering your comments, I think v2 is trying to solve a
broader problem than the one reported, and that the resulting complexity
is difficult to justify.

One thing I do not understand is the proposed revert of 0f38453cdb2e.
The original pte_list_remove() panic was reproduced on then-current
mainline with 0cb2af2ea66a, 81ccda30b4e8, and aad885e774966 already
present.  The panic remained reachable there, and 0f38453cdb2e stopped
it.  How would those three commits prevent the original upper-level
shadow page from becoming unsync?

Your comments also made me separate the general limitations of write
tracking from a narrower issue in this case.  I understand that KVM
cannot guarantee write tracking for every way guest page-table memory can
be modified, and I have not established a current-mainline host-security
consequence for the remaining cross-address-space revocation issue.

In that narrower framing, there may still be something worth fixing.  In
the reported SMM configuration, KVM creates CPU SPTEs in both address
spaces for the same GFN and backing page, accounts that GFN as backing an
indirect shadow page, but can leave the peer SPTE MMU-writable.  KVM's
shadow-page accounting state and the permissions installed by KVM are
therefore inconsistent with each other.

Fixing that local mismatch would not imply support for DMA, host writes,
arbitrary aliases, or a general guarantee that KVM observes all writes to
guest page-table memory.  Those cases can remain unsupported and be
documented as such.

If this narrower boundary makes sense to you, I will rework the patch
around the existing shadow-page accounting and synchronization
transitions.  A replacement would keep the normal mapping and memslot
lifecycle paths unchanged and avoid introducing persistent
cross-address-space state.

Regards,
Jinu

2026년 8월 4일 (화) 오후 10:10, Sean Christopherson <seanjc@xxxxxxxxxx>님이 작성:
>
> On Tue, Aug 04, 2026, Jinu Kim wrote:
> > KVM relies on write tracking to fault all subsequent guest CPU writes to a
> > GFN that backs a shadow page.  The write-protection installed when tracking
> > starts is currently restricted to the supplied memslot.
> >
> > With SMM, the same backing page can be mapped through both x86 address
> > spaces.  If the peer address space already has a writable SPTE, a guest
> > write through that mapping bypasses page tracking and leaves KVM's shadow
> > state stale.
>
> ...
>
> > This restores the invariant that a tracked GFN cannot remain, or become,
> > CPU-writable through another x86 address space.
>
> Not really.  There are multiple ways to bypass KVM's write tracking, for all
> intents and purposes they've already existed, and realistically I don't see us
> ever plugging all the holes.
>
> >  arch/x86/kvm/mmu.h              | 11 +++++
> >  arch/x86/kvm/mmu/mmu.c          | 77 +++++++++++++++++++++++++++------
> >  arch/x86/kvm/mmu/mmu_internal.h |  3 ++
> >  arch/x86/kvm/mmu/page_track.c   |  2 +-
> >  arch/x86/kvm/x86.c              |  8 ++--
> >  5 files changed, 84 insertions(+), 17 deletions(-)
>
> Assuming the true badness referenced by commits:
>
>   2e8a2c1b0306 ("KVM: x86/mmu: Check all address spaces before skipping unsync")
>   0f38453cdb2e ("KVM: x86/mmu: Check write tracking in all address spaces")
>
> was eliminated by:
>
>   0cb2af2ea66a ("KVM: x86: Fix shadow paging use-after-free due to unexpected GFN")
>   81ccda30b4e8 ("KVM: x86: Fix shadow paging use-after-free due to unexpected role")
>   aad885e774966 ("KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE")
>
> I am leaning toward taking an erratum for cross-address-space modifications of
> guest PTEs instead of applying this, and then reverting 2e8a2c1b0306 and 0f38453cdb2e.
>
> This is all a non-trivial amount of complexity that, in practice, no use case
> cares about.  By fixing the issues, we're implicitly stating that such shenanigans
> are supported by KVM, and I would much rather say "don't do that" and document
> exactly what is in/out of scope for shadow paging.
>
> Paolo, emulated SMM matters a lot more to you, what are your thoughts?