Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 04 12月, 2015 1 次提交
  3. 21 11月, 2015 1 次提交
  5. 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
  7. 28 10月, 2015 1 次提交
  9. 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
  11. 10 6月, 2015 1 次提交
    • A
      vfio/pci: Fix racy vfio_device_get_from_dev() call · 20f30017
      由 Alex Williamson 提交于 
      Testing the driver for a PCI device is racy, it can be all but
complete in the release path and still report the driver as ours.
Therefore we can't trust drvdata to be valid.  This race can sometimes
be seen when one port of a multifunction device is being unbound from
the vfio-pci driver while another function is being released by the
user and attempting a bus reset.  The device in the remove path is
found as a dependent device for the bus reset of the release path
device, the driver is still set to vfio-pci, but the drvdata has
already been cleared, resulting in a null pointer dereference.

To resolve this, fix vfio_device_get_from_dev() to not take the
dev_get_drvdata() shortcut and instead traverse through the
iommu_group, vfio_group, vfio_device path to get a reference we
can trust.  Once we have that reference, we know the device isn't
in transition and we can test to make sure the driver is still what
we expect, so that we don't interfere with devices we don't own.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      20f30017
  13. 02 5月, 2015 1 次提交
    • A
      vfio: Fix runaway interruptible timeout · db7d4d7f
      由 Alex Williamson 提交于 
      Commit 13060b64 ("vfio: Add and use device request op for vfio
bus drivers") incorrectly makes use of an interruptible timeout.
When interrupted, the signal remains pending resulting in subsequent
timeouts occurring instantly.  This makes the loop spin at a much
higher rate than intended.

Instead of making this completely non-interruptible, we can change
this into a sort of interruptible-once behavior and use the "once"
to log debug information.  The driver API doesn't allow us to abort
and return an error code.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Fixes: 13060b64
Cc: stable@vger.kernel.org # v4.0
      db7d4d7f
  15. 17 3月, 2015 3 次提交
  17. 11 2月, 2015 1 次提交
    • A
      vfio: Add and use device request op for vfio bus drivers · 13060b64
      由 Alex Williamson 提交于 
      When a request is made to unbind a device from a vfio bus driver,
we need to wait for the device to become unused, ie. for userspace
to release the device.  However, we have a long standing TODO in
the code to do something proactive to make that happen.  To enable
this, we add a request callback on the vfio bus driver struct,
which is intended to signal the user through the vfio device
interface to release the device.  Instead of passively waiting for
the device to become unused, we can now pester the user to give
it up.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      13060b64
  19. 07 2月, 2015 2 次提交
    • A
      vfio: Tie IOMMU group reference to vfio group · 4a68810d
      由 Alex Williamson 提交于 
      Move the iommu_group reference from the device to the vfio_group.
This ensures that the iommu_group persists as long as the vfio_group
remains.  This can be important if all of the device from an
iommu_group are removed, but we still have an outstanding vfio_group
reference; we can still walk the empty list of devices.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      4a68810d
    • A
      vfio: Add device tracking during unbind · 60720a0f
      由 Alex Williamson 提交于 
      There's a small window between the vfio bus driver calling
vfio_del_group_dev() and the device being completely unbound where
the vfio group appears to be non-viable.  This creates a race for
users like QEMU/KVM where the kvm-vfio module tries to get an
external reference to the group in order to match and release an
existing reference, while the device is potentially being removed
from the vfio bus driver.  If the group is momentarily non-viable,
kvm-vfio may not be able to release the group reference until VM
shutdown, making the group unusable until that point.

Bridge the gap between device removal from the group and completion
of the driver unbind by tracking it in a list.  The device is added
to the list before the bus driver reference is released and removed
using the existing unbind notifier.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      60720a0f
  21. 28 5月, 2014 1 次提交
  23. 27 2月, 2014 1 次提交
  25. 20 12月, 2013 1 次提交
  27. 23 8月, 2013 2 次提交
  29. 06 8月, 2013 1 次提交
    • A
      vfio: add external user support · 6cdd9782
      由 Alexey Kardashevskiy 提交于 
      VFIO is designed to be used via ioctls on file descriptors
returned by VFIO.

However in some situations support for an external user is required.
The first user is KVM on PPC64 (SPAPR TCE protocol) which is going to
use the existing VFIO groups for exclusive access in real/virtual mode
on a host to avoid passing map/unmap requests to the user space which
would made things pretty slow.

The protocol includes:

1. do normal VFIO init operation:
	- opening a new container;
	- attaching group(s) to it;
	- setting an IOMMU driver for a container.
When IOMMU is set for a container, all groups in it are
considered ready to use by an external user.

2. User space passes a group fd to an external user.
The external user calls vfio_group_get_external_user()
to verify that:
	- the group is initialized;
	- IOMMU is set for it.
If both checks passed, vfio_group_get_external_user()
increments the container user counter to prevent
the VFIO group from disposal before KVM exits.

3. The external user calls vfio_external_user_iommu_id()
to know an IOMMU ID. PPC64 KVM uses it to link logical bus
number (LIOBN) with IOMMU ID.

4. When the external KVM finishes, it calls
vfio_group_put_external_user() to release the VFIO group.
This call decrements the container user counter.
Everything gets released.

The "vfio: Limit group opens" patch is also required for the consistency.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      6cdd9782
  31. 25 7月, 2013 2 次提交
    • A
      vfio: Ignore sprurious notifies · c6401930
      由 Alex Williamson 提交于 
      Remove debugging WARN_ON if we get a spurious notify for a group that
no longer exists.  No reports of anyone hitting this, but it would
likely be a race and not a bug if they did.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      c6401930
    • A
      vfio: Don't overreact to DEL_DEVICE · de9c7602
      由 Alex Williamson 提交于 
      BUS_NOTIFY_DEL_DEVICE triggers IOMMU drivers to remove devices from
their iommu group, but there's really nothing we can do about it at
this point.  If the device is in use, then the vfio sub-driver will
block the device_del from completing until it's released.  If the
device is not in use or not owned by a vfio sub-driver, then we
really don't care that it's being removed.

The current code can be triggered just by unloading an sr-iov driver
(ex. igb) while the VFs are attached to vfio-pci because it makes an
incorrect assumption about the ordering of driver remove callbacks
vs the DEL_DEVICE notification.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      de9c7602
  33. 26 6月, 2013 1 次提交
    • A
      vfio: Limit group opens · 6d6768c6
      由 Alex Williamson 提交于 
      vfio_group_fops_open attempts to limit concurrent sessions by
disallowing opens once group->container is set.  This really doesn't
do what we want and allow for inconsistent behavior, for instance a
group can be opened twice, then a container set giving the user two
file descriptors to the group.  But then it won't allow more to be
opened.  There's not much reason to have the group opened multiple
times since most access is through devices or the container, so
complete what the original code intended and only allow a single
instance.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      6d6768c6
  35. 20 6月, 2013 1 次提交
  37. 05 6月, 2013 1 次提交
  39. 01 5月, 2013 1 次提交
    • A
      vfio: Set container device mode · 664e9386
      由 Alex Williamson 提交于 
      Minor 0 is the VFIO container device (/dev/vfio/vfio).  On it's own
the container does not provide a user with any privileged access.  It
only supports API version check and extension check ioctls.  Only by
attaching a VFIO group to the container does it gain any access.  Set
the mode of the container to allow access.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      664e9386
  41. 29 4月, 2013 1 次提交
  43. 26 4月, 2013 1 次提交
  45. 11 3月, 2013 1 次提交
  47. 28 2月, 2013 1 次提交
  49. 15 2月, 2013 2 次提交
    • A
      vfio: whitelist pcieport · 2b489a45
      由 Alex Williamson 提交于 
      pcieport does nice things like manage AER and we know it doesn't do
DMA or expose any user accessible devices on the host.  It also keeps
the Memory, I/O, and Busmaster bits enabled, which is pretty handy
when trying to use anyting below it.  Devices owned by pcieport cannot
be given to users via vfio, but we can tolerate them not being owned
by vfio-pci.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      2b489a45
    • A
      vfio: Protect vfio_dev_present against device_del · e014e944
      由 Alex Williamson 提交于 
      vfio_dev_present is meant to give us a wait_event callback so that we
can block removing a device from vfio until it becomes unused.  The
root of this check depends on being able to get the iommu group from
the device.  Unfortunately if the BUS_NOTIFY_DEL_DEVICE notifier has
fired then the device-group reference is no longer searchable and we
fail the lookup.

We don't need to go to such extents for this though.  We have a
reference to the device, from which we can acquire a reference to the
group.  We can then use the group reference to search for the device
and properly block removal.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      e014e944
  51. 08 12月, 2012 2 次提交
  53. 27 9月, 2012 2 次提交
  55. 22 8月, 2012 4 次提交