Genode: possible foundation for a SAFE OS?


A Secure OS for the SAFE internet is the focus here, without which SAFE can never be really safe.

Computer security (especially mobile security) is abysmal. SAFE is an important part of the solution, but the NSA can still just hack into your phone and steal your password as you type it. We need to really own the box, and Genode could complement the SAFE network by serving as the foundation for that.

Think along these lines:

  • your webcam, microphone, screen, keyboard, storage, GPS, wifi, network in general, etc. are literally nonexistent to apps (and even “system services,” whatever that means) that were not explicitly granted access to it
  • you can set up an app in a way that access to e.g. the webcam or the microphone is verified every time (i.e. through an unforgeable popup); see a more detailed example near the end
  • passwords are always entered through a very simple and very secure custom keyboard app, which is verified and trusted; you can use Swype or whatever you want for everything else
  • there’s no way for an app to sit between others and the display module without explicit authorization
  • resource limits can be enforced at every level (e.g. the outgoing data bandwidth used by a messenger app)
  • hard real-time scheduling

Enter Genode

Genode is an insanely awesome project I’ve been (very) loosely following for a few years.

NOTE: I had to edit the following paragraph to correct a confusion I had about the structure of Genode. For more detailed info, check out the book (from the bottom of page 11: “Clean slate approach.”)

It is an “operating system framework” that sits on top of a secure microkernel (e.g. seL4, another personal favorite) and orchestrates a hierarchical network of tiny modules, each providing a single service for those above while using the smallest possible set of modules from below while being responsible for a certain amount of resources, which it can multiplex between its children, or trade with other modules as part of acquiring or providing services. Modules can communicate only with those other modules that they are explicitly allowed to (the concept of “least privilege.”) This can dramatically reduce the trusted computing base (“attack surface”) for a given functionality, e.g. an encryption module or different stacks (networking, VFS, etc).

