If you are in Germany, the country of Sauerkraut and Beethoven, and you move far to the east, you might arrive at the town of Dresden. In this city, the Dresden University of Technology (TU Dresden) is located, which’s operating systems group has developed a C++ implementation of Jochen Liedtkes well-known L4 u-kernel interface. This microkernel, ironically called Fiasco, is the center of all the different projects of the TU Dresden Operating System (TUD:OS) research group.
A small guy you can trust is the master of them all
In contrast to a monolithic kernel OS like Linux, in a microkernel-based system, only that functionality is placed in the kernel, which requires the privileged kernel mode of the processor. All the other code – which would be implemented according to a monolithic design in the kernel as well – is executed by so-called server tasks in the CPU user mode. That means, the server tasks are not able to access the memory of the computer directly but only via virtual address spaces, whereas the translation from virtual to physical memory addresses is controlled by the kernel. By this concept, the lines of code you have to trust – because they run in kernel mode and therefore have uncontrolled access to your computers hardware – is reduced to a minimum amount. For this reason, a microkernel-based architecture is ideal for building highly secure operating systems as well as extremely reliable real-time systems. Both is done in research projects at the TU Dresden.
In a monolithic OS design, a lot of functionality is placed inside the kernel, which does not necessarily require the privileged kernel mode of the CPU.
Out of theory – a demo CD!
But let’s put theory aside and get to the point! To make the outcome of their research easier accessible to the non-OS-research public, on March 13th, 2006 the TU Dresden OS group has published a demo live CD, which is the one that should be grilled here. But what does the demo CD of this TUD:OS – which is rather a collection of many research projects than a complete desktop operating system – provide? When you put the CD into your computer and reboot your machine, a GRUB boot loader appears, offering different demo setups, each presenting a specific research result to you. In all of these scenarios, you will find a tutorial browser called Scout supplying information leading you through the whole tutorial.
Scenario 1: A Nitpicker’s guide to a minimal-complexity secure GUI
The first of these GRUB entries guides you to a minimal-complexity secure GUI called Nitpicker. The idea behind Nitpicker is assigning the microkernel principle to GUI development: having an extremely small host GUI, Nitpicker, providing only the absolute minimum of functionality and running then different guest GUIs on top of it – for instance the L4-native window system DOpE or an conventional X-Server. With the Nitpicker host GUI you can securely supervise the behavior of your guest GUIs and in addition let run many applications of these guest GUIs completely protected from each other on the same system. Extremely challenging about the thing is the fact that all of the guest GUI’s windows are integrated into the Nitpicker desktop as if they were native Nitpicker applications. Without a system like Nitpicker the development of secure GUI applications hardly would be possible. Because, what is the point of having a microkernel protecting address spaces while applications can spy on one another via an insecure GUI server?
By a microkernel-based architecture the number of lines of code you have to trust is reduced to a minimum amount. For this reason, it increases the security and stability of your opearting system. In addition, it makes a much more flexible and modular OS design possible.
In the Nitpicker scenario of the demo CD, you can check out how it feels to run a native Nitpicker application, the Scout tutorial browser, DOpE and X-Window applications on the same Nitpicker desktop. Furthermore it lets you experience several practical proofs that Nitpicker keeps its promises – for instance by invoking the X-Window “spy ware” xeyes and trying to spy out a DoPE application or the Scout tutorial browser with it.
Scenario 2: Qt for the L4 Environment
In the second scenario, the Qt port to the L4/Fiasco microkernel is presented. Qt is a wildly-used open source GUI-toolkit and builds for example the base of the K Desktop Environment (KDE). The port is fairly complete and makes it possible to run many Qt applications natively on L4. To demonstrate this feature, you can watch pictures with the Qt image viewer QVV or play the freaky Qt-based game Little Sheep in the tutorial.
With the GRUB bootloader of the TUD:OS live CD you select one of the diffrent demo setups you want to try out.
Scenario 3: L4Linux – A virtualized Linux on a componentized, small kernel system
A development, which impresses me very much is the L4 adaptation of the Linux kernel in a way that it can be executed as a L4/Fiasco user task. This adjusted L4Linux is binary compatible with the common Linux/x86 kernel and facilitates running Linux programs without any changes in parallel with highly secure L4 applications or real-time tasks with time constraints to be guaranteed. Of course, you can also run many L4Linux instances one your system, which all cannot influence each other since every user task has its own secure address space.
Unfortunately, the L4Linux instances you can invoke in this tutorial do not come with a rich set of features (it is indeed only a command line with nothing more to do) and hence the whole scenario is a little bit boring.
Scenario 3: Driver Reuse In The L4 Environment
If you want to develop a new operating system, it would be extremely annoying to rewrite all the drivers you need for you new OS from the scratch. Therefore, the TU Dresden OS group members decided to develop a Device Driver Environment (DDE), which equips the L4/Fiasco microkernel with a driver interface wrapper to legacy OS’ driver interfaces. This approach facilitates the reuse of unchanged legacy OS device drivers on source-code level. A DDE exits for Linux device drivers and the work on a FreeBSD DDE is already in progress.
A screenshot of the Nitpicker running the Scout tutorial browser, some DOpE real-time applications and the X-Window fun tool xeyes.
The rest is silence
The last two scenarios, L4VFS – L4 virtual file system layer and Trusted E-Commerce Transaction Client, shall be mentioned for the sake of completeness but are not explained here, because in my opinion they are the less interesting ones.
And now: The Evaluation
The most stunning thing about the TUD:OS demo CD to me is that you have the Scout tutorial browser explaining to you all the theoretical matters of the particular project and then – if you want to experience the things you have learned about – you simply can click on the browser and the application that was talked about will show up.
Another thing I was quite surprised of was the fact that the demo live CD worked without any problems on my laptop immediately and on all the computers that I tried to run the CD on – just as you would expect it for example from a Knoppix live CD. I suppose this success could be attributed to the DDE driver reusing approach.
The main aspect I did not like about this demo CD was, as already explained, the practical part of the L4Linux tutorial.
Due to the L4 port of the Qt graphics library many Qt applications can be run natively on L4/Fiasco.
Conclusion
But please let me have some concluding words about the TUD:OS as a whole system. The way I see it, to a normal desktop computer user, the results of the TU Dresden OS group’s research process might be exciting – but they are completely useless for him in most of the cases. Whereas for a developer who wants to realize dependable real-time projects or highly secure applications, maybe even working together with conventional Linux software on the same system, the TUD:OS could be a rich pool of features on which he could base his project upon.
But if however the L4 port of the long awaited GNU/Hurd operating system will ever see its daylight and become a widespread and usable home user system, the TU Dresden OS group’s developments would highly appreciate in importance in that way they could be directly used in a home desktop operating system then.
Links:
http://demo.tudos.org – Demo-CD website
http://www.tudos.org – TU Dresden OS group
http://tudos.org/L4/LinuxOnL4/ – L4Linux website
Remark: All the software of the TUD:OS projects is free software under the terms of the GNU GPL.
About the author:
I am a student of information systems technology (interdisciplinary course of studies consisting of computer science and electrical engineering) at the TU Dresden but I am not involved in any of the TUD:OS’ projects right now.
which are often forgotten about microkernels…
The first one is that in reality, you have to trust more than only the kernel. A bug in the disk driver can very well crash the whole system. Sure, it cannot overwrite data in other processes directly. But it doesn’t have to – in fact, other processes *ask* the disk driver to transfer *their* data. Do these OSes check all data from the disk driver for integrity? And how do they make sure that data is written when the driver says so? I can continue the list of possible problems endlessly here.
Lesson #1: Safety, security, stability and similar features are more than isolating processes against each other.
The second issue is that all processes run in parallel. This mixes up the order of events during processing, very much like IP packets get reordered on their way to a remote computer. The results are nondeterministic, and thus unpredictable. The once-so-simple code has to be modified to make it possible to enforce a certain order in actions. This is in sharp contrast to the goals a microkernel tried to achieve: Lots of simple and maintainable modules, glued together to create a working whole.
Lesson #2: If you couple modularity with concurrency, you are begging for problems.
I’m not rooting for or against microkernels, but here are my thoughts on your points:
The first one is that in reality, you have to trust more than only the kernel. A bug in the disk driver can very well crash the whole system. Sure, it cannot overwrite data in other processes directly. But it doesn’t have to – in fact, other processes *ask* the disk driver to transfer *their* data.
Everyone should know that a microkernel does not itself ensure that code is trusted, or that code does not need to be trusted, or that flaws in code will have no serious impact. All that is ensured, is that memory and resources will be compartmentalized between drivers. However, some people do seem to (erroneously) imply that microkernels make the kinds of guarantees you described! But of course this aspect of microkernels, while having many benefits, is still a far cry from being a silver bullet.
The second issue is that all processes run in parallel. This mixes up the order of events during processing . . . The once-so-simple code has to be modified to make it possible to enforce a certain order in actions. This is in sharp contrast to the goals a microkernel tried to achieve: Lots of simple and maintainable modules, glued together to create a working whole.
Once again, some people can be seen as implying that microkernel systems are dramatically simpler than monolithic systems, which is a misconception. What is mentioned above is indeed one of the major caveats in implementing a microkernel. However, there are solutions to this problem, that keep things relatively simple once implemented. The real problem is that its hard to avoid taking very significant performance penalties when solutions to synchronization issues are implemented. IIRC, the Hurd had this problem, and is trying to curtail such performance penalties by tailoring their system specifically for Intel x86 architectures.
Thanks for your reply. I should have said that these problems are not fatal, and they do not make use of a microkernel impossible or even impractical. One just has to be aware of them.
I thought this article was about Windows. Then I realized it wasn’t about TURD but TUD.
Silly Me.