> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Saturday, April 16, 2022 5:56 AM > > On Fri, Apr 15, 2022 at 04:21:45AM +0000, Tian, Kevin wrote: > > > From: Jason Gunthorpe <jgg@xxxxxxxxxx> > > > Sent: Friday, April 15, 2022 2:46 AM > > > > > > None of the VFIO APIs take in the vfio_group anymore, so we can remove > it > > > completely. > > > > > > This has a subtle side effect on the enforced coherency tracking. The > > > vfio_group_get_external_user() was holding on to the container_users > which > > > would prevent the iommu_domain and thus the enforced coherency > value > > > from > > > changing while the group is registered with kvm. > > > > > > It changes the security proof slightly into 'user must hold a group FD > > > that has a device that cannot enforce DMA coherence'. As opening the > group > > > FD, not attaching the container, is the privileged operation this doesn't > > > change the security properties much. > > > > If we allow vfio_file_enforced_coherent() to return error then the security > > proof can be sustained? In this case kvm can simply reject adding a group > > which is opened but not attached to a container. > > The issue is the user can detatch the container from the group because > kvm no longer holds a refcount on the container. > See your point. In this case the guest already loses the access to the device once the container is detached from the group thus using a stale coherency info in KVM side is probably just fine which becomes more a performance issue. Then what about PPC? w/o holding a reference to container is there any impact on spapr_tce_table which is attached to the group? I don't know the relationship between this table and vfio container and whether there is a lifetime dependency in between. Thanks Kevin
