LOADABLE KERNEL MODULE

In computing, 'loadable kernel modules', or 'LKM', are object files that contain code to extend the running kernel, or so-called ''base kernel'', of an operating system. Most current Unix-like systems, and Microsoft Windows, support loadable kernel modules, although they might use a different name for them, such as "kernel extension" ("kext") in Mac OS X. 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 and/or filesystems, or for adding system calls. When the functionality provided by an LKM is no longer required, it can be unloaded in order to free memory.

Contents

Description

License issues

Linux

Tainting

Linuxant controversy

Binary compatibility

Fragmentation penalty

Security

Description

Without loadable kernel modules, an operating system would have to have all possible anticipated functionality already compiled directly into the base kernel. Much of that functionality would reside in memory without being used, wasting memory, and would require that users rebuild and reboot the base kernel every time new functionality is desired. Most OSes supporting loadable kernel modules will include modules to support most desired functionality.

License issues

Linux

In the opinion of Linux maintainers, LKM are derived works of the kernel. The Linux 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 be less likely to be investigated by the maintainers. This is because, in that LKM's (effectively thus do) become part of the running kernel, they (therefore, and often necessarily) have the ability to corrupt kernel data structures—and/or, to introduce some other bug that cannot be investigated due to the proprietary nature of the module.

Linuxant 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("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.

★ Further discussion here

Binary compatibility

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.
On Linux, in an attempt to mitigate this problem, symbol versioning is used and placed within the .modinfo section of ELF modules. This versioning information can be compared to the running kernel; if incompatible, the module 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, thereby introducing a minor performance penalty.

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.