From: Raz Mathias (razvanma_at_exchange.microsoft.com)
Date: Mon Jan 12 2004 - 15:03:47 PST
The HYDRA paper introduced the a primitive version of the concept of an
object-oriented operating system. Many of the elements of
object-oriented design were embodied in the implementation of HYDRA
(with the exception of dynamic dispatching based on object type).
The goal of the paper was to describe a flexible system for separating
policy from mechanism. The paper introduced the notion of a kernel as a
system that provides the protection mechanisms necessary for
implementing flexible security policies.
Procedures in the HYDRA system embodied the object parameters, private
data, security information, and the code for operating on the passed-in
parameters. Extending the ideas of capability systems originating from
the MCS paper, code executes in the dynamic context of a local name
space (LNS), which is basically a list of capabilities available to the
execution at any given time. These capabilities included
caller-independent capabilities (obtained from procedure objects), which
were present regardless of who was calling the procedure and
caller-dependent parameterized capabilities (dubbed templates), which
included the dynamic capabilities of the caller during the course of the
execution. The LNS essentially tells the execution what it can and
cannot access.
The paper claims that the idea of object ownership is abolished in the
system, giving the system great flexibility. Basically, these access
tokens or "capabilities" are passed around, yielding or taking away
access from underlying objects and procedures. Although sound in
principle, there is a huge amount of complexity introduced into the
system. The idea of caller-independent capabilities for procedures
makes them brittle and potentially dangerous. Consider the case where a
procedure is coded to have access to a critical system resource that the
user shouldn't have access to. Also consider the fact that to access an
object both the correct access-bit capability needs to be in the LSN and
the procedure operating on the object must be there as well.
Objects can be concrete or abstract, representing an underlying resource
in the operating system. Objects combined with procedures and
capabilities form a system akin to modern object-oriented systems.
Objects "derive" from types which hold prototypical sets of capabilities
for classes of objects. This single-level hierarchy reminds me of a
primitive object-oriented system. Procedures encapsulate operations on
these objects, only running if a sufficient set of access capabilities
are granted. The ability to extend the type system, the sets of objects
derived from the type system, and simultaneously retain control over who
can do these operations on these new objects an interesting and valuable
contribution of this paper. The question is whether the increased
complexity in management justifies this increase in flexibility.
This archive was generated by hypermail 2.1.6 : Mon Jan 12 2004 - 15:03:48 PST