Hi Thomas,
Considering the amount of work that would be needed, I think I don't have the resources for that at the moment. I will stay with Xen as hypervisor for now.
no problem. :-)
Out of interest, is there a way to merge Genode and Xen? Xen allows dom0 disaggregation where device drivers are packed with a server backend in unprivileged, isolated VMs, which seems very similar to resource multiplexers in Genode I think. QEMU is also separated into individual VMs for each guest OS. The complexity of dom0 reduces at the same time, so it seems as Xen would be moving towards a micro kernel approach as well? A clear difference for me is that e.g. Genode allows a better capability and resource management at the moment.
So in your opinion, where do you see clear differences between Genode and the future Xen?
I think the main difference are the starting points of both projects. Xen is a hypervisor platform in the first place and seems to gradually move towards componentization wherever it seems sensible. In contrast, Genode is designed as component-based operating system that happens to also support virtualization. Compared to the approaches I know from Xen, the granularity of Genode's componentization is extremely fine. In fact, there are over 100 components that can be combined to compose systems out of. From the security point of view, the most distinctive characteristic of Genode is a much lower TCB complexity. A Xen-based system has to rely on the complex Xen hypervisor and the Linux system that runs as Dom0. In contrast, Genode-based systems do not require a DomU at all and can run on kernels that are as small as 10,000 lines of code (NOVA). This makes the trusted computing base of such systems orders of magnitude less complex.
Would it be possible to bring the advantages of Genode over to Xen?
I believe so. In principle, I could envision three approaches:
* Supporting Xen as a kernel for Genode and use Xen's domains as Genode's protection domains. However, this would require a significant amount of work and the chance for creating synergies between the Xen community and Genode is very little. Also, I do not see any technical advantage of using Xen as kernel over NOVA.
* Using Genode as a replacement of Dom0. This would benefit Xen by drastically reducing the TCB complexity of Xen-based systems compared to the current use of Linux. The main problem here is moving the existing Xen tools from Linux to Genode. There must be a clear incentive to do that.
* Using Genode as a DomU. Instead of using multiple MiniOSes for executing components, Genode could be used to host components and let them interact with each other. Still, selected functionalities could reside in separate VMs. So there would be a migration path. To kick off work in this direction, the NOVA version of Genode could be used in a DomU as is. Then, a set of user-level device drivers for Xen's inter-domain communication facilities must be developed to connect the Genode world with the Xen world.
Would it be possible to run Xen enabled applications directly on the Genode framework?
Could you please be more specific about the applications you refer to?
Cheers Norman