(Here's some more explanation and an example from the Genode site.)

> On Genode, the amount of security-critical code can largely differ for each application depending on the position of the application within Genode’s process tree and the used services. To illustrate the difference, an email-signing application executed on Linux has to rely on a TCB complexity of millions of lines of code (LOC). Most of the code, however, does not provide functionality required to perform the actual cryptographic function of the signing application. Still, the credentials of the user are exposed to an overly complex TCB including the network stack, device drivers, and file systems. In contrast, Genode allows the cryptographic function to be executed with a specific TCB that consists only of components that are needed to perform the signing function. For the signing application, the TCB would contain the microkernel (20 KLOC), the Genode OS framework (10 KLOC), a minimally-complex GUI (2 KLOC), and the signing application (15 KLOC). These components stack up to a complexity of less than 50,000 LOC.

Access is defined by capabilities, so if a module is not authorized to access another, it can’t even address (that is: see) it, which is one of the many reasons why capability based authorization is so cool (another one is that it’s not subject to the confused deputy problem, like ACL based access control.)

The general structure.

Incidentally, this structure would also be perfect for running the SAFE vault and the apps, each in their separate little sandbox, but that’s just a small part of the deal: we’d get all of the benefits I outlined on the top of this post as well.

Basically, we could have a single module, small enough to be virtually (or even verifiably) bug-free, to handle our authorization settings, and, as long as this module is intact, we could be sure we are practically invulnerable: nothing could access stuff we didn’t authorize.

So, if the NSA wants to spy on your camera, they would have to target an app with access to the webcam, and even then you could just default to paranoia and tell the camera module to prompt for authorization every time something wants to snap a shot. Even if they stole such a shot, it’s unlikely the camera app would have access to the network stack, right? In fact, it couldn’t even see there’s a network! You want to share something on Instagram? There would be a tiny and verified IG API client module to handle that, with internet access only to the IG servers; no luck for the NSA again.

As a comment, let me note that this idea is a generalization of the “virtual machine”, and as such it can be used (as in: “it’s already implemented”) as a virtualization platform to give access to existing software, running on a variety of operating systems:

Declare Your Independence w/David Irvine - 4/5/2017
What happens during global outages (EMP, solar flareups) and considerations
Web Browser Security - Mitigation v Isolation

There is also ? No idea how this compares but worth noting I suppose.


They are similar in some sense, but quite different in philosophy.

They both try to restrict the trusted computing base in some way (Qubes:, Genode: it’s pretty much the base idea), but Qubes simply splits up the system across use cases (which covers the different security requirements), while Genode operates on the level of tiny, isolated components that build up into a full system. To be fair, Qubes also uses this idea for its networking and storage domains, but it’s Genode that goes all the way.


I forgot to add that they implement their ideas very differently.

Qubes uses full-blown OSes as host and guests on top of a XEN hypervisor which, while good at providing isolation, provides little with regards to access control. Genode, on the other hand, is specifically designed to work with microkernels that implement proper capability based access control.

It’s like comparing Donald Trump’s border policies to international air traffic control.


A small surprise: the Genode guys are well aware of SAFE :scream_cat:


Some of the best news I have read for a long time. That is very exciting indeed. Us coming form the network and that team from the end devices/nodes would be quite a dramatic shake up for pretty much everything. Very very cool to read this.


You know what’s super cool? Reading their release notes I was reminded to the spirit and the professionalism of Maidsafe. They, too, have been working away for the past decade or more in the shadows, quietly building something groundbreaking. They, too, are technically minded folks who try to solve real-life problems around security in a practical, yet non-compromising way, not looking for flash or hacks, but for robust solutions that can pass the test of time. This is really an awesome match; I’m looking forward to see what comes out of it when the two teams get in touch.

I read it in their 16.05 (last May) release note that there’s an initial Rust something for Genode. Might worth checking out.


I knew about Qubes, but Genode was new to me today. Time to research. Thanks for the post.


Please keep us updated from time to time on this interesting project!


Here are some highlights, tailored to this community, from what the developers of Genode find interesting directions to pursue, not necessarily by themselves, but by others who are interested in furthering this project.

As their introduction says:

It is meant as source of inspiration for individuals who are interested in getting involved with the project and for students who want to base their student research projects on Genode.

  • Interfacing with the SAFE network. The SAFE network is an attempt to fix many shortcomings of the internet - in particular with respect to privacy and freedom - at an architectural level. It is intriguing to explore the opportunity of integrating support for the SAFE network not merely as an application but integrated in the operating system, i.e., in the form of Genode components or a set of Genode VFS plugins. (Yes, I already wrote about this, but I couldn’t leave it out from this list.)

  • Android’s ART VM natively on Genode. ART is a Java virtual machine that is used for executing applications on Android. By running ART directly on Genode, the Linux kernel could be removed from the trusted computing base of Android, facilitating the use of this mobile OS in high-assurance settings.

  • Rust bindings for the Genode API. Since version 16.05, Genode supports the use of the Rust programming language within components. However, to unleash the potential of this combination, Genode’s API must become available to native Rust code.

  • Microkernelizing Linux. The goal of this project is the systematic replacement of in-kernel Linux device drivers by Genode processes running in user space, effectively reducing the Linux kernel to a runtime for Genode’s core process. The goal of this project is to evaluate how small the Linux kernel can get when used as a microkernel.


Oh, @Tim87 I just realized that in your original post you added the link to the book, and in fact your version is actually the current one.
So, I am editing this post to update the link to yours.

I am so hyped about it!! The planets are aligning.


Were heading into the Teal level of ‘self organisation’ and the SAFE economy is on time. I’m guessing there is big money that doesn’t want this to happen…exciting but dangerous times.

From the Frederic Laloux study - ‘Reinventing organisations


10 years from now: Skynet
I, for one, welcome our new robotic overlords.


The FOSDEM 2017 vids are finally up. Here’s one about their approach to VFS, which may actually be very relevant to SAFE.

An interesting thing about Genode is that it doesn’t use a global namespace, such as a root directory or global process ids; resources are accessed through capabilities that are addressed by a local id that has no meaning outside the current context.

This may be a problem for POSIX apps (so the system needs to play make believe with them) but it is the natural state for SAFE apps: they access resources through access tokens, and that is the same capability based access control that Genode uses, conceptually.