Paper Discussion - Fall 2008 - CS 736

Exokernel - exterminate all OS abstractions

Summary

The authors suggest a kernel without any hardware abstractions that just provides features to allocate and multiplex the hardware in a secure way. The authors believe that abstraction and genericism built into a kernel was the reason for complications in performance, development and adaptability of operating systems uptil then.

Description of the problem being solved

The authors want to nail the root cause for the issues of poor performance, poor reliability , poor adaptability and inflexibility in the operating systems for about two decades and to solve these issues with a new kernel developement approach.

Contributions of the paper

1. Radical approach of removing all abstractions : The paper has strongly identified the problems with the genericism that was built into operating systems uptil then and suggests a radical approach that provides lots of advantages in performance, adaptability , flexibility and reliability. It also compare this with the hardware design transition from CISC to RISC.

2. The Exokernel approach really helps increase the performance of heavy weight applications with dedicates machines like a Database or a Web Server serving a lot of requests because such applications no longer need to pay the price for the genericm built into the OS. E.g. the Cheetah web server built on top of XOK performs eight times faster than NCSA or Harvest. Source : http://pdos.csail.mit.edu/exo.html

3. A significant advantage is that applications can now choose to not pay the price for the genericism built into the operating system by choosing the right operating system stack on top of the exokernel.

Flaws in the paper

1. The papers says that with Exokernels, the application can choose from a myriad of operating system stacks that sit over the kernel based on the kind of optimization required for the application. This is not a practically viable approach for reason like:

(a) Personal computer users will try to run many different application on a single machine and they need generic computing facilities. Using multiple stacks for multiple applications will definitely bloat the system. Development of a single stack that works perfect with all applications is very hard and relies on standards for conformance of interfaces.

(b) The development of several stacks needs a lot of development effort and the development and maintenance of standards for conformance will be a behemoth task.

2. The solution proposed for sharing system state in such a system by building trusted Servers is also not convincing. Such servers might become a performance bottleneck.

What is made easier?

1. Builing a operating system stack on top of the exokernel that is optimized for a specific application is made possible and easier ( may be ) provided the required stacks exist and are also compatible with the applications without major changes.

What is made harder?

1. Developing a fully operational stack without major effort seems imposible because of the inherent complexity in development of layers conforming to standards and also layers that are optimized for various requirements.

2. Porting the kernel to newer hardware becomes harder because the kernel has been brought down too closer to the hardware and also since exokernels exposes the features of the hardware explicitly to the applications.

Exterminate All Operating System Abstractions

This is a position paper in which a new definition for operating systems is stated. The authors consider that the idea of an OS having to abstract physical machine resources is wrong; they claim that no abstraction can fit all the applications and that abstractions are the cause of operating systems being unreliable, non adaptable, inflexible and slow. They propose to completely eliminate OS abstractions and define an OS as a software that safely multiplexes the hardware.

This paper proposes to eliminate abstractions from operating systems as a way of making OS more reliable, adaptable, flexible and efficient. The OS provides a low hardware level interface, exporting the raw physical resources. The abstractions should be implemented in the application in a specialize way.

A new simple structure for OS called exokernel is defined; its interface to applications are physical memory, the CPU, disk, DMA, I/O devices, TLB and interrupt/trap events. Applications need to implement the abstractions they will be using, so the abstractions will be more suitable for each particular application, and applications will be more efficient. The task of this exokernel is to securely multiplex the hardware; despite providing a low level hardware interface, security is still an important issue in the system. Although micro-kernels target the same problems, they were not successful in solving them, exokernel is based on similar ideas but gives the applications more control over hardware resources.

This paper does not propose anything new, the main idea is to eliminate the abstractions from the operating systems to have the user applications implement those same abstractions which are still necessary at the end; so the problems that they try to solve will appear again in the application level. They do not consider that application development would be much more difficult for this OS, and that could be an important problem for the success of the OS. They do not state if this exokernel would be suitable for general computing or more specialized computing systems.

This proposed solution makes the design and development of the operating system simpler and faster, it also results in a smaller and cheaper OS. Meanwhile the applications become more complex and difficult to implement, and also bigger and more expensive.

Summary
Paper talk about issue like reliability ,adaptability,performance and flexibility with current operating system. According to author root reason for all problem is abstraction provided by OS .

Problem trying to Solve
Author is trying build new kernel design Exokernel which eliminate abstraction provided by OS and expose hardware to application level software so that they can use them in the best way suited to them .

