What's the status of pre-kDMAp IOMMU-enabled systems?

[tanriol]

Please document somewhere the protection status of systems that are pre-2019 and don't have the opt-in flag in the DMAR table, but do have an enabled IOMMU. Are they still "fully vulnerable", or are they only partially vulnerable (during boot/suspend/resume or something like that)?

[BjornRuytenberg]

Thanks for the question. To enable Kernel DMA Protection, there are three requirements:

1. The CPU provides an IOMMU
2. UEFI enables the opt-in flag in the DMAR table
3. The OS supports enforcing Kernel DMA Protection (DMA remapping of TB-related PCI endpoints)

The opt-in flag is required for the OS to have the IOMMU automatically restrict all PCIe endpoints, downstream of the Thunderbolt bridge, to their own memory range. Unfortunately, while systems might provide the first (both pre-2019 and since), this means they will not provide Kernel DMA Protection if the opt-in flag is not set, and are hence fully vulnerable.

I will have a look if we can clarify this on the webpage.

[tanriol]

The point of my question is what happens when the opt-in flag is not present, but the system supports IOMMU? Does the absence of opt-in force the kernel (I'm primarily interested in Linux 5+) to provide full access to physical memory even though it has the ability to restrict it?

When the Thunderbolt controller is forced online in my system (a 2016 laptop), a number of devices comes up and for every new PCI-E device I see a line in dmesg saying "pci (address): Adding to iommu group (number)", and all the group numbers are different. Does this imply anything about protection? Is the kernel required to give full access to all these groups?

[tanriol]

Also, is it possible to force the kernel to restrict them without the opt-in flag?