This page is about rump kernels in NetBSD and assumes the reader knows the basics of rump kernels. See rumpkernel.org for general information about rump kernels.
File system drivers are vulnerable to consistency errors in file system images, see e.g. here
What this vulnerability means is that whenever an untrusted file system image is mounted using an in-kernel driver, system compromise should be expected. This untrusted images include for example ones on USB sticks. There are heavyweight workarounds for the problem, for example including virtual machines.
NetBSD allows transparently mounting an untrusted file system image by
running the kernel driver in a rump kernel in userspace. The driver
is thus isolated and any damage that a malicious file system image
can directly cause is restricted to a userspace process. From a user
perspective, mounting with the
-o rump option is the only change
/etc/fstab. Notably, even though interacting
with untrusted file systems will suffer from a minor performance penalty,
the performance of mounts from trusted file systems is completely
The problems of automated kernel testing are documented for example in
The Design and Implementation of the Anykernel and Rump Kernels.
Rump kernels are used in the continuous tests run by the NetBSD project.
See http://releng.NetBSD.org/ for the results or the NetBSD source tree
src/tests for the test programs themselves.
On the flipside of testing is kernel development. Rump kernels allow developing kernel drivers in a test-driven manner, including both unit tests and integration tests. Since the iteration time with a rump kernel is in the subsecond range, the development process is smoother than with a virtual machine. Also, the tests written during development can be entered into the automated tests (see above), and later used for further development. This method avoids "throw-away" tests that are hardcoded for one virtual machine environment and unusable in both automated testing and further development done in another environment.