13

I would like to ask you how can I delete some kernel module completely? I mean really delete, not unload or prevent to load. I tried to use rmmod, but it just unloaded module, same as modprobe -r. So I got list of all modules using modprobe -n -v and deleted them manually.

rmmod cramfs:
ERROR: Module cramfs does not exist in /proc/modules

so when I try to load module, I got:

modprobe -v -n cramfs:
FATAL: Could not open '/lib/modules/2.6.32-573.12.1.el6.x86_64/kerne/fs/cramfs/cramfs.ko': No such file or directory

but that means, system still got some information about removed module because it knows the path to the cramfs.ko file. Example of not loaded, but loadable module:

modprobe -v -n jffs2
insmod /lib/modules/2.6.32-573.12.1.el6.x86_64/kernel/lib/zlib_deflat/zlib_deflate.ko 
insmod /lib/modules/2.6.32-573.12.1.el6.x86_64/kernel/fs/jffs2/jffs2.ko

rmmod jffs2
ERROR: Module jffs2 does not exist in /proc/modules

Is there any way how to delete modules correctly?

Stephen Rauch
  • 3,296
Majzlik
  • 131

3 Answers3

2

It depends on your distro/system.

Linux loadable modules are ko files located in /lib/modules/$(uname -r)/, sorted into sub-folders. A few files in this folder helps handling them all, especially modules.dep[.bin] and modules.order[.bin]. modprobe read those files to get full path of a module and its dependencies.

Usual computer Linux distros

On most Linux distributions, module files are installed by packages of your package manager. A core set of them is installed by a quite generic package named kernel-modules for example, and on some distributions extra less-used modules can be installed by specific packages (modules are split into several packages). You can find which packages provides unwanted modules and uninstall them.

Be warned:

  • Even if you uninstall a specific extra module package, its name and path will still be listed in module.order and modules.dep files. Those files are not a threat and you need them in order to use modprobe. They will be removed only if you uninstall core modules package.
  • Uninstalling modules can break your system, by removing the key features of you kernel. You likely want to execute lsmod to get a minimal list of modules you should not remove.

You may be tempted to edit text files to remove references of unwanted modules, but editing binary files counterparts is likely tedious and those files will be recovered every time their package gets updated.

Embedded systems

Small embedded systems can still rely on loadable modules, but may not provide any package managers. You may need to rebuild your embedded system entirely to alter it since some embedded systems use read-only root file systems.

Rebuild your kernel or your embedded system entirely

Depending on your need, you may want to rebuild your kernel in order to

  • remove support of unwanted features
  • lower the use of loadable modules by building them inside the kernel itself whenever possible
  • enable module signing so your kernel will reject patched or foreign modules
  • and even remove kernel support for loadable modules so loading one will not be possible at all

Doing this requires some skills though.

Other kernel hardening techniques

A few other easy-to-use mechanisms can increase your kernel security against dynamically loaded modules:

  • Writing 1 to sysctl kernel.modules_disabled special file (actually /proc/sys/kernel/modules_disabled) deny any further loadable module loading or unloading, freezing them.
  • Doing the same with kernel.kexec_load_disabled deny anyone from hot-switching to another kernel binary (quite recent kernels feature used to apply kernel upgrades on servers without downtime)
A. Loiseau
  • 1,268
1

Modules are loaded into RAM (and linked to the running kernel) at runtime when required somehow. Until that happens, they (only) use disk space (or it's equivalent).

You can save a bit of disk space by building your own kernel that has the module configured out. The kernel will be a very tiny bit faster using the relevant functionality if you build a kernel that includes (not as modules, builtin) whatever you need. But that is a huge hit in flexibility and hassle.

vonbrand
  • 2,509
1

If a kernel module is not loaded, it's the same as if it doesn't exist, unless it was built into the kernel (I'll explain that below), the only exception is you typically can later reload it with an insmod command.

The reason why you get the path in the error message with modprobe is because modprobe is hardcoded to check standard locations for modules (reference). There's no configuration file or anything telling modprobe to do that. (If your module is not in the standard paths and you want to insert it you can always use insmod).

Modules are loaded by some mechanism outside of the kernel after the kernel starts. systemd can load modules, so can udev. You have to find out what mechanism your system uses and blacklist a module from that.

jffs2 strongly suggests you're doing this on a router or other device like an Android phone. Need more information on the make/model of the device to give you specific advice here.

There's two reasons why you might be getting that error about `/proc/modules:

  1. In your example with modprobe jffs2 and then the error you get with rmmod - it may be the insmod jffs2.ko didn't work but no error message was printed. Check your logs (dmesg, etc.) for errors.

  2. The proc virtual filesystem is not mounted. Things like chroot, SELinux, and kernel capabilities can prevent you from accessing or mounting /proc even as root. Check if you can ls /proc and get something like that looks like a list of directories for each PID on your system. If you are running this in a chroot you have to bind mount /proc into your chroot.

It's possible to build a module into a kernel. This makes it part of the kernel. It's no longer a module at that point so rmmod and other things won't work. I am not sure what will happen if you try to insmod a module that is part of the kernel (it will probably give you a cryptic "file in use" error referring to kernel resources already in use).

It used to be common to build in support for disk controllers and such and some embedded platforms may still do the same for devices needed to access the software.

LawrenceC
  • 75,182