Work Summary/Contribution
1. OS should implement basic feature of allocate , deallocate and multiflex physical resource in secure way. as abstraction is eliminated so size of exokernel is really small.

2. current OS abstraction consume significant amount of memory and resources which impact the performance of system. Exokernel remove all abstraction from OS so performance is much better than monolithic kernel.

3. in current OS only kernel architect can include new changes so adaptability is restricted. Exokernel allows application level abstraction so new changes can be made without bothering about whole system dependence .

4. According to author it is impossible to abstract resource in a way that is useful to all application. I totally agree to this point but that doesn't mean we should eliminate the abstraction completely. I feel OS should provide such abstraction but they should also provide some way to by pass these abstraction so that in case some application have better approach to handle physical resource they can build such strategy .
but removing such abstraction for all application will put lot of overhead on application development who are working with existing OS abstraction.

Flaws
1. At one place Author talk that OS should not bother about the being a machine independent interface to application and then in second place he talk about machine independent layer in OS to be portable . These 2 statement seems contradictory to me .

2. Author do mention that user application is responsible for illegal address access or checking for validity . If we leave such abstraction to user level application then reliability of application will be at loss and each application need to implement duplicate module for such checking . which might be concern in multi programming environment where duplicate module is loaded by many program for same function .

What it makes easier
1. Application which need some special handling of resources and application which are not satisfied with current OS policy can bypass the OS abstraction and use physical resources in best possible way .

What it makes harder
1. Application is responsible for validity checking and illegal address access . such approach will put extra overhead on application developer.

Summary
The exokernel paper stresses that OS abstractions provide much lesser value when compared to the cost of implementing them. Instead, it proposes a design where the OS just multiplexes physical resources and leaves every abstraction to be implemented by application.

Problem attempted
The paper attempts to build an operting system that eliminates operating system abstractions by exposing the hardware resources to the application

Contribution
1. The exokernel is built upon the idea of limiting the OS to just safely multiplex resources and get away from the task of managing resources. Any application is free to manage resources. The paper stresses the need to realize the difference between protection and management.

2. As a result, many traditional services offered by OS such as virtual memory, file-system, networking-support are no longer implemented by the OS. There are to be implemented in application-level operating systems. This means that there is a networking-OS for web-applications, a file-system and Virtual memory OS for compilers and other such applications.

3. One major intention is to avoid abstracting physical resources and export the physical resources to application directly. This idea certainly prevents an application pay the cost for a feature it doesn't use and yet is implemented in the OS.

Flaws

The paper says that reliability of the system improves because of its minimal complexity and much lesser lines of code. But clearly the application-specific OS is going to be complicated and it can become unreliable. What is more is that bugs in OS can be detected and fixed much faster than in applications, because of the much larger number of people using it and working on it.

What it makes easier

1. The flexibility offered in the design of the system permits many innovative designs of various functionalities which are provided by kernel now. For example, novel implementations of page-tables, file-systems is possible now. Also, experimentation is very easy in this environment as the OS does not demand that access to any hardware resource should be throuht it.

2. When the OS does resource management, it has to make its trade-offs based on a wide variety of applications that use it. But when resource management is left to application, it can make trade-offs that best reflect its needs.

What it makes harder

Inspite of the presence of libraries, the proposed system design could discourage development of new applications because of the sheer number of features that have been left to the application to implement by itself.

Summary:
The paper proposes the idea that the attempt to provide operating system abstractions is a fallacy and the root of reasons causing poor reliability, poor adaptability, poor performance and poor flexibility. In order to avoid these problems, a complete elimination of operating system abstractions by lowering the operating system interface to hardware level is a solution way, therefore, a structure, exokernel with abstraction-free and low-level interface is presented in this paper to deal with these problems.
The problem the paper was trying to deal with:
By arguing the operation system abstractions is the root causing poor reliability, poor adaptability, poor performance and poor flexibility, the authors propose a new idea to deal with this problem by eliminating the abstractions and lowering the operating system interface to hardware level. By doing these, a large complexity and price paid for abstractions can be reduced and system performance and flexibility can be improved.
Contributions
1． The paper proposes the idea that the attempt to provide operating system abstractions is a fallacy and the root of reasons causing poor reliability, poor adaptability, poor performance and poor flexibility. What is more important, it provides a new solution method, a structure exokernel with abstraction-free, low-level interface to deal with these problems.
2． The authors proposes the idea that allocation and reallocation of the physical resources can be done without abstraction, which reduces a lot of cost caused by operating system abstraction, and then make operating system more efficient.
Flaws:
Although the paper proposes a new solution method, a structure exokernel with abstraction-free, low-level interface to improve operating system performance and flexibility, it is just a position paper, no test and evaluation has been done to show it. And other problems which may incur are that user level code is possible to lose its portability and implementation of upper layer may be hard because of the absence of process abstractions.
What it makes easier:
The structure exokernel having abstraction-free, low-level interface makes the operating system to be easier to achieve reliability, efficiency and extensibility.
What it makes harder:
The implementation of upper layer may be harder because of the absence of process abstractions. And by allowing application-level implementations, all the dependence of the entire system need to be removed, which would make coding harder.

