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

Sean Christopherson <[email protected]> Tue, 4 Aug 2026 06:10:51 -0700
Newsgroups org.kernel.vger.kvm,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
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?