Paper Discussion - Fall 2008 - CS 736

Summary
The HYDRA paper is similar in spirit to the "Nucleus of an operating systems" paper in that it aims at providing the most primitive adequate set of facilities for the construction of a large class of operating environments.

Problem attempted
The HYDRA system has been designed with the objective of being the kernel base for a collection of operating systems that puts to best use the power inherent in a multiprocessor system. Additionally, it aims to provide the environment for the design of a plethora operating systems that achieve the goal of effective hardware utilization.

Contributions
1. The paper gives a whole new approach to protection mechanism. The mechanism is intuitive and the protection it offers extends to any object in the system, rather than just files. Each object in the system has a unique name, type and a representation consisting of capability and data. The capability is a reference to an object along with the access rights to the referred object. Requiring that capabilities be manipulated only by kernel results in a thoroughly protected system.

2. The way in which the capability has been put to use in procedure calls where the calling procedure passes its capability and the call becomes successful only upon verification of access rights is novel. This has resulted from the notion of regarding a procedure also as an object.

3. The paper lays adequate stress on the importance of separation of policy from mechanism. The authors have explained how the protection mechanism in the system is just a mechanism and a variety of security policies can be implemented.

4. The execution domain of a procedure has been implemented as another object named the Local Name Space. LNS stores the totality of capabilities available to a procedure during the execution resulting from a particular invocation.

5. A walk primitive has been implemented to ensure that the objects named by the capabilities in the LNS are not the only objects present in the procedure's environment. As we would expect, it is the set of all objects reachable along a path originating from the LNS. It would have been very difficult to store all these capabilities in LNS but for the presence of such a primitive.

Flaws
1. The paper does not implement the concept of ownership for files (or any object) for the sake of providing protection at a granularity finer than the per-file protection. It can be left to the user to decide what is to be put on a file so that he could achieve his desired protection rather than abandoning ownership concept for a file. Absence of ownership gives rise to issues in disk space allocation between different users of the system. It also necessitates storing the capabilities of every user for every single object in the entire system as no object is owned by any user.

2. There is nothing specific in the design that makes HYDRA a multiprocessor operating system except that it was designed to run on a multiprocessor operating system.

What it makes easier

1. The paper rejects hierarchy, which is a good feature that avoids setting any self-imposed restrictions to the system. For example, we say the inflexibility in "THE" system when it comes to adding one more layer to the strictly hierarchical system.

2. The HYDRA system does not decide on any directory structure. This gives the flexibility of implementing a wide range of directory structures that suits the task at hand.

What it makes harder

Having a separate LNS object for every invoked procedure may be a huge overhead, particularly in the case of recursive calls where the same capability information will be stored repeatedly.

HYDRA: The Kernel of a Multiprocessor Operating System

This paper introduces the design philosophy of HYDRA, a micro kernel that provides certain basic facilities to the different operating systems that can be built on top of it. A difference is made between policies and mechanisms, and HYDRA obtains its flexibility by only implementing mechanisms leaving the policies for the higher level programmer. Objects are introduced as a general notion for resources and capabilities are used as references to objects with access permissions to those objects. Mechanisms perform different actions on different objects.

This research focuses on how to provide flexible basic mechanisms to build protected operating systems. A procedure is an object with a list of capabilities for the objects that it accesses; some of these capabilities are caller independent and some are caller dependent. When a procedure is called a LNS object is created with the list of capabilities available to the procedure in that particular execution, when a procedure finishes the corresponding LNS is deleted. The kernel needs to check that the protection requirements are met and then create the LNS, if the protection requirements are not satisfied the procedure will not execute. With these mechanisms available different subsystems can be developed.

The concept of ownership is rejected and also the hierarchical layering used in other popular systems is questioned; both these concepts frequently used in operating systems are presented as inflexible and not secure enough; as an alternative they present capabilities and a more modular structure for the kernel. The idea of the LNS object type to store the execution environment in each point in time is still used today and is a very good solution to return to the caller of the procedure that just finished. Capabilities are applied to all the resources in the system as the way of providing protection; they can only be modified by the kernel and every object may have capabilities for accessing other objects.

The first flow is that the paper is supposed to introduce the kernel for a multiprocessor system, but the introduced mechanisms have no particularities for multiprocessor systems; the described procedures are sequential. The paper talks in a general way of meaningful mechanisms that would be provided by the kernel, but none is mentioned in particular. The main purpose of this kernel is to be used by higher level subsystems, but apart form the file system no other example is mentioned, no comments are made about memory management or I/O devices. No recovery mechanism is introduced, we know that if the capabilities are not satisfied for a certain procedure call the procedure is not executed, but what happens if the procedure is called and it fails. No evaluation is presented, the kernel has been operational for nine months but no subsystem has been yet developed. They do not provide any information about how the kernel has been implemented, what programming language was used.

