View source for Loadable kernel module

{{Short description|Dynamically loadable module that extends a running operating system kernel}}
A '''loadable kernel module''' (LKM) is an [[executable]] [[Library (computing)|library]] that [[extensibility|extends]] the capabilities of a running [[kernel (operating system)|kernel]], or so-called ''base kernel'', of an [[operating system]]. LKMs are typically used to add support for new [[computer hardware|hardware]] (as [[device driver]]s) and/or [[filesystem]]s, or for adding [[system call]]s. When the functionality provided by an LKM is no longer required, it can be unloaded in order to free [[computer storage|memory]] and other resources.

Most current [[Unix-like]] systems and [[Microsoft Windows|Windows]] support loadable kernel modules but with different names, such as '''kernel loadable module''' (kld) in [[FreeBSD]], '''kernel extension''' (kext) in [[macOS]] (although support for third-party modules is being dropped<ref>{{cite web |title=Deprecated Kernel Extensions and System Extension Alternatives |url=https://developer.apple.com/support/kernel-extensions/ |publisher=Apple Inc. |access-date=13 March 2021}}</ref>),<ref>{{cite web|url=https://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/KEXTConcept/KEXTConceptIntro/introduction.html|title=Kernel Extension Programming Topics: Introduction|publisher=[[Apple Inc.]]|date=September 1, 2010|access-date=May 5, 2013|url-status=live|archive-url=https://web.archive.org/web/20130504142911/http://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/KEXTConcept/KEXTConceptIntro/introduction.html|archive-date=May 4, 2013}}</ref> '''kernel extension module''' in [[AIX]], '''dynamically loadable kernel module''' in [[HP-UX]],<ref>{{cite web|url=https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-c01943990|title=Managing and Developing DynamicallyLoadable Kernel Modules|publisher=[[Hewlett-Packard]]|date=June 7, 2001}}</ref> '''kernel-mode driver''' in [[Windows NT]]<ref>{{cite web|url=http://msdn.microsoft.com/en-us/library/windows/hardware/ff557272(v=vs.85).aspx|title=What Determines When a Driver Is Loaded|work=[[Microsoft Developer Network]]|publisher=[[Microsoft]]|date=November 21, 2012|access-date=May 5, 2013|url-status=live|archive-url=https://web.archive.org/web/20130306121408/http://msdn.microsoft.com/en-us/library/windows/hardware/ff557272%28v%3Dvs.85%29.aspx|archive-date=March 6, 2013}}</ref>  and '''downloadable kernel module''' (DKM) in [[VxWorks]]. They are also known as '''kernel loadable module''' (KLM), or simply as '''kernel module''' (KMOD).

== Advantages ==
Without loadable kernel modules, an operating system would have to include all possible anticipated functionality compiled directly into the base kernel. Much of that functionality would reside in memory without being used, wasting memory {{Citation needed|reason=The existence of a feature doesn't mandate it being loaded into memory|date=February 2024}}, and would require that users rebuild and reboot the base kernel every time they require new functionality.

== Disadvantages ==
One minor criticism of preferring a modular kernel over a static kernel is the so-called ''[[fragmentation (computing)|fragmentation]] penalty''.  The base kernel is always unpacked into real contiguous [[random-access memory|memory]] by its setup routines; thus, the base kernel code is never fragmented. Once the system is in a state in which modules may be inserted, for example once the [[filesystem]]s have been [[Mount (computing)|mount]]ed that contain the modules, it is likely that any new kernel code insertion will cause the kernel to become fragmented, thereby introducing a minor performance penalty by using more [[translation lookaside buffer|TLB]] entries, causing more TLB misses.{{citation needed|date=September 2007}}

== Implementations in different operating systems ==

=== Linux ===
Loadable kernel modules in Linux are loaded (and unloaded) by the <code>[[modprobe]]</code> command.  They are located in <code>/lib/modules</code> or <code>/usr/lib/modules</code> and have had the extension <code>.ko</code> ("kernel object") since version 2.6 (previous versions used the <code>.o</code> extension).<ref>{{cite web|title=The Linux Kernel Module Programming Guide, section 2.2 "Compiling Kernel Modules"|url=https://tldp.org/LDP/lkmpg/2.6/html/x181.html|access-date=2020-10-05}}</ref> The <code>[[lsmod]]</code> command lists the loaded kernel modules. In emergency cases, when the system fails to boot due to e.g. broken modules, specific modules can be enabled or disabled by modifying the kernel boot parameters list (for example, if using [[GNU GRUB|GRUB]], by pressing 'e' in the GRUB start menu, then editing the kernel parameter line).

==== License issues ====
In the opinion of Linux maintainers, LKM are [[derivative work|derived works]] of the kernel{{citation needed|date=September 2015}}. The Linux maintainers tolerate the distribution of [[Proprietary software|proprietary]] modules (such as [[NVIDIA GPU]] drivers),{{Citation needed|date=April 2012}} but allow only [[GNU General Public License]] (GPL) modules to merge to kernel tree of mainline Linux kernel.

Loading a proprietary or non-GPL-compatible module will set a 'taint' flag<ref>{{cite web |date=2011-06-21 |author=Linus Torvalds |title=Documentation/oops-tracing.txt |publisher=kernel.org |url=http://repo.or.cz/w/linux-2.6.git/blob/HEAD:/Documentation/oops-tracing.txt#l222 |access-date=2011-10-03 |display-authors=etal |url-status=live |archive-url=https://web.archive.org/web/20111002110747/http://repo.or.cz/w/linux-2.6.git/blob/HEAD%3A/Documentation/oops-tracing.txt#l222 |archive-date=2011-10-02 }}</ref><ref>{{cite web|url=https://www.kernel.org/doc/html/latest/admin-guide/tainted-kernels.html|title=Tainted kernels|work=The Linux kernel user’s and administrator’s guide}}</ref> in the running kernel—meaning that any problems or bugs experienced will be less likely to be investigated by the maintainers.<ref>{{cite web |date=2006-03-24 |author=Jonathan Corbet |title=Tainting from user space |publisher=[[LWN.net]] |url=https://lwn.net/Articles/184879/ |access-date=2011-10-03 |url-status=live |archive-url=https://web.archive.org/web/20111116215244/http://lwn.net/Articles/184879/ |archive-date=2011-11-16 }}</ref><ref>{{cite web |date=2007-07-26 |title=Novell support documentation: Tainted kernel |url=http://www.novell.com/support/viewContent.do?externalId=3582750&sliceId=1 |access-date=2011-10-03 }}</ref> 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 2004, Linuxant, a consulting company that releases proprietary [[device driver]]s as loadable kernel modules, attempted to abuse a [[Null character|null terminator]] in their <code>MODULE_LICENSE</code>, as visible in the following code excerpt:

<syntaxhighlight lang="c">
MODULE_LICENSE("GPL\0for files in the \"GPL\" directory; for others, only LICENSE file applies");
</syntaxhighlight>

The string comparison code used by the kernel at the time tried to determine whether the module was GPLed stopped when it reached a null character (<code>\0</code>), so it was fooled into thinking that the module was declaring its license to be just "GPL".<ref>{{cite web|author=Jonathan Corbet|title=Being honest with MODULE_LICENSE|url=https://lwn.net/Articles/82305/|publisher=LWN.net|date=April 27, 2004|access-date=October 30, 2012|url-status=live|archive-url=https://web.archive.org/web/20121102095811/http://lwn.net/Articles/82305/|archive-date=November 2, 2012}}</ref>

=== FreeBSD ===
Kernel modules for [[FreeBSD]] are stored within <code>/boot/kernel/</code> for modules distributed with the [[operating system]], or usually <code>/boot/modules/</code> for modules installed from [[FreeBSD ports]] or [[FreeBSD ports#Packages|FreeBSD packages]], or for proprietary or otherwise binary-only modules.  FreeBSD kernel modules usually have the extension <code>.ko</code>. Once the machine has booted, they may be loaded with the <code>kldload</code> command, unloaded with <code>kldunload</code>, and listed with <code>kldstat</code>. Modules can also be loaded from the loader before the kernel starts, either automatically (through <code>/boot/loader.conf</code>) or by hand.

=== macOS ===
Some loadable kernel modules in macOS can be loaded automatically. Loadable kernel modules can also be loaded by the <code>kextload</code> command. They can be listed by the <code>kextstat</code> command. Loadable kernel modules are located in [[bundle (macOS)|bundles]] with the extension <code>.kext</code>. Modules supplied with the operating system are stored in the <code>/System/Library/Extensions</code> directory; modules supplied by third parties are in various other directories.

=== NetWare ===
A NetWare kernel module is referred to as a [[NetWare Loadable Module]] (NLM). NLMs are inserted into the NetWare kernel by means of the LOAD command, and removed by means of the UNLOAD command; the <code>modules</code> command lists currently loaded kernel modules. NLMs may reside in any valid search path assigned on the NetWare server, and they have <code>.NLM</code> as the file name extension.

=== VxWorks ===
A downloadable kernel module (DKM) type project can be created to generate a ".out" file which can then be loaded to kernel space using "ld" command. This downloadable kernel module can be unloaded using "unld" command.

=== Solaris ===
Solaris has a configurable kernel module load path, which defaults to <code>/platform/platform-name/kernel /kernel /usr/kernel</code>.  Most kernel modules live in subdirectories under <code>/kernel</code>; those not considered necessary to boot the system to the point that init can start are often (but not always) found in <code>/usr/kernel</code>. When running a DEBUG kernel build the system actively attempts to unload modules.

== Binary compatibility ==
Linux does not provide a stable [[API]] or [[Application binary interface|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 <code>.modinfo</code> section of loadable [[Executable and Linkable Format|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 (operating system)|Solaris]], [[FreeBSD]], [[macOS]], and [[Microsoft Windows|Windows]] keep the kernel [[API]] and [[Application binary interface|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 attackers on a compromised system to prevent detection of their [[Process (computing)|processes]] or [[Computer file|file]]s, allowing them to maintain control over the system.  Many [[rootkit]]s make use of LKMs in this way. Note that, on most operating systems, modules do not help [[privilege elevation]] in any way, as elevated privilege is required to load a LKM; they merely make it easier for the attacker to hide the break-in.<ref>[http://www.ouah.org/reiterlkm.htm Exploiting Loadable Kernel Modules ] {{webarchive|url=https://web.archive.org/web/20120204165532/http://www.ouah.org/reiterlkm.htm |date=2012-02-04 }}</ref>

=== Linux ===
Linux allows disabling module loading via [[sysctl]] option <code>/proc/sys/kernel/modules_disabled</code>.<ref>{{cite web|title=Sysctl/kernel.txt|url=https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/sysctl/kernel.txt;hb=HEAD|archive-url=https://archive.today/20130415070311/http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/sysctl/kernel.txt;hb=HEAD|url-status=dead|archive-date=April 15, 2013|access-date=January 4, 2013}}</ref><ref>{{cite web
 | url = https://outflux.net/blog/archives/2012/11/28/clean-module-disabling/
 | title = Clean module disabling
 | date = 2012-11-28
 | access-date = 2020-10-05
 | author = Kees Cook
 | publisher = outflux.net
 }}</ref>  An [[initial ramdisk|initramfs]] system may load specific modules needed for a machine at boot and then disable module loading.  This makes the security very similar to a monolithic kernel.  If an attacker can change the initramfs, they can change the kernel binary.

=== macOS ===
In [[OS X Yosemite]] and later releases, a kernel extension has to be [[Code signing|code-signed]] with a developer certificate that holds a particular "entitlement." Such a developer certificate is only provided by Apple on request and not automatically given to [[Apple Developer]] members. This feature, called "kext signing", is enabled by default and it instructs the kernel to stop booting if unsigned kernel extensions are present.<ref>{{Cite web|url=https://developer.apple.com/library/content/documentation/Security/Conceptual/System_Integrity_Protection_Guide/KernelExtensions/KernelExtensions.html|title=Kernel Extensions|date=September 16, 2015|website=Mac Developer Library|publisher=Apple|archive-url=https://web.archive.org/web/20160817085001/https://developer.apple.com/library/mac/documentation/Security/Conceptual/System_Integrity_Protection_Guide/KernelExtensions/KernelExtensions.html|archive-date=August 17, 2016|url-status=live|access-date=September 29, 2016}}</ref> In [[OS X El Capitan|{{Nowrap|OS X}} El Capitan]] and later releases, it is part of [[System Integrity Protection]].

In older versions of macOS, or if kext signing is disabled, a loadable kernel module in a kernel extension bundle can be loaded by non-root users if the OSBundleAllowUserLoad property is set to True in the bundle's property list.<ref>{{cite web|title=Info.plist Properties for Kernel Extensions|url=https://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/KEXTConcept/Articles/infoplist_keys.html|publisher=[[Apple Inc.]]|access-date=September 27, 2012|url-status=live|archive-url=https://web.archive.org/web/20120926232217/http://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/KEXTConcept/Articles/infoplist_keys.html|archive-date=September 26, 2012}}</ref> However, if any of the files in the bundle, including the executable code file, are not owned by root and group wheel, or are writable by the group or "other", the attempt to load the kernel loadable module will fail.<ref>{{man|8|kextload|Darwin}}</ref>

=== Solaris ===
Kernel modules can optionally have a cryptographic signature ELF section which is verified on load depending on the Verified Boot policy settings. The kernel can enforce that modules are cryptographically signed by a set of trusted certificates; the list of trusted certificates is held outside of the OS in the ILOM on some SPARC based platforms. Userspace initiated kernel module loading is only possible from the Trusted Path when the system is running with the Immutable Global Zone feature enabled.

== See also ==
* {{Annotated link|Dynamic link library}}
* {{Annotated link|NetWare Loadable Module}}
* {{Annotated link|Shared library}}

== References ==
{{Reflist|25em}}

{{Operating System}}
{{Linux kernel}}
{{FreeBSD}}

[[Category:FreeBSD]]
[[Category:Linux kernel]]
[[Category:Operating system kernels]]
[[Category:Device drivers]]