Loadable Kernel Module
From Wikipedia, the free encyclopedia
 |
This article or section may require cleanup to meet Wikipedia's quality standards. Please help improve this article or replace this tag with a more specific message. This article has been tagged since June 2006. (help, talk) |
Loadable Kernel Modules, or LKM, are object files that contain code to extend the running kernel, or so-called base kernel. Operating systems other than Linux, such as BSD systems, provide support for LKM's. However, the Linux kernel generally makes far greater and more versatile use of LKM's than other systems. LKM's 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 memory.
Contents |
[edit] 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, such as the case with Microsoft Windows.
[edit] Location
There are no technical restrictions on where LKM are placed on the filesystem 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.
[edit] 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.
[edit] 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's 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 an open-source license.
[edit] 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.
[edit] Criticism
[edit] 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.
[edit] 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.
[edit] Security
While 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.
Many rootkits make use of LKM's in this way. [citation needed]
However, even without module support enabled in the kernel, it is still potentially possible to load a malicious module via the use of kinsmod.
