Note this issue most likely has something to do with some upstream kernel changes.

Can someone file a kernel issue, either upstream or in Fedora bugzilla?

@jforbes - any advice here?

Yes, the config item in question is CONFIG_INTEL_IOMMU_DEFAULT_ON and it is set to off for a reason. We originally kept it on and there are a massive number of systems that choke in various ways. Granted, this was years ago that we turned it off, so I just did a quick check again. Seems Ubuntu tried to turn it back on with 5.15:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1971699
Sadly, this is not really something that can be fixed upstream, it would basically require setting up some sort of a quirk list of systems known to choke on Intel IOMMU. It's not going to happen.

@rhughes we'll probably need your input on this. The HSI levels will need to be modified if we're not willing to turn on the IOMMU. Doesn't make sense to flag every system as insecure when it's a Fedora kernel config decision to keep it off.

Alternatively, this might be a case where we just need to make the jump, turn it on, and let developers deal with the fallout. Otherwise, I can imagine the bugs will never be fixed....

@catanzaro What gave you the impression that the bugs were in software?

@catanzaro What gave you the impression that the bugs were in software?

Uhh, you're suggesting that there could be hardware bugs here? That would be unfortunate, but if so, I guess the only way to figure out how many systems are affected is to enable it....

Yes, there are several hardware bugs. At one point, entire series of Thinkpad laptops. and several other systems. It has been a while, some of those systems are no longer in widespread use, but as we all know, Fedora has plenty of people using old hardware. This is why I said "fixing it upstream" would be essentially compiling a list of every system where it is is broken, and disabling it with a quirk. This seems unlikely to fly. Distros keep this off for a reason, and Ubuntu's turning it on was short lived. It might be interesting to turn it on at command line with the installer if ThunderBolt is found on the system and hope that those systems are new enough to work properly? It is still a gamble, I don't think any distro's turn it on by default.

Yes, there are several hardware bugs. At one point, entire series of Thinkpad laptops. and several other systems. It has been a while, some of those systems are no longer in widespread use, but as we all know, Fedora has plenty of people using old hardware. This is why I said "fixing it upstream" would be essentially compiling a list of every system where it is is broken, and disabling it with a quirk.

OK, very interesting.

This seems unlikely to fly.

Why not? That actually sounds like a good proposal to me: enable it by default early in the release cycle, expect users to report bugs, and denylist anything that's known to be broken. It will no doubt be rough at first, but presumably should be OK in the long run? If we don't try and find out, then we'll never succeed.

Distros keep this off for a reason, and Ubuntu's turning it on was short lived. It might be interesting to turn it on at command line with the installer if ThunderBolt is found on the system and hope that those systems are new enough to work properly? It is still a gamble, I don't think any distro's turn it on by default.

I doubt the IOMMU protection is really only needed by Thunderbolt devices though, is it? I don't know much about it, but I assumed this was important to prevent all manner of peripheral devices from modifying memory they shouldn't have access to?

@catanzaro IOMMUs ( as well as SWIOMMU ) originally came about to solve a 32-bit address issue then someone got the bright idea to use IOMMUs’ address translation features for virtualization ( you dont need IOMMU for virtualization in most common scenarios just for a direct access to a PCI / PCIe devices and maybe GPU's as well ) and at some point someone got even a bigger and brighter idea to use it to plug a security hole for thunderport devices and as I mentioned on the upstream issue it has an impact on bandwidth performance, it's riddle with landmines as @josef has already pointed out and is recommended to be turned off by default which is what upstream kernel community thus Fedora is doing as well and I personally agree with Josef and the rest of the kernel community it is better to keeping it turned off and leave it up to the users who knows those rare scenarios what it's good for, to enable it.

And quite frankly checking for it being enabled or not as part of some kind of a security feature is quite the security theater since we all know regardless if the "master villain" has spent years perfecting some kind of malicious thunderbolt contraption in his or her basement or "hideout" to target the novice end users, if that scoundrel has physical access to the end user device in the first place, that end user has already lost thus the argument could be made that the best solution is simply to remove it from these HSI specifications

Was sort of confused why my name was being invoked here, as I'm pretty sure my deep hatred of IOMMU is only known to my personal friends and family, but I think you meant @jforbes.

Hmm...

BTW we do already have IOMMU enabled for AMD users. At least, the device security panel says it is enabled for me.

My opinion on this: if it is is a broken and problematic hw feature, we should just ignore it . The few users who know what an IOMMU and care about it also know how to set a kernel commandline option.

Sorry, reading this issue could have saved you the trouble.

BTW we do already have IOMMU enabled for AMD users

For most modern hardware the IOMMU is turned on, and being used by the kernel. In some cases the IOMMU has been blacklisted by the kernel as it causes unspecified problems. We probably need a kernel developer to work out if those reasons are still valid -- for instance one reason for turning it off in the kernel for some Lenovo laptops was that it caused tearing in Xorg when multiple GPUs were being used.

For most modern hardware the IOMMU is turned on, and being used by the kernel. In some cases the IOMMU has been blacklisted by the kernel as it causes unspecified problems. We probably need a kernel developer to work out if those reasons are still valid --

This sounds good to me, but it contradicts what Justin has already told us. He says we would need to enable the CONFIG_INTEL_IOMMU_DEFAULT_ON kernel option, which is currently disabled.

for instance one reason for turning it off in the kernel for some Lenovo laptops was that it caused tearing in Xorg when multiple GPUs were being used.

This should not be a blocker for enabling IOMMU.

@rhughes I'm pretty sure your previous comment is not correct? Either you or @jforbes must be wrong because your statements are contradictory... yes?

Anyway, I want to schedule this for discussion at a future working group meeting. Our meetings are Tuesdays at 10:00 AM Eastern (currently 15:00 UTC) on BlueJeans. I'm tempted to schedule this for next week. If @rhughes or @jforbes would like to attend, does that sound OK, or would you prefer a different Tuesday?

I'm tempted to schedule this for next week.

I didn't schedule this for next week. I will plan on Jan 24 instead, unless somebody who wishes to attend requests a different date.

Well that didn't happen. Let's schedule this for Jan 31. Calendar event here

The CONFIG_INTEL_IOMMU_DEFAULT_ON option does not actually control the default for all Intel hardware; in particular, both Allan and Jonathan report IOMMU is enabled on their Intel systems. It seems IOMMU is enabled/disabled by default on different hardware despite this setting.

Agreed:

• It's appropriate for a device with no IOMMU enabled to fail the hardware security checks, but HSI developers (@rhughes) should consider whether it would be appropriate to exempt devices that do not support Thunderbolt from this check.
• Workstation WG would like to see more effort to enable IOMMU where possible (e.g. perhaps on devices manufactured more recently), but defers to kernel developers as to where exactly IOMMU should be enabled since we do not have kernel expertise.

Device Security panel shows it enabled on my laptop (gen 7 X1 Carbon with latest firmware). Not everyone gets firmware updates with GNOME Software still, so folks should probably check that they have the latest logic board firmware for their system since we're told that's where the problem (likely) resides.

It might also be interesting to investigate the relationship between IOMMU and Thunderbolt controls. For example, if IOMMU is disabled, should we disable access to Thunderbolt, and factor that into the security rating?