Linux - Modules

The word "Module" can mean different things in Linux.

Loadable Kernel Modules (LKM)

Previously, if you want a feature that is not included in the default kernel, or if you need to support a special hardware, you need to recompile the Linux kernel; now, you can use Loadable Kernel Modules (LKM) instead.

A kernel module is a piece of compiled binary code that is inserted directly into the Linux kernel, running at ring 0, the lowest and least protected ring of execution in the x86–64 processor.

list installed modules: lsmod, or check /proc/modules;
load modules on the fly (often used for devices, file systems, system calls, etc.)
- insmod, simply tries to load a module.
- modprobe, tries to determine if the module it is loading needs other modules and picks them up from a known location.
remove modules: rmmod
check dependencies depmod
check info modinfo
kernel module suffix: .ko (Kernel Object).
location: /lib/modules or /usr/lib/modules/.
use modinfo XXX to list the attributes of a Kernel module.
examples: firmware and device drivers.

Linux differ from macOS and Windows: it includes drivers at the kernel level.

Commands:

Install: $ insmod <module> (does not resolve dependencies) or $ modprobe <module> (more powerful than insmod)
Remove: $ rmmod <module>
List: $ lsmod (prints a the formatted contents of the /proc/modules)
Rebuild module dependancy database using /lib/modules/$(uname -r)/modules.dep: $ depmod -a
Info: $ modinfo /path/to/module.ko
List all available modules: ls -R /lib/modules/$(uname -r)

Linux Security Modules (LSM)

Linux Security Modules (LSM) are NOT loadable kernel modules. They are selectable at build-time via CONFIG_DEFAULT_SECURITY and can be overridden at boot-time.

Examples: SELinux (Redhat), AppArmor (Ubuntu).

LSM vs. LKM

Compile-time Requirement: Unlike LKMs, standard LSMs (like SELinux, AppArmor, or Smack) must be compiled directly into the kernel. You cannot simply download a .ko file for SELinux and load it into a running kernel that wasn't built with it.
Loading Mechanism: While LKMs are loaded at runtime using insmod, LSMs are initialized during the boot process. You can choose which built-in LSM to use via kernel boot parameters (e.g., lsm=selinux), but you cannot "hot-swap" them while the system is fully running.
Registration: The LSM framework uses a specific set of hooks deeply integrated into the kernel's path for system calls (like opening a file or creating a process). Because these hooks are critical for security, the kernel does not allow them to be modified or "unplugged" easily by a standard LKM to prevent attackers from disabling security at runtime.

The eBPF Exception: BPF-LSM

There is one modern exception: BPF-LSM. This is a special LSM that allows you to load security policies using eBPF programs at runtime. While the BPF-LSM framework itself must still be compiled into the kernel, the actual security logic can be loaded dynamically, giving you LKM-like flexibility with the safety of eBPF.

Linux Pluggable Authentication Modules (PAM)

pam - Pluggable Authentication Modules for Linux.

PAM configuration files are stored in /etc/pam.

Is every driver a loadable kernel module?

The short answer is no. In Linux, drivers can exist in two different states: Built-in or Loadable.

While most drivers you interact with (like for a USB webcam or a WiFi dongle) are indeed Loadable Kernel Modules (LKMs), many critical drivers are compiled directly into the kernel itself.

1. Built-in Drivers (Static)

These drivers are part of the main kernel binary file (usually found in /boot/vmlinuz). They are loaded into memory the moment the kernel starts.

Why build them in? Some drivers are required to boot the system. For example, the driver for your Hard Drive controller or your Root Filesystem (Ext4/XFS) must be built-in. If they were modules stored on the hard drive, the kernel wouldn't be able to read the hard drive to find the module—a "chicken and egg" problem.
Can you remove them? No. Built-in drivers stay in memory as long as the kernel is running.
How are they chosen? When a kernel is compiled, the developer marks them as y (Yes) in the configuration file (.config).

2. Loadable Kernel Modules (Dynamic)

These are the .ko (kernel object) files located in /lib/modules/$(uname -r)/.

Why use modules?
- Memory Efficiency: You don't want to waste RAM loading drivers for 5,000 different printers if you don't own a printer. Modules are only loaded when the hardware is actually detected.
- Development: Developers can unload a module, recompile it, and reload it without rebooting the whole computer.
- Licensing: Some companies provide "Binary Blobs" (closed-source drivers) that cannot be legally built into the open-source Linux kernel but can be distributed as separate modules.
How are they chosen? They are marked as m (Module) in the kernel configuration.

3. Not all Modules are Drivers

It is important to note that the relationship goes both ways:

A driver is a type of module (usually).
But not every module is a driver.

Modules can also be:

Filesystems: (e.g., a module to read NTFS or FAT32).
Network Protocols: (e.g., a module for a specific type of VPN or Tunneling).
Security Features: (e.g., AppArmor or SELinux modules).
Cryptography: (e.g., a module that provides AES encryption).

4. How to see the difference on your system

To see Loadable Modules currently running:

Use the lsmod command. These are the drivers that were loaded dynamically.

lsmod

To see ALL drivers (Built-in + Loaded):

Look at the sysfs directory. This lists every driver the kernel currently knows about, regardless of how it got there.

ls /sys/bus/*/drivers

To see the "Wishlist" (The kernel config):

If you want to see what your Linux distribution decided to build in vs. make a module, look at your config file:

cat /boot/config-$(uname -r) | grep CONFIG_EXT4

If you see =y, it is Built-in.
If you see =m, it is a Module.