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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox