GeezerVison

• Edit
• Source
• History
• New
• Recent Changes

Contents

This page is about rump kernels in NetBSD and assumes the reader knows the basics of rump kernels. General information about rump kernels is available elsewhere.

System security

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 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. Rump kernels are used in the continuous tests run by the NetBSD project. See Release Engineering Status Site 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 the source code history online. Code is found from all areas of the source tree. Some examples of where to look include src/lib, src/usr.bin and src/sys/rump.