Summary
In this paper, Engler and Kaashoek are proposing the idea of an exokernel which doesn't provide any abstraction and leaves all the decisions to the application software. The only job of the exokernel is to securely multiplex across the hardware resources such that any system built on the top of the exokernel can decide upon the implementation and the corresponding trade-offs based on their own application.

Problem
All the operating systems till date have provided a layer of abstraction to the users and made all the decisions(allocation policy, trade-offs etc) on behalf of the user. This has restricted the possible applications of the operating system as changing anything in the system is non-trivial and wouldn't reach the general public without approval from the kernel architect[No Adaptability/Flexibility]. They also point out that OS's come with a lots of bells and whistles which may not all be required and just slow the system. This is obvious from the fact that many corporations use stripped down OS's for their servers.[Performance] This complicated OS design also results in a huge codebase that is difficult to maintain and ensure correct functioning.[No reliability]

Contributions
This minimalist exokernel design solves most of their claimed problems with the existing OS's
- Reliability - They claim that since the design has very few components, the OS as such is small and easy to understand. As a result, it is less likely to have bugs.
- Adaptability - Here again, they have limited their implementation of the OS such that any kind of system can be built using the exokernel. Since no decisions have been made in the OS and the hardware is directly available to the application software, it is even more adaptable than the microkernel or VM/370.
- Efficiency - Every user can choose what features he needs from the system and just use those application software instead of using the general OS's.This would be specifically useful for systems that need to be run on embedded systems or servers that don't need all the facilities of the OS and have limited hardware resources for the OS itself.
- Flexibility- Since application developers would have access to the hardware directly, they can come with innovative implementations using the exokernel.

Flaws
- This design is very closely bound to the hardware it is implemented on. They claim that we can add a layer of "abstraction" to make all the hardware appear same, but isn't that what they have been arguing against?
- Also since people will be building libraries for this system, this would result in a multitude of libraries doing the same thing.Applications built on the top of these libraries wouldn't work with other applications that need other underlying libraries. For e.g. the library that does the processor scheduling cant co-exist with another such library.

Design
This paper is more to do with the principle of an OS than its design. It does give a brief idea about their memory and process management and IPC (which seems more like process switching). They also ensure security of the memory access by making access checks for each TLB lookup.

Easier
- Its easier to build a system for an embedded system or a highly specific application by just re-using their exokernel.

Harder
- Its harder to build a general operating system, considering even the basic applications are missing in this system.
- Considering the different operating systems that may result from this system, it would be a tough job maintaining order in the resultant chaos even with defined standards.

Summary The paper discusses the exokernel approach to building operating systems, where the hardware is not abstracted, but rather is just securely multiplexed and provided to applications.

Problem addressed The authors argue that designing an OS to provide an abstracted view of the hardware to applications is the root cause of the observed problems of poor reliability, adaptability, performance and flexibility of operating systems. The address this by proposing the exokernel structure mentioned above.

Design of the operating system The fundamental idea of the design is that the exokernel will expose a securely multiplexed view of the hardware to applications, without abstracting any feature of the hardware. This will allow for the application to optimize its hardware access effectively and achieve best performance. The system is flexible, because applications can choose the best style of access to the hardware depending upon specific needs. Because of it's simplicity, the exokernel is reliable and adaptable.

Contributions The paper points to the habit of operating systems in providing abstractions as a reason for the insufficiencies of contemporary os-es. The idea of leaving choices to the applications provide a good spearation of mechanism and policy And the approach of exokernels might have particular viability in domains like embedded systems.

