Re: [PATCH v4 11/15] pci: Add pci_iomap_shared{,_range}

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [KVM Development]     [Libvirt Development]     [Libvirt Users]     [CentOS Virtualization]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux