From: David Coleman (dcoleman_at_cs.washington.edu)
Date: Mon Jan 12 2004 - 15:27:58 PST
The HYDRA paper is an interesting discussion of a kernel-based
architecture for operating system exploration built at Carnegie-Mellon
University. HYDRA was built so that operating system exploration could
take place “on top of it” – an interesting goal derived from attempts to
experiment with inflexible systems. This goal influenced the design
significantly and seems to have produced a fairly flexible system.
However, HYDRA is a capability-based system. The design philosophy of
HYDRA emphasized several points, but two of them caught my attention:
separation of mechanism and policy and rejection of strict hierarchical
layering. Separation of mechanism and policy implements low-level
primitives but does not enforce any high-level policies (such allowing a
secure environment by providing protection primitives but not enforcing
any specific use of them). This is a very sound design principle and
often is overlooked resulting in less flexible systems. The rejection of
the strict hierarchical layering does not imply that layering isn’t used
at all, but it isn’t exclusively used or consistently used throughout
various subsystems.
The authors of the HYDRA paper very loosely define the purpose of an
operating system to be managing resources. In HYDRA, all incarnations of
resources are objects. HYDRA allows new types of resources to be defined
and fully supported (including protection). There is no concept of
object ownership in HYDRA – this allows a more flexible protection
mechanism.
A capability is a reference to an object along with the access rights to
that object. If an object is a procedure, a right might be executing
that procedure. If an object is a memory segment, reading and writing to
that memory segment would be types of operations that might be allowed.
New types will have program/user-defined rights. This ability allows
great flexibility in the protection mechanism. Objects can contain lists
of capabilities as well.
HYDRA has a local name space (LNS) that is essentially a list of
capabilities available to the operating process. Only capabilities
within the currently active LNS may be used, and only used as allowed by
the individual capabilities.
Procedures are represented as objects in HYDRA. Procedures are the usual
abstraction but, given that they are objects, with the addition of a
list of capabilities that can be accessed by the procedure. For each
procedure there is a list of capabilities that the procedure will
usually access and is known at compile-time and there is an optional
list of capabilities that can be passed in as parameters at run-time.
The parameter list of a procedure can be type-checked and can also allow
for the inflation of capabilities for objects. The LNS for a called
procedure is created upon the procedure call and destroyed when
returning to the caller. For instance, users outside the database
procedure might not be allowed to even read the segment, but the query
procedure would be allowed to read from the segment and return results
of the query.
The example section of the paper does a nice job of clearly explaining
the interaction between objects, capabilities and the LNS.
The concept of a kernel which allows for multiple operating system
implementations above it is an interesting one. Some of the design
principles are nearly universal to good design but were surprisingly
forgotten in earlier systems and are often absent in libraries and
primitives today. I’d be very interested in knowing about operating
systems built on top of HYDRA and how well the design principles worked
out under real usage conditions.
This archive was generated by hypermail 2.1.6 : Mon Jan 12 2004 - 15:26:09 PST