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. Jason
