Guest post by The just released version 11.02 of the Genode OS Framework pushes its platform support to 8 different kernels. Genode allows the construction of specialized operating systems by combining one of those kernels with a steadily growing number of ready-to-use components. The new platform additions are the support for Fiasco.OC, which is a modern capability-based microkernel, the upgrade to the NOVA hypervisor 0.3, and a custom kernel implementation specifically targeted to softcore CPUs as employed in FPGA-based SoCs. Functionality-wise, Genode 11.02 features the first parts of a new execution environment for running command-line-based GNU software natively on Genode.
Genode’s cross-kernel portability had always been a unique point of the framework. Traditional microkernel-based OSes were tied to one particular microkernel and are regarded as inherently unportable. Genode changes this by providing a uniform API that works transparently across many different kernel APIs. At the same time, the specific features of each kernel are readily accessible if needed.
Most parts of the infrastructure that comes with Genode is completely kernel agnostic. This includes the dynamic linker, many device drivers, a TCP/IP stack, the Libc, a GUI, and Qt4. Consequently, each supported kernel platform immediately profits from enhancements of this infrastructure. The current release makes this rich functionality available on the Fiasco.OC kernel.
Technically, Fiasco.OC is a modernized version of the L4/Fiasco kernel as it emerged from the L4/Fiasco code base. However, Fiasco.OC’s kernel interface diverged entirely from the classical L4 API, towards a modern capability-based object-oriented model. Fiasco.OC is rich when it comes to features. It supports x86_32, x86_64 alongside many ARM-based platforms, facilitate the use of hardware-based virtualization, supports SMP, accounts kernel resources, and implements capability-based security. This feature set is actually a great fit for Genode, which was designed as a capability-based OS from the start.
With the second major addition to Genode’s platform support, the Genode project enters the realms of kernel development. For running Genode on the Xilinx MicroBlaze softcore CPU, a new kernel design was created, which dissolves the classical split of user land and kernel land. Let me explain.
Existing microkernels come in the form of self sustaining programs that include all functionality needed to operate independently from the user land. This functionality includes data structures for tracking memory mappings and memory allocators. However, in practice, each kernel is accompanied by a single user-level component (often referred to as roottask) that manages the creation of further user-level programs. For doing this, roottask has to keep very similar data structures as those used in the kernel. For a real system work load, both the kernel and roottask are always part of the trusted computing base. Consequently, roottask can be characterized as being the user-level portion of the kernel (even though kernel-developers tend to not appreciate this characterization).
Genode’s core component plays the role of such a roottask. If both the kernel and core are always present in a real system, wouldn’t it make sense to let both use the same data structures? Shouldn’t the real goal of a microkernel-based system be a minimal-complexity trusted computing base rather than only a minimally-complex kernel, which is then accompanied by a complex roottask anyway?
Moving Genode to a new CPU architecture provided the right incentive to pursue the experiment of merging core with the kernel. The kernel part is reduced to only a subset of a typical microkernel: CPU exception handling, a scheduler, functions for the direct manipulation of a software-loaded TLB, and an IPC mechanism. The current stage of implementation allows running core and multiple nested instances of the init process on the Xilinx MicroBlaze CPU. The outcome of this work already demonstrates that this approach has the potential to significantly reduce the complexity of the trusted computing based shared by all Genode applications.
The third platform addition of Genode 11.02 is the support for the recently released version 0.3 of the NOVA hypervisor. With this version, NOVA provides all means to run the complete Genode software stack including dynamically linked applications.
A wide range of supported platforms is of limited value without functionality to be used on top of the framework. Hence, each release enriches the framework with new functionality that thereby becomes available as workload for all supported kernels. Version 11.02 is no exception. It features the first parts of the Noux execution environment, which allows the use of command-line based GNU user land programs on top of Genode. Noux is geared towards the needs of the Genode developers, in particular for using the GNU tools. (gcc, binutils, make, etc.) Even though Noux is in an early stage, the code shipping with the new release clearly shows the direction of where its developers are heading – shaping Genode into a scalable yet highly secure general-purpose OS.
Read on about further details regarding the new kernel platforms, the vision behind Noux, and many more improvements of the framework in the release notes of version 11.02.
Why don’t more people rave about this?
It’s a pile of fantastic ideas.
Maybe the name of the microkernel being used doesn’t sound inspiring enough ?
Indeed, Genode sounds like the most promising general purpose operating system out there. It has all the buzz words; graphical, secure (capability-based), real-time, hypervisor, microkernel, 3d-accelerated, with good support and integration of legacy systems (such as Linux), portable (with different kernels and archs, including an FPGA soft core), with native ports of many powerful open source frameworks. What’s left to ask for?
The latest demo is really impressive. In case someone missed it:
http://www.osnews.com/story/24167Genode_OS_Walkthrough_on_YouTube
But if I understand correctly it’s an either/or choice: if you want the drivers you install Linux, if you want to use the ‘object capabilities’ you need to do another installation..
Maybe that’s why people are not so excited about it?
What makes you think that? I’m no expert, but I don’t recall them mentioning that limitation in their demos and explanations. The “object capability” model is the heart and soul of Genode, and they take pride on its ability to run and integrate several Linux VMs, Qt4 applications (like the Arora web browser) directly on Genode, plugins as separate processes and much more.
I guess people are not yet excited because, outside of the demo CD, the installation and configuration may be a bit involved, the system is evolving quickly and it’s probably not quite ready for production yet.
I guess that people have a hard time relating to the project because it cannot be easily compared to well-known OSes. It is different paradigm – maybe meta OS is an appropriate term. In a way, Genode relates to traditional OSes as LEGO relates to Playmobil. A kid that spent his whole lifetime with cool Playmobil gadgets would have a hard time to get excited about a bunch of LEGO bricks with no apparent structure. But an experienced LEGO engineer will appreciate the fact that most Playmobil semantics (say the functions of a police car) can be quite easily emulated with a compositon of fairly generic LEGO bricks.
The Noux execution enviroment as added with the current release shows off this flexibility quite well. Even though still in an early stage, is shows that it is feasible to emulate an UNIX-like interface on top of Genode without much effort.
At the current stage, the target audience for Genode are people who enjoy creating custom operating systems. Coming back to the LEGO analogy, such people can choose to create something from scratch (using a wooden brick and a knife), which takes a lot of effort. Or they could use LEGO to set their imagination free. In contrast to LEGO, however, Genode is free .-)
Regarding the question about device drivers: All device drivers that come with Genode work across all supported kernels. The only exception is Linux. The Linux base platform is used as development platform allowing us to start Genode as fast as a normal applications and use GDB for debugging. But it is not intended as a real target platform for deploying the framework.
Because most people are OS users, not OS designers or builders. The main question for OS users is: what can it do for me today?
Today this question remain largely unanswered with Genode.
It’s an awesome technology though, no doubt about it, and I’m sure it will have some very intersting applications in the, hopefully near, future.
I am very happy for this release. Contrary to what others say uKernels are the future. It makes the OS construction modular. I believe that this is the way forward. I wish Genode had a version with IOKit to use and write MacOSX compatible drivers (there was an IOKit port to L4) some years ago. Since uKernels are the future (and I do not agree with performance FUD) I hope the processor vendors realize that and start providing IOMMUs at desktop boards in order to make drivers more secure and other goodies. All in all Genode is a forward looking example and I would like to see much more uKernel OSs. Hurd is another paradigm though its problems are not uKernel related but both share a common vision. Hobby crowd should focus on writing hobby micro-kernels instead of hobby kernels.
Maybe, remember that we are using a lot of HW&SW which are “suboptimal”: x86, C, C++, etc, even if micro-kernels were better technically, this doesn’t ensure that we will use them in the future..
Wouldn’t you like to give it a try to port IOkit? It sounds like a cool project. On Genode, there exists an API called DDE Kit (Device Driver Environment Kit), which is a suitable hook for such an endeavour.The API is really simple, check out the documentation:
http://genode.org/documentation/api/dde_kit_index
DDE Kit is already being used as backend for Genode’s dde_linux (to run Linux drivers), dde_gpxe (to run gPXE network drivers) as well as the Gallium3D/GEM port. So it might be a natural point to start.
…and I would be happy to support such a project!
To how many processor cores could a linux “process” scale running inside of a Genode microkernel (I assume some of the microkernels have better scalability than others)?
I admit I’m more than a little interested in playing around with this if the answer is >= 32.
Well, as I see it, it is the other way around, at least for the new features in this release. It look like on how little can you scale it down. Running a modern OS on a FPGA is nice, it may be the future after all. Sure, CPUs are good, but FPGA are more flexible. Think of a cache like mechanism for actual code. A pool of soft wired logic gates in a big, fat and powerful CPU. You can use them asynchronously, executing heavy functions that require hundreds of cycles in a single one or poping physical threads on the fly to run light weight but real time process completely cut off from the main CPU while having access to its memory in true DMA mode. It could speed up application by hundreds of times given that a FPGA is able to process certain information faster than a CPU (when well used) while it is not even 1% of the size in term of transistors.
I would love to have a good platform for that, and this kind of OS might just be a perfect fit.
I take your point, and it will be nice if more mainboards become available having an FPGA socket in addition to all of their processor sockets. I think that would begin to increase the prevalence of FPGA-optimized code, which would be fantastic, especially if this was done in terms of existing UNIX libraries simply by replacing the algorithms done in C with something done in verilog or vhdl, so that it would be transparent to the user.
It isn’t the first time I’d wished I had an FPGA either, and it looks like my (core) algorithm-of-need has already been implemented for one:
http://imperial.academia.edu/SamuelBayliss/Papers/229087/An_FPGA_Im…
My question wasn’t really directed at this release, but it is a potentially practical question (for me).
I wonder if something like Microsoft CLR or LLVM runtime compilation could detect functions that can be implemented in pure logic (1 cycle per function) or logic+some latches (some cycle, but most merged together) and let the runtime compilator to produce the most “valuable” set of logic function for a given time or context. Let face it, it would not be like a CPU, unless it is done wrong, you can know at compile time how much gates you would be available at a given time and a given motherboard, as they would grow in transistor count while normal CPU grow in instruction set.
… this is the best non-editor pure-OS submission I’ve read on OSnews for about a year. I didn’t understand a fifth of it but I can see the construction of the news item and I can only say “bravo!”