UNDERSTANDING THE SUBJECT MATTER
In one of the articles on this site, the Linux kernel was explicitly explained. In this article, I will also talk extensively on the Linux kernel module.
A Linux kernel module is a written code (file), that can be loaded and unloaded from the Linux kernel at run-time as demanded.
With kernel modules, the kernel functionalities can be extended without having to recompile/rebuild and reboot the kernel.
Compare these kernel modules as plugins. If you need particular functionality, you can get the plugin(module) of that particular functionality, and integrate/load it with the main software(kernel).
Remember, you can also unload the plugin when you are done.
For example, a device driver is a type of module. The device driver of specific hardware drives the hardware. A device driver can be loaded into and be unloaded from the kernel.
With a device driver being loaded into the kernel, the kernel can address the hardware of the device driver.
There are a lot of kernel modules, both inbuilt and non-inbuilt.
The good thing and one of the things that makes the Linux OS light and fast is that the modules are loaded automatically as needed with the help of the UDEV process, otherwise the Linux kernel would have been very large.
The command used to verify the loaded modules is “lsmod”.
To understand the Linux kernel module extensively, let’s look at the scenario below.
When you have the hardware (Process 1), the next thing is to install the OS, which of course consists of the Linux Kernel (process 2).
The Linux kernel contains every functionality it needs to address or work with the Hardware. One of the functionality is the UDEV process.
How Does The Udev process work?
When a new hardware device (process 3) is added to the hardware, the UDEV process is automatically initiated, it informs the kernel that a new device has been added to the hardware, hence the kernel (which contains every functionalities to address the hardware) will automatically load the new hardware kernel module that has just been added to the hardware to initialize the hardware.
Prior to the new Linux systems, there is nothing like an automatic initialization of a kernel module for new hardware, the kernel module usually requires human intervention, you will have to load the module manually but with the new design of UDEV in the recent Linux OS, the kernel can now automatically detect new hardware.
Let’s be practical about it.
On my RHEL 8 system, to list all the initialized kernel modules, i.e, the loaded modules, I am going to run the command,
[root@HQEBPRD ~]# lsmod
Module Size Used by
uinput 20480 1
nls_utf8 16384 1
isofs 45056 1
fuse 126976 3
xt_CHECKSUM 16384 1
ipt_MASQUERADE 16384 1
xt_conntrack 16384 1
ipt_REJECT 16384 1
nft_counter 16384 16
nf_nat_tftp 16384 0
nft_objref 16384 1
nf_conntrack_tftp 16384 3 nf_nat_tftp
nf_tables_set 32768 5
nft_fib_inet 16384 1
nft_fib_ipv4 16384 1 nft_fib_inet
nft_fib_ipv6 16384 1 nft_fib_inet
nft_fib 16384 3 nft_fib_ipv6,nft_fib_ipv4,nft_fib_inet
nft_reject_inet 16384 5
nf_reject_ipv4 16384 2 nft_reject_inet,ipt_REJECT
nf_reject_ipv6 16384 1 nft_reject_inet
nft_reject 16384 1 nft_reject_inet
From the above command, you can see all the loaded modules, their sizes and the number of dependencies of the module.
Going forward, a common tool that is used to monitor modules in real-time on the Linux system is “udevadm monitor”.
When you run the command, “udevadm monitor” and afterward insert a USB to your system (process 3), you will begin to see how the UDEV process on the kernel works real-time as it is shown below.
[root@HQEBPRD ~]# udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent
KERNEL[1232.288830] add /devices/pci0000:00/0000:00:11.0/0000:02:03.0/usb1/ 1-1 (usb)
KERNEL[1232.300617] add /devices/pci0000:00/0000:00:11.0/0000:02:03.0/usb1/ 1-1/1-1:1.0 (usb)
KERNEL[1232.300672] bind /devices/pci0000:00/0000:00:11.0/0000:02:03.0/usb1/ 1-1 (usb)
UDEV [1232.340630] add /devices/pci0000:00/0000:00:11.0/0000:02:03.0/usb1/ 1-1 (usb)
KERNEL[1232.437297] add /module/usb_storage (module)
KERNEL[1232.457265] add /devices/pci0000:00/0000:00:11.0/0000:02:03.0/usb1/
KERNEL[1232.457309] add /bus/usb/drivers/usb-storage (drivers)
UDEV [1232.462298] add /bus/usb/drivers/usb-storage (drivers)
KERNEL[1232.487760] add /module/uas (module)
UDEV [1232.487876] add /devices/pci0000:00/0000:00:11.0/0000:02:03.0/usb1/ 1-1/1-1:1.0 (usb)
/devices/pci0000:00/0000:00:11.0/0000:02:03.0/usb1/ 1-1/1-1:1.0/host33/target33:0:0/33:0:0:0 (scsi)
You can see the USB modules being loaded automatically. for verification, you can run the command,
[root@HQEBPRD ~]# lsmod |grep usb_storage
usb_storage 73728 1 uas
[root@rhel ~]#
[root@HQEBPRD ~]# lsmod |grep usb
usb_storage 73728 1 uas
[root@HQEBPRD ~]# lsmod |grep uas
uas 28672 0
usb_storage 73728 1 uas
The three modules are all dependent on each other.
Similarly, if you remove the USB, as far as the udevadm monitor command is still running, you will also see what is happening on the kernel real-time. in my case, you can see the display below.
UDEV [1693.698998] remove /devices/pci0000:00/0000:00:11.0/0000:02:03.0/usb1/
UDEV [1693.701177] remove /devices/pci0000:00/0000:00:11.0/0000:02:03.0/usb1/
UDEV [1693.702884] remove /devices/pci0000:00/0000:00:11.0/0000:02:03.0/usb1/
UDEV [1693.704247] remove /devices/virtual/bdi/8:32 (bdi)
UDEV [1693.706789] remove /devices/pci0000:00/0000:00:11.0/0000:02:03.0/usb1/
UDEV [1693.717765] remove /devices/pci0000:00/0000:00:11.0/0000:02:03.0/usb1/
UDEV [1693.722632] remove /devices/pci0000:00/0000:00:11.0/0000:02:03.0/usb1/
UDEV [1693.727771] unbind /devices/pci0000:00/0000:00:11.0/0000:02:03.0/usb1/
UDEV [1693.736730] remove /devices/pci0000:00/0000:00:11.0/0000:02:03.0/usb1/
UDEV [1693.737691] remove /devices/pci0000:00/0000:00:11.0/0000:02:03.0/usb1/
UDEV [1693.738621] remove /devices/pci0000:00/0000:00:11.0/0000:02:03.0/usb1/
UDEV [1693.739481] remove /devices/pci0000:00/0000:00:11.0/0000:02:03.0/usb1/
UDEV [1693.740626] unbind /devices/pci0000:00/0000:00:11.0/0000:02:03.0/usb
Many times, when a kernel module is automatically loaded, the module remains loaded for a while even if it is not in use until the system sees it deem fit to unload the module, most times, till a reboot is done.
However, you can also manually unload a module if you want to.
To unload a kernel module, use the command,
modprobe -r <kernel-module>
[root@HQEBPRD ~]# lsmod |grep usb_storage
usb_storage 73728 1 uas
[root@HQEBPRD ~]# modprobe -r usb_storage
modprobe: FATAL: Module usb_storage is in use.
[root@HQEBPRD ~]# modprobe -r uas
[root@HQEBPRD ~]# lsmod |grep usb_storage
[root@HQEBPRD ~]#
Of course to load the module again, you use the command,
modprobe <kernel-module>
[root@HQEBPRD ~]# modprobe uas
[root@HQEBPRD ~]# lsmod |grep uas
uas 28672 0
usb_storage 73728 1 uas
To get the kernel module information, use the command,
modinfo <kernel-module>
For example, to get the information of the kernel module, usb_storage, use the command,
[root@HQEBPRD ~]# modinfo usb_storage
filename: /lib/modules/4.18.0-147.el8.x86_64/kernel/drivers/usb/storage/usb-storage.ko.xz
license: GPL
description: USB Mass Storage driver for Linux
author: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
rhelversion: 8.1
srcversion: 2690AE1716B1AFBBCFAF198
alias: usb:v*p*d*dc*dsc*dp*ic08isc06ip50in*
alias: usb:v*p*d*dc*dsc*dp*ic08isc05ip50in*
alias: usb:v*p*d*dc*dsc*dp*ic08isc04ip50in*
alias: usb:v*p*d*dc*dsc*dp*ic08isc03ip50in*
parm: option_zero_cd:ZeroCD mode (1=Force Modem (default), 2=Allow CD-Rom (uint)
parm: swi_tru_install:TRU-Install mode (1=Full Logic (def), 2=Force CD-Rom, 3=Force Modem) (uint)
parm: delay_use:seconds to delay before using a new device (uint)
parm: quirks:supplemental list of device IDs and their quirks (string)
The parameter information of a kernel module is a very important information because the kernel parameters can be changed to suit our needs.
Let’s look at another Linux kernel module information.
[root@HQEBPRD ~]# modinfo kvm
filename: /lib/modules/4.18.0-147.el8.x86_64/kernel/arch/x86/kvm/kvm.ko.xz
license: GPL
author: Qumranet
rhelversion: 8.1
srcversion: 9F2646BC27B5B6B3EE48FE1
depends: irqbypass
intree: Y
name: kvm
vermagic: 4.18.0-147.el8.x86_64 SMP mod_unload modversions
sig_id: PKCS#7
signer: Red Hat Enterprise Linux kernel signing key
sig_key: 5E:6D:86:4E:38:DC:58:DE:BB:FF:68:70:25:85:54:3D:31:43:BC:90
sig_hashalgo: sha256
signature: 70:B3:77:75:0A:A4:6C:F6:52:31:2B:B1:22:BC:39:D7:6B:A7:62:2A:
BC:11:AC:F9:77:DC:13:CD:81:54:5E:3B:02:00:9D:15:3E:B6:46:C9:
parm: ignore_msrs:bool
parm: report_ignored_msrs:bool
parm: min_timer_period_us:uint
parm: kvmclock_periodic_sync:bool
parm: tsc_tolerance_ppm:uint
parm: lapic_timer_advance_ns:uint
parm: vector_hashing:bool
parm: enable_vmware_backdoor:bool
parm: force_emulation_prefix:bool
parm: halt_poll_ns:uint
parm: halt_poll_ns_grow:uint
parm: halt_poll_ns_grow_start:uint
parm: halt_poll_ns_shrink:uint
[root@HQEBPRD ~]#
you can see the parameters with the boolean value, you can decide to change the boolean value parameters or not, the KVM module is for the KVM virtualization,
Let’s look at another Linux kernel module information that we can easily understand.
[root@HQEBPRD ~]# modinfo cdrom
filename: /lib/modules/4.18.0-147.el8.x86_64/kernel/drivers/cdrom/cdrom.ko.xz
license: GPL
rhelversion: 8.1
srcversion: E5A2049F635B552113240F5
depends:
intree: Y
name: cdrom
vermagic: 4.18.0-147.el8.x86_64 SMP mod_unload modversions
sig_id: PKCS#7
signer: Red Hat Enterprise Linux kernel signing key
sig_key: 5E:6D:86:4E:38:DC:58:DE:BB:FF:68:70:25:85:54:3D:31:43:BC:90
sig_hashalgo: sha256
signature: 4D:86:52:DB:20:4F:C5:A8:83:6A:AA:BE:32:96:BE:FB:70:DF:45:CD:
57:26:8E:32:9B:8E:07:04:9B:2F:7E:B7:50:D3:06:BF:0F:CD:0C:40:
parm: debug:bool
parm: autoclose:bool
parm: autoeject:bool
parm: lockdoor:bool
parm: check_media_type:bool
parm: mrw_format_restart:bool
[root@HQEBPRD ~]#
You can see the auto-eject parameter, we have the option to change the boolean value to yes or no, i.e. to allow the cdrom drive to do an auto-eject or not.
let us move forward by knowing how to change a kernel module parameter with a boolean(bool) value.
knowing how to change a kernel module parameter is very important. You may have some issues on your system and the only solution sometimes maybe to tune the kernel by changing the kernel module parameter.
Changing the kernel module parameter with boolean can be done with the command,
modprobe <kernel-module> <parameter>=<boolean-value>
boolean value can be (Yes or 1), which agrees with the parameter OR (No or 0) which disagrees with the kernel parameter.
For example, to change the boolean value of the kernel module parameter, “auto-eject” of the module, “cdrom” as displayed above with the modinfo command, use the command,
[root@HQEBPRD ~]# modprobe cdrom autoeject=1
If the value is set to 1, it simply means that the cdrom drive should agree with autoeject.
However, setting the kernel module parameter this way is not persistent.
To make it persistent, you will need to create a configuration file for the parameter you want to change in any of the modprobe configuration directory, mostly “/etc/modprobe.d”.
The modprobe configuration directory’s are
- /lib/modprobe.d
- /etc/modprobe.d
- /run/modprobe.d
It can be verified by checking the manual page of modprobe.d
[root@HQEBPRD ~]# man 5 modprobe.d
MODPROBE.D(5) modprobe.d MODPROBE.D(5)
NAME
modprobe.d - Configuration directory for modprobe
SYNOPSIS
/lib/modprobe.d/*.conf
/etc/modprobe.d/*.conf
/run/modprobe.d/*.conf
DESCRIPTION
Because the modprobe command can add or remove more than one module, due to modules having
dependencies, we need a method of specifying what options are to be used with those modules. All
files underneath the /etc/modprobe.d directory which end with the .conf extension specify those
options as required. They can also be used to create convenient aliases: alternate names for a
The /lib/modprobe.d dirctory contains the default settings for the kernel modules, as such, is not best practice to modify the kernel module parameter in the directory.
The best practice is to create a configuration file in the /etc/modprobe.d directory.
Please see “ACTION TIME” section on the step by step process of how to change the boolean value of kernel module parameter.
ACTION TIME
How To Change The Boolean Value Of A Kernel Module Parameter With Examples
To change the boolean value of a kernel module parameter, autoeject of the cdrom module, the following steps will be taken.
1. get to see the module information.
[root@HQEBPRD ~]# modinfo cdrom
filename: /lib/modules/4.18.0-147.el8.x86_64/kernel/drivers/cdrom/cdrom.ko.xz
license: GPL
rhelversion: 8.1
srcversion: E5A2049F635B552113240F5
depends:
intree: Y
name: cdrom
vermagic: 4.18.0-147.el8.x86_64 SMP mod_unload modversions
sig_id: PKCS#7
signer: Red Hat Enterprise Linux kernel signing key
sig_key: 5E:6D:86:4E:38:DC:58:DE:BB:FF:68:70:25:85:54:3D:31:43:BC:90
sig_hashalgo: sha256
signature: 4D:86:52:DB:20:4F:C5:A8:83:6A:AA:BE:32:96:BE:FB:70:DF:45:CD:
57:26:8E:32:9B:8E:07:04:9B:2F:7E:B7:50:D3:06:BF:0F:CD:0C:40:
56:FD:07:97:1B:33:E8:55:93:BB:65:89:0A:3F:C4:06:06:AD:1E:FF:
1B:DE:E1:FE:3F:9F:62:AC:C8:28:77:51:36:91:8B:D3:73:80:47:89:
parm: debug:bool
parm: autoclose:bool
parm: autoeject:bool
parm: lockdoor:bool
parm: check_media_type:bool
parm: mrw_format_restart:bool
[root@HQEBPRD ~]#
2. Verify the current boolean value.
[root@HQEBPRD ~]# cat /proc/sys/dev/cdrom/autoeject
0
3. Change the boolean value.
For non-persistence change,
Unload the module
[root@HQEBPRD ~]# modprobe -r cdrom
set the boolean value
[root@HQEBPRD ~]# modprobe cdrom autoeject=1
[root@HQEBPRD ~]#
reboot
[root@HQEBPRD ~]# reboot
For a persistent change,
create a configuration file for the parameter that you want to change
[root@HQEBPRD ~]# vi /etc/modprobe.d/cdrom.conf
options cdrom autoeject=1
reboot
[root@HQEBPRD ~]# reboot
Sometimes, for some modules, it may be difficult to verify that the parameter has changed without rebooting the system but generally, you can find a loaded module parameter information in the directory, “/sys/module/”.
An example is the KVM module.
[root@HQEBPRD ~]# cd /sys/module/kvm/parameters/
[root@HQEBPRD parameters]# ls
enable_vmware_backdoor halt_poll_ns_shrink mmu_audit
force_emulation_prefix ignore_msrs report_ignored_msrs
halt_poll_ns kvmclock_periodic_sync tsc_tolerance_ppm
halt_poll_ns_grow lapic_timer_advance_ns vector_hashing
halt_poll_ns_grow_start min_timer_period_us
[root@HQEBPRD parameters]# cat enable_vmware_backdoor
N
for “enable_vmware_backdoor” parameter, the boolean value is no (N)
However, for the cdrom module, the parameters are not in this directory. It all depends on how the programmer wants it, they can decide to write the program that way or not. so you may find the module parameter in the “/sys/module” directory and you may not.
For the cdrom module, the parameters are in the directory, “/proc/sys/dev”
[root@HQEBPRD]# cd /proc/sys/dev/cdrom/
[root@HQEBPRD cdrom]# ls
autoclose autoeject check_media debug info lock
[root@HQEBPRD cdrom]# cat autoeject
1
Hi Victor
i am trying to ans some of the question but it is asking me foe a password. What do i need to do to have the password?
You need to buy the premium pack.
https://tekneed.com/premium-rhcsa-8-exam-practice-questions-answers/