From: Jeff Duzak (jduzak_at_exchange.microsoft.com)
Date: Sun Jan 11 2004 - 23:36:07 PST
This paper discusses the design philosophy of the HYDRA operating system kernel, and gives a very high level description of the mechanisms in the system.
The paper starts out by giving a description of the hardware used for the system. From this description, the system seems more like a network than a single multi-processor machine. Each processor has its own private memory and I/O devices. The only thing shared is a large memory space. In the remainder of the discussion, there doesn't appear to be any ideas applicable to a multi-processor system that are not likewise applicable to a single-processor, multi-process machine.
Like other papers, this paper starts with a discussion of design philosophy. Core to the philosophy is to separate out from the operating system a nucleus or kernel which would provide services that would be required by any operating system. The section continues on to enumerate a number of more specific considerations. Some of these considerations seem disconnected from the remaining discussion. For example, the consideration of reliability is mentioned but then never returned to in the rest of the paper. It is not described how the system described can help "recover from errors that do exist". Lastly, the design philosophy section gives a definition of an operating system, emphasizing the OS as an abstraction layer.
Unlike the "Programming Semantics" paper by Dennis and Van Horn, this paper is very heavy on concepts and light on specifics of implementation. The highest level concept is that of an object. Everything, including procedures, local name spaces (or process spaces), and processes themselves are objects. The paper discusses the components of an object, which are its unique name, type, and representation. I found the term "representation" very confusing. It seems that the representation is the meat of the object. That is, if the object is a procedure, then the representation contains all the code and local data for that procedure. The representation part is further broken down to contain a capability part and a data part.
The capability part of an object is very similar to the capabilities described by Dennis and Van Horn. Further, the idea of associating capabilities with a procedure object seems to serve the same purpose as the "set-user-ID" bit in UNIX programs. It allows the procedure to run with potentially greater privileges than the user executing the procedure. However, the capability part of a procedure in HYDRA is much more specific, more flexible, and therefore much more secure than the set-user-ID bit in UNIX.
The paper continues on to describe an elegant system to specify object types, with the types themselves also being objects. This type system is easily extensible to allow creation of user-defined types.
Lastly, the paper gives an example of the use of HYDRA's protection system. The example describes a bibliography system, with certain restrictions desired on the reading and writing of bibliography data. The example shows how by creating a proprietary type (the bibliography), and only allowing access to this proprietary type through procedures which accept these types as parameters, one could create a system that enforces the desired read and write protections for these bibliographies. This example is again a very elegant demonstration of the system. However, a few questions arise. First, if a bibliography can only be touched by a procedure which takes a bibliography as a parameter, then how does one perform such routine operations as copying, renaming, or moving a bibliography? Does one have to implement new procedures to do all these routine tasks? Further, the paper doesn't explain how a procedure object is assigned its various capabilities. Presumably, the programmer of these procedures has to give the procedures its capabilities. If there is no concept of ownership, in particular no ownership of the bibliography type, then what prevents a malicious user from writing his own procedure to access a bibliography object?
This archive was generated by hypermail 2.1.6 : Sun Jan 11 2004 - 23:36:51 PST