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