All this makes sense but ioremap is such a random place to declare driver has been audited, and it's baked into the binary with no way for userspace to set policy. Again all we will end up with is gradual replacement of all ioremap calls with ioremap_shared as people discover a given driver does not work in a VM.
No the device filter will prevent that. They would need to submit patches to the central list.
Or they can override it at the command line, but there is already an option to force all ioremaps to be shared. So if you just want some driver to run without caring about security you can already do that without modifying it.
Besides the shared concept only makes sense for virtual devices, so if you don't have a device model for a device this will never happen either.
So I don't think your scenario of all ioremaps becoming shared will ever happen.
How are you going to know driver has actually been audited? what the quality of the audit was? did the people doing the auditing understand what they are auditing for? No way, right?
First the primary purpose of the ioremap policy is to avoid messing with all the legacy drivers (which is 99+% of the code base)
How to handle someone maliciously submitting a driver to the kernel is a completely different problem. To some degree there is trust of course. If someone says they audited and a maintainer trusts them with their statement, but they actually didn't there is a problem, but it's larger than just TDX. But in such a case the community code audit will also focus on such areas, and people interested in confidential computing security will also start taking a look.
And we're also working on fuzzing, so these drivers will be fuzzed at some point, so mistakes will be eventually found.
But in any case the ioremap policy is mainly to prevent having to handle this for all legacy drivers.
I would rather change the few drivers that are actually needed, than all the other drivers.
That's really the fundamental problem this is addressing: how to get reasonable security with all the legacy drivers out of the box without touching them.
-Andi _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
