在过去的一两年里，我曾多次尝试将 Linux 内核模块列入黑名单（通过 blacklist.conf 或内核命令行参数），但它没有奏效 - 模块无论如何都会加载到内核中。这里似乎提出了一些与尝试将模块列入黑名单时遇到的类似困难相关的问题，例如：
将 modprobe.d 和内核参数中的模块列入黑名单不起作用
通过 /etc/modprobe.d/blacklist.conf 排除内核模块不起作用
那么，为什么 Linux 中的黑名单行为明显如此薄弱呢？
正如 Sourcejedi 在他的文章中提到的回答，模块黑名单不是在内核中实现的，而是在modprobe.事实上，用户空间工具必须使用 选项-b，modprobe否则会让它们加载列入黑名单的模块。
但是，这又回到了我关于弱行为的观点，即用户空间工具必须选择参加尊重黑名单。用户空间工具是否需要覆盖模块黑名单，或者系统管理员为何需要这种行为？在内核中实现黑名单，这样它就不能被用户空间工具简单地覆盖，这不是更有意义吗？这肯定是一个更强有力的政策吗？
或者，为什么不应该modprobe简单地默认遵守黑名单政策呢？为什么甚至可以选择忽略它？
简而言之，这是由于设计不佳，还是有任何原因无法使黑名单行为变得更简单/更强？
答案1
当前实施情况
黑名单不是由内核实现的。它是由 实现的modprobe。
当用户手动请求加载命名模块时，不受黑名单的影响。
黑名单的存在是为了防止模块被 1) udev 自动加载，当它检测到硬件时，2) request_module() 的内核调用按需加载模块，如果 request_module() 调用是为了模块别名喜欢char-major-10-237或net-pf-10-proto-132。
（udev 的用法也是使用别名加载模块的情况。例如，别名scsi:t-0x01*，用于需要st驱动程序模块的 scsi 设备）。
modprobe使用模块名称调用且不传递给 modprobe 的脚本-b不受黑名单的影响。您可以要求对脚本进行相应修改 - 我猜测这就是拥有该选项的原因-b- 或使用其他方法禁用有问题的脚本:-)。
内核中也可能有一些 request_module() 的用途，它们通过名称而不是别名请求模块。 request_module()-b运行时没有通过modprobe。
modprobe当加载内核模块作为另一个模块的要求时，也不会查阅黑名单。当您想要停止自动加载某些驱动程序模块时，这应该不是一个大问题...您可能需要找出 udev 加载的模块，或者确保将一些不同的可能性列入黑名单。
所以你本来问的是内核设计，但你不妨问为什么命令默认情况下modprobe不暗示。-b
设计
为什么甚至可以选择忽略[黑名单]？
显然“如果您不希望自动加载模块，但希望能够在需要时手动加载它”。
我的默认假设是这不是一个设计目标，而且它恰好没有实现它。一旦设计得到广泛应用，某些类型的更改就会有风险或肯定会破坏现有系统。我还要指出，黑名单不是模块加载命令第一个版本的一部分。
另外，请注意，像这样的配置行install bad-module /bin/false可以避免上述所有“弱点”。从技术上讲，这是“不确定的，它旨在取代[安装命令]”，尽管到目前为止它已经“长期存在”并且至少经历了一次重写/重新许可（module-init-tools项目 ->kmod项目） ），但没有人实施替代方案。
我发现了一个用户的例子做想要绕过黑名单。然而，这似乎不是一个很好的例子，因为该线程显示了一个不同的解决方案，这在我看来显然是正确的做法。
在进行实验时，查看是否要使用当前列入黑名单的模块也很方便。尽管想到的最明显的例子是图形驱动程序，您可能想在其中测试完全重新启动，因此最好只编辑黑名单文件。
弱点
上述答案的弱点 -
听起来好像没有日志记录可以显示 request_module() 调用发生的时间。因此，当您想要排除 request_module() 调用作为可能因素时，这里没有太多透明度。
一旦加载了一个模块，就可以很容易地检查
lsmod它是否正在被另一个模块使用。但这无济于事，例如，如果模块有很多错误，以至于在加载时会立即使系统崩溃:-)。而且我不认为有一个预先制定的命令来搜索哪些模块对特定模块 X 有硬性要求。modprobe --show-depends X显示了相反的方向。其他一些未知的复杂性。因为我真的不清楚上述任何一点是否解释了问题中的问题将 modprobe.d 和内核参数中的模块列入黑名单不起作用