From: Jeff Duzak (jduzak_at_exchange.microsoft.com)
Date: Tue Jan 13 2004 - 22:54:19 PST
This paper describes Opal, an operating system which features a single shared 64-bit address space for all applications. On such a system, addresses are context independent. That is, processes running in separate domains can use the same pointer value to address a particular spot in memory. Besides the single address space, Opal features a protection scheme that is separate from its addressing scheme. That is, any process can address any location in memory, even if it cannot access that location. The single address space and decoupled protection system make possible richer, more complicated sharing of data and procedures between processes, compared with the common model of per-process address spaces. That sharing of data facilitates the design and performance of integrated software environments in which there exist many processes working on common data which may be highly structured.
The cornerstone of the Opal protection system is the capability, a concept now familiar from Dennis & Van Horn's paper as well as the Hydra paper. Capabilities in Opal differ somewhat from Dennis & Van Horn's capabilities. Like Dennis & Van Horn's capabilities, a capability in Opal contains an object identifier. However, in Opal the capability also contains the address of a portal (or secure entry point) into a protected subsystem which could be used to access the object to which the capability refers. Further, in Opal, a capability can be freely manipulated and distributed by user processes. It is briefly mentioned that the capabilities in Opal incorporate passwords, but further description of how capabilities are protected from forgery is not given.
The system of protected domains in Opal is similar to the notion of spheres of protection from Dennis & Van Horn's paper. Like a sphere of protection, a protected domain in Opal can create a child domain with a set of capabilities that are a subset of the parents set of capabilities. There is apparently no mechanism for creating a child domain with heightened capabilities, as there is in Hydra. However, it is possible to make remote procedure calls to other processes, and those RPCs would run with the capabilities of their processes.
The paper describes a CAD system used by Boeing which would be an ideal candidate to be implemented on Opal. The CAD system uses a great deal of common, structured data which is stored in a database but must be reconstructed in a process's memory to be used. If the system were implemented in Opal, the common data could be accessible to all processes while also being in a form that is ready to manipulate.
To test the performance of the system, the authors built an example application which included two processes cooperating and sharing data. One process created the data, and the second process consumed the data. The authors also built two analogous systems in Unix, one in which the processes were separated in their own address spaces, and one in which the producer and consumer existed in a single process and therefore had no protection from each other. Performance testing of the applications showed that the Opal application performed almost as well as the single-process Unix application, while the multi-process Unix application was much slower. Therefore, Opal enjoys the benefits of protected domains without sacrificing performance.
In my opinion, this paper was by far the most difficult to read among all the papers we have read so far. It was especially difficult to read the description of the implementation of Opal on top of the Mach microkernel, as I am completely unfamiliar with that system. Beyond that, I find it a bit discomforting that the Opal system removes almost all distinction between persistent and non-persistent storage. It is described how upon system restart, persisted segments have to be refreshed as required according to an epoch number. I can't help but feel as though on such a system, I as a programmer could not be confident that my application's data is in an orderly state. I am too used to the idea of a clean slate upon start of a process. Considering how often real-world users have to restart a process to recover from an error, it seems very dangerous not to have that clean slate.
This archive was generated by hypermail 2.1.6 : Tue Jan 13 2004 - 22:54:17 PST