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

Sean Christopherson <[email protected]>
Newsgroups gmane.comp.emulators.kvm.devel,gmane.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?
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.