Genode OS Framework

Genode is an OS architecture that is able to align highly dynamic workload with security and robustness. I worked out the rough initial design and managed somehow to inspire my dear comrade Christian Helmuth to finalize the architecture and create a reference implementation together with me. Back then, the project was codenamed Bastei. After we left the TU Dresden OS Group, we put forward the project as an open-source community project. On the project's website, you will find our road-map, architectural and technical documentation, community resources and much more: Genode.org website The Genode OS Framework is my current main project. To support the practical application of this OS technology, Christian Helmuth and me started our own company called Genode Labs: Genode Labs company website One interesting aspect of our implementation is the communication framework, which does not employ an IDL compiler but utilizes C++ language features for realizing RPC calls. The framework turned out to be very flexible and fast. Therefore, I conducted a detailed comparison of my approach against the DICE IDL compiler as traditional IDL-based solution: Norman Feske: "A Case Study on the Cost and Benefit of Dynamic RPC Marshalling for Low-Level System Components", (SIGOPS OSR Special Issue on Secure Small-Kernel Systems, 2007)

TUD:OS Live-Demo CD

In March 2006, we at the Dresden operating system research group released a Live-CD of our custom operating system. I worked out the concept of the CD with the goal to combine the live presentation of our research work with infotainment about microkernel-based operating systems in general. The CD features various demo scenarios highlighting different aspects of our work such as our secure graphical user interface, the reuse of legacy drivers, Linux running ontop of our microkernel, and several others. The scenarios had been contributed by several staff members and students. I managed the integration of the scenarios onto the CD, created artwork (desktop background, boot menu image, CD inlay, etc.), wrote the introduction, created a small RAM-disk-based Linux distribution from scratch, did a lot of testing and debugging, and contributed my own demo scenario about my work on secure graphical user interfaces. Furthermore, I created the website including the content management system and graphics and wrote the press releases. For more information about the TUD:OS Live-CD and the ISO CD image, please visit the official Demo-CD website: http://demo.tudos.org.

Scout tutorial browser

Whereas the business a research group should do in the first place is, indeed, research, the right presentation of research results is often of equal importance. For creating more interesting demos of our research OS, I created an interactive tutorial browser that runs directly on our custom OS foundation. The tutorial browser displays a multi-page hyperlinked document (in GOSH format - see below) to explain the demo scenario. The document can contain accentuations, images, nested items, enumerations, verbatim text, and special execute-links for starting external programs. I created the whole display engine including the widget and window handling from scratch. The implementation features some fancy details such as antialiased fonts, a real-time-generated procedural texture that changes while scrolling, smooth acceleration and decelleration of scrolling with automatic decelleration at the boundaries of a page, images with alpha-channel, translucent icons that distort their background with correct refraction as computed by POV-Ray, drop-shadows, and fading icons and hyperlinks on mouse-over. You can see Scout at the center of the screenshot. If you like to give Scout a try, you can check out the TUD:OS Live-CD (see above) and boot right into the Nitpicker demo.

Euterpe

Euterpe is a project of Matthias Alles aka Charon about creating a custom FPGA development board and playing with it. He managed to design, build and assemble the board in his spare time and it actually works! In 2005, Charon invited me to port my windowing system DOpE to a Xilinx Microblaze core running on his Euterpe board. Since then, I became more and more interested in FPGA development and, gracious as Charon is, he lend me the second board that he assembled. Thanks to this opportunity, I am currently learning VHDL using his board. Charon's website http://www-user.rhrk.uni-kl.de/~alles/fpga/ features much more details about this project including pictures of DOpE running on Euterpe.

Nitpicker secure GUI

