Feeds

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.