The just released version 12.08 of the Genode OS Framework comes with the ability to run Genode-based systems on ARM hardware without an underlying kernel, vastly improves the support for the NOVA hypervisor, and adds device drivers for the OMAP4 SoC. Further functional additions are a FFAT-based file system service, the port of the lighttpd web server, and support for on-target debugging via GDB.

"Would I be right to say that the platforms that are better supported at the moment are NOVA and Fiasco.OC?"

Yes, in particular when looking at the security model. Those two kernels support Genode's way of delegating access rights throughout the system at kernel level, which makes them naturally a good fit for the framework. If factoring out the security aspect, there are other kernels that cover the whole Genode functionality as well. For example, on OKL4 or L4/Fiasco, the whole Genode API is fully functional. Linux is also pretty well supported in terms of stability but, of course, it is inherently limited to the features offered by the Linux kernel. For example, because there is no way to manipulate an address space of a remote process, Genode's managed dataspace concept won't work on Linux.

"Could you compare the level of support for these two kernels (Fiasco.OC and NOVA)."

With the current release, both base platforms are almost on par. Fiasco.OC has a slight edge with regard to the life-time management of kernel resources but we are working on getting the NOVA base platform there, too.

"Also, would it be feasible to fork a kernel with support for a wide range of architectures e.g. Fiasco.OC and modify it to be more deeply integrated with Genode in order to eliminate some of the duplication? (Promoting it to a first class citizen in the framework.)"

Personally, I don't feel the slightest temptation to do so. ;-) The F/OSS microkernel community is small enough, and actually quite fragmented. A fork would not only be a step in the wrong direction, it would pose a big liability for the forking project. We should better try to discuss our findings with the respective kernel developers to elaborate ways of how the redundancies can be reduced by changing the kernel API. For example, from Genode's perspective, the in-kernel mapping database as featured by both Fiasco.OC and NOVA is more of a hindrance than a feature. So we would try to convince the kernel developers to remove it or to make it optional. We are actually in close contact with NOVA's developers, discussing such ideas.

"Is running them in the same address space just an interim solution or is that the way forward?"

As both components are always forming the root of the process tree, there is no security benefit of separating them. Speaking from Genode's perspective, putting them into a single component is clearly the way to go. From the perspective of kernel developers, this is not so easy because each kernel tries to accommodate user-land implementations other than Genode as well.