linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Artemiy Margaritov <artemiy.margaritov@gmail.com>,
	Sasha Levin <sashal@kernel.org>,
	kvm@vger.kernel.org
Subject: [PATCH AUTOSEL 4.19 10/12] kvm: avoid speculation-based attacks from out-of-range memslot accesses
Date: Tue, 15 Jun 2021 11:50:07 -0400	[thread overview]
Message-ID: <20210615155009.62894-10-sashal@kernel.org> (raw)
In-Reply-To: <20210615155009.62894-1-sashal@kernel.org>

From: Paolo Bonzini <pbonzini@redhat.com>

[ Upstream commit da27a83fd6cc7780fea190e1f5c19e87019da65c ]

KVM's mechanism for accessing guest memory translates a guest physical
address (gpa) to a host virtual address using the right-shifted gpa
(also known as gfn) and a struct kvm_memory_slot.  The translation is
performed in __gfn_to_hva_memslot using the following formula:

      hva = slot->userspace_addr + (gfn - slot->base_gfn) * PAGE_SIZE

It is expected that gfn falls within the boundaries of the guest's
physical memory.  However, a guest can access invalid physical addresses
in such a way that the gfn is invalid.

__gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first
retrieves a memslot through __gfn_to_memslot.  While __gfn_to_memslot
does check that the gfn falls within the boundaries of the guest's
physical memory or not, a CPU can speculate the result of the check and
continue execution speculatively using an illegal gfn. The speculation
can result in calculating an out-of-bounds hva.  If the resulting host
virtual address is used to load another guest physical address, this
is effectively a Spectre gadget consisting of two consecutive reads,
the second of which is data dependent on the first.

Right now it's not clear if there are any cases in which this is
exploitable.  One interesting case was reported by the original author
of this patch, and involves visiting guest page tables on x86.  Right
now these are not vulnerable because the hva read goes through get_user(),
which contains an LFENCE speculation barrier.  However, there are
patches in progress for x86 uaccess.h to mask kernel addresses instead of
using LFENCE; once these land, a guest could use speculation to read
from the VMM's ring 3 address space.  Other architectures such as ARM
already use the address masking method, and would be susceptible to
this same kind of data-dependent access gadgets.  Therefore, this patch
proactively protects from these attacks by masking out-of-bounds gfns
in __gfn_to_hva_memslot, which blocks speculation of invalid hvas.

Sean Christopherson noted that this patch does not cover
kvm_read_guest_offset_cached.  This however is limited to a few bytes
past the end of the cache, and therefore it is unlikely to be useful in
the context of building a chain of data dependent accesses.

Reported-by: Artemiy Margaritov <artemiy.margaritov@gmail.com>
Co-developed-by: Artemiy Margaritov <artemiy.margaritov@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 include/linux/kvm_host.h | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index a0de4c7dc9d3..eb758bbdb4f6 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -1017,7 +1017,15 @@ __gfn_to_memslot(struct kvm_memslots *slots, gfn_t gfn)
 static inline unsigned long
 __gfn_to_hva_memslot(struct kvm_memory_slot *slot, gfn_t gfn)
 {
-	return slot->userspace_addr + (gfn - slot->base_gfn) * PAGE_SIZE;
+	/*
+	 * The index was checked originally in search_memslots.  To avoid
+	 * that a malicious guest builds a Spectre gadget out of e.g. page
+	 * table walks, do not let the processor speculate loads outside
+	 * the guest's registered memslots.
+	 */
+	unsigned long offset = array_index_nospec(gfn - slot->base_gfn,
+						  slot->npages);
+	return slot->userspace_addr + offset * PAGE_SIZE;
 }
 
 static inline int memslot_id(struct kvm *kvm, gfn_t gfn)
-- 
2.30.2


  parent reply	other threads:[~2021-06-15 15:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-15 15:49 [PATCH AUTOSEL 4.19 01/12] ASoC: rt5659: Fix the lost powers for the HDA header Sasha Levin
2021-06-15 15:49 ` [PATCH AUTOSEL 4.19 02/12] NFSv4: nfs4_proc_set_acl needs to restore NFS_CAP_UIDGID_NOMAP on error Sasha Levin
2021-06-15 15:50 ` [PATCH AUTOSEL 4.19 03/12] NFSv4: Fix second deadlock in nfs4_evict_inode() Sasha Levin
2021-06-15 15:50 ` [PATCH AUTOSEL 4.19 04/12] pinctrl: ralink: rt2880: avoid to error in calls is pin is already enabled Sasha Levin
2021-06-15 15:50 ` [PATCH AUTOSEL 4.19 05/12] drm/sun4i: dw-hdmi: Make HDMI PHY into a platform device Sasha Levin
2021-06-15 16:34   ` Saravana Kannan
2021-06-15 15:50 ` [PATCH AUTOSEL 4.19 06/12] scsi: core: Fix error handling of scsi_host_alloc() Sasha Levin
2021-06-15 15:50 ` [PATCH AUTOSEL 4.19 07/12] scsi: core: Put .shost_dev in failure path if host state changes to RUNNING Sasha Levin
2021-06-15 15:50 ` [PATCH AUTOSEL 4.19 08/12] scsi: core: Only put parent device if host state differs from SHOST_CREATED Sasha Levin
2021-06-15 15:50 ` [PATCH AUTOSEL 4.19 09/12] radeon: use memcpy_to/fromio for UVD fw upload Sasha Levin
2021-06-15 15:50 ` Sasha Levin [this message]
2021-06-15 15:50 ` [PATCH AUTOSEL 4.19 11/12] kvm: fix previous commit for 32-bit builds Sasha Levin
2021-06-15 15:50 ` [PATCH AUTOSEL 4.19 12/12] hwmon: (scpi-hwmon) shows the negative temperature properly Sasha Levin

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=20210615155009.62894-10-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=artemiy.margaritov@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.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;
as well as URLs for NNTP newsgroup(s).