flaws While the exokernel is made simple and stripped down, this is achieved by moving much functionality into the higher layers. While this improves reliability, performance etc of the exokernel, the system on the whole might not see much improvement as the functionality is still implemented, albeit elsewhere.
And while the authors push the stripped down version, it kind of contradicts when they come up with stuff like implementation of industry standards like POSIX at application layer.

what it makes easier Exokernels could be particularly suitable for embedded and special purpose computing applications. In such a domain, the applications can gain huge benefits by avoiding the overhead of generality provided by OSes.

What it makes harder As mentioned, the exokernel is stripped down but this is achieved by delegating those functionality to the higher layers. Thus the job of the application implementor could be made harder, as he has to now have intimate knowledge of hardware details. And while the exokernel may be reliable (in the event for crash for eg.) the overall system reliability etc will now depend even more on the application reliability as well.

Summary: 'Exterminate All Operating System Abstractions' is a position paper advocating a minimal kernel that exposes the bare hardware using minimal OS intervention to insure security and some fairness. 'Exokernel' is the structure of an OS build according to this abstraction-free design philosophy. Library-operating systems are supposed to be built on top of Exokernels.

Problem: Decades of abstraction based operating systems failed to offer a solution satisfactory for everybody. Moreover, the price paid for abstractions is often paid out of the benefits they are supposed to offer: the reliability and flexibility suffer in correlation with the size of the code required to support the abstractions. This is in addition to the price expected to be paid for abstractions: performance and inability to satisfy all possible applications (example: databases that want direct control to storage, without a file system abstraction). On the 'flexibility' side, a notable problem is the increasing difficulty that one faces when attempting to experiment with new concepts. This thing alone impedes the penetration of good ideas.

Contributions: Exokernel's plead for a minimal kernel is not new. What is new is the extreme it is willing to go to achieve this. Contrast this with Hydra or Nucleus which also attempt to offer a minimal OS, but they do it by carefully selected abstractions. Another novel feature present only in Exokernel is the ability to execute user provided prologue/epilogue code at context switch time.

Organization: Exokernel separates the mechanism from policy simply by providing the hardware as the mechanism. Exokernel's only job is to ensure secure access to physical resources. Other than that it relies on user level code to implement policies. Security is enforced by (revocable) capabilities which are offered to library OS's (binding them to HW resources). The simplicity and reduced size of an Exokernel OS is supposed to make it easier to understand. It is also easy to develop and test OS's on top of Exokernel, since they are in user mode. However, lack of abstraction enforces the user to be aware of machine details. Another difficulty is that Exokernels may have to be re-thought for each new hardware.

Weaknesses: User level code may loose its portability in an Exokernel world. Even if portable, the performance of library-OS's may be very machine-dependent. There is an increasing number of interfaces that need to be tested and potentially standardize. The prologue/epilogue user code at context switch time is a nice idea, but it could easily be abused/misused. It is unclear the level of security that such a system can offer against malicious users.

In this paper, the authors present their view that the elimination of all operating system abstractions will make operating systems more reliable and better performing. They analyze their philosophy and describe the basic features of exokernel, an operating system kernel whose functionality is limited to allocating, deallocating and multiplexing physical resources in a secure way.

According to the authors, the abstractions used within the kernel are responsible for the poor performance, inflexibility and poor reliability of operating systems. They believe that it is impossible to create abstractions which can be used efficiently for any application. They completely disagree with this designing approach, as according to them, it makes operating systems more complex. They argue that by eliminating the abstractions and lowering the operating system interface to the hardware level these problems will be solved.

The kernel exports some hardware resources, like CPU, physical memory, disk and I/O devices among others. It also places a guard for every resource that checks access privileges. The system’s functionality is limited to securely multiplexing physical resources. It then grants control to high-level applications.

The main contribution of this paper is the concept of a minimal kernel whose functionality is to multiplex resources and ensure protection. Users can improve program performance by creating their own abstractions on top of the kernel. This approach has many benefits, as it is not possible to create abstractions useful to all applications. Moreover, the simplicity of the kernel, makes it more portable between architectures and flexible.

However, in my opinion this approach doesn’t solve the problem. It only shifts it to an upper level. Users have to deal now with problems which otherwise would be handled by the kernel. One of the goals of this system is to facilitate the writing of code and improve program performance. However, I believe that
users are more likely to write faulty code, as understanding how this kernel works is not trivial.