This perspective makes the structure of the kernel more complicated to design and implement, but gives more flexibility to the operating system designers and the potential of developing operational systems with very different characteristics from the common ones.

Summary:
The paper proposes HYDRA, the kernel of a multiprocessor operating system, which is implemented in C.mmp hardware. By introducing that everything like procedure, LNS, and process can be considered as an object, the paper describes the protection mechanism for these objects mainly; it also proposes the system can be built without strict hierarchical layering.
The problem the paper was trying to deal with:
The authors try to implement a HYDRA system which provides mechanisms to create highly secure and effective system and provides a multiple operating environment. The system also implements the separation of mechanism and policy by giving the flexibility of the policy to the user, and it also doesn’t use idea of strict hierarchical layering to give more flexibility to higher lever user.
Contributions
1． The system implements the separation of mechanism and policy by giving the flexibility of the policy to the user.
2． The system doesn’t use idea of strict hierarchical layering to give more flexibility to higher lever user.
3． Three primitive objects, procedure, LNS, and process are provided to create and manipulate an execution environment. For call mechanism, a callee must get a new LNS and environment to begin execution, once it complete its function, callee’s LNS is deleted and previous environment is restored. And process is a stack of LNS’s which have ability of asynchronous processing.
4． By introducing the idea of objects, the HYDRA system implements the abstraction of physical and virtual resources into an object-oriented level.
Flaws:
Chaining of all types of objects increases the extra overhead of the implementation of the system. And the Paper doesn’t talk about inter process communication, multiprocessing and resource allocation for which HYDRA was developed.
What it makes easier:
After implementing the abstraction of physical and virtual resources into an object-oriented level, it is easier to implement a secure and flexible multiprocessing operating system with the separation of mechanism and policy.
What it makes harder:
The rejection of strict hierarchical layering will make the implementation of the system harder. And the complicated protection mechanism, the specific primitives like path names and walk right, and the sophisticated interrelationships of different primitive objects would make system be harder to implement.

Summary
This paper introduces the micro-kernel based Hydra OS designed for the C.Mmp. The design of this OS seems to concentrate more on the operations(procedure) performed on various resources(objects) and how to provide protection facilities for these operations without limiting the policy decisions at the higher levels.

Problem
The authors want to design an OS that is flexible enough that anyone can make policy decisions on the top of it. They want to provide a system that is secure, reliable and can handle multiprocessor systems.

Contributions
- In this kernel, they have decided to just implement the basics and leave the decisions to the higher levels. They provide the mechanism to implement any policy that the user requires. Accesses on each object is controlled by the capability list stored within each procedure(which is also an object). But the decision of how these capabilities are assigned are left to the higher levels.
- Each user can choose its own environment. This allows having multiple systems(having its own objects and procedures) which perform basically the same function and user can decide which ones to use.
- The OS was designed keeping the protection of the system in the mind unlike other OS's where security was the last thing added. As a result it provides protection at the granularity of each operation by using capability lists for each object that determine what actions it can perform.
- Fewer kernel level operations are needed in this system as the capabilities of a callee can be more than that of a caller.

Flaws
- Since there is no ownership in their design, its difficult to charge these objects(e.g. files) to anyone's quota.
- No lower level abstractions have been discussed in the paper, such as processor scheduling, memory management.
- Because of the lack of structure, it gets complicated to understand the interactions between the various objects.

Design
Each resource is modeled as an object and it has references to other objects called as capabilities. Capabilities also decide what operations an object can perform on other objects. These objects are passed to other procedures which may then expand the capability list. As a result, you don't need the kernel threads for all privileged operations. These references result in an object tree where paths can be used to refer to any object within this tree.

Easier
- To add security policies using the capabilities list.
- To plug-in different sub-systems within the same operating system and select the ones appropriate for each task.

Harder
- To understand the path taken by each procedure call as there is no fixed structure.
- To debug the system because of the added complexity.

Summary :
Paper describe the design philosophy of the HYDRA system which is based on structural programming concept involving object,capabilities and procedure .

Goal :
Build a system in which kernel provides mechanism to implement policies at user level program. In other word separate the policy decision from kernel and provide user enough facilities to implement policy at user level program

