Re: [PATCH v6 12/24] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Mar 17, 2023 at 09:15:57AM -0600, Alex Williamson wrote:
> > If that is the intended usage then I don't see why this proposal will
> > promote userspace to ignore the _INFO ioctl. It should be always
> > queried no matter how the reset ioctl itself is designed. The motivation
> > of calling _INFO is not from the reset ioctl asking for an array of fds.
> 
> The VFIO_DEVICE_PCI_HOT_RESET ioctl requires a set of group (or cdev)
> fds that encompass the set of affected devices reported by the
> VFIO_DEVICE_GET_PCI_HOT_RESET_INFO ioctl, so I don't agree with the
> last sentence above.

There are two things going on - VFIO_DEVICE_PCI_HOT_RESET requires to
prove security that the userspace is not attempting to reset something
that it does not have ownership over. Eg a reset group that spans
multiple iommu groups.

The second is for userspace to discover the reset group so it can
understand what is happening.

IMHO it is perfectly fine for each API to be only concerned with its
own purpose.

VFIO_DEVICE_PCI_HOT_RESET needs to check security, which the
iommufd_ctx check does just fine

VFIO_DEVICE_GET_PCI_HOT_RESET_INFO needs to convey the reset group
span so userspace can do something with this.

I think confusing security and scope and "acknowledgment" is not a
good idea.

The APIs are well defined and userspace can always use them wrong. It
doesn't need to call RESET_INFO even today, it can just trivially pass
every group FD it owns to meet the security check.

It is much simpler if VFIO_DEVICE_PCI_HOT_RESET can pass the security
check without code marshalling fds, which is why we went this
direction.

Jason



[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux