On Fri, Jul 11, 2025 at 08:55:04AM -0600, Alex Williamson wrote: > Sorry, you hit me right before holiday and PTO here. I agree that > we're currently looking at isolation primarily from an egress > perspective. Unfortunately it's not always symmetric. In your case > above, I think we'd consider it safe to assign 1f.6 to a userspace > driver because 1f.6 cannot generate DMA out of its isolation domain. > On the other hand, 1f.4 can theoretically DMA into 1f.6, so it would be > unwise to attach 1f.4 to a userspace driver. In practice there's not > much utility in assigning 1f.4 to a userspace driver, it's generally > bound to a "trusted" kernel driver, so all is well. That is not how we've defined groups as a security object though. If you flip the direction and say 1f.4 is used by VFIO and 1f.6 is in a kernel driver this would not be acceptable. While I like the idea, I think if we keep the current group system we can't really make arguments like this. FWIW, my v2 does seem to solve this problem class well enough. > If we say that 1f.4 taints the group, including 1f.6, I think we're > going to see a bunch of functional regressions for not much actual gain > in security. I have been thinking if we should have an isolation=relaxed/strict boot option and relaxed has assumptions that are closer to what the current kernel does in practice while strict would basically require ACS everywhere to get smaller grouping. For this problem relaxed could assume that a MFD function with no ACS also has no internal loopback at all. Realistically this is probably true in most cases. What concerns me is the enterprise market that does have a strong need for security here but does not have the resources of a CSP to properly self-audit their systems. I think if the enterprise world could be happy in a strict mode where quirks and ACS caps are mandatory which would force their vendors to audit. Consumer/etc doesn't really have the same security need and could be use with relaxed if they have any problems. > Maybe we need some extension to the concept of groups to > represent the asymmetry. Thanks, Do you have any ideas? Arguably the right answer is for groups to only be about DMA aliases and a separate 'P2P security graph' of what devices are allowed to P2P to other devices is used to enforce the VFIO opening rules. I can imagine how to make most of that work in iommufd, but not how to fully retain the VFIO group uAPI. It would be alot of work. But my main concern right now is the switch ACS which is the first three patches only. If we remove the MFD loopback downstream propagation from pci_get_alias_group() I think it will behave quite like today unless switches are present. Would you be comfortable going that far as a first step? Jason
