RE: [PATCH 09/10] kvm/vfio: Remove vfio_group from kvm

Tian, Kevin
2022-04-16T01:05:43Z

> From: Jason Gunthorpe <jgg@nvidia.com>
> 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@nvidia.com>
> > > 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