On Thu, Sep 30, 2021 at 10:48:54AM -0400, Michael S. Tsirkin wrote: > On Thu, Sep 30, 2021 at 10:43:05AM -0400, Alan Stern wrote: > > I don't see any point in talking about "untrusted drivers". If a > > driver isn't trusted then it doesn't belong in your kernel. Period. > > When you load a driver into your kernel, you are implicitly trusting > > it (aside from limitations imposed by security modules). The code > > it contains, the module_init code in particular, runs with full > > superuser permissions. > > > > What use is there in loading a driver but telling the kernel "I don't > > trust this driver, so don't allow it to probe any devices"? Why not > > just blacklist it so that it never gets modprobed in the first place? > > > > Alan Stern > > When the driver is built-in, it seems useful to be able to block it > without rebuilding the kernel. This is just flipping it around > and using an allow-list for cases where you want to severly > limit the available functionality.
Does this make sense? The only way to tell the kernel to block a built-in driver is by using some boot-command-line option. Otherwise the driver's init code will run before you have a chance to tell the kernel anything at all. So if you change your mind about whether a driver should be blocked, all you have to do is remove the blocking option from the command line and reboot. No kernel rebuild is necessary. Alan Stern _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
