Runnable Userspace Meta Programs in NetBSD 5.0

Introduction

Rump (Runnable Userspace Meta Programs) is a kernel virtualization and isolation technique available only in NetBSD. Rump uses the standard user process abstraction to provide a virtualization container for kernel components such as file systems and networking. The first release to feature rump support is NetBSD 5.0.

For the user, rump offers increased reliability and system partitioning for a very low runtime overhead and usually no setup effort. For the developer, it offers a kernel development environment which behaves like an application process and can leverage standard application development tools.

The remainder of this short article will give a brief overview of the key ideas behind rump and offer some examples of how to use it on NetBSD 5.

Key Ideas

An operating system kernel offers two central features for everything running on the system: resource arbitration and services. Resource arbitration means that the kernel tries to hand out physical computing resources, e.g. cpu and memory, in a fair way to tasks which request them. Services logically extend the hardware and provide features on top of it. Examples of services are TCP/IP networking provided on top of a network interface physical resource and a file system provided on top of a hard disk physical resource.

A conventional approach to virtualization is to take the entire operating system and virtualize everything including resource arbitration and services. This can be done for instance by using a machine emulator, Xen or the usermode version of the OS. Rump is radically different in that it does not aim to virtualize the entire system. Rather, it provides very lightweight virtualization of the service subcomponents of the OS.

For example, the NetBSD kernel contains drivers to interpret various file systems. To be usable, this driver code must be inside the kernel. In practise, this means that support must be compiled into the kernel or it must be loaded as a kernel module. In rump, the kernel code is contained in a user process. Reading and writing the contents of a file system is possible even without kernel support for that type of file system. The key difference to other usermode file systems is that rump file systems reuse the kernel file system code and modules can be interchangeably used in the kernel or in userspace. The key difference to in-kernel file system drivers is isolation from the rest of the kernel. It is also possible to provide multiple versions of the same kernel file system driver.

Although rump is a virtualization technology, it does not seek to replace the Xen virtualization present in NetBSD 5.0. Rather, Xen and rump should be seen as complementary technologies which each have their own strengths and weaknesses. For example, the setup of Xen from scratch for a one-off debugging task is heavyweight and time consuming, while using rump introduces no setup penalty. On the contrary, Xen is the choice for setting up a server farm, as rump does not virtualize the entire operating system.

What does rump do for you?

We will discuss the uses of rump with three example cases, the first being a microkernel style approach where we mount a file system with a file server running in userspace. The second example is a toolset for accessing file systems. The third usage example is kernel testing and development.

• rump_msdos: USB sticks with FAT file systems are a common sight. Mounting an untrusted image from removable media with the file system driver running in the kernel is risky in many ways: inopportune unplugging of the media or a corrupted file system may have adverse effects such as system crashes or worse. By using the rump_msdos command instead of mount_msdos, the file system service runs in userspace and is accessed via puffs. This isolates the main kernel from any resulting problems such as buffer overflows.

  The usage of mount_msdos and rump_msdos are equivalent. It is possible to use the userspace version of any supported file system by entering the keyword "rump" into the options field of /etc/fstab, e.g.:

  /dev/sd0e               /m/stick        msdos   rw,noauto,-u=100,rump
  

  The FAT fs from /dev/sd0e can now be mounted with a rump file server simply by typing "mount /m/stick &". Unmounting works as usual with umount /m/stick. Note: In NetBSD 5.0 the rump file servers do not background themselves automatically. Therefore the above mount example contains the ampersand. The behavior has been changed to background by default in NetBSD-current.

• fs-utils: The famous mtools tool suite provides access to FAT file systems directly from userland without requiring to have FAT support in the kernel or having to mount the file system. fs-utils does the same as mtools by means of rump and supports FAT plus 9 other NetBSD disk-based file systems, including FFS, cd9660 and UDF. As examples of provided utilities, fsu_ls lists the contents of an image and fsu_ecp can be used to copy files in and out of the file system.

  Currently, fs-utils is not shipped with the base system and must be installed separately from pkgsrc. It is available as pkgsrc/filesystems/fs-utils. The fs-utils application suite was written by Arnaud Ysmal.

• testing (for developers): Kernel testing is difficult for two reasons: 1) it requires the use of a possibly buggy kernel on the test host 2) if the kernel crashes as a result of the test, it is difficult to automatically generate an error report. As rump allows making system calls to a process local kernel, a bug will only result in an application crash, which is well handled by the Automatic Testing Framework (atf) available in NetBSD 5.0. Rump makes regression testing the kernel easy, quick, gives accessible results automatically and does not require a full OS setup.

Further Resources

Rump is still under constant development and changes are taking place daily. The rump website at http://www.NetBSD.org/docs/rump/ is a good source for current and future information and includes links to publications containing more in-depth coverage. Feedback via the NetBSD mailing lists or the issue tracker is encouraged.

The use of rump is described in manual pages:

• rump_msdos.8 (similarly for other file systems, e.g. rump_ffs)
• rump.3
• p2k.3