From: Alex Williamson <alex.williamson@redhat.com>
To: Ajay Kaher <akaher@vmware.com>
Cc: <gregkh@linuxfoundation.org>, <sashal@kernel.org>,
<cohuck@redhat.com>, <peterx@redhat.com>, <kvm@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <stable@vger.kernel.org>,
<srivatsab@vmware.com>, <srivatsa@csail.mit.edu>,
<vsirnapalli@vmware.com>
Subject: Re: [PATCH v4.14.y 0/3] vfio: Fix for CVE-2020-12888
Date: Tue, 8 Sep 2020 08:29:04 -0600 [thread overview]
Message-ID: <20200908082904.045ff744@w520.home> (raw)
In-Reply-To: <1599509828-23596-4-git-send-email-akaher@vmware.com>
On Tue, 8 Sep 2020 01:47:08 +0530
Ajay Kaher <akaher@vmware.com> wrote:
> CVE-2020-12888 Kernel: vfio: access to disabled MMIO space of some
> devices may lead to DoS scenario
>
> The VFIO modules allow users (guest VMs) to enable or disable access to the
> devices' MMIO memory address spaces. If a user attempts to access (read/write)
> the devices' MMIO address space when it is disabled, some h/w devices issue an
> interrupt to the CPU to indicate a fatal error condition, crashing the system.
> This flaw allows a guest user or process to crash the host system resulting in
> a denial of service.
>
> Patch 1/ is to force the user fault if PFNMAP vma might be DMA mapped
> before user access.
>
> Patch 2/ setup a vm_ops handler to support dynamic faulting instead of calling
> remap_pfn_range(). Also provides a list of vmas actively mapping the area which
> can later use to invalidate those mappings.
>
> Patch 3/ block the user from accessing memory spaces which is disabled by using
> new vma list support to zap, or invalidate, those memory mappings in order to
> force them to be faulted back in on access.
>
> Upstreamed patches link:
> https://lore.kernel.org/kvm/158871401328.15589.17598154478222071285.stgit@gimli.home
>
> [PATCH v4.14.y 1/3]:
> Backporting of upsream commit 41311242221e:
> vfio/type1: Support faulting PFNMAP vmas
>
> [PATCH v4.14.y 2/3]:
> Backporting of upsream commit 11c4cd07ba11:
> vfio-pci: Fault mmaps to enable vma tracking
>
> [PATCH v4.14.y 3/3]:
> Backporting of upsream commit abafbc551fdd:
> vfio-pci: Invalidate mmaps and block MMIO access on disabled memory
>
I'd recommend also including the following or else SR-IOV VFs will be
broken for DPDK:
commit ebfa440ce38b7e2e04c3124aa89c8a9f4094cf21
Author: Alex Williamson <alex.williamson@redhat.com>
Date: Thu Jun 25 11:04:23 2020 -0600
vfio/pci: Fix SR-IOV VF handling with MMIO blocking
SR-IOV VFs do not implement the memory enable bit of the command
register, therefore this bit is not set in config space after
pci_enable_device(). This leads to an unintended difference
between PF and VF in hand-off state to the user. We can correct
this by setting the initial value of the memory enable bit in our
virtualized config space. There's really no need however to
ever fault a user on a VF though as this would only indicate an
error in the user's management of the enable bit, versus a PF
where the same access could trigger hardware faults.
Fixes: abafbc551fdd ("vfio-pci: Invalidate mmaps and block MMIO access on disabled memory")
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
next prev parent reply other threads:[~2020-09-08 20:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-07 20:17 [PATCH v4.14.y 1/3] vfio/type1: Support faulting PFNMAP vmas Ajay Kaher
2020-09-07 20:17 ` [PATCH v4.14.y 2/3] vfio-pci: Fault mmaps to enable vma tracking Ajay Kaher
2020-09-08 13:06 ` Greg KH
2020-09-07 20:17 ` [PATCH v4.14.y 3/3] vfio-pci: Invalidate mmaps and block MMIO access on disabled memory Ajay Kaher
2020-09-07 20:17 ` [PATCH v4.14.y 0/3] vfio: Fix for CVE-2020-12888 Ajay Kaher
2020-09-08 13:02 ` Greg KH
2020-09-08 14:29 ` Alex Williamson [this message]
2020-09-08 14:33 ` Greg KH
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=20200908082904.045ff744@w520.home \
--to=alex.williamson@redhat.com \
--cc=akaher@vmware.com \
--cc=cohuck@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterx@redhat.com \
--cc=sashal@kernel.org \
--cc=srivatsa@csail.mit.edu \
--cc=srivatsab@vmware.com \
--cc=stable@vger.kernel.org \
--cc=vsirnapalli@vmware.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox