2019-06-04 08:11:33 +00:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-only */
|
2012-07-31 14:16:24 +00:00
|
|
|
/*
|
|
|
|
|
* Copyright (C) 2012 Red Hat, Inc. All rights reserved.
|
|
|
|
|
* Author: Alex Williamson <alex.williamson@redhat.com>
|
|
|
|
|
*
|
|
|
|
|
* Derived from original vfio:
|
|
|
|
|
* Copyright 2010 Cisco Systems, Inc. All rights reserved.
|
|
|
|
|
* Author: Tom Lyon, pugs@cisco.com
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <linux/mutex.h>
|
|
|
|
|
#include <linux/pci.h>
|
2021-08-26 10:39:04 +00:00
|
|
|
#include <linux/vfio.h>
|
2015-09-18 14:29:50 +00:00
|
|
|
#include <linux/irqbypass.h>
|
2016-02-22 23:02:39 +00:00
|
|
|
#include <linux/types.h>
|
vfio/pci: Introduce VF token
If we enable SR-IOV on a vfio-pci owned PF, the resulting VFs are not
fully isolated from the PF. The PF can always cause a denial of service
to the VF, even if by simply resetting itself. The degree to which a PF
can access the data passed through a VF or interfere with its operation
is dependent on a given SR-IOV implementation. Therefore we want to
avoid a scenario where an existing vfio-pci based userspace driver might
assume the PF driver is trusted, for example assigning a PF to one VM
and VF to another with some expectation of isolation. IOMMU grouping
could be a solution to this, but imposes an unnecessarily strong
relationship between PF and VF drivers if they need to operate with the
same IOMMU context. Instead we introduce a "VF token", which is
essentially just a shared secret between PF and VF drivers, implemented
as a UUID.
The VF token can be set by a vfio-pci based PF driver and must be known
by the vfio-pci based VF driver in order to gain access to the device.
This allows the degree to which this VF token is considered secret to be
determined by the applications and environment. For example a VM might
generate a random UUID known only internally to the hypervisor while a
userspace networking appliance might use a shared, or even well know,
UUID among the application drivers.
To incorporate this VF token, the VFIO_GROUP_GET_DEVICE_FD interface is
extended to accept key=value pairs in addition to the device name. This
allows us to most easily deny user access to the device without risk
that existing userspace drivers assume region offsets, IRQs, and other
device features, leading to more elaborate error paths. The format of
these options are expected to take the form:
"$DEVICE_NAME $OPTION1=$VALUE1 $OPTION2=$VALUE2"
Where the device name is always provided first for compatibility and
additional options are specified in a space separated list. The
relation between and requirements for the additional options will be
vfio bus driver dependent, however unknown or unused option within this
schema should return error. This allow for future use of unknown
options as well as a positive indication to the user that an option is
used.
An example VF token option would take this form:
"0000:03:00.0 vf_token=2ab74924-c335-45f4-9b16-8569e5b08258"
When accessing a VF where the PF is making use of vfio-pci, the user
MUST provide the current vf_token. When accessing a PF, the user MUST
provide the current vf_token IF there are active VF users or MAY provide
a vf_token in order to set the current VF token when no VF users are
active. The former requirement assures VF users that an unassociated
driver cannot usurp the PF device. These semantics also imply that a
VF token MUST be set by a PF driver before VF drivers can access their
device, the default token is random and mechanisms to read the token are
not provided in order to protect the VF token of previous users. Use of
the vf_token option outside of these cases will return an error, as
discussed above.
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2020-03-24 15:28:27 +00:00
|
|
|
#include <linux/uuid.h>
|
2020-03-24 15:28:28 +00:00
|
|
|
#include <linux/notifier.h>
|
2012-07-31 14:16:24 +00:00
|
|
|
|
2021-08-26 10:39:01 +00:00
|
|
|
#ifndef VFIO_PCI_CORE_H
|
|
|
|
|
#define VFIO_PCI_CORE_H
|
2012-07-31 14:16:24 +00:00
|
|
|
|
|
|
|
|
#define VFIO_PCI_OFFSET_SHIFT 40
|
|
|
|
|
|
|
|
|
|
#define VFIO_PCI_OFFSET_TO_INDEX(off) (off >> VFIO_PCI_OFFSET_SHIFT)
|
|
|
|
|
#define VFIO_PCI_INDEX_TO_OFFSET(index) ((u64)(index) << VFIO_PCI_OFFSET_SHIFT)
|
|
|
|
|
#define VFIO_PCI_OFFSET_MASK (((u64)(1) << VFIO_PCI_OFFSET_SHIFT) - 1)
|
|
|
|
|
|
2016-02-22 23:02:41 +00:00
|
|
|
/* Special capability IDs predefined access */
|
|
|
|
|
#define PCI_CAP_ID_INVALID 0xFF /* default raw access */
|
|
|
|
|
#define PCI_CAP_ID_INVALID_VIRT 0xFE /* default virt access */
|
|
|
|
|
|
2018-03-21 18:46:21 +00:00
|
|
|
/* Cap maximum number of ioeventfds per device (arbitrary) */
|
|
|
|
|
#define VFIO_PCI_IOEVENTFD_MAX 1000
|
|
|
|
|
|
|
|
|
|
struct vfio_pci_ioeventfd {
|
|
|
|
|
struct list_head next;
|
2021-08-26 10:39:02 +00:00
|
|
|
struct vfio_pci_core_device *vdev;
|
2018-03-21 18:46:21 +00:00
|
|
|
struct virqfd *virqfd;
|
|
|
|
|
void __iomem *addr;
|
|
|
|
|
uint64_t data;
|
|
|
|
|
loff_t pos;
|
|
|
|
|
int bar;
|
|
|
|
|
int count;
|
2020-08-17 17:08:18 +00:00
|
|
|
bool test_mem;
|
2018-03-21 18:46:21 +00:00
|
|
|
};
|
|
|
|
|
|
2012-07-31 14:16:24 +00:00
|
|
|
struct vfio_pci_irq_ctx {
|
|
|
|
|
struct eventfd_ctx *trigger;
|
|
|
|
|
struct virqfd *unmask;
|
|
|
|
|
struct virqfd *mask;
|
|
|
|
|
char *name;
|
|
|
|
|
bool masked;
|
2015-09-18 14:29:50 +00:00
|
|
|
struct irq_bypass_producer producer;
|
2012-07-31 14:16:24 +00:00
|
|
|
};
|
|
|
|
|
|
2021-08-26 10:39:02 +00:00
|
|
|
struct vfio_pci_core_device;
|
2016-02-22 23:02:39 +00:00
|
|
|
struct vfio_pci_region;
|
|
|
|
|
|
|
|
|
|
struct vfio_pci_regops {
|
2021-08-26 10:39:02 +00:00
|
|
|
ssize_t (*rw)(struct vfio_pci_core_device *vdev, char __user *buf,
|
2016-02-22 23:02:39 +00:00
|
|
|
size_t count, loff_t *ppos, bool iswrite);
|
2021-08-26 10:39:02 +00:00
|
|
|
void (*release)(struct vfio_pci_core_device *vdev,
|
2016-02-22 23:02:39 +00:00
|
|
|
struct vfio_pci_region *region);
|
2021-08-26 10:39:02 +00:00
|
|
|
int (*mmap)(struct vfio_pci_core_device *vdev,
|
2018-12-19 08:52:30 +00:00
|
|
|
struct vfio_pci_region *region,
|
|
|
|
|
struct vm_area_struct *vma);
|
2021-08-26 10:39:02 +00:00
|
|
|
int (*add_capability)(struct vfio_pci_core_device *vdev,
|
2018-12-19 08:52:31 +00:00
|
|
|
struct vfio_pci_region *region,
|
|
|
|
|
struct vfio_info_cap *caps);
|
2016-02-22 23:02:39 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct vfio_pci_region {
|
|
|
|
|
u32 type;
|
|
|
|
|
u32 subtype;
|
|
|
|
|
const struct vfio_pci_regops *ops;
|
|
|
|
|
void *data;
|
|
|
|
|
size_t size;
|
|
|
|
|
u32 flags;
|
|
|
|
|
};
|
|
|
|
|
|
2016-06-30 07:21:24 +00:00
|
|
|
struct vfio_pci_dummy_resource {
|
|
|
|
|
struct resource resource;
|
|
|
|
|
int index;
|
|
|
|
|
struct list_head res_next;
|
|
|
|
|
};
|
|
|
|
|
|
vfio/pci: Introduce VF token
If we enable SR-IOV on a vfio-pci owned PF, the resulting VFs are not
fully isolated from the PF. The PF can always cause a denial of service
to the VF, even if by simply resetting itself. The degree to which a PF
can access the data passed through a VF or interfere with its operation
is dependent on a given SR-IOV implementation. Therefore we want to
avoid a scenario where an existing vfio-pci based userspace driver might
assume the PF driver is trusted, for example assigning a PF to one VM
and VF to another with some expectation of isolation. IOMMU grouping
could be a solution to this, but imposes an unnecessarily strong
relationship between PF and VF drivers if they need to operate with the
same IOMMU context. Instead we introduce a "VF token", which is
essentially just a shared secret between PF and VF drivers, implemented
as a UUID.
The VF token can be set by a vfio-pci based PF driver and must be known
by the vfio-pci based VF driver in order to gain access to the device.
This allows the degree to which this VF token is considered secret to be
determined by the applications and environment. For example a VM might
generate a random UUID known only internally to the hypervisor while a
userspace networking appliance might use a shared, or even well know,
UUID among the application drivers.
To incorporate this VF token, the VFIO_GROUP_GET_DEVICE_FD interface is
extended to accept key=value pairs in addition to the device name. This
allows us to most easily deny user access to the device without risk
that existing userspace drivers assume region offsets, IRQs, and other
device features, leading to more elaborate error paths. The format of
these options are expected to take the form:
"$DEVICE_NAME $OPTION1=$VALUE1 $OPTION2=$VALUE2"
Where the device name is always provided first for compatibility and
additional options are specified in a space separated list. The
relation between and requirements for the additional options will be
vfio bus driver dependent, however unknown or unused option within this
schema should return error. This allow for future use of unknown
options as well as a positive indication to the user that an option is
used.
An example VF token option would take this form:
"0000:03:00.0 vf_token=2ab74924-c335-45f4-9b16-8569e5b08258"
When accessing a VF where the PF is making use of vfio-pci, the user
MUST provide the current vf_token. When accessing a PF, the user MUST
provide the current vf_token IF there are active VF users or MAY provide
a vf_token in order to set the current VF token when no VF users are
active. The former requirement assures VF users that an unassociated
driver cannot usurp the PF device. These semantics also imply that a
VF token MUST be set by a PF driver before VF drivers can access their
device, the default token is random and mechanisms to read the token are
not provided in order to protect the VF token of previous users. Use of
the vf_token option outside of these cases will return an error, as
discussed above.
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2020-03-24 15:28:27 +00:00
|
|
|
struct vfio_pci_vf_token {
|
|
|
|
|
struct mutex lock;
|
|
|
|
|
uuid_t uuid;
|
|
|
|
|
int users;
|
|
|
|
|
};
|
|
|
|
|
|
2020-04-28 19:12:20 +00:00
|
|
|
struct vfio_pci_mmap_vma {
|
|
|
|
|
struct vm_area_struct *vma;
|
|
|
|
|
struct list_head vma_next;
|
|
|
|
|
};
|
|
|
|
|
|
2021-08-26 10:39:02 +00:00
|
|
|
struct vfio_pci_core_device {
|
2021-03-30 15:53:07 +00:00
|
|
|
struct vfio_device vdev;
|
2012-07-31 14:16:24 +00:00
|
|
|
struct pci_dev *pdev;
|
2019-09-27 23:43:08 +00:00
|
|
|
void __iomem *barmap[PCI_STD_NUM_BARS];
|
|
|
|
|
bool bar_mmap_supported[PCI_STD_NUM_BARS];
|
2012-07-31 14:16:24 +00:00
|
|
|
u8 *pci_config_map;
|
|
|
|
|
u8 *vconfig;
|
|
|
|
|
struct perm_bits *msi_perm;
|
|
|
|
|
spinlock_t irqlock;
|
|
|
|
|
struct mutex igate;
|
|
|
|
|
struct vfio_pci_irq_ctx *ctx;
|
|
|
|
|
int num_ctx;
|
|
|
|
|
int irq_type;
|
2016-02-22 23:02:39 +00:00
|
|
|
int num_regions;
|
|
|
|
|
struct vfio_pci_region *region;
|
2012-07-31 14:16:24 +00:00
|
|
|
u8 msi_qmax;
|
|
|
|
|
u8 msix_bar;
|
|
|
|
|
u16 msix_size;
|
|
|
|
|
u32 msix_offset;
|
|
|
|
|
u32 rbar[7];
|
|
|
|
|
bool pci_2_3;
|
|
|
|
|
bool virq_disabled;
|
|
|
|
|
bool reset_works;
|
|
|
|
|
bool extended_caps;
|
|
|
|
|
bool bardirty;
|
2013-02-18 17:11:13 +00:00
|
|
|
bool has_vga;
|
2014-08-07 17:12:07 +00:00
|
|
|
bool needs_reset;
|
vfio/pci: Hide broken INTx support from user
INTx masking has two components, the first is that we need the ability
to prevent the device from continuing to assert INTx. This is
provided via the DisINTx bit in the command register and is the only
thing we can really probe for when testing if INTx masking is
supported. The second component is that the device needs to indicate
if INTx is asserted via the interrupt status bit in the device status
register. With these two features we can generically determine if one
of the devices we own is asserting INTx, signal the user, and mask the
interrupt while the user services the device.
Generally if one or both of these components is broken we resort to
APIC level interrupt masking, which requires an exclusive interrupt
since we have no way to determine the source of the interrupt in a
shared configuration. This often makes it difficult or impossible to
configure the system for userspace use of the device, for an interrupt
mode that the user may not need.
One possible configuration of broken INTx masking is that the DisINTx
support is fully functional, but the interrupt status bit never
signals interrupt assertion. In this case we do have the ability to
prevent the device from asserting INTx, but lack the ability to
identify the interrupt source. For this case we can simply pretend
that the device lacks INTx support entirely, keeping DisINTx set on
the physical device, virtualizing this bit for the user, and
virtualizing the interrupt pin register to indicate no INTx support.
We already support virtualization of the DisINTx bit and already
virtualize the interrupt pin for platforms without INTx support. By
tying these components together, setting DisINTx on open and reset,
and identifying devices broken in this particular way, we can provide
support for them w/o the handicap of APIC level INTx masking.
Intel i40e (XL710/X710) 10/20/40GbE NICs have been identified as being
broken in this specific way. We leave the vfio-pci.nointxmask option
as a mechanism to bypass this support, enabling INTx on the device
with all the requirements of APIC level masking.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Cc: John Ronciak <john.ronciak@intel.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
2016-03-24 19:05:18 +00:00
|
|
|
bool nointx;
|
2019-02-09 20:43:30 +00:00
|
|
|
bool needs_pm_restore;
|
2012-07-31 14:16:24 +00:00
|
|
|
struct pci_saved_state *pci_saved_state;
|
2019-02-09 20:43:30 +00:00
|
|
|
struct pci_saved_state *pm_save;
|
2018-03-21 18:46:21 +00:00
|
|
|
int ioeventfds_nr;
|
2013-03-11 15:31:22 +00:00
|
|
|
struct eventfd_ctx *err_trigger;
|
2015-02-06 22:05:08 +00:00
|
|
|
struct eventfd_ctx *req_trigger;
|
2016-06-30 07:21:24 +00:00
|
|
|
struct list_head dummy_resources_list;
|
2018-03-21 18:46:21 +00:00
|
|
|
struct mutex ioeventfds_lock;
|
|
|
|
|
struct list_head ioeventfds_list;
|
vfio/pci: Introduce VF token
If we enable SR-IOV on a vfio-pci owned PF, the resulting VFs are not
fully isolated from the PF. The PF can always cause a denial of service
to the VF, even if by simply resetting itself. The degree to which a PF
can access the data passed through a VF or interfere with its operation
is dependent on a given SR-IOV implementation. Therefore we want to
avoid a scenario where an existing vfio-pci based userspace driver might
assume the PF driver is trusted, for example assigning a PF to one VM
and VF to another with some expectation of isolation. IOMMU grouping
could be a solution to this, but imposes an unnecessarily strong
relationship between PF and VF drivers if they need to operate with the
same IOMMU context. Instead we introduce a "VF token", which is
essentially just a shared secret between PF and VF drivers, implemented
as a UUID.
The VF token can be set by a vfio-pci based PF driver and must be known
by the vfio-pci based VF driver in order to gain access to the device.
This allows the degree to which this VF token is considered secret to be
determined by the applications and environment. For example a VM might
generate a random UUID known only internally to the hypervisor while a
userspace networking appliance might use a shared, or even well know,
UUID among the application drivers.
To incorporate this VF token, the VFIO_GROUP_GET_DEVICE_FD interface is
extended to accept key=value pairs in addition to the device name. This
allows us to most easily deny user access to the device without risk
that existing userspace drivers assume region offsets, IRQs, and other
device features, leading to more elaborate error paths. The format of
these options are expected to take the form:
"$DEVICE_NAME $OPTION1=$VALUE1 $OPTION2=$VALUE2"
Where the device name is always provided first for compatibility and
additional options are specified in a space separated list. The
relation between and requirements for the additional options will be
vfio bus driver dependent, however unknown or unused option within this
schema should return error. This allow for future use of unknown
options as well as a positive indication to the user that an option is
used.
An example VF token option would take this form:
"0000:03:00.0 vf_token=2ab74924-c335-45f4-9b16-8569e5b08258"
When accessing a VF where the PF is making use of vfio-pci, the user
MUST provide the current vf_token. When accessing a PF, the user MUST
provide the current vf_token IF there are active VF users or MAY provide
a vf_token in order to set the current VF token when no VF users are
active. The former requirement assures VF users that an unassociated
driver cannot usurp the PF device. These semantics also imply that a
VF token MUST be set by a PF driver before VF drivers can access their
device, the default token is random and mechanisms to read the token are
not provided in order to protect the VF token of previous users. Use of
the vf_token option outside of these cases will return an error, as
discussed above.
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2020-03-24 15:28:27 +00:00
|
|
|
struct vfio_pci_vf_token *vf_token;
|
2020-03-24 15:28:28 +00:00
|
|
|
struct notifier_block nb;
|
2020-04-28 19:12:20 +00:00
|
|
|
struct mutex vma_lock;
|
|
|
|
|
struct list_head vma_list;
|
vfio-pci: Invalidate mmaps and block MMIO access on disabled memory
Accessing the disabled memory space of a PCI device would typically
result in a master abort response on conventional PCI, or an
unsupported request on PCI express. The user would generally see
these as a -1 response for the read return data and the write would be
silently discarded, possibly with an uncorrected, non-fatal AER error
triggered on the host. Some systems however take it upon themselves
to bring down the entire system when they see something that might
indicate a loss of data, such as this discarded write to a disabled
memory space.
To avoid this, we want to try to block the user from accessing memory
spaces while they're disabled. We start with a semaphore around the
memory enable bit, where writers modify the memory enable state and
must be serialized, while readers make use of the memory region and
can access in parallel. Writers include both direct manipulation via
the command register, as well as any reset path where the internal
mechanics of the reset may both explicitly and implicitly disable
memory access, and manipulation of the MSI-X configuration, where the
MSI-X vector table resides in MMIO space of the device. Readers
include the read and write file ops to access the vfio device fd
offsets as well as memory mapped access. In the latter case, we make
use of our new vma list support to zap, or invalidate, those memory
mappings in order to force them to be faulted back in on access.
Our semaphore usage will stall user access to MMIO spaces across
internal operations like reset, but the user might experience new
behavior when trying to access the MMIO space while disabled via the
PCI command register. Access via read or write while disabled will
return -EIO and access via memory maps will result in a SIGBUS. This
is expected to be compatible with known use cases and potentially
provides better error handling capabilities than present in the
hardware, while avoiding the more readily accessible and severe
platform error responses that might otherwise occur.
Fixes: CVE-2020-12888
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2020-04-22 19:48:11 +00:00
|
|
|
struct rw_semaphore memory_lock;
|
2012-07-31 14:16:24 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#define is_intx(vdev) (vdev->irq_type == VFIO_PCI_INTX_IRQ_INDEX)
|
|
|
|
|
#define is_msi(vdev) (vdev->irq_type == VFIO_PCI_MSI_IRQ_INDEX)
|
|
|
|
|
#define is_msix(vdev) (vdev->irq_type == VFIO_PCI_MSIX_IRQ_INDEX)
|
|
|
|
|
#define is_irq_none(vdev) (!(is_intx(vdev) || is_msi(vdev) || is_msix(vdev)))
|
|
|
|
|
#define irq_is(vdev, type) (vdev->irq_type == type)
|
|
|
|
|
|
2021-08-26 10:39:02 +00:00
|
|
|
extern void vfio_pci_intx_mask(struct vfio_pci_core_device *vdev);
|
|
|
|
|
extern void vfio_pci_intx_unmask(struct vfio_pci_core_device *vdev);
|
2012-07-31 14:16:24 +00:00
|
|
|
|
2021-08-26 10:39:02 +00:00
|
|
|
extern int vfio_pci_set_irqs_ioctl(struct vfio_pci_core_device *vdev,
|
2012-07-31 14:16:24 +00:00
|
|
|
uint32_t flags, unsigned index,
|
|
|
|
|
unsigned start, unsigned count, void *data);
|
|
|
|
|
|
2021-08-26 10:39:02 +00:00
|
|
|
extern ssize_t vfio_pci_config_rw(struct vfio_pci_core_device *vdev,
|
2013-02-14 21:02:12 +00:00
|
|
|
char __user *buf, size_t count,
|
|
|
|
|
loff_t *ppos, bool iswrite);
|
|
|
|
|
|
2021-08-26 10:39:02 +00:00
|
|
|
extern ssize_t vfio_pci_bar_rw(struct vfio_pci_core_device *vdev, char __user *buf,
|
2013-02-14 21:02:12 +00:00
|
|
|
size_t count, loff_t *ppos, bool iswrite);
|
2012-07-31 14:16:24 +00:00
|
|
|
|
2021-08-26 10:39:02 +00:00
|
|
|
extern ssize_t vfio_pci_vga_rw(struct vfio_pci_core_device *vdev, char __user *buf,
|
2013-02-18 17:11:13 +00:00
|
|
|
size_t count, loff_t *ppos, bool iswrite);
|
|
|
|
|
|
2021-08-26 10:39:02 +00:00
|
|
|
extern long vfio_pci_ioeventfd(struct vfio_pci_core_device *vdev, loff_t offset,
|
2018-03-21 18:46:21 +00:00
|
|
|
uint64_t data, int count, int fd);
|
|
|
|
|
|
2012-07-31 14:16:24 +00:00
|
|
|
extern int vfio_pci_init_perm_bits(void);
|
|
|
|
|
extern void vfio_pci_uninit_perm_bits(void);
|
|
|
|
|
|
2021-08-26 10:39:02 +00:00
|
|
|
extern int vfio_config_init(struct vfio_pci_core_device *vdev);
|
|
|
|
|
extern void vfio_config_free(struct vfio_pci_core_device *vdev);
|
2016-02-22 23:02:39 +00:00
|
|
|
|
2021-08-26 10:39:02 +00:00
|
|
|
extern int vfio_pci_register_dev_region(struct vfio_pci_core_device *vdev,
|
2016-02-22 23:02:39 +00:00
|
|
|
unsigned int type, unsigned int subtype,
|
|
|
|
|
const struct vfio_pci_regops *ops,
|
|
|
|
|
size_t size, u32 flags, void *data);
|
2019-02-09 20:43:30 +00:00
|
|
|
|
2021-08-26 10:39:02 +00:00
|
|
|
extern int vfio_pci_set_power_state(struct vfio_pci_core_device *vdev,
|
2019-02-09 20:43:30 +00:00
|
|
|
pci_power_t state);
|
|
|
|
|
|
2021-08-26 10:39:02 +00:00
|
|
|
extern bool __vfio_pci_memory_enabled(struct vfio_pci_core_device *vdev);
|
|
|
|
|
extern void vfio_pci_zap_and_down_write_memory_lock(struct vfio_pci_core_device
|
vfio-pci: Invalidate mmaps and block MMIO access on disabled memory
Accessing the disabled memory space of a PCI device would typically
result in a master abort response on conventional PCI, or an
unsupported request on PCI express. The user would generally see
these as a -1 response for the read return data and the write would be
silently discarded, possibly with an uncorrected, non-fatal AER error
triggered on the host. Some systems however take it upon themselves
to bring down the entire system when they see something that might
indicate a loss of data, such as this discarded write to a disabled
memory space.
To avoid this, we want to try to block the user from accessing memory
spaces while they're disabled. We start with a semaphore around the
memory enable bit, where writers modify the memory enable state and
must be serialized, while readers make use of the memory region and
can access in parallel. Writers include both direct manipulation via
the command register, as well as any reset path where the internal
mechanics of the reset may both explicitly and implicitly disable
memory access, and manipulation of the MSI-X configuration, where the
MSI-X vector table resides in MMIO space of the device. Readers
include the read and write file ops to access the vfio device fd
offsets as well as memory mapped access. In the latter case, we make
use of our new vma list support to zap, or invalidate, those memory
mappings in order to force them to be faulted back in on access.
Our semaphore usage will stall user access to MMIO spaces across
internal operations like reset, but the user might experience new
behavior when trying to access the MMIO space while disabled via the
PCI command register. Access via read or write while disabled will
return -EIO and access via memory maps will result in a SIGBUS. This
is expected to be compatible with known use cases and potentially
provides better error handling capabilities than present in the
hardware, while avoiding the more readily accessible and severe
platform error responses that might otherwise occur.
Fixes: CVE-2020-12888
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2020-04-22 19:48:11 +00:00
|
|
|
*vdev);
|
2021-08-26 10:39:02 +00:00
|
|
|
extern u16 vfio_pci_memory_lock_and_enable(struct vfio_pci_core_device *vdev);
|
|
|
|
|
extern void vfio_pci_memory_unlock_and_restore(struct vfio_pci_core_device *vdev,
|
vfio-pci: Invalidate mmaps and block MMIO access on disabled memory
Accessing the disabled memory space of a PCI device would typically
result in a master abort response on conventional PCI, or an
unsupported request on PCI express. The user would generally see
these as a -1 response for the read return data and the write would be
silently discarded, possibly with an uncorrected, non-fatal AER error
triggered on the host. Some systems however take it upon themselves
to bring down the entire system when they see something that might
indicate a loss of data, such as this discarded write to a disabled
memory space.
To avoid this, we want to try to block the user from accessing memory
spaces while they're disabled. We start with a semaphore around the
memory enable bit, where writers modify the memory enable state and
must be serialized, while readers make use of the memory region and
can access in parallel. Writers include both direct manipulation via
the command register, as well as any reset path where the internal
mechanics of the reset may both explicitly and implicitly disable
memory access, and manipulation of the MSI-X configuration, where the
MSI-X vector table resides in MMIO space of the device. Readers
include the read and write file ops to access the vfio device fd
offsets as well as memory mapped access. In the latter case, we make
use of our new vma list support to zap, or invalidate, those memory
mappings in order to force them to be faulted back in on access.
Our semaphore usage will stall user access to MMIO spaces across
internal operations like reset, but the user might experience new
behavior when trying to access the MMIO space while disabled via the
PCI command register. Access via read or write while disabled will
return -EIO and access via memory maps will result in a SIGBUS. This
is expected to be compatible with known use cases and potentially
provides better error handling capabilities than present in the
hardware, while avoiding the more readily accessible and severe
platform error responses that might otherwise occur.
Fixes: CVE-2020-12888
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2020-04-22 19:48:11 +00:00
|
|
|
u16 cmd);
|
|
|
|
|
|
2016-02-22 23:02:43 +00:00
|
|
|
#ifdef CONFIG_VFIO_PCI_IGD
|
2021-08-26 10:39:02 +00:00
|
|
|
extern int vfio_pci_igd_init(struct vfio_pci_core_device *vdev);
|
2016-02-22 23:02:43 +00:00
|
|
|
#else
|
2021-08-26 10:39:02 +00:00
|
|
|
static inline int vfio_pci_igd_init(struct vfio_pci_core_device *vdev)
|
2016-02-22 23:02:43 +00:00
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
2020-10-07 18:56:23 +00:00
|
|
|
|
2021-02-18 10:44:35 +00:00
|
|
|
#ifdef CONFIG_S390
|
2021-08-26 10:39:02 +00:00
|
|
|
extern int vfio_pci_info_zdev_add_caps(struct vfio_pci_core_device *vdev,
|
2020-10-07 18:56:23 +00:00
|
|
|
struct vfio_info_cap *caps);
|
|
|
|
|
#else
|
2021-08-26 10:39:02 +00:00
|
|
|
static inline int vfio_pci_info_zdev_add_caps(struct vfio_pci_core_device *vdev,
|
2020-10-07 18:56:23 +00:00
|
|
|
struct vfio_info_cap *caps)
|
|
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2021-08-26 10:39:05 +00:00
|
|
|
/* Will be exported for vfio pci drivers usage */
|
2021-08-26 10:39:07 +00:00
|
|
|
void vfio_pci_core_set_params(bool nointxmask, bool is_disable_vga,
|
|
|
|
|
bool is_disable_idle_d3);
|
2021-08-26 10:39:05 +00:00
|
|
|
void vfio_pci_core_close_device(struct vfio_device *core_vdev);
|
|
|
|
|
void vfio_pci_core_init_device(struct vfio_pci_core_device *vdev,
|
|
|
|
|
struct pci_dev *pdev,
|
|
|
|
|
const struct vfio_device_ops *vfio_pci_ops);
|
|
|
|
|
int vfio_pci_core_register_device(struct vfio_pci_core_device *vdev);
|
|
|
|
|
void vfio_pci_core_uninit_device(struct vfio_pci_core_device *vdev);
|
|
|
|
|
void vfio_pci_core_unregister_device(struct vfio_pci_core_device *vdev);
|
|
|
|
|
int vfio_pci_core_sriov_configure(struct pci_dev *pdev, int nr_virtfn);
|
|
|
|
|
extern const struct pci_error_handlers vfio_pci_core_err_handlers;
|
|
|
|
|
long vfio_pci_core_ioctl(struct vfio_device *core_vdev, unsigned int cmd,
|
|
|
|
|
unsigned long arg);
|
|
|
|
|
ssize_t vfio_pci_core_read(struct vfio_device *core_vdev, char __user *buf,
|
|
|
|
|
size_t count, loff_t *ppos);
|
|
|
|
|
ssize_t vfio_pci_core_write(struct vfio_device *core_vdev, const char __user *buf,
|
|
|
|
|
size_t count, loff_t *ppos);
|
|
|
|
|
int vfio_pci_core_mmap(struct vfio_device *core_vdev, struct vm_area_struct *vma);
|
|
|
|
|
void vfio_pci_core_request(struct vfio_device *core_vdev, unsigned int count);
|
|
|
|
|
int vfio_pci_core_match(struct vfio_device *core_vdev, char *buf);
|
2021-08-26 10:39:06 +00:00
|
|
|
int vfio_pci_core_enable(struct vfio_pci_core_device *vdev);
|
|
|
|
|
void vfio_pci_core_disable(struct vfio_pci_core_device *vdev);
|
|
|
|
|
void vfio_pci_core_finish_enable(struct vfio_pci_core_device *vdev);
|
|
|
|
|
|
|
|
|
|
static inline bool vfio_pci_is_vga(struct pci_dev *pdev)
|
|
|
|
|
{
|
|
|
|
|
return (pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA;
|
|
|
|
|
}
|
2021-08-26 10:39:05 +00:00
|
|
|
|
2021-08-26 10:39:01 +00:00
|
|
|
#endif /* VFIO_PCI_CORE_H */
|