On 9/30/2021 10:23 AM, Greg Kroah-Hartman wrote:
On Thu, Sep 30, 2021 at 10:17:09AM -0700, Andi Kleen wrote:
The "it" that I referred to is the claim that no driver should be
touching hardware in their module init call. Andi seems to think
such drivers are worth working around with a special remap API.
Andi is wrong.
While overall it's a small percentage of the total, there are still quite a
few drivers that do touch hardware in init functions. Sometimes for good
reasons -- they need to do some extra probing to discover something that is
not enumerated -- sometimes just because it's very old legacy code that
predates the modern driver model.
Are any of them in the kernel today?
PCI drivers should not be messing with this, we have had well over a
decade to fix that up.
It's not just PCI driver, it's every driver that can do io port / MMIO /
MSR / config space accesses.
Maybe read the excellent article from Jon on this:
https://lwn.net/Articles/865918/
The legacy drivers could be fixed, but nobody really wants to touch them
anymore and they're impossible to test.
Pointers to them?
For example if you look over old SCSI drivers in drivers/scsi/*.c there
is a substantial number that has a module init longer than just
registering a driver. As a single example look at drivers/scsi/BusLogic.c
There were also quite a few platform drivers like this.
The drivers that probe something that is not enumerated in a standard way
have no choice, it cannot be implemented in a different way.
PCI devices are not enumerated in a standard way???
The pci devices are enumerated in a standard way, but typically the
driver also needs something else outside PCI that needs some other
probing mechanism.
So instead we're using a "firewall" the prevents these drivers from doing
bad things by not allowing ioremap access unless opted in, and also do some
filtering on the IO ports The device filter is still the primary mechanism,
the ioremap filtering is just belts and suspenders for those odd cases.
That's horrible, don't try to protect the kernel from itself. Just fix
the drivers.
I thought we had already established this last time we discussed it.
That's completely impractical. We cannot harden thousands of drivers,
especially since it would be all wasted work since nobody will ever need
them in virtual guests. Even if we could harden them how would such a
work be maintained long term? Using a firewall and filtering mechanism
is much saner for everyone.
-Andi
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
