From: David Coleman (David.Coleman_at_roxio.com)
Date: Wed Jan 14 2004 - 13:22:11 PST
“Sharing and Protection in a Single-Address-Space Operating System” is a description of the Opal operating system running on a 64-bit platform on top of the Mach microkernel. The purpose of a single address space is for more convenient and efficient sharing of memory between processes. Private address spaces are used to provide a large address space for processes and protection. A single address space model using a wide addressing platform provides enough address space for all processes (if you don’t believe me, read the Introduction of the paper). Protection is still achieved using capabilities and access control lists (ACL). Opal decouples the protection domain from the rest of the process architecture (program execution, resource ownership, resource naming, etc.).
In Opal, segments are the basic memory unit accessible to the user programs. Segments are allocated via the supervisor and can be marked as persistent and are reference counted. If a segment’s reference count goes to zero, it will not be freed if it is marked as persistent. Threads are the basic unit of execution. A protection domain is the equivalent of a process context. Multiple threads can run inside of a single protection domain. In this sense, they are analogous to processes running in a “sphere of protection” as described by Dennis and Van Horn. Multiple threads can combine to work on a single “task” which is managed by a protection domain. Protection domains are the subject of access control.
All kernel resources are named by capabilities which are 256-bit objects. A name service provides support for symbolic naming. ACL’s are used for protection. Passwords are used as capabilities and can be passed between threads and protection domains. A thread can attach and detach segments to a protection domain via the Attach and Detach requests.
A portal is a protected entry point and the basis for protected subsystems. A system call is made using a portal capability which provides for the correct protection of the call. A portal entry begins execution at a fixed entry point specified by its creator. This prevent randomly jumping into the protected segment which could obviously lead to protection violations or worse. Sharing of information between a protected subsystem and its caller is done via shared memory.
Child domains, more restrictive than the parent, can be created and used. Portals are used to call into the child domain.
The implementation of Opal included a runtime package for C++. Other languages could easily have been supported. The various system calls for creating resources, attaching, detaching, etc. are implemented via this package. Custom linking utilities were created to perform some final fixups to support a single-address space and executables that did not require run-time fixups.
There are useful descriptions of some details of implementing Opal on top of the Mach 3.0 microkernel and also a very interesting section describing how it would work for a Boeing CAD system and database. The performance of Opal turned out to be surprisingly good given the extra overhead of running on top of a microkernel. Also included in the paper is a good description of the relationship of Opal to previous work, including Multics, the Dennis and Van Horn system, Hydra, and others.
In the interests of brevity I’ve not even scratched the surface of what is presented in this paper. Opal is a fascinating system and cannot be adequately described in a short summary like this one.
This archive was generated by hypermail 2.1.6 : Wed Jan 14 2004 - 13:19:39 PST