Guest post by With the just released version 12.11, the developers of the Genode OS Framework are celebrating the break-through to execute the entire build system based on GCC 4.7.2 within their genuine operating-system environment. The new release gets accompanied with new audio drivers from the Open Sound System project, extended support for OMAP4, and numerous stability and performance improvements concerning the underlying kernel platforms.
For the stated goal to use Genode as a day-to-day OS by their developers, the ability to run the build system in the Genode environment is considered as pivotal. Of course, the build system could be executed using one of the available virtualization solutions, for example by using L4Linux on Fiasco.OC. However, this would not have much appeal for the Genode developers because it would not prove anything about the versatility of the actual environment provided by the framework itself. Instead, the developers consider this kind of virtualization just as a stop-gap solution until Genode is able to live on its own account.
The preceding releases came with several stepping stones geared to reach this goal, but the final step was an elaborative one. The work load induced by the build system stressed the framework and the underlying kernel platform far more intensely than the traditional usage scenarios and ultimately uncovered shortcomings that were unknown before. Consequently, extensive efforts went into overcoming those stumbling blocks, which spanned the whole software stack, reaching from the underlying kernels, over the base framework, C runtime, the Unix glue layer, up to the actual tool-chain components. As a result, it has become possible to run the unmodified build system to a degree that builds Genode’s base system including the core and init processes.
In addition to the improvements motivated by the build-system-related work, several of Genode’s base platforms underwent significant changes. On Linux, Genode has taken steps to become an attractive middleware for building component-based software on top of the Linux kernel. This line of work already produced surprising new ways of how the concepts of the Genode architecture meet the mechanisms provided by the Linux kernel. The custom kernel platform for ARM hardware has received new support for TrustZone technology, improved caching, and extended the support for different SoCs.
With regard to device support, the new version introduces a device-driver environment for audio drivers of the Open Sound System. With this environment, unmodified OSS audio drivers for popular x86 sound hardware can be reused on Genode. When it comes to ARM-based hardware, the project added support for Freescale i.MX, and extended the device-driver coverage of the Texas Instruments OMAP4 platform by including a new driver for general-purpose I/O pins. Speaking of the OMAP4 platform, the project just published an article reporting on the experience with adapting and optimizing Genode for the Pandaboard.
To learn more about the background of all the improvements, continue with browsing the release notes.
The Genode team has done some truly amazing work on the Genode Framework and I can only congratulate them on their progress.
Keep up the great work, and hope you come for a visit in Sweden for another hack’n’hike!
/robin
Congratulations for the new release. You innovate.
Thank you for the cheering. 😉 We will definitely keep up the work.
@robin Great to see a life sign of you! I was already wondering a bit if you got safe back home, or if we might have alienated you for some reason? Btw, now that gcc-4.7.2 is default, maybe it is a good time to look at gcc-go again?
Good work! I like the goals of microkernel (and exokernel) projects like Genode.
I know I’m being ultra thick, but I’ve never managed to wrap my head around the point of Genode. And I don’t mean this in a “why do we need another x, y, z” argument that people often raise when reading about a new OS et al.
What I mean is, I understand enough about Genode to understand that it’s considerably different to what’s already out there. And I understand enough about it to know that it’s a very interesting project. But I’ve never been able to wrap my head around the jargon on their web site to grasp the true concept and ramifications of their project.
Is anyone able to dumb this down for someone who understands technology but is largely illiterate? hehe
I am afraid that your perception is not uncommon. I find it extremely difficult to express the appeal of Genode in simple words. In a recent interview for the Brazilian EspÃÂrito Livre Magazine, I tried it anyway. Maybe you’d like to skim over it, in particular the first two questions?
http://genode.org/about/interview_rel36
Please don’t hesitate to check back with me if things remain still unclear. In any case, I would welcome suggestions of how we could make the point of Genode more clear for people approaching the project. Maybe you (with being in this position right now) have a good idea? 😉
That article does clear a lot up. Thank you very much (I would rep but OSNews has a rule that people who comment in articles cannot vote).
I think I can see why you guys have difficulty dumbing down for the layman (if you don’t mind me saying that). It sounds like Genode has a very specific vision, but one that crosses so many fields of OS development that it’s very difficult to give an overall summary.
I’ve read about Linux distributions that try to tackle similar issues by running each application within their own virtual machine, but I like your approach much more.
I do have a few questions, if you don’t mind:
How do applications grant themselves access to different subsystems? Your article reminded me a little of iOS and Android apps where the OS specifically has to request access to various subsystems on their respective mobile platforms; and the user is prompted about the requested permissions. I’m guessing your solution is more sophisticated than this though.
However, and with my limited understanding of Genode, I wonder if the same scope for permission abuse is available that you see with mobile apps. ie developers deciding they need access to various additional subsystems to implement largely pointless application features. (eg a camera app having access to your contact list to implement MMS). This is an increasing problem these days as users are used to integrated ecosystems and oblivious to the dangers of sharing data across the various different applications.
The other big question your article raised was how you’re able to borrow subsystems from monolithic kernels like Linux? Does that require Linux to be compiled in a special way to support Genode or does Genode have bespoke code to interface with an array of kernels? ie is Genode a bit like an API and kernels have to be hacked to link with the Genode, or do you have to hardcode support in Genode to interface with the various components?
The way I’m imagining this is a bit like a website: Websites are written to be served on any platform as the web servers act like the ‘kernel’ and allow web developer to concentrate on just writing their applications. And websites should run on the majority of browsers, but browsers need to support various web standards to work.
I’m imagining Genode a bit like the web site. It’s the essential interface between the web servers (kernels) and the applications (browsers). Applications need to be compiled to support Genode’s standards (else users a faced with a very restricted environment; like browsing the web in Lynx) but Genode aims to be platform independent (like PHP).
I know no analogy is perfect and I appretiate that Genode is looked to include some bespoke applications and kernels of it’s own, but is that the basic structure / aim you’re working to?
And one last question, could Genode be used as a foundation for hobbyist OSs? There was a discussion on OSNews a little while back where one commenter speculated that Genode could be used as a common driver stack, thus enabling hobbyist OS developers to focus on the fun stuff (writing pretty user interfaces).
I think when I’ve wrapped my head around this, I’m going to write a layman’s guide to Genode to help raise awareness for this fascinating project.
Edited 2012-11-30 18:06 UTC
Your questions are spot-on. Let me try to cover them one by one.
How do applications grant themselves access to different subsystems? Your article reminded me a little of iOS and Android apps where the OS specifically has to request access to various subsystems on their respective mobile platforms; and the user is prompted about the requested permissions. I’m guessing your solution is more sophisticated than this though.
A Genode system is a tree of processes. When booting up, there is only the root of the tree that we call “core”. Core runs directly on the kernel (e.g., Linux or a microkernel) and owns all physical resources like RAM and devices. After having started up, core creates the so-called init process, which becomes thereby a child of core. But in contrast to Unix where a forked process inherits the privileges and identity of the forking process, a Genode child process has no privileges at all when created. The only thing such a process can do, is to send messages to its immediate parent (the one who just created the process). The parent can then decide to respond to such messages in any way the parent sees fit, e.g., it can grant specific permissions to the child. Conceptually, the child process is like a virtual machine and the parent process is like its virtual-machine monitor. Now, the cool thing is that the child process, in turn, can again create child processes using the same mechanism. So the system becomes like a tree of nested virtual machines where parent processes are always in full control over their children.
Compared to iOS or Android, which are essentially “flat”, Genode’s recursive structure provides a much more flexible way to model security policies, for example by hosting critical system functions nearby the root of the tree, and subordinating a complex piece of untrusted code into a dedicated subsystem at an upper tree level.
This is the basic idea how the system looks like. The other interesting question is how it behaves and how processes interact with each other. To blatantly simplify it, processes can only interact with each other if their common parent process agrees.
However, and with my limited understanding of Genode, I wonder if the same scope for permission abuse is available that you see with mobile apps. ie developers deciding they need access to various additional subsystems to implement largely pointless application features. (eg a camera app having access to your contact list to implement MMS). This is an increasing problem these days as users are used to integrated ecosystems and oblivious to the dangers of sharing data across the various different applications.
Because in Genode, each process lives in its own world as shaped by its parent, it may never know whether if it interacts with a real device or a virtual one. It is for the parent to decide (and again, this parent may also not know if he is interacting with something physical or virtual). So Genode would make it very easy to let the user supply custom versions of a contact list or a virtual camera to an application.
Our concern for privacy is actually one of the driving motivations behind developing Genode.
The other big question your article raised was how you’re able to borrow subsystems from monolithic kernels like Linux? Does that require Linux to be compiled in a special way to support Genode or does Genode have bespoke code to interface with an array of kernels? ie is Genode a bit like an API and kernels have to be hacked to link with the Genode, or do you have to hardcode support in Genode to interface with the various components?
Both actually. Genode’s core can be executed on top of a variety of kernels, for example Linux, NOVA, OKL4, Fiasco.OC. There is a different version of core for each kernel. The role of core is to translate the respective kernel interface to a generic programming interface (the Genode API).
All processes upon core are using the Genode API only and are thereby independent from the kernel. So a device driver implemented using the Genode API can run on all kernels supported by Genode. When using Linux device driver code on Genode, we use to build glue code that translates the API used by driver to the Genode API. For example, to get the Linux USB stack running, we have created a small library that looks like the Linux kernel from the driver’s perspective. In reality, it just maps all the used function calls to the Genode API.
The way I’m imagining this is a bit like a website: Websites are written to be served on any platform as the web servers act like the ‘kernel’ and allow web developer to concentrate on just writing their applications. And websites should run on the majority of browsers, but browsers need to support various web standards to work.
I’m imagining Genode a bit like the web site. It’s the essential interface between the web servers (kernels) and the applications (browsers). Applications need to be compiled to support Genode’s standards (else users a faced with a very restricted environment; like browsing the web in Lynx) but Genode aims to be platform independent (like PHP).
I know no analogy is perfect and I appretiate that Genode is looked to include some bespoke applications and kernels of it’s own, but is that the basic structure / aim you’re working to?
I think this specific analogy is a bit complex to be expressive. It has too many roles (web server, web application, browser, web standard, PHP). In one way, the analogy is quite fitting. When using PHP you don’t care too much about the web server. So you can move your website to another (e.g. faster) web server without needing to change the code. For Genode, it is similar. A program developed using the Genode API can be used on many kernel without changing the driver’s code. But that particular trait is common for all kind of abstraction layers and not so much a unique point of Genode.
And one last question, could Genode be used as a foundation for hobbyist OSs? There was a discussion on OSNews a little while back where one commenter speculated that Genode could be used as a common driver stack, thus enabling hobbyist OS developers to focus on the fun stuff (writing pretty user interfaces).
Definitely!
I think when I’ve wrapped my head around this, I’m going to write a layman’s guide to Genode to help raise awareness for this fascinating project.
Wow! I would greatly appreciate that. Thanks for taking the time for investigating the project more deeply.
Thanks for taking the time to answer my questions. And it’s been an absolute pleasure talking to you.
I’ll definitely get an article drafted up, though it may not be until Christmas. I hope you don’t mind, but I’ve added you on G+ so I can forward you the draft before publishing
Ah, that was you on Google+. You are very welcome! Let’s keep in touch 🙂
Thank you for the explanations – I was in a similar position to Laurence, an OS-layman, but now I think I get the general idea behind Genode.
BTW, in http://genode.org/about/interview_rel36 by “main-stream computing” (middle of first answer) you mean user-facing/visible, I suppose? Don’t some microkernels see wide adoption – just hidden from view a bit, ~embedded?… (also ~L4, so related to your Dresden efforts?)
And I love the 4th answer, transformers and Lego analogy
Generally, too bad that “good enough is the enemy of better” …the landscape, which form of OS will dominate, might be possibly largely decided; it would be a shame if all this remained mostly an academic curiosity.
(maybe it’s a bad sign when the project is hard to explain; or maybe the laymen always see ~permission mechanisms as too convoluted
– like it was with UAC, and that not even a very extreme mechanism)
Are there any notable entities expressing their interest already? (maybe not necessarily the kinds of Red Hat or Google with their million or so servers and Android, but something which could already determine if the project goes somewhere)
Thanks for following the discussion!
BTW, in http://genode.org/about/interview_rel36 by “main-stream computing” (middle of first answer) you mean user-facing/visible, I suppose? Don’t some microkernels see wide adoption – just hidden from view a bit, ~embedded?… (also ~L4, so related to your Dresden efforts?) And I love the 4th answer, transformers and Lego analogy
Indeed, microkernels seem to be everywhere but mostly go unnoticed. For example, did you know that there is a microkernel running in the Samsung Galaxy S3? (see here for a press release on that:
http://www.gi-de.com/gd_media/media/en/press/prs_1/pdf_2012/Samsung…
Also in safetly-critical systems, microkernels are ubiquitous. Because the correct functioning of such systems needs to be thoroughly evaluated, the use of microkernels is advantageous to split one complex system into several less complex parts, which can be looked at individually. Those uses of microkernel technology, however, are what I call “special-purpose computing”. Those solutions are not designed to scale to dynamic and general-purpose workloads. This is where Genode is different as our declared goal is to scale beyond special-purpose application domains.
That said, there already exist microkernel-based general-purpose OSes. Minix3 or QNX come in mind. However, the user-land architectures of these OSes largely resemble the same concepts as used on monolithic systems, namely Unix / POSIX and a VFS. Genode radically departs from this classical POSIX approach and instead applies microkernel principles and in particular the principle of least privilege to the whole system, not just the kernel. So in contrast to those existing OSes, the critical parts of Genode do not carry the legacy of POSIX with it. It just happened that the resulting Genode API is capable to implement POSIX on top. This is the role of Noux, which I think is a quite fascinating approach to align POSIX compatibility with Genode’s architecture.
Generally, too bad that “good enough is the enemy of better” …the landscape, which form of OS will dominate, might be possibly largely decided; it would be a shame if all this remained mostly an academic curiosity. (maybe it’s a bad sign when the project is hard to explain; or maybe the laymen always see ~permission mechanisms as too convoluted
– like it was with UAC, and that not even a very extreme mechanism)
We certainly do not strive for domination. 🙂 As I expressed in the interview, I think that Genode will eventually become integrated into devices without most people being aware of it’s presence – similar of how most consumers that buy the Android brand do not realize that they are using Linux.
Are there any notable entities expressing their interest already? (maybe not necessarily the kinds of Red Hat or Google with their million or so servers and Android, but something which could already determine if the project goes somewhere)
Indeed, there is commercial interest. We actually built our small company around this technology and maintain a sustainable business by supporting the framework and conducting industrial research related to Genode. Hence, for me personally, the project already has gotten somewhere. 🙂
As a surprising turn of events, there is even commercial interest in using Genode on top of Linux. Apparently, the qualities that the framework brings to the world of microkernels turned out to be valuable on Linux, too. This was quite unexpected.
Thanks for further info, I think I really have now a decent idea about what Genode is.
Reminded me about a big L4 deploymant info, in the most straightforward of places: http://en.wikipedia.org/wiki/L4_microkernel_family#Commercial_deplo…
Also about http://en.wikipedia.org/wiki/Nucleus_RTOS (apparently “used in Mediatek Dual SIM Dual processor based chipsets found on most Chinese phones […] A large number of Motorola, Samsung, LG, Siemens/Benq, Sagem and NEC mobile phones. […] Infineon S-Gold2 baseband chip used in Apple’s iPhone” and many other non-mobile usages) – but is that a microkernel OS?
At least http://en.wikipedia.org/wiki/Operating_System_Embedded is a microkernel, it seems, and it also apparently has tons of ~mobile deployment.
WRT where Genode could end up – I wonder if it might eventually become a new basis for GNU OS / Hurd, maybe that project will finally go somewhere
Best of wishes with your project.
Edited 2012-12-04 12:52 UTC
I hope that I’m not overly generalizing, but as far as I know, most “RTOS” solutions do not support address spaces, which, however, would be the solely defining point of being a microkernel-based OS. The scheduler, applications, drivers, and networking code tend to be executed in a single address space with no memory protection at all. This is ok for the typical use cases where they are deployed because all userland code is regarded as trusted anyway. So the desire to protect userland components from each other is not very strong in these scenarios. The baseband processor you just mentioned is such a scenario.
Microkernels become attractive not before multiple third-party (and potentially untrusted) components must be integrated on one platform. For example, OK-Labs used to argue that by using their OKL4 microvisor product, baseband functionality and Android can be executed on a single processor, yet both remain isolated from each other. So when using their product, no separate baseband processor is needed anymore. According to their website, they are pretty successful: “The Next Billion Devices” they state. (Admittedly, I am not sure if this number refers to the microvisor or their pico product. The latter seems to be more of an RTOS than a microkernel.)
Reading about how OKL4 is used reminded me about another thing – apparently there was already a “main-stream computing” example of ~microkernel OS, in the form of (2nd revision) http://en.wikipedia.org/wiki/Mac_OS_nanokernel ?
Still, rather hidden of course…
Later Symbian versions were also similar, IIRC.
Edited 2012-12-04 14:40 UTC