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 an LKM is no longer required, it can be unloaded, freeing computer storage.
=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 Kernel (computer science)s, this has the disadvantage of requiring users to rebuild and reboot the Linux 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 subdirectory of kernel version, and module category.
The Filesystem Hierarchy Standard dictates where Loadable Kernel Modules should be located. [http://www.pathname.com/fhs/pub/fhs-2.3.html#LIBESSENTIALSHAREDLIBRARIESANDKERN See /lib section of FHS 2.3]
=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#Computer_programming in their MODULE_LICENSE .
:MODULE_LICENSE( GPLfor 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 (), 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.
*[http://kerneltrap.org/node/2991 Further Discussion Here]
=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 Executable and Linkable Format 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.
=See also=
*Vmlinux *Linux kernel *Linux *Executable and Linkable Format|
|