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:
quoted
On Thu, Sep 30, 2021 at 10:43:05AM -0400, Alan Stern wrote:
quoted
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