**Contents**

[[!toc levels=2]]

This page is about rump kernels in NetBSD and assumes the reader knows
the basics of rump kernels.  [General information
about rump kernels](https://github.com/rumpkernel/wiki) is available elsewhere.

## System security

File system drivers are vulnerable to consistency errors in
file system images, see e.g.
[here](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.114.4312)

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
required, or `rump` in `/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
unaffected.


## Automated testing

The problems of automated kernel testing are documented for example in
[The Design and Implementation of the Anykernel and Rump Kernels](http://lib.tkk.fi/Diss/2012/isbn9789526049175/isbn9789526049175.pdf).
Rump kernels are used in the continuous tests run by the NetBSD project.
See [Release Engineering Status Site](http://releng.NetBSD.org/) for the results or the NetBSD source tree
under `src/tests` for the test programs themselves.


## Kernel development

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.


## Source Code

You can also [browse](http://cvsweb.NetBSD.org/bsdweb.cgi/src/) the
source code history online. Code is found from all areas of the source
tree. Some examples of where to look include
[src/lib](http://cvsweb.NetBSD.org/bsdweb.cgi/src/lib/),
[src/usr.bin](http://cvsweb.NetBSD.org/bsdweb.cgi/src/usr.bin/) and
[src/sys/rump](http://cvsweb.NetBSD.org/bsdweb.cgi/src/sys/rump/).