The Design and Implementation of the Anykernel and Rump Kernels

128
Host Dynamic Linker
Using the host’s dynamic linker requires that the component is in a format that
the dynamic linker can understand. In practice, this requirement means that the
component needs to be a shared library (ELF type ET_DYN). All loading and linking
is done by the host, but the init routine must be run by the rump kernel. Revisiting
Table 3.3, a module loaded and linked by the host is a builtin module from the
perspective of the kernel.
Since there is no system call for informing the kernel about new builtin modules
appearing at runtime, we defined a rump kernel interface for running the init routine.
The rump_pub_module_init() routine takes as an argument the pointer to the
beginning of the modules section and the number of struct modinfo pointers. An
example of client side code (adapted from lib/libukfs/ukfs.c) is presented in
Figure 3.16.
In the monolithic kernel builtin modules cannot be unloaded because they are loaded
as part of the kernel at system bootstrap time, and are not placed in separately allocated
memory. However, if builtin modules are loaded into a rump kernel with
dlopen(), it is possible to unload modules which are not busy via dlclose(). First,
the module’s fini routine should be run so that other kernel subsystems are no longer
aware of it. For running the fini routine to be possible, we added the concept of disabling
a builtin module to NetBSD’s kernel module support. What disabling does is
run the fini routine of the module thereby removing the functionality from the kernel.
This concept is useful also outside the scope of rump kernels, and can for example
be used to disable a driver with a newly discovered security vulnerability, perhaps
making it possible to postpone the system upgrade until a suitable time. A rump
kernel client can disable a builtin module by calling rump_pub_module_fini(). If
disabling is successful, it can proceed to call dlclose() to unload the module from
memory.