Kernel KVM virtualization development
 help / color / mirror / Atom feed
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?

  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