Chapter 3. Managing kernel modules

Procedure

1. Select a kernel module you want to load.

   The modules are located in the /lib/modules/$(uname -r)/kernel/<SUBSYSTEM>/ directory.

2. Load the relevant kernel module:

   # modprobe <MODULE_NAME>

   Note

   When entering the name of a kernel module, do not append the .ko.xz extension to the end of the name. Kernel module names do not have extensions; their corresponding files do.

3. Optionally, verify the relevant module was loaded:

   $ lsmod | grep <MODULE_NAME>

   If the module was loaded correctly, this command displays the relevant kernel module. For example:

   $ lsmod | grep serio_raw
   serio_raw              16384  0

Procedure

1. Execute the lsmod command and select a kernel module you want to unload.

   If a kernel module has dependencies, unload those prior to unloading the kernel module. For details on identifying modules with dependencies, see Listing currently loaded kernel modules and Kernel module dependencies.

2. Unload the relevant kernel module:

   # modprobe -r <MODULE_NAME>

   When entering the name of a kernel module, do not append the .ko.xz extension to the end of the name. Kernel module names do not have extensions; their corresponding files do.

   Warning

   Do not unload kernel modules when they are used by the running system. Doing so can lead to an unstable or non-operational system.

3. Optionally, verify the relevant module was unloaded:

   $ lsmod | grep <MODULE_NAME>

   If the module was unloaded successfully, this command does not display any output.

Procedure

1. Select a kernel module you want to load during the boot process.

   The modules are located in the /lib/modules/$(uname -r)/kernel/<SUBSYSTEM>/ directory.

2. Create a configuration file for the module:

   # echo <MODULE_NAME> > /etc/modules-load.d/<MODULE_NAME>.conf

   Note

   When entering the name of a kernel module, do not append the .ko.xz extension to the end of the name. Kernel module names do not have extensions; their corresponding files do.

3. Optionally, after reboot, verify the relevant module was loaded:

   $ lsmod | grep <MODULE_NAME>

   The example command above should succeed and display the relevant kernel module.

Procedure

1. Select a kernel module that you want to put in a denylist:

   $ lsmod
   
   Module                  Size  Used by
   fuse                  126976  3
   xt_CHECKSUM            16384  1
   ipt_MASQUERADE         16384  1
   uinput                 20480  1
   xt_conntrack           16384  1
   …​

   The lsmod command displays a list of modules loaded to the currently running kernel.

   • Alternatively, identify an unloaded kernel module you want to prevent from potentially loading.

     All kernel modules are located in the /lib/modules/<KERNEL_VERSION>/kernel/<SUBSYSTEM>/ directory.

2. Create a configuration file for a denylist:

   # vim /etc/modprobe.d/blacklist.conf
   
   	# Blacklists <KERNEL_MODULE_1>
   	blacklist <MODULE_NAME_1>
   	install <MODULE_NAME_1> /bin/false
   
   	# Blacklists <KERNEL_MODULE_2>
   	blacklist <MODULE_NAME_2>
   	install <MODULE_NAME_2> /bin/false
   
   	# Blacklists <KERNEL_MODULE_n>
   	blacklist <MODULE_NAME_n>
   	install <MODULE_NAME_n> /bin/false
   	…​

   The example shows the contents of the blacklist.conf file, edited by the vim editor. The blacklist line ensures that the relevant kernel module will not be automatically loaded during the boot process. The blacklist command, however, does not prevent the module from being loaded as a dependency for another kernel module that is not in a denylist. Therefore the install line causes the /bin/false to run instead of installing a module.

   The lines starting with a hash sign are comments to make the file more readable.

   Note

   When entering the name of a kernel module, do not append the .ko.xz extension to the end of the name. Kernel module names do not have extensions; their corresponding files do.

3. Create a backup copy of the current initial ramdisk image before rebuilding:

   # cp /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).bak.$(date +%m-%d-%H%M%S).img

   The command above creates a backup initramfs image in case the new version has an unexpected problem.

   • Alternatively, create a backup copy of other initial ramdisk image which corresponds to the kernel version for which you want to put kernel modules in a denylist:

     # cp /boot/initramfs-<SOME_VERSION>.img /boot/initramfs-<SOME_VERSION>.img.bak.$(date +%m-%d-%H%M%S)

4. Generate a new initial ramdisk image to reflect the changes:

   # dracut -f -v

   • If you are building an initial ramdisk image for a different kernel version than you are currently booted into, specify both target initramfs and kernel version:

     # dracut -f -v /boot/initramfs-<TARGET_VERSION>.img <CORRESPONDING_TARGET_KERNEL_VERSION>

5. Reboot the system:

   $ reboot

Procedure

1. Create the /root/testmodule/test.c file with the following content:

   #include <linux/module.h>
   
   #include <linux/kernel.h>
   
   int init_module(void)
       { printk("Hello World\n This is a test\n"); return 0; }
   
   void cleanup_module(void)
       { printk("Good Bye World"); }

   The test.c file is a source file that provides the main functionality to the kernel module. The file has been created in a dedicated /root/testmodule/ directory for organizational purposes. After the module compilation, the /root/testmodule/ directory will contain multiple files.

   The test.c file includes from the system libraries:

   • The linux/kernel.h header file is necessary for the printk() function in the example code.

   • The linux/module.h file contains function declarations and macro definitions to be shared between several source files written in C programming language.

     Next follow the init_module() and cleanup_module() functions to start and end the kernel logging function printk(), which prints text.

2. Create the /root/testmodule/Makefile file with the following content:

   obj-m := test.o

   The Makefile contains instructions that the compiler has to produce an object file specifically named test.o. The obj-m directive specifies that the resulting test.ko file is going to be compiled as a loadable kernel module. Alternatively, the obj-y directive would instruct to build test.ko as a built-in kernel module.

3. Compile the kernel module:

Verification

1. Optional: check the contents of the /root/testmodule/ directory:

   ls -l /root/testmodule/
   total 452
   -rw-r—​r--. 1 root root     16 Jul 12 10:16 Makefile
   -rw-r—​r--. 1 root root     32 Jul 12 10:16 modules.order
   -rw-r—​r--. 1 root root      0 Jul 12 10:16 Module.symvers
   -rw-r—​r--. 1 root root    197 Jul 12 10:15 test.c
   -rw-r—​r--. 1 root root 219736 Jul 12 10:16 test.ko
   -rw-r—​r--. 1 root root    826 Jul 12 10:16 test.mod.c
   -rw-r—​r--. 1 root root 113760 Jul 12 10:16 test.mod.o
   -rw-r—​r--. 1 root root 107424 Jul 12 10:16 test.o

2. Copy the kernel module to the /lib/modules/$(uname -r)/ directory:

   # cp /root/testmodule/test.ko /lib/modules/$(uname -r)/

3. Update the modular dependency list:

   # depmod -a

4. Load the kernel module:

1. Verify that the kernel module was successfully loaded:

   # lsmod | grep test
   test                   16384  0

2. Read the latest messages from the kernel ring buffer:

   # dmesg
   …​
   [74422.545004] Hello World
                   This is a test