On Tue, Aug 24, 2021 at 10:20:44AM -0700, Andi Kleen wrote: > > > I see. Hmm. It's a bit of a random thing to do it at the map time > > though. E.g. DMA is all handled transparently behind the DMA API. > > Hardening is much more than just replacing map with map_shared > > and I suspect what you will end up with is basically > > vendors replacing map with map shared to make things work > > for their users and washing their hands. > > That concept exists too. There is a separate allow list for the drivers. So > just adding shared to a driver is not enough, until it's also added to the > allowlist > > Users can of course chose to disable the allowlist, but they need to > understand the security implications. Right. So given that, why do we need to tweak a random API like the map? If you just make all maps be shared then the user is in control. Seems sensible to me. > > > > > I would say an explicit flag in the driver that says "hardened" > > and refusing to init a non hardened one would be better. > > > We have that too (that's the device filtering) > > But the problem is that device filtering just stops the probe functions, not > the initcalls, and lot of legacy drivers do MMIO interactions before going > into probe. In some cases it's unavoidable because of the device doesn't > have a separate enumeration mechanism it needs some kind of probing to even > check for its existence And since we don't want to change all of them it's > far safer to make the ioremap opt-in. > > > -Andi Let's be frank, even without encryption disabling most drivers - especially weird ones that poke at hardware before probe - is far safer than keeping them, but one loses a bunch of features. IOW all this hardening is nice but which security/feature tradeoff to take it a policy decision, not something kernel should do imho. -- MST
