In the software world, high complexity of a problem solution comes along with a high risk for bugs and vulnerabilities. This correlation is particular perturbing for todays commodity operating systems with their tremendous complexity. The numerous approaches to increase the user’s confidence in the correct functioning of software comprise exhaustive tests, code auditing, static code analysis, and formal verification. Such quality-assurance measures are either rather shallow or they scale badly with increasing complexity. The operating-system design presented in this paper focuses on the root of the problem by providing means to minimize the underlying system complexity for each security-sensitive application individually. On the other hand, we want to enable multiple applications to execute on the system at the same time whereas each application may have different functional requirements from the operating system. Todays operating systems provide a functional superset of the requirements of all applications and thus, violate the principle of minimalism for each single application. We resolve the conflict between the principle of minimalism and the versatility of the operating system by decomposing the operating system into small components and by providing a way to execute those components isolated and independent from each other. Components can be device drivers, protocol stacks such as file systems and network stacks, native applications, and containers for executing legacy software. Each application depends only on the functionality of a bounded set of components that we call application-specific trusted computing base (TCB). If the TCBs of two applications are executed completely isolated and independent from each other, we consider both TCBs as minimal. In practice however, we want to share physical resources between multiple applications without sacrificing their independence. Therefore, the operating-system design has to enable the assignment of physical resources to each application and its TCB to maintain independence from other applications. Furthermore, rather than living in complete isolation, components require to communicate with each other to cooperate. The operating-system design must enable components to create other components and get them to know each other while maintaining isolation from uninvolved parts of the system. First, we narrow our goals and pose our mayor challenges in Section 1. Section 2 introduces our fundamental concepts and protocols that apply to each component in the system. In Section 3, we present the one component that is mandatory part of each TCB, enables the bootstrapping of the system, and provides abstractions for the lowest-level resources. We exercise the composition of the presented mechanisms by the means of process creation in Section 4.

In the software world, high complexity of a problem solution comes along with a high risk for bugs and vulnerabilities. This correlation is particular perturbing for todays commodity operating systems with their tremendous complexity. The numerous approaches to increase the user’s confidence in the correct functioning of software comprise exhaustive tests, code auditing, static code analysis, and formal verification. Such quality-assurance measures are either rather shallow or they scale badly with increasing complexity. The operating-system design presented in this paper focuses on the root of the problem by providing means to minimize the underlying system complexity for each security-sensitive application individually. On the other hand, we want to enable multiple applications to execute on the system at the same time whereas each application may have different functional requirements from the operating system. Todays operating systems provide a functional superset of the requirements of all applications and thus, violate the principle of minimalism for each single application. We resolve the conflict between the principle of minimalism and the versatility of the operating system by decomposing the operating system into small components and by providing a way to execute those components isolated and independent from each other. Components can be device drivers, protocol stacks such as file systems and network stacks, native applications, and containers for executing legacy software. Each application depends only on the functionality of a bounded set of components that we call application-specific trusted computing base (TCB). If the TCBs of two applications are executed completely isolated and independent from each other, we consider both TCBs as minimal. In practice however, we want to share physical resources between multiple applications without sacrificing their independence. Therefore, the operating-system design has to enable the assignment of physical resources to each application and its TCB to maintain independence from other applications. Furthermore, rather than living in complete isolation, components require to communicate with each other to cooperate. The operating-system design must enable components to create other components and get them to know each other while maintaining isolation from uninvolved parts of the system. First, we narrow our goals and pose our mayor challenges in Section 1. Section 2 introduces our fundamental concepts and protocols that apply to each component in the system. In Section 3, we present the one component that is mandatory part of each TCB, enables the bootstrapping of the system, and provides abstractions for the lowest-level resources. We exercise the composition of the presented mechanisms by the means of process creation in Section 4.