From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Jim Mattson <jmattson@google.com>,
Mingwei Zhang <mizhang@google.com>
Subject: Re: [PATCH v2 4/4] KVM: x86/mmu: Fix a *very* theoretical race in kvm_mmu_track_write()
Date: Fri, 23 Feb 2024 10:12:53 -0800 [thread overview]
Message-ID: <ZdjgJaVqHs7WbFnk@google.com> (raw)
In-Reply-To: <34504abb-ff58-4a83-9a63-87f22841adc7@redhat.com>
On Fri, Feb 23, 2024, Paolo Bonzini wrote:
> On 2/3/24 01:23, Sean Christopherson wrote:
> > Add full memory barriers in kvm_mmu_track_write() and account_shadowed()
> > to plug a (very, very theoretical) race where kvm_mmu_track_write() could
> > miss a 0->1 transition of indirect_shadow_pages and fail to zap relevant,
> > *stale* SPTEs.
>
> Ok, so we have
>
> emulator_write_phys
> overwrite PTE
> kvm_page_track_write
> kvm_mmu_track_write
> // memory barrier missing here
> if (indirect_shadow_pages)
> zap();
>
> and on the other side
>
> FNAME(page_fault)
> FNAME(fetch)
> kvm_mmu_get_child_sp
> kvm_mmu_get_shadow_page
> __kvm_mmu_get_shadow_page
> kvm_mmu_alloc_shadow_page
> account_shadowed
> indirect shadow pages++
> // memory barrier missing here
> if (FNAME(gpte_changed)) // reads PTE
> goto out
>
> If you can weave something like this in the commit message the sequence
> would be a bit clearer.
Roger that.
> > In practice, this bug is likely benign as both the 0=>1 transition and
> > reordering of this scope are extremely rare occurrences.
>
> I wouldn't call it benign, it's more that it's unobservable in practice but
> the race is real. However...
> > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> > index 3c193b096b45..86b85060534d 100644
> > --- a/arch/x86/kvm/mmu/mmu.c
> > +++ b/arch/x86/kvm/mmu/mmu.c
> > @@ -830,6 +830,14 @@ static void account_shadowed(struct kvm *kvm, struct kvm_mmu_page *sp)
> > struct kvm_memory_slot *slot;
> > gfn_t gfn;
> > + /*
> > + * Ensure indirect_shadow_pages is elevated prior to re-reading guest
> > + * child PTEs in FNAME(gpte_changed), i.e. guarantee either in-flight
> > + * emulated writes are visible before re-reading guest PTEs, or that
> > + * an emulated write will see the elevated count and acquire mmu_lock
> > + * to update SPTEs. Pairs with the smp_mb() in kvm_mmu_track_write().
> > + */
> > + smp_mb();
>
> ... this memory barrier needs to be after the increment (the desired
> ordering is store-before-read).
Doh. I'll post a fixed version as a one-off v3.
Thanks!
next prev parent reply other threads:[~2024-02-23 18:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-03 0:23 [PATCH v2 0/4] KVM: x86/mmu: Clean up indirect_shadow_pages usage Sean Christopherson
2024-02-03 0:23 ` [PATCH v2 1/4] KVM: x86/mmu: Don't acquire mmu_lock when using indirect_shadow_pages as a heuristic Sean Christopherson
2024-02-03 0:23 ` [PATCH v2 2/4] KVM: x86: Drop dedicated logic for direct MMUs in reexecute_instruction() Sean Christopherson
2024-02-03 0:23 ` [PATCH v2 3/4] KVM: x86: Drop superfluous check on direct MMU vs. WRITE_PF_TO_SP flag Sean Christopherson
2024-02-03 0:23 ` [PATCH v2 4/4] KVM: x86/mmu: Fix a *very* theoretical race in kvm_mmu_track_write() Sean Christopherson
2024-02-23 8:09 ` Paolo Bonzini
2024-02-23 18:12 ` Sean Christopherson [this message]
2024-02-23 1:35 ` [PATCH v2 0/4] KVM: x86/mmu: Clean up indirect_shadow_pages usage 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=ZdjgJaVqHs7WbFnk@google.com \
--to=seanjc@google.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mizhang@google.com \
--cc=pbonzini@redhat.com \
/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.