tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Lightweight virtualization - the rump approach



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




Home | Main Index | Thread Index | Old Index