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?