Contribution/Work Summary :
1. HYDRA is based on 'Structured Programming' model in which resources are presented as object to user and only way user can manipulate or access these object is procedure defined as part of object.
2. Protection to object is provided through capabilities .protection facilities is entirely built in kernel .
3. Separation of policies and Mechanism provide greater flexibilities to user . Author argument is that its really difficult for system designer to find policies which will work in all scenario and such policies usually constrain the application developer .
4 . new prospective to system design is provided by rejecting the hierarchical layering in system which limit the flexibility and reduce the experimentation .
5 . paper introduce the Template concept in which a particular procedure can be called with different capabilities . current programming model also type independent method or class . which seems to be inspired from this template concept.
6 . This design also introduce to LNS which is very similar to Function stack of modern days Programming language . Till no most of the system were sharing address space but LNS provide a different address space for each execution of procedure.

Flaws :
1. Its impractical to leave all policy decision to user level program as there will be situation where some application might try to monopolize the resource so OS need to have some kind of policy implemented.
2. Protection mechanism is entirely built in kernel . so kernel is responsible for each object's access and need to verify each and every access to object . This seems to be limitation to scalability of system.
3. Handling of capability becomes really complex as no of procedure implemented in object increase and object is inherited by some other object .
4. For garbage collection purpose each object keep the count of reference . this do add lot of overhead whenever a reference is created or removed .

Made easy :
1. By representing each resource as object and operation permit-table as Procedure its easy to implement a secure and flexible system with custom policy .

Made difficult :
1. Balance between flexibility and protection is really difficult. By protecting a resource against a particular action we might be compromising with flexibility or vice-versa.

PS : I referred to following paper on HYDRA -
1.'Policy/Mechanism separation in HYDRA', R. Levin et al.
2. Overview of the HYDRA operating system development, W. Wulf et al

The paper describes the kernel of a multi-processor operating system which employs a capability based model for security over objects in the system. This protection mechanism is the underlying theme of the paper.

The heart of the problem discussed in the paper is the separation of policy and mechanism. The kernel is designed to incorporate mechanisms while excluding policy. For instance, security which constitutes policy is not built into the system, but rather a set of protection mechanisms are provided which can be utilized by the policy-making entity (OS built on top of the kernel) to provide for security. Similar is the treatment of filesystems.

The kernel is built around objects. The primitive objects (procedure, process and LNS) together define execution environments. Instances of resources like files are also objects. Objects have associated capabilities which define how they can be accessed/used; this forms the core of the protection mechanism. The creation of execution environments through merging of capabilities allows for callee procedures to have greater permissions than their respective callers. And the walk primitive allows for object discovery.

The object oriented approach allows great flexibility in organizing programs as objects interacting with other objects. And with the capability model, each object can take care of it's own protection (of-course with a bit of kernel help). And the capabilities and walk primitve together forms a good base to build higher abstractions like the filesystem example described.

However, the system requires the kernel to arbitrate every procedure call and object interaction involving capabilites, and hence the system is likely to suffer in terms of performance. The system could also be memory intensive, given the book keeping required for the capabilities, references to them etc.

The key contribution of the paper is the separation of mechanism and policy. The fine grained protection mechanism developed through the use of policies, and the development of the concept of execution environments are other major contributions.

On the flaws side, I felt the claim on rejection of strict heirarchical model not sufficiently substantiated. The paper does not devle into all those details, it just confines itself to the discussion of capabilities and objects. And in that respect the paper seems slightly mis-titled.

Summary

The paper discusses the design principles behind Hydra multiprocessor os kernel. Key philosophies are a) separating policy and mechanism to build a kernel, having only the essential features for universal applicability with absolute reliabilty, that allows building vast number of system with varying requirements on top of it b) generic handling of all types of resources by abstracting them as objects c) providing protection as part of the kernel by defining capabilities in the execution environments that define how objects can be accessed through procedures.

Description of the problem being solved

The problem is to design a multiprocessor os kernel with only the essential features on top of which vast number of system varying in their policy requirements can be built on. Some essential features would be primitives for efficient and fair resource usage, sharing of resources and protection while sharing.

Contributions of the paper

1. Clear separation of policy and mechanism: This helped in providing only the essential features for universal appliacability.

2. Concept of Execution environments that control processes & procedures in accessing resources.

3. Kernel supported capability based primitives to solve most of the protection and security requirements that can arise for real world systems. Good capability extension primitives like "path names & walk right", "extension of capabilities in the callee procedure from the caller's capabilities"

4. Removing structured layering of the kernel and the concept of ownership over resources to lay the basis for a fair and protected resource usage world.

