Editing Loadable kernel module (section)

== 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.