MODULE(7) | Miscellaneous Information Manual | MODULE(7) |
module
— Kernel
Modules interface
options MODULAR
Kernel modules allow the system administrator to dynamically add and remove functionality from a running system. This also helps software developers add new parts of the kernel without constantly rebooting to test their changes.
The kernel may automatically load software modules as needed to perform requested operations. For example, an “xyzfs” module can be loaded automatically when an attempt is made to mount an “xyzfs” file system. Modules can also depend on other modules, and dependent modules are automatically loaded. When a module is no longer needed, it can be automatically unloaded.
An in-kernel linker resolves symbol references between the module and the rest of the kernel.
The module
interface is accessed with the
modctl(2) system call. All
common operations involving kernel modules are handled by the
modload(8),
modunload(8), and
modstat(8) programs. Users
should never have to interact with
modctl(2) directly.
Virtual file systems may be added via the
module
interface.
Many device drivers can be loaded as a kernel module. One potential problem specific to block and character device drivers is that the device nodes must exist for the devices to be accessed. These need to be created manually, after the driver module has been successfully loaded. Most device driver modules do not need any manual intervention to function properly.
Execution Interpreters can be loaded to provide support for executing binaries not normally supported by the kernel. This also allows loading support for executing foreign system binaries. Execution Interpreters may require that an appropriate emulation module also be loaded.
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-provided module initialization routine is expected to install the necessary "hooks" into the rest of the operating system. 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.
Alternate system security models also may be loaded using
module
.
The common build tool of NetBSD, “build.sh”, automatically compiles and installs most modules during a full system build and install. (The exceptions are some modules from external sources which, due to licensing concerns, can be built only as separately-loaded modules.) However, sometimes it is useful to update only modules. The following example demonstrates one way to do this. It is assumed that the source code is under /usr/src, while the object and toolchain directories are under /usr/obj and /usr/tools, respectively.
cd /usr/src/sys/modules export OBJDIR=/usr/obj export TOOLDIR=/usr/tools make clean make make install
Alternatively, the “build.sh” tool can be used to build and install only the modules:
cd /usr/src ./build.sh -O /usr/obj -T /usr/tools modules ./build.sh -O /usr/obj -T /usr/tools installmodules=/
The module
facility was designed to be
similar in functionality to the loadable kernel modules facility provided by
SunOS 4.1.3. The old LKM
interface was replaced by
module
in NetBSD 5.0.
The module
subsystem was implemented by
Andrew Doran ⟨ad@netbsd.org⟩.
The module
framework is still under active
development. At least two potential caveats can be mentioned.
The absence of required modules or the inability of the bootloader
to load the modules are common reasons for failures to boot a
MODULAR
kernel. It may be a good practice to
maintain a non-MODULAR kernel in the root file system for recovery
purposes.
A module becomes part of the kernel once loaded. Unlike in userland programs, fatal errors in kernel modules may crash the operating system. There is no memory protection between modules and the rest of the kernel. Hence, a potential attacker with access to the modctl(2) system call can acquire total control over the system.
To avoid such security risks, new modules can only be loaded when
securelevel is less than or equal to zero, or if the
kernel was built with options INSECURE
. Refer to
secmodel_securelevel(9)
for additional details on the securelevel. Only use
modules from trusted sources.
July 13, 2020 | NetBSD 10.99 |