Summary:
"This is a flamy paper describing the philosophical underpinnings of the exokernel approach."
- Dawson Engler.

This paper proposes a new approach to operating system design by having almost no abstractions between applications and low-level hardware. The authors claim that this approach improves the reliability, adapatability and performance of the system.

Problem:
This paper argues that operating systems should not abstract physical resources, following the "ene-to-end" principle coined by innovators of protocols like TCP and UDP (Jerome Saltzer, David Reed and David Clark). The prototype exokernel performs 10-100 times faster than a mature monolithic system.

Contributions:
- ExoKernel approach - Its sole function is to allocate, deallocate and multiplex physical resources in a secure way. Thereby eliminating all OS abstractions.
- Improved reliability due to minimal or no abstractions of resources (minimal complex and multi-threaded code which is the major source of bugs).
- Improved adaptability and flexibility. Applications can implement abstractions which satisfy theier own needs. Have direct access to raw hardware (pages, CPU time-slices, disk blocks, DMA channels, TLB, etc.)
- Though this approach never flourished commercially, it provided a radically new direction for OS researchers. ExoKernel and Microkernel are also closely related to hypervisors.

Flaws:
- Being a position paper only (HotOS '95), it does not present any evaluation. (So not a flaw actiually).
- The authors claim that in exokernel, if an unreliable application can only harm itself. This does not seem convincing, since all applications dependent on it will also get affected (a simple example is any producer-consumer system).
- A low-level hardware abstraction layer is still needed for hiding machine dependence and allowing portability. But the paper never describes this HAL (is it just providing access to raw devices).
- Complexity of exokernel interfaces is never discussed.

What it makes easier?
- Improves reliability and flexibility for applications.
- Improves upon the performance (10-100x over monlithic designs).

What it makes harder?
- Each application has to implement its own abstractions. Though the libraries can be shared, even then this is a huge overhead. Library OS are written over exokernel interfaces.

Summary: The authors of this paper present exokernel, an operating system without abstractions to improve reliability, adaptability, performance and flexibility of the system. By focusing on only implementing user-level software for the base operating systems, the size of the OS is decreased while allowing programmers to implement the most prevalent applications for the system with minimal overhead costs.
Problem to Solve: The goal was to create an operating system that is able to multiplex physical resources without abstractions that decreased the overall performance of the system and prevented application developers from efficiently utilizing hardware resources.
Contributions: First, the authors define the exokernel system as an operating system without abstractions, which is a very different approach to solving the problems that exist in operating systems than previously explored. Secondly, they introduce the idea that even without abstraction the kernel can be in charge of allocation and reallocation of the physical resources, thus preventing the starvation of any process.
Flaws: One flaw of the paper is that they don’t discuss how machine portability will be addressed in this model. They note that this layer is needed to hide machine dependence, but don’t explain how this can be done without abstract or rewriting the code for every different machine. Another flaw is that since this is a position paper there is no implementation or prototype evaluation details, yet they say it out performs a monolithic system and present no other systems for comparison, .
Advantages of Proposed OS: One advantage of the exokernel is the smaller base operating system, because this leads to the ability to customize applications and system components to meet the needs of individual systems or users. Another advantage is that correctly implemented applications should incur less overhead costs in terms of garbage collection, memory usage, etc.
Disadvantages: One major disadvantage of this system is that now the burden is placed on application developers to create (correct) abstractions for each application/component they build. Reusable libraries are a simple way to ease this burden as pointed out, but these libraries must then be correctly interfaced between the application and OS, and contain all the necessary functionality needed.

The “Exterminate all Operating System Abstractions” paper discusses the idea that an operating system should not abstract hardware resources. In eliminating this abstraction in the operating system, the reliability, adaptability, performance and flexibility will be enhanced.

The problem this paper is trying to solve is that current operating systems have drawbacks in performance and capabilities in certain cases because of the lack of flexibility in the underlying high level operating system.

This paper contributes the notion of thinking about an operating system in another approach. This more simplistic operating system focuses on resource management and adding security to every resource.

The paper discusses that the exokernel exports the hardware such as DMA channels and I/O devices, but never explains how this interface looks to a user for different types of devices. In addition the inter-process communication functionality does not seem robust. Transferring of the Program Counter from one domain to another does not seem defined well enough to even pass messages from one process to another.

The operating system is organized with an exokernel at the base that exports low level resource interfaces with resource management, TLB’s for virtual mapping capabilities and exception handling. Above this layer there can be applications, or libraries with applications above this layer. This organization makes it easier to develop experiment and research new techniques on top of the exokernel as well as allow applications to be written as optimized as necessary. However, the exokernel layer is at such a low level that it is necessary to write libraries to interface to applications which will degrade performance. This operating system also leaves all the application design open to the developers which means standards would need to guide how things like IPC and virtual mapping work between unrelated programs.

Summary
Paper discusses about eradicating all the Operating System abstractions. The belief that all the hardware resources can be abstracted and implemented to perform efficiently in all the areas is considered a fallacy and the reason for the poor performance, poor reliability, poor adaptability and poor inflexibility. Thus an exokernel is designed, where all the resource management is handed over to Applications.

Problem trying to solve
The Operating System removal is targeted as they are complex and large; decrease reliability and discourage change. They enforce some higher level abstraction that’s supposed to affect the efficiency of new abstractions outside OS. The abstractions and highly complex implementation for them cannot be considered efficient for all the user applications. Thus, they are trying to resolve all the issues caused by Operating System.

Contributions:
This suggests total eradication of resource abstraction and exposing the entire set of resources to Higher level applications, so that they have higher flexibility in access and can implement their application as per the requirement.
The kernel is required to allocate, dellocate and multiplex resources in a secure way. The rest of resource management is given to Application user as opposed to typical OS design, where resource allocation is fixed by it and application user has no access whatsoever.

Flaws in the Paper:
The paper doesn’t speak about how the resources would be shared amongst different applications. It suggests removing all the layers between Kernel and Application user, then why is there a discussion about portability and adding a thin layer between kernel and user application.

What it makes Easier:
Increased Reliability: As hardware resources are directly visible to Application user, kernel nor user has to write complex algorithms. Things are easier to access and it doesn’t have to bother about multiplexing.
Increased Adaptability: As the Application users aren’t dependent upon the kernel code, kernel is easy to change and easily adaptable to all applications.
Increased Efficiency: Resource Management has been given to application, thus the efficiency should be higher as the applications knows best about itself.
Increased Flexibility: Page Tables, process abstractions, address space etc can be implemented by application itself. These weren’t possible with an operating system layer. This allows large number of applications to utilize the resources as and when desired.

What it makes Harder:
It doesn’t provide with any high level interface. Application user might not be interested to take care of all the resources on its own, and doing that, could make the application development harder on exokernel. Since kernel trusts applications, they are given access to address spaces.
This doesn’t make application reliable. The kernel doesn’t care about paging, guarding illegal address and checking for validity, and users can be ignorant. This makes the overall application or a system unreliable. Agreed that performance would increase, but what about the reliability of applications?

Summary
The paper introduces an exokernel structure, where the goal is simply to multiplex and allocate, but not abstract, physical resources.

Problem
This structure is trying to address an oft-repeated list of problems that operating systems have poor performance, reliability, adaptability, and flexibility. To this end the authors ask a question that has been asked before but they feel has not been correctly answered: What is the minimum functionality that a kernel needs to provide (for any given primitive)?

Proposed Organization
The system proposes a kernel structure designed to securely multiplex physical resources. The resources they wish to expose are exactly those provided by hardware, such as the CPU, physical memory, disk memory, devices, and the TLB, but no attempt is made to abstract these to a higher level. Every resource usage is “guarded” by the kernel, enforcing security and checking access privileges. The system tries to grant as much control as possible to the application, even placing such things as context-switching code under application control.

Contributions
They authors note that the implementation of abstractions in operating systems can be overly complex, overly policy-laden, overly general, consume large amounts of resources, and force high-level abstractions that make it difficult to efficiently implement other potentially new and useful abstractions. The system that is created is incredibly adaptable and flexible in theory, and the kernel, in avoiding abstractions, is much simpler, increasing the likelihood it will be reliable and efficient.

Flaws
When addressing issues such as executable size, portability, and system structure, the general answer is to use industry standards, dynamically linked libraries, etc. as sort of an intermediary between the kernel and applications. In this case, abstractions outside of the kernel are encouraged where useful. While I can’t help but agree in principle, the question remains how well this would work in practice if exokernel systems were in widespread use. As the authors readily admit, the exokernel allows for both incredibly beautiful systems and incredibly ugly ones. But what is the tendency of exokernel systems?

In this opinion paper Engler and Kaashoek propose a radically different operating system architecture: exokernels. They argue that abstractions are the cause of all evil in operating systems and claim that the main focus of operating system architects should not be on finding the correct abstractions but instead on eliminating abstractions altogether.

Operating systems are often criticized for their lack of reliability, adaptability, efficiency and flexibility. The authors argue that poor reliability is the artifact of the complexity of operating systems. They attribute poor adaptability to the principle of "being everything to everyone" which forces kernel architects to be very reluctant to incorporate new ideas. Those problems are amplified by the lack of different abstractions for different applications, which forces particular applications to pay a significant overhead. Finally, kernel support for isolation and security often translates to absence of mechanisms to implement custom abstractions, thereby limiting the flexibility of the system.

The authors propose a very innovative solution: creating an operating system that provides no abstractions. The kernel will manage physical resources and do nothing more. The regular operating system abstractions can be provided by an application that will run on top of the kernel. This way flexibility and adaptability can be achieved and the system will be simpler as it will only implement primitives and not abstractions.

The paper is an example of good rhetoric on how to build a great system. Unfortunately the authors don't attempt to address any of the implications of their design choices and often contradict themselves. For example, although they mention that abstractions are only a cause of problems they choose to abstract away the hardware, into CPU, memory, disk and I/O. It is far from obvious why disk is considered a primitive but the network is an abstraction.

I find hard to believe that an exokernel would improve reliability and efficiency, as both are end-to-end concerns. Saying that you can improve reliability by using an exokernel is like saying that you can improve the reliability of Windows by running them inside a virtual machine: maybe crashes are not fatal, but the design doesn't prevent them from happening. The same also applies to their performance argument, as I fail to understand why the majority of the applications would run faster in an environment where access management and abstractions are separated. Despite decades of criticism, operating systems have proven to be the strong link in the chain, both for reliability and efficiency, as user programs are the prime culprits of unstable and inefficient behavior.

Introduction:
In this paper, the authors present a design philosophy which calls for eliminating all abstractions from the kernel. They call such a minimalist base layer an Exokernel. The authors claim (and to some extent, rationalize) that this approach mitigates most of the problems of existing operating systems.

What were they trying to solve:
In the two decades between the first complex operating system architectures(~1975) and this paper(~1995), all operating systems were designed with abstraction being their central philosophy. In spite of many different approaches being implemented, all of them suffered from issues like performance and reliability. The authors try to solve this by adopting an "abstraction free kernel" approach where the only job of the kernel is to safely multiplex physical resources.

Contributions:
This approach improves Performance, Adaptibility and Flexibility. The problem with providing some kind of abstraction at the lowest level, is that in cases where these abstractions don't apply, the program suffers from various problems. Attempts at creating abstractions which are wide enough to accomodate different applications are too general, and generally pay a performance penalty. Their philosophy is: unnecessary abstractions are worse than no abstractions.
This completely detaches mechanism from policy. Since the kernel doesn't do any resource management, it is entirely upto the application-level software to allocate and manage all resources.
IPC mechanism is generic, and more conventional IPC primitives like shared memory and messages can be easily built on top of this architecture.

Flaws:
It's simplistic to assume that system reliability increases with a minimalist base layer. All the system does is delegate most of the protection requirements into user space. It's unclear if application level programs(i.e. non privileged code) can deal effectively with a malicious program.
The absense of a process abstraction makes writing the upper layer application difficult. Applications have to co-exist with one another, and often cannot make comparitive decisions(eg:Does this process have more priority than me?) unless there is some additional structure or restriction.
Since Exokernel exports rather than abstracts physical resources, it is not simple to port to different architectures. If something remains the same across architectures, then it is, by definition an abstraction.
The paper quotes perfomance increases of 10x and 100x for IPC calls. It is unclear what exactly is being tested, systems with same application-lvel features (eg: Shared memory in Linux vs Shared memory implemented on top of Exokernel) or with different features. It seems unlikely that a 100x performance gain can be obtained with significant loss of functionality.

OS Organization:
The Exokernel consists of the bare minimum layer needed to run the system: support for paging, CPU time slicing, disk access, DMA channels, I/O devices, TLBs and interrupt handlers.
Advantages:
Since most of the code is outside the privileged domain, very few calls acrross protection boundaries are needed. This improves performance and robustness.
Since all policy decisions are done in the application level, domain specific knowledge can be incorporated into those decisions more easily.
This architecture is most suitable for minimal functionality kernels which run in constrainted environments, i.e. embedded devices.
Disadvantages:
The onus on doing everything is now (directly or indirectly) on the application programmer. Very few applications need this kind of low-level support, and even those who need may not want to write it from scratch.
Scheduling decisions are complex, because the scheduling component of each application may be radically different, and in some cases incompatible.

Summary
In “Exterminate All Operating System Abstractions”, Dawson R. Engler and M. Frans Kaashoek present their view that operating systems should be made more reliable, easier to adapt, better performing, and more flexible simply by eliminating abstractions and creating an OS that does nothing but multiplexes the hardware securely.

Problem
As time progressed, operating systems tended to become increasingly complex as they tried to become all things to all people. By creating abstractions that would, in theory, make it easier to use system resources, to share them between users, to provide “useful” facilities to programs, and accomplish additional work that may or may not be needed in a certain case, operating systems became large and complex pieces of software that consumed considerable system resources, failed to provide complete reliability (due to bugs presumably arising from the complexity), and provided unusual interfaces to hardware because of imperfect abstractions. The solution to all these problems, according to Engler and Kaashoek, was to eliminate a lot of work from the OS, specifically to eliminate all provided abstractions and act simply as a multiplexor for hardware, allowing software to access the machine at a hardware level.

Contributions
Creating a system that could facilitate sharing of hardware resources without creating abstractions that did not potentially fit in line with what potential programs might need (thereby decreasing performance and possibly complexity, if workarounds were needed to do things that should have been easy).

Flaws
Arguing that the solution to current complexity (and specifically the poor reliability, adaptability, performance, and flexibility associated with it) is to eliminate all OS abstractions. While doing so would allow remove the issues from the exokernel, the issues would all persist in the libraries which would be implemented to do what current operating systems do (the intuition behind the necessity for all the features and complexity being that if the complexity were not needed at all it would simply be removed from current OSes).

Organization
The exokernel has a simple organization, resting in the fact that it is such a minimalistic operating system. Its only function is to “allocate, deallocate, and multiplex physical resources in a secure way.” The exokernel context switches processes, giving them access to various hardware resources, and managing the memory allocations, but it does not contain excess abstractions that would limit the way which these resources could be accessed. However, the lack of available abstractions also make it harder for applications to do what they want across varying hardware (even if libraries are used to provide functionality, they need to be available on the system.

In Exterminate All Operating System Abstractions, Engler et al. argue that abstractions used within the kernel generally lead to the construction of unreliable systems plagued by performance problems.

This view of the authors is diametrically opposed to that of Dijkstra in The Structure of the "THE" Multiprogramming System. Dijkstra strongly believes abstractions serve both as a simplifying mechanism for software built atop them and a clear interface to test against. He praises them as a useful tool in the (correct) construction of an operating system. Engler, on the other hand, feels abstractions in the kernel unnecessarily increase complexity and reduce control over hardware resources.

Engler proposes an "exokernel" that simply provides support for sharing physical resources between processes (i.e. CPU time, physical memory, TLBs, I/O devices and their DMA capabilities, interrupts, etc.) in a secure manner. He does not elaborate on exactly what type of security. That said, other comments he makes lead me to believe that it is standards-based and that non-compliant kernel-level routines could easily crash the system given their low-level control of hardware resources.

Engler's solution simplifies the kernel by virtue of reducing the amount of functionality the kernel is responsible for implementing. This pushes more responsibility to "do the right thing" to the authors of device drivers and services exposed to userland. In theory, exposing more capabilities to access low-level hardware to the authors of device drivers should allow them to write better performing routines. In practice, however, device driver authors may write performant, faulty code: misunderstanding or not caring to understand how the kernel works.

Engler's exokernel would be small, and undoubtedly easy to port between architectures. It would likely be most ideal, out of the box, for application programmers willing to trade convenience for guaranteed execution performance, applied to "real-time systems".

That said, applications written for other operating systems that sport more features than the exokernel would certainly require more work to adapt to run under it. In some sense, the exokernel might serve as a reasonable starting point for kernel developers to implement features seen in the more modern desktop operating systems of today, such as software TLBs, memory-mapped I/O, and IPC (that doesn't involve specifying exactly what to save when accomplishing a context switch between processes).