From: Sean Christopherson <seanjc@google.com>
To: Jinu Kim <kimjw04271234@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
x86@kernel.org
Subject: Re: [PATCH v2] KVM: x86/mmu: Write-protect tracked GFNs in all address spaces
Date: Tue, 4 Aug 2026 06:10:51 -0700 [thread overview]
Message-ID: <anHk2wTLHYxdB0jD@google.com> (raw)
In-Reply-To: <20260804105755.276646-1-kimjw04271234@gmail.com>
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?
next prev parent reply other threads:[~2026-08-04 13:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-04 10:57 [PATCH v2] KVM: x86/mmu: Write-protect tracked GFNs in all address spaces Jinu Kim
2026-08-04 13:10 ` Sean Christopherson [this message]
2026-08-05 8:24 ` Jinu Kim
2026-08-05 19:14 ` 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=anHk2wTLHYxdB0jD@google.com \
--to=seanjc@google.com \
--cc=kimjw04271234@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=x86@kernel.org \
/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.