Kernel Modules

A loadable kernel module is privileged code that can extend the running kernel with a driver, filesystem, network feature, or other subsystem. Modules avoid building every optional feature into one kernel image, but loading one expands the trusted kernel attack surface.

Listing and Inspecting Modules

List modules currently loaded:

$ lsmod

The output is derived from kernel state such as /proc/modules and includes module name, size, and a use count or dependencies. A zero-looking count is not complete proof that removal is safe; a driver can still own active devices or participate in subsystem state.

Inspect a module available for the running kernel with:

$ modinfo MODULE_NAME

modinfo can show filename, aliases, parameters, license, description, and signature information. Treat metadata as descriptive, not proof that the module is trustworthy or compatible with the workload.

Loading with modprobe

Load a module by name:

$ sudo modprobe MODULE_NAME

modprobe consults dependency indexes, aliases, and configuration for the running kernel under /lib/modules/$(uname -r)/. It loads required dependencies and passes configured parameters. insmod instead inserts one specified module file directly and does not provide the same dependency-resolution workflow.

Before loading, confirm module provenance, signature policy, kernel release compatibility, parameters, expected hardware binding, and rollback. Secure Boot or kernel lockdown can reject unsigned modules; forcing incompatible code risks a crash or compromise.

Module Parameters and Boot-Time Loading

Persistent parameter and alias policy belongs in a .conf file under /etc/modprobe.d/:

options example_module mode=careful

This line affects how modprobe loads the module; it does not by itself request that the module load at boot. A simple boot-time load list commonly belongs under /etc/modules-load.d/:

example_module

Hardware aliases often trigger automatic loading without an explicit list. For modules needed inside early boot, update the initramfs through the distribution's documented process after configuration changes.

Blacklisting and Its Limits

A modprobe configuration can contain:

blacklist example_module

Blacklisting normally suppresses automatic loading through the module's aliases. It does not unload an already loaded module, remove it from an initramfs, or necessarily prevent an explicit load by exact name or loading as a dependency. Security hardening requires a threat-specific combination of module availability, signature enforcement, initramfs content, boot parameters, and policy.

Removing a Module Safely

Request removal with:

$ sudo modprobe -r MODULE_NAME

Modprobe can remove now-unused dependencies as appropriate. The kernel refuses removal when ordinary reference tracking shows the module is busy, but do not rely on that as the only safety check. Stop services, unmount filesystems, detach devices, quiesce networking, and confirm another driver or recovery path before removing code that supports active hardware.

Never force-unload a module on a system you need to preserve. Removal bugs or outstanding activity can crash the kernel or corrupt data.

Use Manage Kernel Modules in Linux to practice with modules designated safe by the lab.

Summary

You can now manage modules while respecting their kernel-level risk.

1. Use lsmod for live state and modinfo for available metadata.
2. Use modprobe for alias and dependency-aware loading.
3. Separate modprobe parameters from boot-time load requests.
4. Treat blacklisting as limited policy rather than an absolute block.
5. Quiesce every consumer before modprobe -r.