Jorrit N. Herder

Can we make operating systems reliable and secure

Microkernels long discarded as unacceptable because of their lower performance compared with monolithic kernels might be making a comeback in operating systems due to their potentially higher reliability, which many researchers now regard as more important than performance. Each of the four different attempts to improve operating system reliability focuses on preventing buggy device drivers from crashing the system. In the Nooks approach, each driver is individually hand wrapped in a software jacket to carefully control its interactions with the rest of the operating system, but it leaves all the drivers in the kernel. The paravirtual machine approach takes this one step further and moves the drivers to one or more machines distinct from the main one, taking away even more power from the drivers. Both of these approaches are intended to improve the reliability of existing (legacy) operating systems. In contrast, two other approaches replace legacy operating systems with more reliable and secure ones. The multiserver approach runs each driver and operating system component in a separate user process and allows them to communicate using the microkernels IPC mechanism. Finally, Singularity, the most radical approach, uses a type-safe language, a single address space, and formal contracts to carefully limit what each module can do.

MINIX 3: a highly reliable, self-repairing operating system

Different kinds of people use computers now than several decades ago, but operating systems have not fully kept pace with this change. It is true that we have point-and-click GUIs now instead of command line interfaces, but the expectation of the average user is different from what it used to be, because the user is different. Thirty or 40 years ago, when operating systems began to solidify into their current form, almost all computer users were programmers, scientists, engineers, or similar professionals doing heavy-duty computation, and they cared a great deal about speed. Few teenagers and even fewer grandmothers spent hours a day behind their terminal. Early users expected the computer to crash often; reboots came as naturally as waiting for the neighborhood TV repairman to come replace the picture tube on their home TVs. All that has changed and operating systems need to change with the times.

Failure Resilience for Device Drivers

Studies have shown that device drivers and extensions contain 3-7 times more bugs than other operating system code and thus are more likely to fail. Therefore, we present a failure-resilient operating system design that can recover from dead drivers and other critical components - primarily through monitoring and replacing malfunctioning components on the fly - transparent to applications and without user intervention. This paper focuses on the post-mortem recovery procedure. We explain the working of our defect detection mechanism, the policy-driven recovery procedure, and post-restart reintegration of the components. Furthermore, we discuss the concrete steps taken to recover from network, block device, and character device driver failures. Finally, we evaluate our design using performance measurements, software fault-injection experiments, and an analysis of the reengineering effort.

Construction of a Highly Dependable Operating System

It has been well established that most operating system crashes are due to bugs in device drivers. Because drivers are normally linked into the kernel address space, a buggy driver can wipe out kernel tables and bring the system crashing to a grinding halt. We have greatly mitigated this problem by reducing the kernel to an absolute minimum and running each driver as a separate, unprivileged user-mode process. In addition, we implemented a POSIX-conformant operating system, MINIX 3, as multiple user-mode servers. In this design, a server or driver failure no longer is fatal and does not require rebooting the computer. This paper discusses how we designed and implemented the system, which problems we encountered, and how we solved these problems. We also discuss the performance effects of our changes and evaluate how our multiserver design improves operating system dependability over monolithic designs

Fault isolation for device drivers

This work explores the principles and practice of isolating low-level device drivers in order to improve OS dependability. In particular, we explore the operations drivers can perform and how fault propagation in the event a bug is triggered can be prevented. We have prototyped our ideas in an open-source multiserver OS (MINIX 3) that isolates drivers by strictly enforcing least authority and iteratively refined our isolation techniques using a pragmatic approach based on extensive software-implemented fault-injection (SWIFI) testing. In the end, out of 3,400,000 common faults injected randomly into 4 different Ethernet drivers using both programmed I/O and DMA, no fault was able to break our protection mechanisms and crash the OS. In total, we experienced only one hang, but this appears to be caused by buggy hardware.

File size distribution on UNIX systems: then and now

Knowledge of the file size distribution is needed to optimize file system design. In particular, if all the files are small, the disk block size should be small, too, to avoid wasting too large a fraction of the disk. On the other hand, if files are generally large, choosing a large block size is good since it leads to more efficient transfers. Only by knowing the file size distribution can reasonable choices be made. In 1984, we published the file size distribution for a university computer science department. We have now made the same measurements 20 years later to see how file sizes have changed. In short, the median file size has more than doubled (from 1080 bytes to 2475 bytes), but large files still dominate the storage requirements.

Reorganizing UNIX for reliability

In this paper, we discuss the architecture of a modular UNIX-compatible operating system, MINIX3, that provides reliability beyond that of most other systems. With nearly the entire operating system running as a set of user-mode servers and drivers atop a minimal kernel, the system is fully compartmentalized. By moving most of the code to unprivileged user-mode processes and restricting the powers of each one, we gain proper fault isolation and limit the damage bugs can do. Moreover, the system has been designed to survive and automatically recover from failures in critical modules, such as device drivers, transparent to applications and without user intervention. We used this new design to develop a highly reliable, open-source, POSIX-conformant member of the UNIX family. The resulting system is freely available and has been downloaded over 75,000 times since its release.

Dealing with Driver Failures in the Storage Stack

This work augments MINIX 3s failure-resilience mechanisms with novel disk-driver recovery strategies and guaranteed file-system data integrity. We propose a flexible filter-driver framework that operates transparently to both the file system and the disk driver and enforces different protection strategies. The filter uses checksumming and mirroring in order to achieve end-to-end integrity and provide hard guarantees for detection of silent data corruption and recovery of lost data. In addition, the filter uses semantic information about the drivers working in order to verify correct operation and proactively replace the driver if an anomaly is detected. We evaluated our design through a series of experiments on a prototype implementation: application-level benchmarks show modest performance overhead of 0-28% and software-implemented fault-injection (SWIFI) testing demonstrates the filters ability to detect and transparently recover from both data-integrity problems and driver-protocol violations.

Countering IPC Threats in Multiserver Operating Systems (A Fundamental Requirement for Dependability)

Multiserver operating systems have great potential to improve dependability, but, paradoxically, are paired with inherently more complex interprocess communication (IPC). Several projects have attempted to run drivers and extensions in isolated protection domains, but a systematic way to deal with IPC threats posed by untrusted parties is not yet available in the literature. IPC is fundamental to the dependability of multiserver systems.In this paper, we present a classification of IPC threats in multiserver systems with unreliable and hostile senders and receivers, such as resource exhaustion, spoofing, and unauthorized access. We also introduce an extended asymmetric trust model, describing two new IPC vulnerabilities relating to caller blockage. Based on our classification of IPC threats we present the IPC defense mechanisms and architecture of MINIX 3.