Flaws in the paper

1. Lack of a formal specification led to debugging complexities and this was not given due thought while design. Writing software in a protected execution environment like this needs a good debugging mechanism. This is also noted in the related paper on "Overview of the Hydra operating system development" at http://portal.acm.org/citation.cfm?id=1067629.806530

What is made easier?

1. Since policy is completely taken outside the kernel, building systems with almost all kinds of policy requirements over resource usage is made possible and easier.

2. Because of the protection primitives like execution environment, capabilities, walk paths,etc software systems with almost any kind of protection mechanism requirement can be built on top of this kernel.

What is made harder?

1. Design of a software system that will run on top of this kernel needs to be rigorous because of the informal layering of kernel and the sophisticated protection primitives like capabilities, walk paths and callee's extended capability set.

2. The kind of rigorous design of software is often not feasible in practice and therefore leads to debugging complexities often.

This paper is about the design of an operating system framework which is designed to include protection by making available kernel protection mechanisms while leaving the flexibility of the policy up to the user. The system creates self contained LNS spaces for executing procedures and each object has a list of references to which access is allowed known as capabilities. The Hydra operating system also tries to incorporate non-hierarchical layering, reliability and multiprocessor capabilities.

The Hydra operating system is trying to solve the problem of integrating protection mechanisms into the operating system while still making the system flexible and freedom to choose the security policy.

The Hydra operating system has contributed the idea of integrating security/protection mechanisms into the kernel system development. Prior to this time, security mechanisms were overlooked during the development and implemented later in the operating systems life. Additionally the idea of isolating the execution environment of procedures to protect the state of the application adds a layer of robustness and possibility for recursive procedures in the operating system. In addition, the protection strategy is very versatile in privileges expanding the ideas of protection mechanisms in operating systems.

The Hydra system makes is very difficult for the system to be maintained. For example, there is no simple way to make backups of the data unless there is an underlying unsecure method of reading the entire object structure. It may also be possible for a user to remove modify access to a file and not be able to delete or free up resources in the future. Also the idea of infinite resource names with only a 64 bits naming space is not true as file count increases over time. Finally, the Hydra system is still developing the subsystems therefore the complete system is not show design effectiveness in reliability or functionality.

Hydra is organized as a non-hierarchical system that abstracts the resources as objects. Each object contains protection capabilities pointing to other objects access is permitted. This system makes it easier to design secure applications during development since the OS has built in protection mechanisms, but can add a level of complexity that might be ignored when developing applications under time constraints, and only adding overhead to the application that doesn’t make use of a policy.

Summary
This Paper discusses the design principles of Hydra, the kernel of an operating system for Carnegie-Mellon Multi Mini Processor. It generalizes on the notion of resource, both physical and virtual, called an object, the definition of an execution domain, and the protection mechanism which allows or prevents access to resources within domain.
Problem they are trying to solve:
The problem discussed here is designing of kernel which resolves the inflexibility of user programs and provides a better resource allocation scheme. It eradicates the hierarchical system to remove the default access and control rights as per hierarchy.

Contribution of the Paper:
1. The Simple notion of defining all resources as objects, they can be passed between different objects and protected. The concept of capability, thus handing over the object rights to anyone with proper access rights provides greater flexibility. However, the resource manager is provided with the all the rights.
2. Mechanism and Policy: The act of separating out the both leads to higher flexibility to the system. Handing over the policy making to high level designer reduces an over head from implementer.
3. Discarding Hierarchical File system and treating all the files at the same level, giving them a unique name all over the system, provides the user with the greater flexibility to maintain its own abstraction.
4. Local Name space is record of execution of execution environment for the procedure executed. There are unique LNS for each procedure execution, which disappears at termination of procedure.

Flaws
1. Hydra involves creation of huge number of objects for everything, so they would occupy huge time and space. Recursion procedural calls with same capabilities leads to creation of same copy of LNS, thus this is wastage of memory space.
2. The Paper doesn’t talk about resource allocation, Inter Process communication, Paging and multiprocessing for which hydra was developed.
What it makes Easier
1. Hierarchical Architecture, resource abstraction and separation of policy/mechanism provides user programs with more implementation flexibility and doesn’t restrict them in design approaches.
2. Introduction of capability and protection bits enables the user to share resources amongst other users while securing the data and hiding the layout design.

