Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 23 2月, 2016 8 次提交
  3. 28 1月, 2016 1 次提交
  5. 05 1月, 2016 1 次提交
  7. 22 12月, 2015 2 次提交
    • A
      vfio: Include No-IOMMU mode · 03a76b60
      由 Alex Williamson 提交于 
      There is really no way to safely give a user full access to a DMA
capable device without an IOMMU to protect the host system.  There is
also no way to provide DMA translation, for use cases such as device
assignment to virtual machines.  However, there are still those users
that want userspace drivers even under those conditions.  The UIO
driver exists for this use case, but does not provide the degree of
device access and programming that VFIO has.  In an effort to avoid
code duplication, this introduces a No-IOMMU mode for VFIO.

This mode requires building VFIO with CONFIG_VFIO_NOIOMMU and enabling
the "enable_unsafe_noiommu_mode" option on the vfio driver.  This
should make it very clear that this mode is not safe.  Additionally,
CAP_SYS_RAWIO privileges are necessary to work with groups and
containers using this mode.  Groups making use of this support are
named /dev/vfio/noiommu-$GROUP and can only make use of the special
VFIO_NOIOMMU_IOMMU for the container.  Use of this mode, specifically
binding a device without a native IOMMU group to a VFIO bus driver
will taint the kernel and should therefore not be considered
supported.  This patch includes no-iommu support for the vfio-pci bus
driver only.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>
      03a76b60
    • D
      VFIO: platform: reset: fix a warning message condition · 96762882
      由 Dan Carpenter 提交于 
      This loop ends with count set to -1 and not zero so the warning message
isn't printed when it should be.  I've fixed this by change the postop
to a preop.

Fixes: 0990822c ('VFIO: platform: reset: AMD xgbe reset module')
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NEric Auger <eric.auger@linaro.org>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      96762882
  9. 04 12月, 2015 1 次提交
  11. 21 11月, 2015 2 次提交
  13. 20 11月, 2015 2 次提交
  15. 09 11月, 2015 1 次提交
    • D
      vfio/pci: make an array larger · 222e684c
      由 Dan Carpenter 提交于 
      Smatch complains about a possible out of bounds error:

	drivers/vfio/pci/vfio_pci_config.c:1241 vfio_cap_init()
	error: buffer overflow 'pci_cap_length' 20 <= 20

The problem is that pci_cap_length[] was defined as large enough to
hold "PCI_CAP_ID_AF + 1" elements.  The code in vfio_cap_init() assumes
it has PCI_CAP_ID_MAX + 1 elements.  Originally, PCI_CAP_ID_AF and
PCI_CAP_ID_MAX were the same but then we introduced PCI_CAP_ID_EA in
commit f80b0ba9 ("PCI: Add Enhanced Allocation register entries")
so now the array is too small.

Let's fix this by making the array size PCI_CAP_ID_MAX + 1.  And let's
make a similar change to pci_ext_cap_length[] for consistency.  Also
both these arrays can be made const.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      222e684c
  17. 05 11月, 2015 2 次提交
    • A
      vfio: Include No-IOMMU mode · 033291ec
      由 Alex Williamson 提交于 
      There is really no way to safely give a user full access to a DMA
capable device without an IOMMU to protect the host system.  There is
also no way to provide DMA translation, for use cases such as device
assignment to virtual machines.  However, there are still those users
that want userspace drivers even under those conditions.  The UIO
driver exists for this use case, but does not provide the degree of
device access and programming that VFIO has.  In an effort to avoid
code duplication, this introduces a No-IOMMU mode for VFIO.

This mode requires building VFIO with CONFIG_VFIO_NOIOMMU and enabling
the "enable_unsafe_noiommu_mode" option on the vfio driver.  This
should make it very clear that this mode is not safe.  Additionally,
CAP_SYS_RAWIO privileges are necessary to work with groups and
containers using this mode.  Groups making use of this support are
named /dev/vfio/noiommu-$GROUP and can only make use of the special
VFIO_NOIOMMU_IOMMU for the container.  Use of this mode, specifically
binding a device without a native IOMMU group to a VFIO bus driver
will taint the kernel and should therefore not be considered
supported.  This patch includes no-iommu support for the vfio-pci bus
driver only.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>
      033291ec
    • J
      vfio: Fix bug in vfio_device_get_from_name() · e324fc82
      由 Joerg Roedel 提交于 
      The vfio_device_get_from_name() function might return a
non-NULL pointer, when called with a device name that is not
found in the list. This causes undefined behavior, in my
case calling an invalid function pointer later on:

 kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
 BUG: unable to handle kernel paging request at ffff8800cb3ddc08

