All of lore.kernel.org
 help / color / mirror / Atom feed
From: Salvatore Bonaccorso <carnil@debian.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	Sean Christopherson <sean.j.christopherson@intel.com>,
	stable@vger.kernel.org, Wanpeng Li <kernellwp@gmail.com>
Subject: Re: [PATCH 1/2] KVM: SVM: avoid infinite loop on NPF from bad address
Date: Tue, 8 Jun 2021 06:39:46 +0200	[thread overview]
Message-ID: <YL70kh5/vLW8gmAY@eldamar.lan> (raw)
In-Reply-To: <20200417163843.71624-2-pbonzini@redhat.com>

Hi Paolo,

On Fri, Apr 17, 2020 at 12:38:42PM -0400, Paolo Bonzini wrote:
> When a nested page fault is taken from an address that does not have
> a memslot associated to it, kvm_mmu_do_page_fault returns RET_PF_EMULATE
> (via mmu_set_spte) and kvm_mmu_page_fault then invokes svm_need_emulation_on_page_fault.
> 
> The default answer there is to return false, but in this case this just
> causes the page fault to be retried ad libitum.  Since this is not a
> fast path, and the only other case where it is taken is an erratum,
> just stick a kvm_vcpu_gfn_to_memslot check in there to detect the
> common case where the erratum is not happening.
> 
> This fixes an infinite loop in the new set_memory_region_test.
> 
> Fixes: 05d5a4863525 ("KVM: SVM: Workaround errata#1096 (insn_len maybe zero on SMAP violation)")
> Cc: stable@vger.kernel.org
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  arch/x86/kvm/svm/svm.c | 7 +++++++
>  virt/kvm/kvm_main.c    | 1 +
>  2 files changed, 8 insertions(+)
> 
> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> index a91e397d6750..c86f7278509b 100644
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
> @@ -3837,6 +3837,13 @@ static bool svm_need_emulation_on_page_fault(struct kvm_vcpu *vcpu)
>  	bool smap = cr4 & X86_CR4_SMAP;
>  	bool is_user = svm_get_cpl(vcpu) == 3;
>  
> +	/*
> +	 * If RIP is invalid, go ahead with emulation which will cause an
> +	 * internal error exit.
> +	 */
> +	if (!kvm_vcpu_gfn_to_memslot(vcpu, kvm_rip_read(vcpu) >> PAGE_SHIFT))
> +		return true;
> +
>  	/*
>  	 * Detect and workaround Errata 1096 Fam_17h_00_0Fh.
>  	 *
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index e2f60e313c87..e7436d054305 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -1602,6 +1602,7 @@ struct kvm_memory_slot *kvm_vcpu_gfn_to_memslot(struct kvm_vcpu *vcpu, gfn_t gfn
>  {
>  	return __gfn_to_memslot(kvm_vcpu_memslots(vcpu), gfn);
>  }
> +EXPORT_SYMBOL_GPL(kvm_vcpu_gfn_to_memslot);
>  
>  bool kvm_is_visible_gfn(struct kvm *kvm, gfn_t gfn)
>  {
> -- 
> 2.18.2

I noticed that this patch, whilst beeing CC'ed for stable, appers to
not have been applied to stable branches back then. There was first a
mail from Sasha's bot that patches do not apply and Wanpeng Li.

Did this simply felt through the cracks here or is it not worth
backporting to older series? At least
https://bugzilla.redhat.com/show_bug.cgi?id=1947982#c3 seem to
indicate it might not be worth of if there is risk for regression if I
understand Wanpeng Li. Is this right?

Regards,
Salvatore

  parent reply	other threads:[~2021-06-08  4:39 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-17 16:38 [PATCH 0/2] KVM: fix set_memory_region_test on AMD Paolo Bonzini
2020-04-17 16:38 ` [PATCH 1/2] KVM: SVM: avoid infinite loop on NPF from bad address Paolo Bonzini
2020-04-21 19:56   ` Sasha Levin
2020-07-08  8:17   ` Wanpeng Li
2020-07-08  8:38     ` Paolo Bonzini
2020-07-08  9:08       ` Wanpeng Li
2020-07-08 11:10         ` Paolo Bonzini
2021-06-08  4:39   ` Salvatore Bonaccorso [this message]
2021-06-08  7:17     ` Paolo Bonzini
2022-01-13 16:27   ` Query about calling kvm_vcpu_gfn_to_memslot() with a GVA (Re: " Liam Merwick
2022-01-13 16:57     ` Sean Christopherson
2022-01-17 17:09       ` Liam Merwick
2022-01-18 18:46         ` Sean Christopherson
2020-04-17 16:38 ` [PATCH 2/2] selftests: kvm/set_memory_region_test: do not check RIP if the guest shuts down Paolo Bonzini

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=YL70kh5/vLW8gmAY@eldamar.lan \
    --to=carnil@debian.org \
    --cc=kernellwp@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=sean.j.christopherson@intel.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.