Past and current projects
This is a history of things for which I spent a considerable amount of lifetime.
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:
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:
"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 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
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!
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
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.
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
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
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
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:
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
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
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
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
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
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
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
All the Atari stuff released under the Escape label is available at the