What it makes Harder
Introduction of protection bits might cause some unwanted problems. The caller has to decide upon the protection bits of cal lee, but those bits might not provide the correct access in the execution environment. The chaining of protection bits from one procedure to rest, can lead to a state where a subroutine might not have access to an object, which it was supposed to have. This concept includes an extra overhead to be taken care by caller each time and needs extra attention.
The huge flexibility in the hand of user program might scare them off, a user program expecting some hierarchical control might have to implement it itself and wouldn’t be interested in using hydra low level abstractions.

Summary: This paper describes Hydra, the base for various multiprocessor OS's. The core of the system's philosophy is the separation between mechanism and policy supported by the view that everything is an object.

Problem: The authors openly reject a strict hierarchical layering. Thus, their problem is how "to maintain order in a nonhierarchical environment", in such a way that mechanisms are provided, but no policies. An important particular case is how to offer 'protection' without specifying a 'security' policy, and without the notion of ownership.

Contributions: I think that the novelty of Hydra is a clear separation between mechanism and policy across the entire system. This is done by using an almost Object Oriented view for OS construction. Resources are generalized as objects. Objects have types, and types are special objects. Procedures are objects. Capabilities are references to objects and are required to access objects, in particular to perform CALLs. Local Name Spaces, are dynamically composed of capabilities and they define a function's execution environment. Capabilities are manipulated only by the kernel (which provides the right to 'walk' capabilities). In Hydra, all these objects and rules form the base for OS construction.

Organization: In Hydra, an object has a unique name, a type, and a representation. The representation is composed of capability and data. A procedure's capability has a statically defined component and a template for processing the 'parameter' component supplied by the caller. Static capabilities insure that callees can have more rights then the caller. A procedure is invoked using the CALL mechanism which traps into the kernel. The kernel is responsible for checking required capabilities and continuing the CALL only if enough capabilities are provided. However, the kernel doesn't need to know the meaning of the capabilities. A process is a stack of such CALLS and their corresponding execution environments.
Objects are deleted if a reference count becomes zero.

Weaknesses/Flaws: Although HYDRA offers a very flexible set of 'building blocks', it seems that this comes at a high cost both in time and space. Without a higher level view, each system call has to go through a lot of overhead to process capabilities and verify permissions. Bookkeeping the capabilities requires a lot of space too.
Hydra offers a lot of flexibility, but it is not clear if it is easy to work in. It looks like it is easy to make mistakes: it is possible for a user to create new objects without having the right to delete them; or to create circular references for inaccessible objects. It is also unclear how easy is to retrofit/add new rights into an existing system (example: right to inspect data and time creation in a file system).

Summary: This paper presents HYDRA a kernel implementation for building operating systems, which focuses on providing mechanisms for protection. Using the abstraction of resources into objects and the use of capabilities the authors are able to create a flexible implementation of mechanisms that provide a kernel to build on without strict layering or language dependence.
Problem to Solve: The authors goal was to build a base on which operating systems could be built that separated mechanisms from policies and provided a way to create secure systems through the use of abstracted objects. They wanted to avoid hierarchical layering that limited flexibility and allow the system to be reliable in a variety of ways.
Contributions: One important concept that came out of this paper is the idea of building a secure system that was versatile. The authors showed that by implementing a few key mechanisms a user could define whatever type of security they needed. Another important point is that procedures, LNS and processes can all be abstracted into objects which are used in the execution environment as a way to communicate with the underlying hardware. This is important because it showed that it didn’t matter if something was virtual or material, it could be abstracted in the same form for use. Lastly, the introduction of templates is a form of type-checking. This allowed the kernel to know what type of data it was expecting and to throw an error before the parameter was passed to the actual procedure, which helped increase reliability.
Flaws: There is almost no evaluation of the HYDRA system presented in the paper and in the conclusion it says that the system has been running for nine months. It seems very unclear as to whether the implementation they are running is the kernel they have described or if they built upon it to create an OS since they talk about adding a file system to it. Another flaw is that they say they use something similar to semaphores, but never explain this in further detail to show that objects are protected from accidental overwrites.
Advantages of Proposed OS: One advantage of this system is the ability of a user to define their own policies so that different levels of security can be achieved based on the needs of the system. HYDRA has the base code implemented for protection mechanisms to support these policies, thus it is easy for a user to define and change these as requirements change. Another advantage of this system is that HYDRA is like a microkernel and thus it is easy for different subsystems to be built upon the base to create an OS for a specific purpose. Another advantage is that the use of capabilities on all objects provides a framework that prevents malicious procedures from accessing objects it shouldn’t have control over for protection purposes and ensure reliability
Disadvantages: Since HYDRA aims to provided an efficient implementation of a kernel some basic components are not included in the system such as a file system. Although this does provide flexibility, it is a necessary component of an OS that without it makes the OS slightly useless for a user.

