From: Cem Paya 98 (Cem.Paya.98_at_Alum.Dartmouth.ORG)
Date: Wed Jan 14 2004 - 16:57:38 PST
Paper review
Sharing and Protection in a Single Address Space Operating
System.
Jeffrey Chase, Henry Levy, Michael Feeley, and Edward
Lazowska
CSE 551P, Cem Paya
This paper proesents a new approach for memory protection
between multiple processes. In traditional virtual-memory
systems where every process gets a different view of the
address space, with different VM à physical memory
mappings for each one, and the attendant “context
switching” problem. In the Opal described there is a
single flat address space shared by all applications. This
would not work very long in 32 bit system because it would
mean the total memory available to all processes is
limited by 4GB. Even at the time this paper was authored—
and its relatively recent at 1993 publication date—there
were applications requiring more memory and it was clear
that even personal computers would sooner or later exceed
this limit. (Authors cite an interesting analogue to
Moore’s law for memory: that address space approximately
doubles every year.) Opal makes more sense given existence
of 64b architectures such as the DEC/Digital Alpha and
MIPS—although the initial prototype was implemented on 32b
architecture before being ported.
In Opal address space is shared. All threads (in fact Opal
has an even more granular concept of execution context
than ordinary threading) can refer to same data. Pointers
are portable across process boundaries. That in turn
provides two major benefits: sharing data is very easy and
depends only on allowing another thread access to the
segment where data resides. It also means pointers are
portable between different threads, which simplifies inter-
process communication. Assuming that some collection of
bits is accessible from both contexts, it can be passed by
reference instead of marhsalled, which can become
bottleneck for systems heavily dependent on RPC. There is
also a notion of controlled RPC mechanism dubbed portals,
with well defined entry points and capabilities.
There are some complications: for example linking and
addressing global variables is more difficult because now
everything is relative to a base address. This is also
downside from developer point of view; it is much easier
to debug applications that have same memory layout at all
times. For example knowing that the stack always starts at
the same location or this library gets loaded at known
address are properties useful for inspecting state of a
process. It’s difficult to judge without doing detailed
review of the design but there is also dangerous use of
obfuscation with random check fields for access control.
In most systems capabilities are not direclty exposed to
application except by opaque handles to kernel-mode memory
not directly addressable. Opal allows applications to pass
capability structures around which raises serious concerns
about quality of the random number generator for check
fields and risk for brute-forcing etc.
This archive was generated by hypermail 2.1.6 : Wed Jan 14 2004 - 16:58:29 PST