I’m on the 7840U Framework 13, BIOS 3.05, secure boot disabled, kernel 6.13.6 (void Linux default x86_64 config, except added CONFIG_BLK_SED_OPAL=y) and these two options (amd_iommu=off iommu=pt) worked for me. Once I added them to the kernel cmdline suspend to RAM wakes quickly and successfully. I did not need to use the sed-opal-unlocker s3save.
What’s the consequence of those options? Is it a bad idea to keep them so I can suspend to RAM? Anything else I can/should do to help debug and offer more information?
1 Like
Nice find! I can confirm on my setup that adding iommu=pt works for me with the same benefits; resume from suspend is fast and I don’t need sed-opal-unlocker either.
My setup: 7640U Framework 13 with BIOS 3.05, Secure Boot enabled, kernel 6.12.12 (from bookworm-backports), SSD is WD_BLACK SN850X 1TB
About the flags themselves: I’m not an expert, but you shouldn’t need both amd_iommu=off and iommu=pt. From what I know, the latter option is commonly used passing through PCIe devices to KVM to increase performance of the host. I don’t know of any consequences to enabling it.
Thanks again to both of you! Finally, suspend & resume works normally with a storage password set.
The IOMMU enforces that devices can only access their own designated memory space.
The consequence is that you will be more vulnerable to a DMA attack from an untrusted external device. Linux mitigates this for USB4/TBT3 devices by “security levels” when it’s not a safely configured IOMMU configuration. You can read more about them here.
But if hypothetically a vulnerability existed in another PCIe device like your WLAN it could compromise memory outside of the space designated for the WLAN to communicate. Or if there was a GFX driver vulnerability the PCI GFX device might be able to access more memory than it should.
From my experience in this type of issue what is going on is that there is a specific memory address that the BIOS uses to “cache” the password for unlocking the disk across a suspend cycle. So when you resume it fetches that password from that designated memory address and then uses it to unlock the disk. If that memory range isn’t something that is described in the ACPI IVRS table then it’s a page fault when the IOMMU attempts to access such an address. The most likely solution is to introduce what’s called a “Unity mapping” to the ACPI IVRS table.
If not already reported here, you should file an issue with your findings.