Summary:
This paper presents Hydra, one of the first multiprocessor kernels, developed for C.mmps architecture. Notable features of this system are its minimalistic design philosophy and providing flexibilty and protection at the same time, along with the idea of execution domains.

Problem:
This paper discusses a minimalistic kernel with a generalized notion of resources (object). Further, it associates these objects with capabilities and allows the existence of an arbitrary number of subsystems.

Contributions:
- Like Nucleus, the authors advocate a micro-kernel approach for Hydra. They also clearly separate mechanism and policy, with Hydra mostly implementing the mechanisms.
- Unlike Pilot, Hydra advocates structured programming of Djkstra and modularization philosophy of Parnas. Pilot on the other hand, bears remarkable resemblance to the organization that built it, by coupling it to Mesa.
- It strictly discard the idea of heirarchical layering (\cite{djkstra:The}) and ownership for security.
- Capability-based protection for a generalized definition of resources or objects. Objects could be procedures, local name spaces and processes.
- Allows addition of user-specified subsytems.
- Idea of execution domains, defined by LNS for a procedure in the form of caller and callee-dependent capabilities.
- Idea of right lists - both type-independent (kernel rights) and type-dependent (auxilliary rights) associated with capabilities.

Flaws:
- Though the paper's title promises Hydra to be explicitly as multiprocessor kernel, there is very less description about it.
- Capabilities are references to an object. An object is deleted when its reference count goes down to zero. Self-referential structures will require a garbage collection mechanism, which does not exist in Hydra.
- For each new object (even with a representation of an existing object, like file); Hydra forces the creation of completelty new procedures without any reuse.

What it makes easier?
- The design philosophy discards the strict heirarchical layering in OSes. This forms the basis of modern systems today.
- Concept of execution domains is very relevant to OS today for virtualization.

What it makes harder?
- Many-a-times, Hydra suffers due to its own design philosophy, eg. the cost of high degree of modularization. As mentioned earlier in flaws, code re-use is minimal because of unique representation of objects.

In this paper, the authors present Hydra, a capability-based kernel for the C. mmp multiprocessor. Firstly, they describe the design philosophy of Hydra and then they present the basic features of the system.

The main goal is the creation of a basic kernel which supports a number of operating systems to run on top of it and simultaneously provides the users with flexible and reliable mechanisms, so that they can easily construct operating system policies and facilities.

The system uses three primitive objects (process, procedure, LNS) which are used to create the execution environment. Users can also create objects which represent physical and virtual resources and define operations on them. They can also link them. This gives them great flexibility, as they are not constrained to follow a specific policy. For example, they can create a file system by creating objects for files and directories and defining operations on them. Another contribution of the system is the permission model. Users can run a procedure on an object only if they have a capability to run this procedure against the object. In this way, different links can be placed between users, procedures and other objects. A user may not have direct access to an object, but can have the right to call a procedure that operates on it. Very important is the fact that a procedure called by another procedure may have greater freedom to operate on an object than the caller. Finally, the primitive walk is a very interesting idea. By using the primitive a procedure can find all the capabilities available to it. Moreover, it is used to prevent access to an object.

In my opinion, the system will probably have a bad performance as it can easily become very complicated. Even if we have a few procedures and objects, a lot of links can be created among them. In this way, finding, for example, the operations that can be used on a specific object by a user, becomes a complicated task.

The main advantage of the system is its very flexibility. Users can easily define complex policies. Moreover, the system seems to provide a good protection mechanism as the permissions for each object are well-defined.

Summary
The paper introduces HYDRA, a kernel of an operating system designed to support objects as a general abstraction of resources and capabilities as a protection mechanism.

Problem
The goal of the system is to implement a reliable and universally applicable kernel for a multiprocessor environment.

Proposed Organization
The HYDRA system was designed with a certain methodology and goals in mind. Specifically, mechanism and policy are separated, so as to give any higher level system flexibility when making policy decisions. The design is influenced by the methodology of structured programming and modularization. The organization proposes objects as general abstractions of resources, and capabilities as a protection mechanism. A capability is a reference to an object and details what operations may be performed on the referenced object. The referenced object may have more capabilities than the referencer who performs an operation, or vice versa. As such, security policies are not inherently defined, but capabilities allow for security as determined by higher level designers.

