On Thu, Sep 30, 2021 at 11:32:41AM -0400, Alan Stern wrote: > 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
Right. -- MST _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
