From: Praveen Rao (psrao_at_windows.microsoft.com)
Date: Mon Jan 12 2004 - 01:24:11 PST
The paper describes HYDRA which is a kernel for a multi-processing system, design philosophy behind it and the reasoning behind the design philosophy.
Authors set two goals for HYDRA:
1) Providing an environment for effective utilization of resources much like any Operating System
2) Facilitate creation of such environments through the flexibility of the kernel (which seems to be a much broader goal to me)
Authors state the following principles their design would follow:
1) Multi-processor environment
2) Separation of mechanism from policy
3) Integration of design with implementation methodology - This is an interesting one, while purists might argue to the contrary, I agree with this goal of integrating design with implementation methodology, since that it the practical choice.
4) Rejection of strict hierarchical layering - for flexibility - e.g. different hierarchy for control/resource allocation/protection
5) Protection - not just restricted to r/w/e, allow for extensibility of protection- allowed protection for all entities not just some specific objects e.g. files
6) Reliability - correctness as well as recovery from erroneous conditions
The paper argues great deal about flexibility - e.g. user should be able to create his own operating environment without being confined to predetermined command/file systems/execution scenarios and resource allocation policies - and this seems to be the central theme in the paper.
The key ideas in HYDRA design are:
1) Generalized notion of resource
2) Execution domain
3) Protection mechanism
HYDRA Environment
HYDRA environment has the following primitive object (instances of resources) types: procedure, LNS, process.
Procedure object - contains list of references to other objects which must be accessed and also a list of capabilities to say what actions can be performed to those objects. Capabilities have two groups: caller dependent and caller-independent.
LNS: While procedure is a static entity, LNS is the record of the execution environment. LNS for a particular invocation is a result of combining caller dependent and independent capabilities. (Capability consists of reference to an object together with a collection of 'access rights'. Capabilities are only manipulated by kernel.)
Process: Process if a unit of asynchronous processing. A process is a stack of LNSs which represent cumulative state of a single sequential task. Inter-process communication is implemented using elementary message buffering and synchronization is implemented using semaphore. These details though are not the focus of the paper.
CALL mechanism - an executing body notifies kernel that it wishes to make a call. Kernel checks protection requisites and creates a new LNS for the call which gets deleted when call returns.
The protection mechanism
The paper makes a distinction between protection and security. Protection is a mechanism, security is a policy.
Hydra provides a protection mechanism for the application of operations (procedures) to instances of resources (objects).
Protection mechanism has three primary aspects -
1) objects
2) capabilities
3) Rules governing passing from one execution domain to the other
Each object has unique name, type part and a representation (which, in turn, consists of data part and capability part). Data of the objects can be manipulated by programs but capabilities can be manipulated only by invocation of kernel functions.
Capabilities are references to objects. Capabilities are key to the protection mechanism (IMO capabilities are analogous to handles in modern OSes)
Rights can be type-independent (kernel rights), type dependent (auxiliary rights). A right grants a permission to pass capability as a parameter to any procedure of a particular class.
At any instant execution domain of a program is defined by an LNS object. The capability part of LNS contains references to objects which may be accessed by that program at that instant. LNS provides a mapping function between local names in a program to globally unique objects. LNS is uniquely associated with a procedure and thus execution domain changes when procedure is entered/exited.
The paper then describes how systems and subsystems can be built upon these primitives. It argues immense flexibility in building such sub-systems resulting from objects containing data as well as capabilities and the nature of the protection system.
It also provides an example which highlights the flexibility of HYDRA vis-à-vis a simple system with non-extensible file primitive.
Overall, the paper does make convincing arguments about flexibility of kernel, although at the time of writing of the paper there wasn't a full-fledged sub-system on top of the kernel. This makes it hard to evaluate whether this flexibility comes at a cost of - say - performance or complexity. I can't draw straightforward parallels between this design and the current popular OSes, which makes me think that there might be overriding practical considerations. I can somewhat liken the call model to Code Access Security in Java and .NET VMs.
This archive was generated by hypermail 2.1.6 : Mon Jan 12 2004 - 01:24:15 PST