An object consists of a unique name (64-bit integer), a type, and a representation consisting of data and a list of capabilities. The type is the unique name of an object serving as the representative of the class of objects of that type. It does not appear to be addressed well, but presumably there is a mechanism to create a new object from a type. Specifically, with regards to execution, there are three object types of note: procedure, LNS, and process. A procedure is a static abstraction of a subroutine, the LNS (local name space) is the record of an invocation of a procedure, and a process is the smallest schedulable entity.

An advantage is that the kernel provides a great deal of flexibility to the designer when deciding on policy. A disadvantage is that, on first look, it appears it would be potentially difficult to create programs that take advantage of the flexibility provided with good performance.

Contributions
The system provides a number of abstractions that are used to this day and contains language at times suggestive of object-oriented programming. As such, the system can be viewed as a success, even though the system didn’t catch on and it was seemingly over-complicated at times in its desire to be universal.

Flaws
It was alluded to that the cost of using these objects (specifically procedures) is considerable, and if so, this could have impact on higher level designer using (or not using) the flexibility of the system in the ways envisioned. As well I found, in my case, that the organization of the paper did no favors when trying to understand the system.

Summary
Wulf et al., in “HYDRA: The Kernel of a Multiprocessor Operating System” describe the design of an operating system core which generalizes resources as “objects” and provides for protection and interaction between these “objects.”

Problem
Hydra was created to provide a set of flexible facilities, a type of “kernel”, of “universal applicability” and “absolute reliability” upon which other systems could be built. Two important goals which, according to Wulf, had not been implemented sufficiently well in the past (hence the design of this system) rested with providing resources in a sufficiently abstract manner and ensuring protection between programs. This increasing emphasis on security was necessary as more systems that supported an increasing number of users were built.

Contributions
• Creating an advanced protection system which gives the user permissions to execute procedures (any subset of which can be allowed for some user) upon a variety of objects (which can also be tuned to only be accessible by certain users). Furthermore, the capability granting system allows for calls from an object upon which a call is made to other objects, and these calling objects can have different permissions to the callee than the original caller had.
• Abstrating a variety of resources into easily accessible objects with interfaces that made it easier to interact with these resources. Additionally, allowing for a means by which new types of objects could be defined and created, each with a different interface available.

Flaws
• This paper appears to be inappropriately named—while the title suggests that the topic would address issues with efficiently utilizing a number of processors and detail issues with consistency and communication among processors, the information addressed is actually in regards to security, communication, and protection among user programs.
• An issue that was even suggested in the paper (“the cost of entering a HYDRA procedure is greater than a Fortran subroutine”) was that the system, due to all the additional work it needed to do to provide and enforce the permissions, could be quite slow compared to other systems of the time.

Organization
Hydra is designed around the abstract notion of objects and the resources which they represent. The system is primarily guided by the procedures being invoked and acting upon a variety of objects, all of which have a separate execution environment (the LNS) and which can in turn internally make use of other objects. This provided abstraction provides a wealth of control, especially in that new types of objects can be created.

Introduction:
This paper describes the philosophy and concepts behind the HYDRA operating system kernel, built for the CMU multi-mini-processor. This paper focuses on the resource abstraction part of Hydra, without going into either the low level details(like scheduling) or the application/user level details.

What were they trying to solve:
Unlike UNIX, which focused on timesharing on a single processor, and Pilot, which focused on single-user personal systems, HYDRA is built for a multiprocessor system. The author's goal was to create a flexible and reliable base for creating multiple operating environments, with security and protection inherently built into the system.

Contributions:
One of the earliest systems built from ground-up targeting multiprocessor systems.
Reliability, Security, Protection being integral part of the design: As Prof. Swift said in class, in most systems of the day security was added to the system as an afterthought.
High level of resource abstraction via objects: HYDRA extended the abstraction of physical and virtual resources to an "object-oriented" level. Resources have types, they can have arbitrary operations defined on them.
Fine-grained security: The single biggest feature of HYDRA is the protection mechanism. Access to every procedure and object is controlled by rights. References between objects are controlled via capabilities, which are pointers with some extra protection related bits. The protection mechanism is so designed that a malicious program cannot accidentally get additional permission.
The separation of mechanism from policy. Since one of the design goals is to create a flexible system, the kernel only provides ways to achieve some result, while it is the responsibility of the higher level software to implement how that result will be utilized.
Removal of the owner concept: Traditional systems have an asymmetry concerning resources that a certain user is designated as the "owner". This is not present in HYDRA, where a resource is not owned by any user, but shared across users based on their permissions.
The idea of a walk traversing the object graph of resources simplifies writing a procedure. Also, by adjusting the walk privileges on certain objects, we can restrict the usage of the object by the procedure.

