Publications related to Genode

Slides, FOSDEM 2012, Brussels, February 2012

Today's operating systems try to find a balance between seemingly conflicting goals. Ease of use is traded against security, resource utilization is traded against resource accountability, and system complexity is traded against scalability. For example, SELinux is ill famed as hard to use and consequently remains widely unused. As another example, isolation kernels minimize the complexity of critical system software but at the cost of limiting these solutions to static applications.

The Genode OS architecture shows how these apparently inherent conflicts can be solved by operating-system design. By combining a recursive system structure with capability-based security, mandatory access control becomes easy to deploy. At the same time, the trusted computing base can be minimized for each application individually such that the attack surface for security-critical system functions gets reduced by orders of magnitude compared to existing approaches. Furthermore, a concept for trading physical resources among processes allows for dynamic workloads while maintaining quality of service. That is not just theory - the system is ready for demonstration and its developers are planning to use it as development environment by the end of 2012.

The talk is focused on the OS architecture and gives a glimpse at the implementation via live demonstrations. Finally, it briefly discusses the planned steps towards using Genode as general-purpose OS.

Slides, FOSDEM 2012, Brussels, February 2012

One shiny aspect of the Genode OS framework is its diversity with respect to microkernels and hardware platforms it's running on top of. Although primarily of interest to clients and users, this property provides some hidden benefits to the system-developer itself. This talk is an experience report. It gives you an insight into the benefits and troubles of developing on a diverse biotope, the strength and weaknesses of the available platforms, how Genode gets ported to a kernel, and what is basically necessary from the kernel's perspective to drive Genode.

TU Dresden technical report TUD-FI06-07, Dresden, Germany, December 2006

Genode's ancestor is the Bastei experiment. This paper depicts the challenges and the architectural design of Bastei, as well as the basic building blocks (e.g., RPC, heap partitioning). We also emphasis the importance of a small application-specific Trusted Computing Base (TCB) and its positive impact on system security and reliability. An updated version of this document is available from the documentation section on this webpage.

First release March 2006

The demo CD was our effort to give the public an understanding of more than a decade of OS research at TU Dresden. The interactive demos are executable on any standard PC.

Diploma thesis, Dresden, October 2006

In his thesis, Stefan Kalkowski brings together the abstract Nizza ideas, the experimental L4.sec microkernel, and the Bastei OS architecture. He describes how hierarchical security policies can be implemented leveraging Bastei's system structure. The example use case is a consolidated server for a small company with internal CMS with some public objects, mailing, and web server.

CollaborateCom 2005, San Jose, California, USA, December 2005

The Nizza architecture aims at systems with a drastically reduced TCB for security-sensitive applications. The basic building blocks are microkernels, kernelization and legacy software reuse via trusted wrappers.

Proceedings of the D.A.CH Security 2005, Darmstadt, Germany, March 2005

During Mikro-SINA project, our group implemented a microkernel-based VPN gateway and made first experiences with kernelization and trusted wrappers. At the bottom line, the TCB of our IPSec ESP implementation comprises about 50,000 lines of code and, thus, it is at least one magnitude lower than comparable solutions based on, e.g., Linux.

SIGOPS OSR Special Issue on Secure Small-Kernel Systems, 2007

The TCB concept only covers code that is executed on the target platform, but programmers also trust their programming tools, e.g., compilers. In our microkernel-based research project, a significant amount of complexity derived from our custom IDL compiler, which was reflected in additional maintenance costs and IDL-specific bugs. This paper raises and answers the questions if an IDL compiler can be removed from the set of required tools.

Student research project, 2008

For many non-trivial software projects, the build infrastructure is an important concern. In his paper, Ludwig Hähne pursues the question of which build system to choose for an operating-system project such as ours. For his study, he took the Genode build system as a real-world use case. His results are not only valuable for our particular project but for everyone with an interest in build systems.

Dissertation, TU Dresden, February 2009

Malware such as Trojan Horses and spyware remain to be persistent security threats that exploit the overly complex graphical user interfaces of today's commodity operating systems. Current GUI architectures have to find a balance between the four conflicting goals of maintaining compatibility to existing applications, providing quality of service, operating at high performance, and of being secure, whereby the latter goal still remains widely disregarded by mainstream GUI architectures. The challenge of Norman Feske's work was to resolve the conflict. He developed key techniques and substantiated the concepts by a number of exhaustive experiments. The resulting architecture consolidates the advantages of extremely low source-code complexity, full client isolation, protection against spyware and Trojan Horses, bounded output latency, and compatibility to existing applications into one GUI-server design.

Proceedings of ACSAC 2005, Tucson, Arizona, USA, December 2005

Nitpicker applies the concept of minimal TCBs to GUIs and does to legacy GUIs what a hypervisor does to legacy operating systems. It virtualizes the frame buffer output and user input in a way that enables the user to execute any number of windowing systems at the same time, displayed on one and the same screen while keeping those windowing systems completely isolated from each other.

Proceedings of RTSS 2003, Cancun, Mexico, December 2003

The Desktop Operating Environment (DOpE) is a window server with sophisticated local scheduling of drawing operations and, therefore, any output on screen as well as user interactions have a bounded latency. Furthermore, graphical hard-real-time applications are able to reserve a fixed amount of bus bandwidth to the graphics hardware. This paper is an extended abstract of the original technical report.

TU Dresden technical report TUD-FI04-02, Dresden, Germany, March 2004

This paper details the integration of multiple isolated legacy window systems against the background of security-sensitive applications, e.g., compartmented workstations.