With Nitpicker, I developed an extreme approach to securing graphical user interfaces. My observation was that Trojan Horses and other GUI-based malware is on the rise while todays commodity graphical user interfaces are incredibly complex and provide no means to protect the user from such threats. Incorporating the missing security into such existing GUIs is near to impossible because that would mean to sacrifice compatibility and convenience of todays GUIs while taking a huge development effort. Nitpicker does to such 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. Furthermore, Nitpicker addresses the problem of securely labeling screen regions and it is designed to be resistent against denial-of-service attacks. I implemented Nitpicker on L4/Fiasco and enabled DOpE, my own window system, to run ontop of Nitpicker. I also implemented the drivers and infrastructure to integrate the X-Window system (running on L4Linux) into a Nitpicker session. The nicest property of Nitpicker however, is its extremely low source-code complexity of just 1,500 lines of code. These are very good news, especially when the complexity of the TCB (Trusted Computing Base) becomes a crucial point. If you are interested in learning more about Nitpicker, you may take a look at the following paper: Norman Feske and Christian Helmuth: "A Nitpicker's guide to a minimal-complexity secure GUI", (In proceedings of the 21st Annual Computer Security Applications Conference (ACSAC 2005), Tucson, Arizona, USA, December 2005) You also can try it out at home by booting the TUD:OS demo CD! http://demo.tudos.org The interactive presentation of Nitpicker is second boot entry of the CD.

MikroSINA Cebit Fair Demo

In 2004, I was working for the Mikro-SINA project, which was about building a microkernel-based VPN gateway implementation and comparing our architecture against state-of-the-art Linux-based VPN gateways. At the last period of the project, we presented our results at the Cebit'04 fair. For demonstrating our implementation, we presented a graphical model of the system architecture on the screen of the machine that was running our VPN software stack. Rather than presenting just a static picture, the model reflected the actual system state. For example, the flow of network packets through the system was visualized by moving dots of different colors depending on whether the packets are encrypted or plain data. Additionally, the model could be used as an interactive configuration tool to manage the system behaviour in runtime and observe the changes from the outside (via network sniffing software). I designed and implemented the interactive presentation engine that runs directly ontop of DOpE (see below). For creating the artwork, I used POV-Ray and some scripting magic. The actual Mikro-SINA presentation consists of 480 animation snippets that are composed in real-time, based on the current system state. Apart from building the presentation engine, I also used POV-Ray for creating the project's official poster. The poster is implemented in ca. 1,600 lines of POV code. For more information about the technical side of the Mikro-SINA project, I refer you to the following paper: C. Helmuth, A. Warg, and N. Feske: Mikro-SINAHands-on Experiences with the Nizza Security Architecture. (In Proceedings of the D.A.CH Security 2005, Darmstadt, Germany, March 2005)

FLIPS - Flexible IP Stack

FLIPS started as an experiment. In 2003, Krishna and me wanted to find out if it is possible to run the TCP/IP stack of Linux without erm... indeed Linux. Ripping such a huge subsystem out of the Linux kernel and making it work in another execution environment sounds weird, doesn't it? It is even more weird that it actually works! After one week of intensive hacking, we successfully ran FLIPS on the L4 microkernel and sent network packets through the loop device. Our approach was to provide as much environment to the IP stack as it needs to feel quite at home but to make no changes on original files at all. Of course, the Linux IP stack was never meant to be used without the Linux kernel and thus, we had to face numerious problems, for example emulating the sysctl and proc interfaces that are used to configure the IP stack under Linux, exporting the socket interface via L4 IPC, emulating the control flow inside the IP stack, and providing the right initialization sequence for the different subsystems. I also implemented a couple of test programs, for example a minimalistic HTTP server, and ported parts of the GNU nettools to our system. Sometimes, experiments like this survive much longer than expected. Today, FLIPS is used by our group as well as other research groups when a native TCP/IP stack on L4 is needed.

Object Dive

Understanding software projects consisting of a large number of source files is difficult. It gets even harder when the software is highly compile-time configurable as it is the case for the Linux kernel. In preparation of the FLIPS project, I studied the Linux TCP/IP stack closely and tried to understand the relationship of its components. For analysing the dependencies of the involved software components from each other, I created Object Dive. With the help of binutils, especially nm, Object Dive extracts symbol information from each object file and creates a directed reference graph. Each arrow of the graph expresses a reference relationship (e.g., function calls), the higher the number of different references - the bolder the arrow. A bold arrow usually indicates a very strong dependency of the originating component from the targeted component. The graph can be freely arranged by dragging nodes with the mouse. Once, a nice-looking graph is created, Object Dive can save the result as postscript or dot file. I also added support to display the symbol-referencing position in the source code when a symbol is selected with the mouse. For this, I created a small expect script for remote-controlling the VIM editor from Object Dive. Object Dive is available as GPL: http://os.inf.tu-dresden.de/~nf2/files/Objdive

