Publications related to 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.