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 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.