Atari Coldfire Project

Atari suspended the development of home computers in 1995 leaving a not-so-bright future for fans of Atari home computers as I am. Several Atari clones had been announced by different developers but in 2002, none of these project were active anymore. For this reason, the Atari Coldfire Project was started. Initially, a lot of developers had been involved and I volunteered to create the website for the project. At the end of 2003 however, the number of active developers had shrinked to only two - Jens Klietz doing hardware design and me doing software development. Jens created a first prototype board while I focused my work to OS software development on a Motorola evaluation board. I created drivers for the Cypress PCI bridge, different types of graphics cards (ATI Rage, Matrox), and a Wacom Artpad. Based on these drivers, I ported my DOpE windowing system to this platform and conducted a series of other experiments. I documented my work on this project in the following document: My life with the MCF5407 Coldfire Board The project is still not finished but slowly progressing. Despite our initial goal to provide an Atari compatible computer to a broad number of people got a bit out of sight, we still devote our efforts to our vision of a custom hardware and software platform. Official website of the Atari Coldfire Project

MiNT kernel on an embedded Coldfire board

As the Atari Coldfire Project aims to create an Atari compatible computer, we need to run an Atari TOS compatible operating system. MiNT is an alternative OS kernel for Atari computers that is largely compatible to the original TOS but much more UNIX-like. The best thing about MiNT is that it is free software being still actively developed. Hence my decision in porting the MiNT kernel to the Coldfire platform. My approach was leaving the MiNT kernel as unmodified as possible and run it in an execution environment that looks like an Atari from MiNT's perspective. This execution environment consists of three parts, an MC68k compatible virtual CPU as provided by the cf68Klib, the emulation of the Atari platform (e.g., Timers, VBL), and BIOS services that MiNT relies on (e.g., I/O during bootup). After weeks of tracing the MiNT kernel code by hand and building up the execution environment step by step, I managed to boot up the MiNT kernel completely, and to issue commands to the built-in MiNT shell, browsing the file system, creating directories, etc. This means MiNT including its multitasking facilities is running happily on the Coldfire CPU. However, a lot of things such as VDI/AES support and drivers for block devices and network are still missing. My source code of this work is available as GPL at my public subversion repository: http://os.inf.tu-dresden.de/~nf2/svn

GOSH Usenet-style LaTeX frontend

GOSH is a tool, which takes an Usenet-styled ASCII text as input and generates Latex-code, HTML, or Man-pages. This way, you can create a PDF of your text document or create even a fancy Website. The primary goal of GOSH was to spare me the syntactical mayhem of LaTeX while enabling me to use my favorite text editor when I wrote my diploma thesis. The concept of having a plaintext frontend to LaTeX turned out to make my textual work much more productive. I use GOSH for all my publications, web content management, readme files, and any other textual work. It is useful for me, so it may be useful for others. Therefore, I released GOSH as GPL. In the meantime, quite a few members of our research staff and students use GOSH on a regular basis. You can download the latest version of GOSH here: http://os.inf.tu-dresden.de/~nf2/files/GOSH/

Overlay Window Manager

When using multiple operating systems with their legacy GUIs on one machine simultaneously, the classical mode of user interaction is having virtual consoles or displaying a complete desktop of a guest operating system within one window of the host operating system. This classical approach does not scale very well with the number of used OS instances and such nested windowing systems are quite inconvenient to use. I developed a different solution for this problem that lets us integrate any number of window systems into one and the same desktop and deal with the windows of all running legacy GUIs in a natural way. I conducted my first experiments with this techniqe (that I call overlay window management) on the basis of my DOpE window server. The screenshot displays three window systems merged on one screen: the DOpE windowing system, the XFree86 X window system running on L4Linux, and the Atari GEM window system running in the Hatari emulator that I ported to L4. In my further GUI-related work, the overlay window management technique continued to play an important role. It is one key feature of Nitpicker (see above). The following paper describes the overlay window management approach in more detail: N. Feske and C. Helmuth: Overlay Window Management: User interaction with multiple security domains. (TU Dresden technical report TUD-FI04-02, March 2004)

DOpE real-time window system