Flaws:
Performance is likely to be this system's biggest problem. Since there is a protection boundary between every object, this will be a significant overhead for the kernel.
Since low level details are missing in this paper, it's not known how things like scheduling, mutual exclusion etc are implemented. Since this is a parallel processing system, these are not issues that can be neglected.
The paper is not clear if capabilities are persisted across sessions or not.

OS Organization:
The authors state that they consciously chose not to have a hierarchical system, since it was not flexible. The system comprises of objects which interact with each other controlled by capabilities. The process forms the smallest schedulable entity, which executes procedures(which are themselves objects), with the state of the process stored in a stack of LNSs(local namespaces).
Advantages:
Very fine granularity for protection: Each object can specify what operations are permitted on it by each procedure. This makes it very unlikely that a malicious piece of code gets more rights than it should.
Disadvantages:
Programming such a system would be a nightmare. The system would grow into large loosely-structured graph of objects and procedures, making it difficult to change or update it, since a change in one part can affect other parts.

PS: This link sheds some more light on the HYDRA system.

Wulf et al present HYDRA as a "kernel of a multiprocessor operating system," but the subject of their work here is not well-described as such. Wulf's core contribution, instead, is a tidy protection mechanism with which one is able to implement arbitrary access policies at a higher level. He accomplishes this by employing the kernel to perform access checks at procedure boundaries, and encourages users to employ these boundaries wherever a significant change of context occurs.

The discussion of protection versus security is very astute here: Wulf defines the latter as a policy-driven application of the former, and so identifies protection as a nuclear device which belongs in the operating system. Below this, objects (conceptually equivalent to data) and their capabilities (functions which may be applied to an object) are separated into separate lists. These lists may then be compared against the permissions of the requestor (presumably another list), which reminds the modern programmer of schemes implemented with related database tables in web applications. Such programmers will note that, when applied to the correct problem domain, this mechanism works very well.

The programmer may use this protection mechanism by using the Hydra system calls "CALL" and "RETURN" to switch contexts. He may do this (or not) at any point, but the suggestion made is that these calls be used at boundaries where protection should be re-evaluated. The programmer is, in fact, under no obligation to use these abstractions, which alleviates some well-founded concern over the performance of the mechanism. A program with many such contexts, however, would find itself slowed considerably by constant checking of types and permission bits, especially as CALL and RETURN involve additional kernel/user context switches.

A good evaluation of this mechanism would include measurement of performance impact together with a structured evaluation of a programmer's ability to use Hydra protection to his benefit. The authors present no such evaluation. As such, any judgement made for or against the design may be cautious at best. An opinion over the work may, however, be greatly soured by the apparently unrelated title. The introduction following iterates and re-iterates the emerging significance of multi-processor hardware systems, and suggests that this body somehow addresses the new space they present. Following this, however, the issue is not revisited, and one is hard-pressed to find any feature of Hydra's protection system which is more pertinent to multiprocessors than to any other system.

HYDRA: The Kernel of a Multiprocessor Operating System describes the structure of an operating system with a highly-abstract, advanced permissions model that lends extreme flexibility to users constructing software to run within it.

This permissions model consists of an interaction between users, procedures, and
objects. The users can run a procedure against an object if they have both been granted access to the procedure and a "capability" to run it against an object. A capability is simply a relationship between a user and an object that states the procedures the user is allowed to run on the data the object contains.

The paper does not provide many examples of objects, stating that they represent
"resources". Presumably, objects serve both as a named, abstract interface to machine hardware and as logical collections of data and procedures. For example, a user might print to a printer object or search a database object (both of which hide different types of complexity).

Objects can also invoke procedures on other objects, again provided the proper
capability is defined. A procedure can explore the capabilities of the objects
it is aware of using the "walk" primitive. These objects may or may not allow the procedure to enumerate their capabilities based upon what is allowed to walk them.
It appears that a procedure can explore all the capabilities available to it using this approach.

A likely weakness in this permission model is the overhead involved in the kernel
mechanism that checks if each procedure call can be allowed to run. For example, note the authors are interested in building a file system out of these abstract objects where directories link to files. This could make crawling deeply nested directory structures prohibitively expensive.

Another performance weakness in this system is the need to keep a reference count for every instantiated object. A more pragmatic approach might entail defining a delete kernel primitive and the necessary capabilities for processes to use it.

A strength of the permissions model is its incredible flexibility: it is easy for a programmer to represent complex security policies and write modular code that can be reconfigured or replaced without much work.