Module (Linux)
|
|
Linux Loadable Kernel Modules, or LKM, are object files that contain code to extend the running kernel, or so-called base kernel. They are typically used to add support for new hardware, filesystems or for adding system calls. When the functionality provided by a LKM is no longer required, it can be unloaded, freeing memory.
| Contents |
Description
Without Linux Loadable Kernel Modules, Linux distributions would have to build kernels with all possible anticipated functionality already compiled directly into the kernel image. Besides having larger kernels, this has the disadvantage of requiring users to rebuild and reboot the kernel every time new functionality is desired.
Location
There are no technical restrictions on where LKM are placed on the fileystem hierarchy, however, by convention they are usually installed into /lib/modules, which is divided into subdirectories of kernel version, and module category.
The Filesystem Hierarchy Standard dictates where Loadable Kernel Modules should be located. See /lib section of FHS 2.3 (http://www.pathname.com/fhs/pub/fhs-2.3.html#LIBESSENTIALSHAREDLIBRARIESANDKERN)
License
In the opinion of the Kernel maintainers, LKM are derived works of the kernel. The kernel maintainers tolerate the distribution of proprietary modules but allow symbols to be marked as only available to GPL modules.
Tainting
Loading a proprietary LKM will taint the running kernel, meaning that any problems or bugs experienced will likely not be investigated by Kernel maintainers. This is because LKM become part of the running kernel, they have the ability to corrupt kernel data structures or introduce some other bug that cannot be investigated due to the proprietary nature of the module.
The solution is simple, reproduce the problem with an untainted kernel or encourage the vendor to release the module with a GPL-compatible license.
Controversy
In 2001 Linuxant, a consulting company that releases proprietary device drivers as Loadable Kernel Modules attempted to bypass GPLONLY symbol restrictions by abusing a NULL terminator in their MODULE_LICENSE.
MODULE_LICENSE("GPL\0for files in the \"GPL\" directory; for others, only LICENSE file applies");
The string comparison code used by the kernel at the time to determine whether the module was GPLed stopped when it reached a null character (\0), so it would be fooled into thinking that the module was declaring its licence to be just "GPL". The \GPL\ directory referred to in the rest of the licence string was empty.
- Further Discussion Here (http://kerneltrap.org/node/2991)
Criticism
Symbol versioning
Because of the intimate relationship between Loadable Kernel Modules and the base kernel, relatively minor differences in internal structures or methods can result in problems. To mitigate this problem, symbol versioning is used and placed in the .modinfo section of ELF modules.
The versioning information can be compared to the running kernel and if incompatible, will not be loaded.
Fragmentation penalty
One minor criticism of preferring a modular kernel over a static kernel is the so-called Fragmentation Penalty.
The base kernel is always unpacked into real contiguous memory by its setup routines, so the base kernel code is never fragmented.
Once the system is in a state where modules may be inserted (for example, once the filesystems have been mounted that contain the modules) it is probable that any new kernel code insertion will cause the kernel to become fragmented, introducing a minor performance penalty.
Security
Loadable Kernel Modules are a convenient method of modifying the running kernel, this can be abused by an attacker on a compromised system to prevent detection of his processes or files, allowing him to maintain control over the system.
This method of maintaining a compromised host is known as installing a rootkit.