Since 1997, I am experimenting with graphical user interfaces. During the years, I created several windowing systems for my Atari-related projects (e.g., for the Modulation-III demo and Whip!). When I went to the TU Dresden operating systems group to write my diploma thesis, I proposed to create a real-time-capable window server for the DROPS operating system. I called the result of this experiment DOpE (Desktop Operating Environment). Thanks to DOpE's sophisticated local scheduling of drawing operations, any output on screen and user interaction have a bounded latency. Furthermore, graphical hard-real-time applications are able to reserve a fixed amount of bus bandwidth to the graphics hardware. Aside from the real-time aspects, DOpE has several other interesting properties: The client-interface of DOpE is, similar to the concept of Tcl/Tk, based on textual command strings. This concept is great for debugging and rapid prototyping. DOpE provides a low-footprint server-side widget implementation providing buttons, images, scrollable frames, grid-layout, load displays, etc. Thanks to platform-independent design right from the beginning, it is a breeze to port DOpE to different hardware and OS platforms. I ported DOpE to Linux (using libSDL), the Atari Falcon, an embedded Coldfire evaluation board, and a custom XilinX FPGA board (using Microblaze), built by Matthias Alles. The screenshot displays a version of DOpE with some experimental features such as drop shadows and translucency (on the cost of sacrificing some real-time properties of the original implementation). The DOpE experiment was quite successful. It formed the basis for further research of our group, numerious live demonstrations, and the TUD:OS demo CD. In 2003, I presented DOpE at the Real-time Systems Symposium in Cancun/Mexico: N. Feske and H. Härtig: Demonstration of DOpE, a Window Server for Real-time and Embedded Systems. (In Proceedings of the 24th IEEE Real-Time Systems Symposium (RTSS 2003), December 2003, Cancun, Mexico) Technical report featuring more details For learning more about DOpE, I refer you to the official DOpE website. Since I developed the DOpE server, I created a bunch of DOpE client applications as well, for example VScrTest (a graphical demonstration of DOpE's real-time features), Proxygon (a console implementation), Dopecmd (an interactive rapid-prototyping tool), Hatari-port (Atari emulator, ported via libSDL - thanks to Thomas Friebel's DOpE-port of libSDL), Minitop (simple top for L4/Fiasco), Textedit (very basic text displayer/editor), Overlay Window Manager (for support of X11 applications), L4Linux console stub, and several other toys.

VNNlab

VNNlab is an experimentation platform that I developed as part of a student research project at the institute for artificial intelligence and image processing. My idea was to apply neural network techniques to the domain of stereo analysis to create a 3D polygon model from a pair of stereo images. My reasoning was as follows: The estimation of the depth of a point on one picture is based on the horizontal displacement of its corresponding point in the other picture. When automating such an estimation, the biggest problem is to actually find "corresponding" points in both images. A lot of pixels in natural pictures are worthless for such an estimation, for example pixels of planar surfaces. I focus my attention to the "interesting pixels", for which a good estimation is likely. First, the interesting pixels are determined by filtering one source image using an edge-detection filter (Sobel) and applying a treshold. Now, we have a discrete set of points that are interesting but we want to go for a 3D polygon model. For this reason, we let a vector-based neural network learn the interesting points - in fact, we want the network to imitate the discrete distribution in a way that all network vertices are placed at interesting points only. I implemented different algorithms for the learning process, for example k-means, learning vector quantization, neural gas, and simulated annealing. Now that we have the network vertices representing the interesting points of our source image, we can create a contiguous, beautiful mesh using delaunay triangulation. The depth estimation needs only to be performed for the vertices - only a few points for which we can afford to apply powerful disparity evaluations. I implemented some standard algorithms such as intensity-based (block matching, Shirai, cross correlation) and color-based methods. The best result for natural images however, produced a custom algorithm that uses local texture-parameters (the fast-fourier-transformation coefficients of small blocks). Finally, VNNlab visualizes the result via OpenGL (2D mesh, 3D mesh, 3D textured mesh). VNNlab features a plug-in architecture. algorithms can be exchanged in runtime and the parameters of algorithms can be modified live while the algorithm is working. VNNlab including my seminar paper (german) is available here: VNNlab download Other things that I created at the institute for artificial intelligence such as Linux driver support for stereo head equipment are available here: AI stuff

DSP56k 3D Engine

My most adventurous and most exciting coding experience so far was creating a 3D engine that runs completely on a DSP56001. The primary motivation for doing this was to create cool and fast demo effects on the Atari Falcon. On this machine, built in the year 1992, the DSP, originally intended for audio processing, clearly outperforms the MC68030 CPU in terms of raw computational power. First, I created a small operating system for managing the control flow inside the DSP from the host and for loading new code and data into the DSP while the audio mixer (running in the DSP interrupt context) continues to play music. Then I started doing 3D transformations, polygon sorting, clipping, scanline rendering, and finally real-time 3D model generation (e.g., a fractal tree, morphing 3D IFS fractals) directly on the DSP (some examples). Later, I experimented with using the DSP's 32Kword memory as frame buffer and applying 2D postprocessing (e.g., real-time blur with varying filter size, feedback effects) onto the result of the 3D renderer and performing subpixel-interpolation in the DSP wait cycles of the data transfer loop to the host CPU. So why was this such an exciting thing to do? Because living with the limitations of the DSP, dealing with its idiosyncrasies (fractional arithmetic, modulo address logic, pipeline effects, dealing exlicitely with three independent busses, crazy memory layout, hardware loops, the unique instruction performance profile), and letting the DSP cooperate nicely with the CPU is rewarded by absolutely exciting performance. The DSP enables the Atari Falcon to fly like a rocket!

Whip! virtual light machine

The CD-ROM drive of the Atari Jaguar 64bit game console featured a great software called Virtual Light Machine that created visual effects when an audio CD was played. The effects were actually modulated after the music. I really admired this stuff but I did not own a Jaguar. So I created my own virtual light machine, called Whip!, for the Atari Falcon 030. The DSP featured in the Atari Falcon could be used for both, the sound processing as well as effect computations. Most of the effects that I created for Whip! have their origin in various of my demos. I spent a lot of effort in the development of dedicated sound analyzing routines for the different effects with the result of pretty good responsiveness. Thanks to the very low latency of the DSP in sound processing, the effects really dance to the music. Depending on the effect, the sound analysis is based on FFT, various filters, and home-brewed dynamic-detection algorithms. Whip! provides a plug-in interface so that other developers can produce own effects. This feature proved to be quite successful. Actually. there exist more Whip! effect modules developed by other people from the Atari scene than by myself. For more information on Whip!, the available effect plug-ins, download, and the documentation of the plug-in interface, you may visit the official Whip! website.

Escape Paint

When in 1993, the Atari Falcon with its unique graphics capabilities arrived, I wanted to create a game. Unfortunately, there was no art package available that enabled the use of the colorful Falcon graphics modes - so I decided to create Escape Paint, a high-color graphics program especially suited for pixeling work for games and demos. Escape Paint features lots of different zoom types, a very fast workflow, powerful block handling functions, and lots of functions that are essential for pixel artists, for example real-time keyboard-triggered modification of the drawing color while drawing. Escape Paint also features a quite powerful plug-in interface, for which a lot of effect modules, loader modules, and export modules are available, for example color filters, masked alpha-blending, distortion effects, bump mapping, high-quality scaling, and a lot more. Numerious very cool modules had been contributed by other programmers, especially by Dynacore/.tSCc. - this collaboration was just exciting! For about four years, Escape Paint was my main project. While my friends from school played soccer outside, I sat inside, programming recursive floodfill routines in assembly. When looking back, not having played soccer was right. Escape Paint is available at the Escape Paint website. By the way, I never finished the game.

Atari Falcon Demos

Before I joined the OS group, my most enthusiastic hobby was creating visual effects on the Atari Falcon 030 and combining them with the great music composed by my dear brother Nils. I founded the Atari Demo group "Escape" and created quite a few demos, intros, and music compilations. In the Atari Falcon 030, the MC68k CPU was complemented by a DSP56k that was originally intended to perform audio processing. It turned out that the DSP was far more powerful than the CPU, which made the DSP very attractive for implementing graphical effects as well. Exploiting the power of two so radically different parallel-running processors to the max turned out to be a thrilling experience. My personal highlight was creating a demo called "Hmmm...". I coded this demo from scratch during five weeks, working night-and-day while Nils composed the music. Of course, the demo looks best when running on real hardware, but there is an AVI video available too. All the Atari stuff released under the Escape label is available at the Escape Website.