On Wed, 9 Jun 2021 17:51:26 +0200 Joerg Roedel <joro@xxxxxxxxxx> wrote: > On Wed, Jun 09, 2021 at 12:00:09PM -0300, Jason Gunthorpe wrote: > > Only *drivers* know what the actual device is going to do, devices do > > not. Since the group doesn't have drivers it is the wrong layer to be > > making choices about how to configure the IOMMU. > > Groups don't carry how to configure IOMMUs, that information is > mostly in the IOMMU domains. And those (or an abstraction of them) is > configured through /dev/ioasid. So not sure what you wanted to say with > the above. > > All a group carries is information about which devices are not > sufficiently isolated from each other and thus need to always be in the > same domain. > > > The device centric approach is my attempt at this, and it is pretty > > clean, I think. > > Clean, but still insecure. > > > All ACS does is prevent P2P operations, if you assign all the group > > devices into the same /dev/iommu then you may not care about that > > security isolation property. At the very least it is policy for user > > to decide, not kernel. > > It is a kernel decision, because a fundamental task of the kernel is to > ensure isolation between user-space tasks as good as it can. And if a > device assigned to one task can interfer with a device of another task > (e.g. by sending P2P messages), then the promise of isolation is broken. AIUI, the IOASID model will still enforce IOMMU groups, but it's not an explicit part of the interface like it is for vfio. For example the IOASID model allows attaching individual devices such that we have granularity to create per device IOASIDs, but all devices within an IOMMU group are required to be attached to an IOASID before they can be used. It's not entirely clear to me yet how that last bit gets implemented though, ie. what barrier is in place to prevent device usage prior to reaching this viable state. > > Groups should be primarily about isolation security, not about IOASID > > matching. > > That doesn't make any sense, what do you mean by 'IOASID matching'? One of the problems with the vfio interface use of groups is that we conflate the IOMMU group for both isolation and granularity. I think what Jason is referring to here is that we still want groups to be the basis of isolation, but we don't want a uAPI that presumes all devices within the group must use the same IOASID. For example, if a user owns an IOMMU group consisting of non-isolated functions of a multi-function device, they should be able to create a vIOMMU VM where each of those functions has its own address space. That can't be done today, the entire group would need to be attached to the VM under a PCIe-to-PCI bridge to reflect the address space limitation imposed by the vfio group uAPI model. Thanks, Alex
