On Fri, Mar 1, 2019 at 11:21 AM Douglas Anderson <dianders@xxxxxxxxxxxx> wrote: > > 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. > > 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. > > Suggested-by: Robin Murphy <robin.murphy@xxxxxxx> > Signed-off-by: Douglas Anderson <dianders@xxxxxxxxxxxx> > --- Hi Doug / Robin, I ran into this breaking things on OcteonTx boards based on CN80XX CPU. The IOMMU configuration is a bit beyond me and I'm hoping you can offer some advice. The IOMMU here is cavium,smmu-v2 as defined in https://github.com/Gateworks/dts-newport/blob/master/cn81xx-linux.dtsi Booting with 'arm-smmu.disable_bypass=n' does indeed work around the breakage as the commit suggests. Any suggestions for a proper fix? Best Regards, Tim
