Layerscapeのトピックarm-smmu.disable_bypass=n on DPAA2(LS1088/2088/2160) for Kernel 5.2

arm-smmu.disable_bypass=n on DPAA2(LS1088/2088/2160) for Kernel 5.2

mcbridematt — Fri, 06 Sep 2019 04:44:52 GMT

I've been testing out different mainline Linux kernels on the LS1088 and found that kernel 5.2 and later will not boot out of the box due to this change:

Commit 954a03be033c7cef80ddc232e7cbdb17df735663

iommu/arm-smmu: Break insecure users by disabling bypass by default

If you're bisecting why your peripherals stopped working, it's probably this CL. Specifically if you see this in your dmesg: Unexpected global fault, this could be serious ...then it's almost certainly this CL. Running your IOMMU-enabled peripherals with the IOMMU in bypass mode is insecure and effectively disables the protection they provide. There are few reasons to allow unmatched stream bypass, and even fewer good ones.

With this change, there will be iommu error messages on boot:

"[   28.551066] arm_smmu_global_fault: 2455962 callbacks suppressed
[   28.551069] arm-smmu 5000000.iommu: Unexpected global fault, this could be serious
[   28.564542] arm_smmu_global_fault: 2455962 callbacks suppressed
[   28.564545] arm-smmu 5000000.iommu: GFSR 0x80000002, GFSYNR0 0x00000008, GFSYNR1 0x00001300, GFSYNR2 0x00000000
[   28.580630] arm-smmu 5000000.iommu: Unexpected global fault, this could be serious
[   28.588193] arm-smmu 5000000.iommu: GFSR 0x80000002, GFSYNR0 0x00000008, GFSYNR1 0x00001300, GFSYNR2 0x00000000"

etc.

The workaround is to add "arm-smmu.disable_bypass=n" to the kernel command line and the system will boot normally (I have tested the latest 5.3.0-rc7 and it works with this command line argument)

Does NXP have any timeline for a fix for future kernels that would allow them to boot without bypass enabled?

Without a fix, the usage of standard Linux distributions (not LSDK) on DPAA2 platforms is hindered.

Re: arm-smmu.disable_bypass=n on DPAA2(LS1088/2088/2160) for Kernel 5.2

yipingwang — Mon, 09 Sep 2019 09:02:46 GMT

Hello Mathew McBride,

This problem has already been tracked in https://jira.sw.nxp.com/browse/QORIQLU-471 in our internal defect system, it has not been fixed so far.

This patch starts the transition over to make it much harder to run
your system insecurely. Expected steps:

1. By default disable bypass (so anyone insecure will notice) but make
it easy for someone to re-enable bypass with just a KConfig change.
That's this patch.

2. After people have had a little time to come to grips with the fact
that they need to set their IOMMUs properly and have had time to
dig into how to do this, the KConfig will be eliminated and bypass
will simply be disabled. Folks who are truly upset and still
haven't fixed their system can either figure out how to add
'arm-smmu.disable_bypass=n' to their command line or revert the
patch in their own private kernel. Of course these folks will be
less secure.

Thanks,

Yiping

Re: arm-smmu.disable_bypass=n on DPAA2(LS1088/2088/2160) for Kernel 5.2

jrddunbr — Sun, 27 Feb 2022 01:37:06 GMT

Yiping,

I was wondering if there is an update on this issue? I tried following the link to your JIRA site that you provided, but it gives my browser a "Secure Connection Failed" message in Firefox, so I cannot see the progress.

I am currently using the mitigation that has been suggested ("arm-smmu.disable_bypass=n"), but I would really appreciate it if I can remove the mitigation and have the correct, secure configuration.

Thank you!

Jared D.

Re: arm-smmu.disable_bypass=n on DPAA2(LS1088/2088/2160) for Kernel 5.2

anju_bhartiya — Tue, 08 Apr 2025 07:53:19 GMT

edited an old ticket by mistake.