> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Wednesday, September 29, 2021 8:28 PM > > On Wed, Sep 29, 2021 at 06:41:00AM +0000, Tian, Kevin wrote: > > > From: David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> > > > Sent: Wednesday, September 29, 2021 2:01 PM > > > > > > On Sun, Sep 19, 2021 at 02:38:36PM +0800, Liu Yi L wrote: > > > > This patch adds VFIO_DEVICE_BIND_IOMMUFD for userspace to bind > the > > > vfio > > > > device to an iommufd. No VFIO_DEVICE_UNBIND_IOMMUFD interface > is > > > provided > > > > because it's implicitly done when the device fd is closed. > > > > > > > > In concept a vfio device can be bound to multiple iommufds, each > hosting > > > > a subset of I/O address spaces attached by this device. > > > > > > I really feel like this many<->many mapping between devices is going > > > to be super-confusing, and therefore make it really hard to be > > > confident we have all the rules right for proper isolation. > > > > Based on new discussion on group ownership part (patch06), I feel this > > many<->many relationship will disappear. The context fd (either container > > or iommufd) will uniquely mark the ownership on a physical device and > > its group. With this design it's impractical to have one device bound > > to multiple iommufds. > > That should be a requirement! We have no way to prove that two > iommufds are the same security domain, so devices/groups cannot be > shared. > > That is why the API I suggested takes in a struct file to ID the user > security context. A group is accessible only from that single struct > file and no more. > > If the first series goes the way I outlined then I think David's > concern about security is strongly solved as the IOMMU layer is > directly managing it with a very clear responsiblity and semantic. > Yes, this is also my understanding now.
