posted by Steffen Liebergeld on Thu 13th Jul 2006 17:26 UTC
IconDROPS is the educational operating system of the Dresden University of Technology, Germany (TU-Dresden). Its name is an acronym for Dresden Real-Time Operating System, which reveals its strongest feature, it is real-time capable and it is designed with security in mind. Its homepage can be found here. Note: This is the 4th entry to our Alternative OS Contest which runs through 14th July!

A bit background about me and how I discovered DROPS

I study computer science in the sixth semester at the TU-Dresden. Since about 7 years, I am interested in new concepts of computer science, especially concerning operating systems. Thus I started using and developing Linux very early and gained knowledge about its workings. I also kept an eye on BeOS, the BSD line, Plan 9 and other operating systems.

In the third semester, we had an introductory course about operating systems where our professor introduced simple things like access rights under UNIX and other general concepts, mentioning DROPS as a side note. Because code and instructions are available on their homepage, I started doing my little experiments with it. Later on, I followed the lectures about microkernel construction and about building operation systems on top of microkernels.

Now I work at the operating systems group developing user-space applications like my shell (littleshell) and a filesystem adaptor called proxyfs that exports L4Linux filesystems into l4env. I will say something about this later on, to give you an understanding how that works.

Motivation and history

We believe the best way to achieve security is to minimize the code one has to trust. The keyword is trusted computing base (TCB), which means that the less code you have to trust, the more secure is your system. To achieve real-time capabilities, we needed to design a system that allows for clear division of its parts. That is why we decided to design a microkernel based operating system.

At that time, there was a big depression concerning microkernels because implementations like Mach showed very poor performance when compared to typical monolithic operating systems of that time.

Luckily, Jochen Liedtke was able to find the problems of those first generation microkernels and designed a platform for new microkernels by further minimizing kernel functionality. This new design, called L4, consists of only 7 different syscalls. The main idea behind it is that everything that can be done in user-space should be done in user-space. Microkernels following that new idea are called second generation microkernels.

We adopted this new design and implemented an operating system with it. That way we are trying to show how great those second generation microkernels can perform, how secure and well designed the operating systems on top of a microkernel can be, how one can add real-time capablities, and how one can use such a basis to create truly secure systems.

System overview

I'll try to keep the technical details aside as long as they aren't needed for understanding, to make this document readable.

DROPS is built around the L4 microkernel Fiasco that was developed at our group. Fiasco consists of only 15k lines of code and is fully preemptable and fast. Fiasco has also been ported to run as a Linux user-level program, which is very convenient for development because you don't have to reboot your system every time, but simply run it as a plain Linux program.

Because we use a second generation microkernel, every bit except of the most basic functionality (everything except addresspace magic, threading, and communication) has to be done in userspace. We call those basic programs servers, each having its own distinct address space (task). However, programming on the raw system while keeping track of all the dependencies is quite difficult, but we have a good solution which abstracts the system for the programmer. The solution is called L4env, the L4 development environment, which makes programming easy.

Of course, DROPS also has means of providing a graphical user environment. Actually, there are two solutions--one being a console that abstracts from the raw framebuffer providing one console per application. The other is DOpE, the Desktop Operating Environment being a server-side-widget-based realtime-capable windowing environment.

DOpE is able to guarantee certain refresh rates to clients and redrawing the remaining widgets whenever there is processing time left. All the redraw operations are started and done by DOpE, so it is not of concern for the client application. DOpE can be easily programmed by using a simple text-based configuration language. It even provides its own command interpreter for easy prototyping. You may learn about it here.

Table of contents
  1. "DROPS, 1/3"
  2. "DROPS, 2/3"
  3. "DROPS, 3/3"
e p (7)    10 Comment(s)

Technology White Papers

See More