- NetBSD Manual Pages
LKM(4) NetBSD Kernel Interfaces Manual LKM(4)
Powered by man-cgi (2021-06-01).
Maintained for NetBSD
by Kimmo Suominen.
Based on man-cgi by Panagiotis Christias.
lkm -- Loadable Kernel Modules interface
Loadable kernel modules allow the system administrator to dynamically add
and remove functionality from a running system. This ability also helps
software developers to develop new parts of the kernel without constantly
rebooting to test their changes.
Various types of modules can be loaded into the system. There are sev-
eral defined module types, listed below, which can be added to the system
in a predefined way. In addition, there is a generic type, for which the
module itself handles loading and unloading.
The lkm interface is used by performing ioctl(2) calls on the /dev/lkm
device. Normally all operations involving Loadable Kernel Modules are
handled by the modload(8), modunload(8), and modstat(8) programs. Users
should never have to interact with /dev/lkm directly.
System Call modules
System calls may be replaced by loading new ones via the lkm interface.
All system calls may be replaced, but special care should be taken with
the ioctl(2) system call, as it is used to load and unload modules.
When a system call module is unloaded, the system call which was replaced
by the loadable module is returned to its rightful place in the system
call table by LKM code.
Virtual File System modules
Virtual file systems may be added via the lkm interface.
Device Driver modules
New block and character device drivers may be loaded into the system with
options LKM. A problem with loading a device driver is that the driver's
device nodes must exist for the devices to be accessed. They are usually
created by instructing modload(8) to run an appropriate program when the
driver has been successfully loaded.
Emulation modules allow to load an emulation support for foreign operat-
Execution Interpreters allow to load support for execution of new type of
binaries, not normally supported by kernel. This also allows to load
support for executing foreign system binaries. Execution Interpreters
normally depend on Emulation modules, in that appropriate Emulation mod-
ule has to be loaded before Execution Interpreter can be.
Miscellaneous modules are modules for which there are not currently well-
defined or well-used interfaces for extension. They are provided for
extension, and the user is expected to write their own loader to handle
the kernel pointer/table manipulation to "wire in" their loaded module
(and "unwire" it on unload). An example of a "miscellaneous module"
might be a loader for card-specific VGA drivers or alternate terminal
emulations in an appropriately layered console driver.
Loaded kernel modules can do anything with kernel structures. There is
no memory protection between modules and the rest of the kernel. Hence,
a potential attacker controlling /dev/lkm can do anything they want with
To avoid associated security risks, new LKMs cannot be loaded when
securelevel is higher than zero.
Module might crash system
Loading and using a buggy module is likely to crash operating system -
since the module becomes part of kernel, a code error is much more fatal
than for userland programs. If you are doing kernel development, this
would hopefully end up happening less frequently than changing, recompil-
ing, installing, and rebooting would normally occur. This should speed
development considerably for a lot of the in-kernel work that is cur-
rently taking place.
/dev/lkm lkm interface device
/usr/include/sys/lkm.h file containing definitions of module types
lkm/* subdirectory lkm within kernel source tree con-
tains many LKMs which are suitable as a base for
modload(8), modstat(8), modunload(8)
The lkm facility was designed to be similar in functionality to the load-
able kernel modules facility provided by SunOS 4.1.3.
Terrence R. Lambert <email@example.com>
NetBSD 4.0 September 4, 1993 NetBSD 4.0