[...]

 Call Trace:
  [<ffffffffa03bd733>] ? vfio_group_fops_unl_ioctl+0x253/0x410 [vfio]
  [<ffffffff811efc4d>] do_vfs_ioctl+0x2cd/0x4c0
  [<ffffffff811f9657>] ? __fget+0x77/0xb0
  [<ffffffff811efeb9>] SyS_ioctl+0x79/0x90
  [<ffffffff81001bb0>] ? syscall_return_slowpath+0x50/0x130
  [<ffffffff8167f776>] entry_SYSCALL_64_fastpath+0x16/0x75

Fix the issue by returning NULL when there is no device with
the requested name in the list.

Cc: stable@vger.kernel.org # v4.2+
Fixes: 4bc94d5d ("vfio: Fix lockdep issue")
Signed-off-by: NJoerg Roedel <jroedel@suse.de>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      e324fc82
  19. 04 11月, 2015 11 次提交
  21. 28 10月, 2015 3 次提交
    • E
      VFIO: platform: clear IRQ_NOAUTOEN when de-assigning the IRQ · 1276ece3
      由 Eric Auger 提交于 
      The vfio platform driver currently sets the IRQ_NOAUTOEN before
doing the request_irq to properly handle the user masking. However
it does not clear it when de-assigning the IRQ. This brings issues
when loading the native driver again which may not explicitly enable
the IRQ. This problem was observed with xgbe driver.
Signed-off-by: NEric Auger <eric.auger@linaro.org>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      1276ece3
    • A
      vfio/pci: Use kernel VPD access functions · 4e1a6355
      由 Alex Williamson 提交于 
      The PCI VPD capability operates on a set of window registers in PCI
config space.  Writing to the address register triggers either a read
or write, depending on the setting of the PCI_VPD_ADDR_F bit within
the address register.  The data register provides either the source
for writes or the target for reads.

This model is susceptible to being broken by concurrent access, for
which the kernel has adopted a set of access functions to serialize
these registers.  Additionally, commits like 932c435c ("PCI: Add
dev_flags bit to access VPD through function 0") and 7aa6ca4d
("PCI: Add VPD function 0 quirk for Intel Ethernet devices") indicate
that VPD registers can be shared between functions on multifunction
devices creating dependencies between otherwise independent devices.

Fortunately it's quite easy to emulate the VPD registers, simply
storing copies of the address and data registers in memory and
triggering a VPD read or write on writes to the address register.
This allows vfio users to avoid seeing spurious register changes from
accesses on other devices and enables the use of shared quirks in the
host kernel.  We can theoretically still race with access through
sysfs, but the window of opportunity is much smaller.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Acked-by: NMark Rustad <mark.d.rustad@intel.com>
      4e1a6355
    • A
      vfio: Whitelist PCI bridges · 5f096b14
      由 Alex Williamson 提交于 
      When determining whether a group is viable, we already allow devices
bound to pcieport.  Generalize this to include any PCI bridge device.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      5f096b14
  23. 01 10月, 2015 1 次提交
  25. 25 7月, 2015 1 次提交
    • A
      vfio: Fix lockdep issue · 4bc94d5d
      由 Alex Williamson 提交于 
      When we open a device file descriptor, we currently have the
following:

vfio_group_get_device_fd()
  mutex_lock(&group->device_lock);
    open()
    ...
    if (ret)
      release()

If we hit that error case, we call the backend driver release path,
which for vfio-pci looks like this:

vfio_pci_release()
  vfio_pci_disable()
    vfio_pci_try_bus_reset()
      vfio_pci_get_devs()
        vfio_device_get_from_dev()
          vfio_group_get_device()
            mutex_lock(&group->device_lock);

Whoops, we've stumbled back onto group.device_lock and created a
deadlock.  There's a low likelihood of ever seeing this play out, but
obviously it needs to be fixed.  To do that we can use a reference to
the vfio_device for vfio_group_get_device_fd() rather than holding the
lock.  There was a loop in this function, theoretically allowing
multiple devices with the same name, but in practice we don't expect
such a thing to happen and the code is already aborting from the loop
with break on any sort of error rather than continuing and only
parsing the first match anyway, so the loop was effectively unused
already.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Fixes: 20f30017 ("vfio/pci: Fix racy vfio_device_get_from_dev() call")
Reported-by: NJoerg Roedel <joro@8bytes.org>
Tested-by: NJoerg Roedel <jroedel@suse.de>
      4bc94d5d
  27. 22 6月, 2015 4 次提交