Re: [PATCH 00/11] Fix incorrect iommu_groups with PCIe switches

[Jason Gunthorpe <jgg@nvidia.com>]

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