web.archive.org

Loadable kernel module

In computing, a loadable kernel module (or LKM) is an object file that contains 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 loadable module (kld) in FreeBSD and kernel extension (kext) in Mac OS X. They are also known as Kernel Loadable Modules (or KLM), and simply as Kernel Modules (KMOD). LKMs 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.

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 operating systems supporting loadable kernel modules will include modules to support most desired functionality.

Linux

Loadable kernel modules in Linux are loaded by the modprobe command. They are located in /lib/modules and they have had the extension ".ko" since version 2.6.

License issues

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 GNU General Public License (GPL) modules.

Tainting

Loading a proprietary or non-GPL-compatible LKM will 'taint' the running kernel—meaning that any problems or bugs experienced will be less likely to be investigated by the maintainers. LKMs effectively become part of the running kernel, so can corrupt kernel data structures and produce bugs that may not be able to be investigated if the module is indeed proprietary.

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("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.[1]

Mac OS X

Some loadable kernel modules in Mac OS X can be loaded automatically; they can also be loaded by the kextload command. The modules supplied with the operating system are located in application bundles under /System/Library/Extensions.

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.[citation needed]

Binary compatibility

Linux does not provide a stable API or ABI for kernel modules. This means that there are differences in internal structure and function between different kernel versions, which can cause compatibility problems. In an attempt to combat those problems, symbol versioning data is placed within the .modinfo section of loadable ELF modules. This versioning information can be compared with that of the running kernel before loading a module; if the versions are incompatible, the module will not be loaded.

Other operating systems, such as Solaris, FreeBSD, Mac OS X, and Windows keep the kernel API and ABI relatively stable, thus avoiding this problem. For example, FreeBSD kernel modules compiled against kernel version 6.0 will work without recompilation on any other FreeBSD 6.x version, e.g. 6.4. However, they are not compatible with other major versions and must be recompiled for use with FreeBSD 7.x, as API and ABI compatibility is maintained only within a branch.

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 LKMs in this way. Note that modules do not help in any way in privilege elevation, as root access is required to load a LKM; they merely make it easier for the attacker to hide the break-in.[citation needed]

See also

References

External links

v · d · eOperating system
General
Kernel

Architectures

General

Subtypes

Components

User/Kernel space · Server · Loadable kernel module · Device driver
Process management

Concepts
Memory management
Examples

AmigaOS · BeOS · BSD · DOS · GNU · Linux · Mac OS · MorphOS · OS/2 · ReactOS · Solaris · Unix · Windows · more...
Miscellaneous concepts
v · d · eLinux operating system
Linux Tux, the Linux mascot
Distribution
GNU
Window manager

X Window Manager · AfterStep · Blackbox · CTWM · Enlightenment · FVWM · Hackedbox · IceWM · Metisse · OLVWM · PLWM · PWM · Sawfish · vtwm · wm2 · wmx · Xmonad
User interface

CLI · GUI · GNOME · KDE · Xfce · LXDE
Applications

Desktop · Devices · Embedded · Gaming · LAMP · Thin client
People
Media
Lists
System arrangement
and features

Startup process · Console · Framebuffer · Kernel modules
Mobile
Other topics

This entry is from Wikipedia, the leading user-contributed encyclopedia. It may not have been reviewed by professional editors (see full disclaimer)