From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Sean Christopherson <seanjc@google.com>
Cc: stable@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 6.1] KVM: x86/mmu: Fix an sign-extension bug with mmu_seq that hangs vCPUs
Date: Thu, 24 Aug 2023 08:53:40 +0200 [thread overview]
Message-ID: <2023082423-ninetieth-hamlet-54dc@gregkh> (raw)
In-Reply-To: <20230824010104.2714198-1-seanjc@google.com>
On Wed, Aug 23, 2023 at 06:01:04PM -0700, Sean Christopherson wrote:
> Take the vCPU's mmu_seq snapshot as an "unsigned long" instead of an "int"
> when checking to see if a page fault is stale, as the sequence count is
> stored as an "unsigned long" everywhere else in KVM. This fixes a bug
> where KVM will effectively hang vCPUs due to always thinking page faults
> are stale, which results in KVM refusing to "fix" faults.
>
> mmu_invalidate_seq (née mmu_notifier_seq) is a sequence counter used when
> KVM is handling page faults to detect if userspace mappings relevant to
> the guest were invalidated between snapshotting the counter and acquiring
> mmu_lock, i.e. to ensure that the userspace mapping KVM is using to
> resolve the page fault is fresh. If KVM sees that the counter has
> changed, KVM simply resumes the guest without fixing the fault.
>
> What _should_ happen is that the source of the mmu_notifier invalidations
> eventually goes away, mmu_invalidate_seq becomes stable, and KVM can once
> again fix guest page fault(s).
>
> But for a long-lived VM and/or a VM that the host just doesn't particularly
> like, it's possible for a VM to be on the receiving end of 2 billion (with
> a B) mmu_notifier invalidations. When that happens, bit 31 will be set in
> mmu_invalidate_seq. This causes the value to be turned into a 32-bit
> negative value when implicitly cast to an "int" by is_page_fault_stale(),
> and then sign-extended into a 64-bit unsigned when the signed "int" is
> implicitly cast back to an "unsigned long" on the call to
> mmu_invalidate_retry_hva().
>
> As a result of the casting and sign-extension, given a sequence counter of
> e.g. 0x8002dc25, mmu_invalidate_retry_hva() ends up doing
>
> if (0x8002dc25 != 0xffffffff8002dc25)
>
> and signals that the page fault is stale and needs to be retried even
> though the sequence counter is stable, and KVM effectively hangs any vCPU
> that takes a page fault (EPT violation or #NPF when TDP is enabled).
>
> Note, upstream commit ba6e3fe25543 ("KVM: x86/mmu: Grab mmu_invalidate_seq
> in kvm_faultin_pfn()") unknowingly fixed the bug in v6.3 when refactoring
> how KVM tracks the sequence counter snapshot.
>
> Reported-by: Brian Rak <brak@vultr.com>
> Reported-by: Amaan Cheval <amaan.cheval@gmail.com>
> Reported-by: Eric Wheeler <kvm@lists.ewheeler.net>
> Closes: https://lore.kernel.org/all/f023d927-52aa-7e08-2ee5-59a2fbc65953@gameservers.com
> Fixes: a955cad84cda ("KVM: x86/mmu: Retry page fault if root is invalidated by memslot update")
> Signed-off-by: Sean Christopherson <seanjc@google.com>
What is the git commit id of this change in Linus's tree?
thanks,
greg k-h
next prev parent reply other threads:[~2023-08-24 6:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-24 1:01 [PATCH 6.1] KVM: x86/mmu: Fix an sign-extension bug with mmu_seq that hangs vCPUs Sean Christopherson
2023-08-24 6:53 ` Greg Kroah-Hartman [this message]
2023-08-24 13:46 ` Sean Christopherson
2023-08-24 14:46 ` Greg Kroah-Hartman
2023-08-26 16:46 ` Greg Kroah-Hartman
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=2023082423-ninetieth-hamlet-54dc@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=stable@vger.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