0

There have been several times in the past year or two where I have tried to blacklist Linux kernel modules (either through blacklist.conf or kernel command line parameters), and yet it hasn't worked - the modules get loaded into the kernel anyway. There seem to have been a few questions asked on here that relate to similar difficulties with trying to blacklist modules, for example:

Blacklisting modules in modprobe.d and kernel params is not working

Excluding kernel modules through /etc/modprobe.d/blacklist.conf does not work

Kernel module blacklist not working

So, why is the blacklisting behavior in Linux apparently so weak?

As sourcejedi mentions in his answer, module blacklisting is not implemented in the kernel, it is implemented in modprobe. In fact, user-space tools have to use the -b option with modprobe, otherwise it will let them load blacklisted modules.

But, this comes back to my point about weak behavior, that user-space tools have to opt-in to respecting the blacklist. Is there any reason why user-space tools would need to override the module blacklist, or why a system admin would desire such behavior? Would it not make more sense to implement blacklisting in the kernel, in such a way that it can't be simply overridden by user-space tools? Surely that would be a stronger policy?

Alternatively, why shouldn't modprobe simply respect the blacklist policy by default? Why even have an option to ignore it?

In short, is this down to poor design, or is there any reason why the blacklisting behavior couldn't be made simpler/stronger?

Time4Tea
  • 2,288
  • 5
  • 23
  • 54
  • I for 1 have never had problems blacklisting modules that needed blacklisting. As long as the blacklisting is done at the proper location and with the proper module name. All 3 links are user errors though. Not running `sudo update-initramfs -u` is a user error. Not using the correct module name is also a user error. Your problem could be fixed with a graphical interface where the user no longer needs to add the module himself BUT that seems counter productive for servers. – Rinzwind Apr 19 '19 at 14:50
  • 2
    @Rinzwind in the first linked question, the user stated that they ran `update-initramfs -u`, but the module was apparently still loaded. That one was never conclusively resolved. I personally have had situations where I have added a blacklist command to the kernel command line (e.g. via the GRUB config), but the module still got loaded. How would that be a user error? – Time4Tea Apr 19 '19 at 14:56
  • It's direct result of being implemented in userspace. Kernel implementation of this functionality doesn't provide much safety at all. You should use force signature of kernel modules – 炸鱼薯条德里克 Apr 20 '19 at 01:59

1 Answers1

1

Current implementation

blacklisting is not implemented by the kernel. It is implemented by modprobe.

When a user manually requests to load a named module, it is not affected by the blacklist.

blacklisting exists to prevent modules being automatically loaded by 1) udev, when it detects hardware, 2) kernel calls of request_module() which load modules on-demand, if the request_module() call is for a module alias like char-major-10-237 or net-pf-10-proto-132.

(udev's usage is also a case of loading modules using their aliases. E.g. the alias scsi:t-0x01*, is used for a scsi device which requires the st driver module).

Scripts which call modprobe with a module name, and do not pass -b to modprobe, are not affected by the blacklist. You may request that the script be amended accordingly - I guess this is the reason for having the -b option - or disable the script in question using some other method :-).

There might also be a few uses of request_module() inside the kernel which request a module by name, not by an alias. request_module() does not pass -b when it runs modprobe.

The blacklist is also not consulted when modprobe loads a kernel module as a requirement of another module. This should not be a big problem when you want to stop certain driver modules being loaded automatically... you might need to find out which is the module loaded by udev, or else make sure to blacklist a few different possibilities.

So you originally asked about the kernel design, but you may as well ask why the modprobe command does not imply -b by default.

Design

Why even have an option to ignore [the blacklist]?

obviously "if you don't want a module to be loaded automatically, but you want to be able to load it manually when desired".

My default assumption is this was not a design goal, and it happens not to fulfil it. And once a design is widespread, some types of changes are risky or guarantee to break existing systems. I would also note that blacklists were not part of the first version of the module-loading command.

Also, notice that a config line like install bad-module /bin/false avoids all of the above "weaknesses". Technically this is "not assured and it is intended to replace [the install command]", although by this point it has been around "for the long term" and survived at least one re-write/re-licensing (module-init-tools project -> kmod project), with no-one having implemented a replacement for it.

I found one example of a user who does wants to bypass a blacklist. However this does not seem a good example, as the thread shows a different solution which seems obviously the right thing to do IMO.

It can also be convenient when experimenting, to see whether you want to use a module which is currently blacklisted. Although the most obvious example that comes to mind is graphics drivers, where you would want to test a full reboot, so it would be best to just edit the blacklist file.

Weak points

Weak points in the above answer -

  1. It sounds like there is no logging to show you when request_module() calls happen. So there is not much transparency here, when you want to rule out request_module() calls as a possible factor.

  2. Once you have a module loaded, it is easy to check in lsmod if it is being used by another module. But this would not help e.g. if the module is so buggy that it crashes the system immediately when it is loaded :-). And I don't think there is a pre-made command, to search for which modules have a hard requirement on a specific module X. modprobe --show-depends X shows the opposite direction.

  3. Some other unknown complexities. Because it is really not clear to me that either of the above points explains the problem in the question Blacklisting modules in modprobe.d and kernel params is not working

sourcejedi
  • 48,311
  • 17
  • 143
  • 296
  • Thanks for the info. However, why couldn't blacklisting be implemented in the kernel? User-space tool/script tries to load blacklisted module --> kernel checks list and says 'no'. Seems like it would be fairly simple and robust. – Time4Tea Apr 19 '19 at 20:03
  • @Time4Tea why is that better than changing `modprobe` to imply `-b` by default ? – sourcejedi Apr 19 '19 at 20:05
  • It's a good point. Perhaps I could edit my question to ask why, with `modprobe`, user-space scripts and tools have to 'opt-in' to respecting the blacklist. Coming back to my original point, it seems like rather weak behavior. – Time4Tea Apr 19 '19 at 20:10
  • Implementing it in the kernel would, in my opinion, be stronger, because it wouldn't give userspace tools the *option* of disrespecting the policy (which I have set, as an admin). – Time4Tea Apr 19 '19 at 20:18
  • @Time4Tea unless the userspace tool modifies the policy :-P. – sourcejedi Apr 19 '19 at 20:20
  • Would that be possible, if the blacklist policy is set on the kernel command line? – Time4Tea Apr 19 '19 at 20:32
  • @Time4Tea it might be possible to write kernel code which does not allow blacklist entries to be removed, but the kernel does not usually get into such fights. Usually it would also allow you to remove such an entry. The exceptions are mostly security features. Or in one case, if Linus was angry enough to swear at you, when you broke his debugging workflow. – sourcejedi Apr 19 '19 at 20:38