3: [[!toc levels=2]]
5: This page is about rump kernels in NetBSD and assumes the reader knows
6: the basics of rump kernels. See
7: [rumpkernel.org](http://www.rumpkernel.org/) for general information
8: about rump kernels.
10: ## System security
12: File system drivers are vulnerable to consistency errors in
13: file system images, see e.g.
16: What this vulnerability means is that whenever an untrusted file system
17: image is mounted using an in-kernel driver, system compromise should be
18: expected. This untrusted images include for example ones on USB sticks.
19: There are heavyweight workarounds for the problem, for example including
20: virtual machines.
22: NetBSD allows transparently mounting an untrusted file system image by
23: running the kernel driver in a rump kernel in userspace. The driver
24: is thus isolated and any damage that a malicious file system image
25: can directly cause is restricted to a userspace process. From a user
26: perspective, mounting with the `-o rump` option is the only change
27: required, or `rump` in `/etc/fstab`. Notably, even though interacting
28: with untrusted file systems will suffer from a minor performance penalty,
29: the performance of mounts from trusted file systems is completely
33: ## Automated testing
35: The problems of automated kernel testing are documented for example in
36: [The Design and Implementation of the Anykernel and Rump Kernels](http://lib.tkk.fi/Diss/2012/isbn9789526049175/isbn9789526049175.pdf).
37: Rump kernels are used in the continuous tests run by the NetBSD project.
38: See [Release Engineering Status Site](http://releng.NetBSD.org/) for the results or the NetBSD source tree
39: under `src/tests` for the test programs themselves.
42: ## Kernel development
44: On the flipside of testing is kernel development. Rump kernels allow
45: developing kernel drivers in a test-driven manner, including both unit
46: tests and integration tests. Since the iteration time with a rump
47: kernel is in the subsecond range, the development process is smoother
48: than with a virtual machine. Also, the tests written during development
49: can be entered into the automated tests (see above), and later used
50: for further development. This method avoids "throw-away" tests that
51: are hardcoded for one virtual machine environment and unusable in both
52: automated testing and further development done in another environment.
55: ## Source Code
57: You can also [browse](http://cvsweb.NetBSD.org/bsdweb.cgi/src/) the
58: source code history online. Code is found from all areas of the source
59: tree. Some examples of where to look include
61: [src/usr.bin](http://cvsweb.NetBSD.org/bsdweb.cgi/src/usr.bin/) and
CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb