CS 736 - Spring 2007 - Paper Discussion

Summary:
HYDRA is a kernel, minimal set of mechanisms, that facilitates OS development especially in reliability and protection. HYDRA separates protection mechanism from security policy and gives an abstraction of each resource as an object to with capability associated.

Problem:
- The paper tried to define the flexible kernel which provides primitive mechanisms for OS development.
- HYDRA solved the inflexibility of strict hierarchy system proposed by Dijstra and suggested more efficient method to protect object in finer granularity

Contributions:
- Kernel is a simple and efficient way to create OS foundation.
- Separation of mechanism and policy simplified the OS designer task. The kernel of the OS just provides good tools to make a policy matched to users’ needs.
- Concept of capability pointing to every object is proved to be very elegant method to have flexible and efficient security policy instead of each object having its own access control.

Flaws:
- The HYDRA concept sacrifices performance for flexibility of protection mechanism. There are too many steps to access any objects; for instance, a user must check LNS to get capability information, then he probably needs to “walk” to get all capabilities before he could use such capability to access an object.
- The system is too complicate. The following paper, Policy/Mechanism Separation in Hydra, which implement the HYDRA showed that the separation implementation requires layers of mechanism. This contradicts to the non-hierarchy concept of HYDRA.

Relevance:
- The idea of using capability to protect every object creates a lot of possibility to provides highly secured services which impossible on other system. For example, the bibliographies archive system in the paper.
- The concept of kernel, is a breakthrough and lays a foundation for today OS like Linux. It makes OS development faster and simpler.

Summary
This paper describes the HYDRA kernel. The design of this system has the goal of creating a "set of mechanisms from which an arbitrary set of operating system facilities and policies scan be conveniently, flexibly, and reliable constructed."

Problem
To provide a kernel that allows for construction of environments that are seen by the user.

Contributions

• Separation of Mechanism and Policy
  
• Rejection of strict hierarchical layering
  
• Abstracted notion of resource

Flaws

• While the protection mechanism is powerful, it can also be complicated and difficult to use in my opinion. It seems like having the ability to perform selected operations on objects could lead to unintended consequences.
  
• Lack of testing or comparison

Relevance
I believe that this paper is relevant today, the most relevant piece in my opinion is the rejection of hierarchical layering.

Summary:
This paper describes the outline and key features of a kernel which enables to implement protection and flexibility for programs to fully utilize a multiprocessor environment by cutting the requirements for the lower base system and leaving a freedom for implementing various type of system on it. The kernel uses a general “object” which contains “capability” to realize the concept of simple and flexible.

Problems:
To use a group of mini-computers as a single huge pool of resources efficiently (including the idea of sharing), a system that provides a minimum abstraction of function and is flexible, expandable, and allows to create various type of systems on it was desired. And systems at that time had a tendency to provide a strict hierarchical system that is secured and usable for some programs but not flexible such as “THE system” proposed by Dijkstra.

Contributions:
Showing that creating a simple minimum layer “kernel” is another way of increasing the efficiency, and justifying that kernel is useful to support a variety of expandable and highly secured systems on multi-processor environment is an important contribution.
Creating a new layer might become just painful to develop a system, but by limiting the requirements minimum and trying to justify them also by using examples makes this idea sound reasonable.
An idea of objects with capability including “check-rights” enables (and not really includes) flexible user-based access control management in simple and secure way without ownership and strict hierarchy.

Flaws:
The first half of this paper was difficult to understand because I couldn’t visualize the concepts and relationships by my self. It might be better if they had some illustrations.
But the Bibliography example helped me to understand and now the possibilities of the kernel. To justify their shape of kernel, they should have tried to implement one scenario implemented with subsystems, but I guess because of the layering or modularizing takes time and needs many cases and people to find out whether it was useful or not, it should have been important to advertise the system and gather people who are interested in it.

Relevance:
The concept of this paper was really interesting for me because I started reading this paper after the info session of VMware and I notied that they were pointing out almost exactly the same problem and solutions. Creating a layer that provides an abstraction of a number of servers as a pool of resource and enabling a dynamic resource assignment increases the reliability and efficiency of multiple systems running concurrently on the environment. So not only in the desktop environment, there are many ideas that seems like based on this paper.

Summary:
This paper concerns itself with building a highly flexible kernel with a protection mechanism based on capabilities.

Problem:
The scope of systems research seemed to be limited by the inflexibility of existing systems. HYDRA is an attempt to define a small core of functionality (a kernel) that would provide effective resource use and management while providing enough flexibility to allow programmers to design the remainder of the operating system.

Contributions:

• Hierarchical layering, while conceptually nice, is simply too limiting. Additionally, the authors argue that hierarchical layering eventually leads to system components occupying space in a privilege gradient. The authors claim that this is not a viable approach to security.
  
• Mechanism != Policy: The HYDRA kernel enables programmers to use various mechanisms to create their own sort of security policies.
  
• Discarding the idea of ownership: by requiring things to be owned, the kernel would implicitly exclude classes of secure systems.
  
• Capabilities are great. Kernel-level protection via capabilities offers very finely-grained control over the usage of various objects. Example: "type" creators can define arbitrary capabilities for a given type.
  
• Everything is an object
  

Criticisms:

• Even with such limited functionality, HYDRA seems to maintain a large overhead penalty. Each procedure has its own LNS, you have to "walk" through the chain of capabilities...
  
• Apocalyptic chaos likely to result from users being held hostage to the capabilities added by developers. Users could potentially have many different objects, all with [slightly] different capabilities regardless of conceptual similarities between objects.
  

Relevance:
The limited functionality of the kernel is very obviously relevant to developers of micro-kernels. I feel like the most useful contribution of this paper was the rejection of strict hierarchical layering. After all, you don't want to have to wait while your OS negotiates its way through some convoluted hierarchy when it could potentially just use a few modules and be done with whatever triggered the context switch.

Summary:
This paper concerns itself with building a highly flexible kernel with a protection mechanism based on capabilities.

Problem:
The scope of systems research seemed to be limited by the inflexibility of existing systems. HYDRA is an attempt to define a small core of functionality (a kernel) that would provide effective resource use and management while providing enough flexibility to allow programmers to design the remainder of the operating system.

Contributions:

• Hierarchical layering, while conceptually nice, is simply too limiting. Additionally, the authors argue that hierarchical layering eventually leads to system components occupying space in a privilege gradient. The authors claim that this is not a viable approach to security.
  
• Mechanism != Policy: The HYDRA kernel enables programmers to use various mechanisms to create their own sort of security policies.
  
• Discarding the idea of ownership: by requiring things to be owned, the kernel would implicitly exclude classes of secure systems.
  
• Capabilities are great. Kernel-level protection via capabilities offers very finely-grained control over the usage of various objects. Example: "type" creators can define arbitrary capabilities for a given type.
  
• Everything is an object
  

Criticisms:

• Even with such limited functionality, HYDRA seems to maintain a large overhead penalty. Each procedure has its own LNS, you have to "walk" through the chain of capabilities...
  
• Apocalyptic chaos likely to result from users being held hostage to the capabilities added by developers. Users could potentially have many different objects, all with [slightly] different capabilities regardless of conceptual similarities between objects.
  

Relevance:
The limited functionality of the kernel is very obviously relevant to developers of micro-kernels. I feel like the most useful contribution of this paper was the rejection of strict hierarchical layering. After all, you don't want to have to wait while your OS negotiates its way through some convoluted hierarchy when it could potentially just use a few modules and be done with whatever triggered the context switch.

Summary:
The paper is about design of micro-kernel operating system. The system sees everything as objects (with capabilities) and places special importance in separating mechanisms and policies, thus making it a highly flexible system.

Problem:
The Hydra was an attempt for an operating system that makes efficient use of resources available on multi processor computer systems (especially, C.mmp system based on an array of PDP-11 processors), and also to enable creation of other such systems (that efficiently use multi-processor systems)

