Lightweight virtualization - the rump approach

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

Dear lists,

Some of you have probably noticed a posting of mine on TNF blog [1] 
regarding Antti's work (rump) in NetBSD [2]. After discussing it briefly 
with him via mails, we chose to bring the subject to a wider audience; 
so here it is.

To sum up a bit the situation, some of you have probably seen a trend 
towards "microkernel"-like approach to improve system availability, 
resilience, or security.

By "microkernel-like" approach, I mean:
- consolidating different general purpose OS above some kind of 
microkernel, like Xen,
- security through isolation, target being desktop, like Qubes (COTS 
with Xen, Linux, IOMMU, etc.)
- specific microkernel architecture of the embedded world (many, many more).

The thing is not new. I guess that the increase in performance of 
today's hardware made it more attractive, as well as the need for 
stronger security, especially for kernels, with MILS systems in mind [3].

I am not posting this to reinstate the decades old monolithic vs 
microkernel troll, so please avoid that field; thanks.

Lights on the work of Antti, with rump. Most systems I have seen lately 
provide the characteristics enumerated above by pulling in a general 
purpose OS, like Linux, with its environment, just to get a specific 
need, like an up-to-date network stack (strong push for IPv6, anyone?), 
drivers (filesystems, usb, pci stacks, devices), etc. There is no real 
componentization in mind.

Everything being virtual these days (see cloud computing buzzwords, or 
hardware systems delivered with some kind of hypervisor inside - PS3, or 
sun4v, for example -), I see Antti's work (well, all TNF work too ;) ) 
as being a real asset to make the NetBSD's code base more widely known, 
appreciated and used. I have yet to see a solution where you could port 
then debug kernel code directly to userland (at least, for a general 
purpose OS), or offer an alternative when you need to port specific 
components, like network functionality or filesystem code.

For this reason, I have a few questions for the ones familiar with rump 
technology here, especially:

- the basic architecture; how did/do you achieve such a functionality? 
Adding an extra layer of indirection within the kernel? Suppose we have 
improvements in one part of it, like TCP, IP stacks, could it directly 
benefit the rumpnet component, or any service sitting above it?

- What kind of effort would it require to port it to other OS 
architectures, especially when the API they offer could be a subset of 
POSIX, or specific low level API (like Xen's hypercalls)? (closely 
related to the work of Arnaud Ysmall in misc/rump [4])

- If rump could be used both for lightweight virtualization (like rump 
fs servers), or more heavyweight one (netbsd-usermode...)?

- eventually, extra icing on the cake, especially with the appearance of 
IOMMU in common x86. Could rump be used for (device) drivers to offer 
better isolation and cause less harm to the kernel?

Thanks to all who responds, and please, avoid flaming on that one. I'd 
like to keep the discussion on technical grounds.

Cheers,

[1] http://blog.netbsd.org/tnf/entry/kernel_modules_autoload_from_host

[2] http://www.netbsd.org/docs/rump/

[3] http://en.wikipedia.org/wiki/Multiple_Independent_Levels_of_Security

[4] http://www.netbsd.org/~stacktic/rumpabroad.html

--
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost