Sharing and Protection in a Single-Address-Space Operating System
This write-up is based on a research paper by Jeffrey S. Chase et al, University of Washington.
The above-mentioned research paper takes into consideration the sharing and protection in Opal Operating system. Opal is a single-address-space operating system intended to support complex applications on wide-address architectures. Opal provides a single global virtual address space that is shared by all procedures and data. The Wide-address architectures facilitate the single-address approach by eliminating the need to reuse addresses, which is required in a 32-bit architecture.
Looking a little into private space approach, the major advantage of private spaces are:
- The amount of address space available to all programs increases.
- Hard protection boundaries are provided.
- Easy cleanup when a program exits.
The disadvantages of this approach are:
- Isolating programs within private virtual address spaces presents obstacles to efficient cooperation between protected application components.
- Pointers have no meaning beyond the boundary or lifetime of the process that creates them, so the pointer based information can't be easily shared, stored or transmitted.
In private-address-space systems, there are two choices available with an application designer:
- Place application components in independent processes that exchange data through pipes, files, or messages but the problem here is that the performance goes down.
- Place all components in one process but in this case, the protection is not there.
The solution to the above problem provided in the paper is judicious sharing of the virtual memory between protected components. In a single-address-space model, the system coordinates the address bindings, to accommodate dynamic sharing patterns in a uniform way.
The advantages of the wide address systems can be incorporated in single address space systems specifically, with wide address architectures, sufficient addressing can be provided without multiple address spaces. Along with this, there need be no loss of protection in the single address space and cleanup is not difficult for the conventional programs that do not share data.
The Opal Approach:
Opal separates program execution, resource ownership, and resource naming from protection domains in addition to the separating protection from addressing.
The independence of protection and addressing in Opal substantially increases flexibility. Programs can directly share procedures and complex pointer-based data structures, without requiring a prior negotiation of address space usage. There is no need to decide in advance what is shared and what is private, any memory segment can be shared at any time without the address conflicts, and memory access rights are easily passed on-the-fly from domain to domain.
The Opal units of storage and allocation and protection are segments. Segments are the contiguous extents of virtual pages. The Opal units of execution are threads. A protection domain is an execution context for context for threads. Each thread executes in exactly one protection domain but many threads may execute in the same domain. An Opal domain is the analogue of a Unix Process. Also, a protection domain can also be called as a collection of segments accessible to a protection context. In Opal, it is believed that storage allocation, protection, and reclamation should be coarse-grained at the operating system level. Fine-grained control is best provided best provided at the language level by compilers and runtime systems.
In Opal, shared memory is the primary form of sharing and communication between threads in different protection domains. A portal is an entry point to the domain, uniquely identified by a 64-bit value(portalID). Any thread knowing the portalID can make a system call that transfers the control into the domain associated with the portal.
A thread running in one protection domain(parent domain) can create a new domain(child), to protect the parent data from an untrusted subprogram. Parents can attach arbitrary segments to their children and can cause arbitrary codes to execute in their children. So, here the child completely trusts the parent but the reverse does not hold. To execute code in the child, the parent registers a portal for the child domain, specifies a procedure as the entry point, and then calls through that portal.
An application can create one or more domains, attach code and data to them, and make one or more protected calls, possibly causing the domains to call each other or parent.
The Opal Approach:
Opal separates program execution, resource ownership, and resource naming from protection domains in addition to the separating protection from addressing.
The independence of protection and addressing in Opal substantially increases flexibility. Programs can directly share procedures and complex pointer-based data structures, without requiring a prior negotiation of address space usage. There is no need to decide in advance what is shared and what is private, any memory segment can be shared at any time without the address conflicts, and memory access rights are easily passed on-the-fly from domain to domain.
The Opal units of storage and allocation and protection are segments. Segments are the contiguous extents of virtual pages. The Opal units of execution are threads. A protection domain is an execution context for context for threads. Each thread executes in exactly one protection domain but many threads may execute in the same domain. An Opal domain is the analogue of a Unix Process. Also, a protection domain can also be called as a collection of segments accessible to a protection context. In Opal, it is believed that storage allocation, protection, and reclamation should be coarse-grained at the operating system level. Fine-grained control is best provided best provided at the language level by compilers and runtime systems.
In Opal, shared memory is the primary form of sharing and communication between threads in different protection domains. A portal is an entry point to the domain, uniquely identified by a 64-bit value(portalID). Any thread knowing the portalID can make a system call that transfers the control into the domain associated with the portal.
A thread running in one protection domain(parent domain) can create a new domain(child), to protect the parent data from an untrusted subprogram. Parents can attach arbitrary segments to their children and can cause arbitrary codes to execute in their children. So, here the child completely trusts the parent but the reverse does not hold. To execute code in the child, the parent registers a portal for the child domain, specifies a procedure as the entry point, and then calls through that portal.
An application can create one or more domains, attach code and data to them, and make one or more protected calls, possibly causing the domains to call each other or parent.
Comments
Post a Comment