Contributions:
The biggest contribution is the concept of separating mechanisms and policies. The system provides facilities around which secure systems can be built, but doesnt by itself provide the security.
Another contribution is the "everything-is-a-resource" abstraction that simplifies the system design. Associated with it are the protection mechanisms in parallel processing environment by innovative use of capabilities (templates, check-rights, merged capabilties)

Flaws:
The system probably overdid the flexibility part a bit. It is impossible for every user to create his own file systems and do his own peripheral management subsystems.
Like other papers we reviewed, the evaluation hasnt been very thourough in this case as well. Though kernel has been made operational, the system was not usable, and it is not clear how it fared ultimately.

Relevance:
The paper stuck to its stated aim - designing a kernel that is flexible enough to create operating systems around it. Techniques used like splitting policies and mechanisms (in other words - interfaces and implementations) is used in modern operating systems like Linux (kernel modules, for e.g.)

Summary
A capability based kernel was designed to separate mechanism and policy as well as possible. The highly extensible kernel supplied minimal functionality for a multprocessor parallel system.

Problem
Supply basic facilities for a parallel system in such a way they allow for development of a highly modifiable system. The system needed to: Allow for policies independent of the mechanisms used to realize them, allow for non-hierarchical designs, include access control, and be reliable.

Contributions

• Attempted and justified a non-hierarchical system.
• Implemented a working capabilities based kernel. Flushed out all of the details involved with a capabilities based system.
• Local name space (a copy of the execution environment when a function is called), which allowed for recursion.
• Created a kernel with minimal functionality, which could be built upon, to allow new mechanisms need to implement arbitrary policies.
• Typed parameters with procedure calls.

Flaws
I felt this paper was well written with a number of good examples, but the boundaries of the kernel could have used a bit more clarification. For example, the paper gives a great description of how the file systems will be left to the user for implementation, but it does not say how the file system will interact with the disk. Will the disk have a standard disck object? Will the user need to modify the kernel for each disk type? Or supply a driver? A clear description of this boundary would have helped me understand how the system works as a whole.

Relevance
The paper seems especially relevant today with the increased popularity of multi-core processors. Beyond the items listed in contributions the paper gives a good contrast of the many decisions that can be made when designing a kernel.

Paper Review: HYDRA: The Kernel of a Multiprocessor Operating System [Wulf, et. al.]

Summary:

This paper proposes a set of kernel primitives atop which can be built
operating systems with their own more specific policies and features.
This kernel is proposed as a meta-environment to explore the space of
user-visible operating systems.

Problem:

Someone had apparently connected 16 PDP-11s together with a cross-bar bus
and wanted to utilize it effectively. The authors wanted to design an
operating system of "unversal applicability" and "absolute reliability"
that could virtually present the hardware resources effectively to
higher-level operating systems or subsystems.

Contributions:

The HYDRA design is resource-centric. The authors proposed that
resource management is the least-common-denominator in operating system
definitions, so if they provide that consistently and cleanly it would
be a suitable foundation for any other operating subsystem.

The HYDRA system explicitly separates policy and mechanism. That is,
policy is not implemented in the HYDRA kernel. For example, it provides
protection features that can optionally be used to implement security.

Flaws:

I found this paper very confusing, owing to the fact that most of it is
speaking very generally about philosophy of [meta-] operating system
design and introduces new and overloaded terms for its
components that are hard to assimilate quickly. The example at
the end of the paper is not interesting since it is preposterous that
one would build a bibliography application as an operating system atop
only the primitives provided in their kernel.

At the time of the writing, the authors had an operational kernel but no
user services and therefore show no justification for the optimism that
"the facilities provided by the kernel do indeed significantly simplify
the construction of [effective] subsystems."

Relevance:

Presumably this sort of meta-operating system or micro-kernel is
relevant today, especially as server computing is moving toward running
virtual machines on a larger hardware, rather than hundreds or thousands
of individual servers.