Linked by nfeske on Thu 29th Nov 2012 17:38 UTC
OSNews, Generic OSes 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.
Permalink for comment 543743
To read all comments associated with this story, please click here.
RE[3]: I feel like a thicko
by nfeske on Fri 30th Nov 2012 19:15 UTC in reply to "RE[2]: I feel like a thicko"
Member since:

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).


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.

Reply Parent Score: 5