Flexible Kernel Systems

Some operating systems researchers argue that the performance, flexibility, and extensibility of operating systems are greatly limited by the design, where the interfaces and the implementations of OS abstractions such as inter-process communication and virtual memory are fixed. The need for flexibility and extensibility have been recognized as OS requirements by researchers even in the 1970s [131, 132]. In [131], the authors have advo- cated the design of open operating systems, where the system provides a variety of facilities, and the user may use, accept, reject, modify the facili- ties based on permissions and requirements. In many cases, one facility may become a component on which other facilities are built or developed, like files and disk pages. In that case, there is a need to identify smaller components, and make them accessible to the users and other larger com- ponents. The development of flexible kernel design provides a whole lot of interesting concepts and design. In this chapter, we will try to cover the three decades of conceptualization, design, and development efforts by identifying two representative solutions in this research area. The first pro- ject called Hydra [133] was developed in the 1970s, where the researchers have separated the policies and mechanisms of kernel, and used it as a guiding principle in kernel design. The second work, called exokernels [134] developed in MIT, looks at handling resource management at the ap- plication layer, thus providing faster transactions, and secure operations.

Project Hydra

One of the earliest examples of a flexible operating system was Hydra, de- signed in Carnegie Melon University (CMU), way back in 1974. It was an ambitious project designed to exploit the inherent potential of the multi- processor computing system. The system was designed on C.mmp [135], a proprietary multiprocessor also designed and developed at CMU. The main purpose of the project was to demonstrate the possible development of a flexible operating system, where at the center there is an arbitrary set of fa- cilities, which can be used to create the operating system based on the cus- tom defined policies. Some of the considerations which guided the devel- opment of the Hydra system are as follows:

• Multi-Processor Environment: The main use case of the Hy- dra system was the development in a multi-processor environ- ment.

• Mechanism and Policy Separation: Another consideration that led to the development of the Hydra project was to separate the

mechanisms and policies. This separation leads to a flexible sys- tem design as the system designer can make complex system decisions.

• Protection: Hydra develops protection based on capabilities. These capabilities can also be custom defined and are used to provide protection for all entities in the system.

• Reliability: The reliability of the system is guaranteed by the C.mmp hardware through the redundancy of critical hardware resources.

As mentioned earlier, the protection of the Hydra system is provided through the mapping of policies and mechanisms. Hydra system develops the protection mechanism by building on top of the underlying core facili- ties guided by the custom-defined policies. The protection mechanisms are defined through the interaction between objects, capabilities, and proce- dures. Objects refer to abstract reference of the arbitrary set of resources, capabilities are references to objects, and procedures are the abstract no- tion of any arbitrary set of operations. Each capability includes information detailing operations that can be performed on the object referenced by the capability. Whenever an operation is attempted on an object, the requestor supplies the capability referencing that object. The kernel examines the rights list of the requestor and prevents the operation when the rights fail- ure occurs. The right has been defined as the set of permissions granting the requestor to supply capability as a parameter to any procedure. Based on the rights, some operations can be denied access to certain objects based on exclusive “kernel” rights.

The Hydra project may not be useful for immediate deployment; however, the concept of separating policies from mechanisms is powerful and has been applied in security systems in different contexts. The next system that we will discuss in this chapter is called an exokernel imple- mented as Aegis system in MIT. Exokernels extends the Hydra concept by eliminating mechanisms whenever possible through the application level policy handling, which offers high performance and flexibility.

Exokernels

In the mid 1990s, researchers in MIT came up with the design of a flexible operating system architecture, where the management of physical re- sources is handled at the application layer. The lack of flexibility of the ex- isting operating system architectures to incorporate domain-specific op- timizations and implementations motivated the development of the

7.2 Data Protection Issue 147 exokernel architecture. Another point that motivated the design is the need to provide more flexibility to the application builders, as the abstraction development methodology followed in traditional operating systems lim- ited the application development to a great extent. The researchers in MIT attempted to solve these problems through application level resource man- agement. The flexible operating system, thus designed, implements the traditional kernel level functionalities like Inter-Process Communication (IPC), Virtual Memory (VM), etc. at the application layer. In this architec- ture, the exokernel is a minimal kernel which securely multiplexes the un- derlying hardware resources. Library operating systems, working on top of the exokernel interfaces, implement higher level abstractions. The applica- tions select libraries, or implement their own libraries by simply relinking the application interfaces. Different components of the exokernel system are illustrated in Fig. 7.5. As shown in the figure, the exokernel architec- ture securely multiplexes and exposes the hardware through low level primitives. The library operating system uses the low level primitives to implement the higher level abstractions, and finally the applications uses these to manage the resources according to need.

The different components of the exokernel systems are:

• Managing Policies: The task of managing policies is handled by the library operating system. The policies identify the appli- cations, the share of resources, the way to arbitrate the compet- ing applications, and so on. Different security policies can be embedded into the general policy definitions, as exokernels al- low the extensibility in the systems.

• Secure Bindings: Another important task of the exokernel sys- tem is to securely multiplex resources, and provide protection to applications which have an existing trust relationship. The pro- tection mechanism in secure bindings is created by separating the authorization from the actual use of the resources. This im- proves the performance of the system to a great extent. The pro- tection checks are carried out by the kernel as simple processes, which are done quickly. The authorizations are carried out at bind time only, allowing the separation of management from protection.

• Secure Multiplexing: Secure multiplexing of physical memory is implemented in the exokernels using capabilities which can be authenticated. Whenever a library operating system allocates physical memory page, the exokernel creates a secure binding

for the page recording the owner and the permissions. The owner will then have the rights to access the page based on the permissions. In addition to multiplexing at the physical memory level, there is a need for multiplexing at the network packet/message level. The message multiplexing at software can be provided through packet filtering mechanisms.

Fig. 7.5. High level view of an exokernel

Researchers have shown that the exokernel approach is able to attain a very high performance. Experiments show that the Aegis (an implemen- tation of the exokernel architecture) is much more efficient that any other traditional operating system. Though the exokernel architecture does not include security benefits directly, there are security benefits which are at- tained as a byproduct. The benefits are:

• Separation of management and protection guarantees a more flexi- ble and scalable mechanism of providing security. Different secu- rity policies can be incorporated easily.

• High performance of the overall system implies that the overhead associated with security is considerably reduced. Therefore, sys-

7.2 Data Protection Issue 149 tem administrators can go for more complicated policies and secu- rity mechanisms without sacrificing performance to a great extent. In spite of the advantages, the exokernel approach is still limited to laboratory implementation and has not seen an industry scale implementa- tion. More research and development efforts need to be undertaken in this direction to make the concept of exokernel a commercially viable solution.