On Fri, Jun 11, 2021 at 01:38:28PM -0600, Alex Williamson wrote: > That's fine for a serial port, but not a device that can do DMA. > The entire point of vfio is to try to provide secure, DMA capable > userspace drivers. If we relax enforcement of that isolation we've > failed. I don't understand why the IOASID matters at all in this. Can you explain? What is the breach of isolation? A userspace process can create many IOASIDs, it can create an IOASID that can touch any memory the process can touch. It can create two IOASID's that are identical copies of each other. How does restricting a device from attaching to an IOASID create security if I can just make a copy of that IOASID and attach to that? Is there some quirk of the IOMMU I'm missing? My understanding of isolation has been that two different security contexts cannot have access to devices in the same group because that can leak access across a security bounday, eg because device A can do DMA to device B and take control of it. Isolation means that the control of the devices in a group is not inadventantly spread between two security contexts, like two processes. > I don't see how this provides isolation. If a user only needs to > attach their devicefd to an ioasidfd to have full access to their > device, not even bound by attaching to an ioasid context, then we've > failed. That is not quite what I tried to explain. The first ioasid any device in the group attaches to becomes the only ioasid that any device in the group attaches to. It is an ownership model unique to the iommu_fd. It directly prevents process A and process B from opening devices in the same group and trying to operate them independently. A and B will not posses the same iommu fd so only one of them can activate a device. The other device remains unusable. Iin this model, I consider the iommu_fd to be the security domain. The meaning of isolation is that only devices explicitly joined to an iommu_fd can access IOASIDs in that iommu_fd. Userspace has choices how to use this Placing all devices in the same iommu_fd userspace is telling the kernel that they are in the same security domain. This means userspace says is safe for them to all share IOASIDs without isolation. If userspace wants tigher security domains then userspace can create additional iommu_fds, up to a unique iommu_fd per group. This would duplicate the security model that the vfio groups force today. The kernel security feature is to prevent un-isolated devices from being joined to different iommu_fd security contexts. Jason
