Introduction into TUD:OS

Welcome to the Demo-CD of the OS Group of the TU Dresden. For more than a decade, our group researches and develops experimental operating systems with the focus on real-time and security. We compiled this Demo-CD to present our work and to share our experimental results with you.

The Demo-CD features various demo scenarios, which highlight different aspects of our work. However, all scenarios share the common principle of a microkernel-based system architecture.

Most of todays operating system kernels, for example the Linux kernel, are a highly-complex pieces of software that contains everything needed to manage resources (e.g., memory), access the hardware, store information on a file system, handle network packets, and control user processes. Therefore, such a kernel requires the privileges to control the whole machine. The following figure illustrates such a (monolithic) operating system kernel.

The high functional requirements and the broad range of existing hardware let such a kernel grow huge. Users expect different network cards to be supported, different file systems, a wide variety of network protocols, and a lot more. Consequently, a typical Linux kernel contains far more than 500,000 lines of code. It is impossible to fully avoid bugs and security leaks at a system of such scale. Bug-prone code in the kernel can corrupt the proper operation of the whole system and thus, can impose fatal consequences. As illustrated in the following figure, a broken network driver can corrupt the whole operating system.

With virtual address spaces, modern operating systems and hardware platforms provide mechanisms to isolate concurrently running user applications. Each user application runs within a dedicated address space and interact in a safe, well-controlled manner with other user applications only via mechanisms provided by the kernel. This way, the kernel effectively protects user applications from each other.

Microkernel-based systems use these techniques not only for user applications but also for device drivers, file systems and other typical kernel-level services. Therefore, the effect of a bug-prone component is locally restricted. The minimal-complexity microkernel withdraws all non-needed privileges from each component. The application of the microkernel approach shrinks the overall complexity of program code running in privileged mode by an order of magnitude. Our microkernel L4/Fiasco is implemented in only 20,000 lines of code. The following figure illustrates this approach:

All components are protected from each other by address spaces. Thus, one component cannot inspect or corrupt other components without authorization. Communication between components can only happen by using communication mechanisms provided by the microkernel. If one component of the system gets corrupted by a bug or an attack, the fault is locally restricted to the broken component.

Furthermore, the microkernel enforces CPU time scheduling and can grant guaranteed processing time to user processes. No depriviledged system component is able to violate such guarantees. Therefore, we can execute time-sensitive applications and large untrusted applications (and even whole operating systems) side by side on one machine.

After this short introduction, we wish you a lot of fun trying out our demo configurations. Simply pick the different entries of the boot loader menu.

Reboot the machine

Click here (in the Demo-CD version of this document) to reboot your machine.