Hi Lonnie,

I found Open vSwitch (http://openvswitch.org/) and wanted to see what your thought were on this as it might be a good solution to allow for multiple VirtualBox VM's to be running under NOVA & Genode.

Any thoughts on this?

I remember your email. Admittedly, when I studied the web site, I did not immediately grasp the problem that Open vSwitch would solve for Genode. Could you elaborate a bit more about your thoughts?

For simple multiplexing of a physical NIC to multiple network-using processes, we usually use the NIC bridge (os/src/server/nic_bridge) component. How do you envision the role of Open vSwitch in a Genode system? Would that be an alternative to NIC bridge? If yes, what would be the benefits of using one over the other?

Best regards Norman

Hi Lonnie,

Based upon my current understanding of Genode, which is still minimal but growing steadily, as you move to get VirtualBox running well, it seems that for the networking to be viable in the VB instance, you might want to support network-bridging as well as NAT (masquerading IP's) in a similar way that VB currently allows and also how XEN seems to work in that each VM instance can be bridged to the host with a "real" IP of it's own on he same subnet as the host, or to possible use the VB built in NAT support VM instances on another subnet but all channeled through the host network adapter. Typically, it seems that VB sets up a TAP/TUN device (virtual network card) on the host and then allows for the various network setups like NAT, bridged, host-only, etc...

As I was not sure if these questions had been investigated, I thought that perhaps Open vSwitch ( ie. a software hub basically) might be easily implemented in Genode and serve as the networking center for VirtualBox in a similar way that XEN seems to do it (http://wiki.xen.org/wiki/Xen_Networking).

This allows VB under Genode to support many VMM's concurrently.

You have probably already thought of these things, but I thought that I would mention them as the question arose in my mind as well.

admittedly our current networking setups are rather simple. We are using nic_bridge when we need to share a NIC among multiple subsystems. I agree that a virtual NAT component would be a very useful addition to the toolbox. It would certainly be a relief for the DHCP server of the host network. ;-) We will definitely have to look into Open vServer when picking up the work on this topic. So thank you for the pointer!

Just some thoughts that I had since my goal is to try and set up NOVA-Genode-VirtualBox in a complete Type-1 Hypervisor that could be competitive to XEN while being much more secure, stable, and address the shortcomings found in that hypervisor which is very code bloated and heavy. The NOVA-Genode-VirtualBox approach should require much lest LOC and in general be better given the wonderful design that you and your team have developed from the inception.

The overall complexity may still be high - VirtualBox is not tiny after all. However, the advantage of the Genode/NOVA platform is that this complexity becomes uncritical to uphold security (i.e., the isolation between VMs). When using VirtualBox on Linux, one needs to trust the Linux kernel + init system + daemons, the VBox kernel module, the X server, the VirtualBox application (because it can load code into the Linux kernel). This amounts to millions of lines of code to trust. On Xen, the situation does not look much different as the Linux system in Dom0 must be trusted.

Compared to that, the trusted computing base (TCB) of a Genode/NOVA-based virtualization solution would be orders of magnitude less complex. It comprises the NOVA kernel (10 KLOC), Genode's core + init (< 20 KLOC), a few device drivers (for timer, NIC, disk), and eventually a few resource multiplexers (nic_bridge, part_blk come into mind). So we are well below 50 KLOC.

Cheers Norman