From: Raz Mathias (razvanma_at_exchange.microsoft.com)
Date: Wed Jan 14 2004 - 16:19:22 PST
This paper discusses an interesting concept in a world in which address
bits are becoming a commodity. What if the address space was so large
that instead of executing every process in a separate virtual memory
environment, all processes were to execute in the same memory space?
The simple answer is that pointers could be shared across processes
boundaries, thereby enabling us to share complex data structures and
call procedures in other processes. This paper takes this concept much
further by illustrating the benefits of a shared-pointer message passing
system over existing systems, demonstrating a working model (the Opal
operating system), and most importantly, decoupling the fundamental
concepts embedded in the modern notion of a "process."
The paper begins by assuming that there will come a time at which an
address space becomes large enough to support any number of coexisting
applications. In my opinion, this is a fundamentally dangerous
assumption to make. Suspending disbelief, the paper goes on to state
that in this context, it would be possible to efficiently share
pointer-based information by simply sharing pointers. The paper
introduces the concept of "protection domains," abstractions for objects
accessible to a (set of) thread(s). Threads embody the basic units of
program execution in this paper.
Protection is achieved via capabilities, which are 256-bit identifiers
composed of <object-id, address offset, unique-id> tuples. Capabilities
provide access to protection domains, which provide access to kernel
resources. Symbolic names exist for these capabilities and are brokered
via a name server. The name server looks up the principle requesting
access in an access control list (ACL) and hands a 256-bit capability to
the principle's thread accordingly.
A segment capability allows the owning thread to directly address memory
in a segment (without the overhead of an RPC or portals) by "attaching"
to it. This is how pointer-based information is shared between
protection domains in Opal. Note the lack of a need for copying
information across "process boundaries." Instead, a protection
capability is passed on from one thread to another. Note also how the
process boundary melts away and all that is left is a set of executing
threads, the naming server, and overlapping protection domains. In this
way, the program execution, naming/ownership, and protection are
elegantly teased apart. I found the discussion about the tradeoffs in
protection and efficiency in conventional systems to be particularly
relevant to modern programming. The pointer sharing mechanism shown
here solves both problems at the same time.
Opal also provides a mechanism for communication between protection
domains. This mechanism is very similar to the HTTP model existing for
web services or an RPC model. Requests are generated from the caller
(or client). A "proxy" intercepts the call and redirects it to a
portal, a kernel concept abstracting the entry to a domain. The calling
thread's capability is checked to see whether the client has access to
the portal. On the other side of the portal, a "guard" intercepts the
call and passes it on to the server process, which then dispatches it (a
portal can support multiple procedures or entire objects). All data
across the protected domains happens via capability sharing.
The paper also discusses the idea that a parent domain can create
children domains of which the parent can control the capabilities. This
idea (which we've already seen in the Multi paper) is useful for running
un-trusted code. The paper also discussed the idea of resource groups
for cleaning up. Also, implementations of Opal over Mach and of a
mediator implementation over Opal were described. All these were minor
points. The meat of the paper was in sections 1-3.
The paper also goes into the technical drawbacks and complications of a
shared memory space. These include problems with static data,
copy-on-write semantics, the inability to implement fork(), and the fact
that segments cannot grow. In my opinion, given the potential increase
in performance from reduced data copying and protection, the drawbacks
of these limitations were limited.
Having worked on MS Exchange, I would be excited about the possibility
of porting a large-scale server (where we tried to squeeze out the last
bit of performance/scalability from our implementation) to this
single-address-memory idiom. The two major drawbacks I saw were 1) Are
64-bits enough? and 2) Compatibility: who's going to rewrite all of the
existing code to take advantage of this shared model?
One question I still have is when passing parameters in a call via a
portal, do the parameters need to be passed using call-by-value
semantics? Consider malicious domain A calling domain B. As I see it,
if domain A were to pass a pointer parameter to a call in domain B, the
receiving thread in domain B could be corrupted (caused to crash, go
into an infinite loop, etc.). In this case, copying of data is
mandatory. Perhaps the very fact that protection domain A has the
capability to access domain B's portal means that B trusts A? Or
perhaps the point of protected calls is that they are used when two
domains do not trust each other, in which case data copying is an
acceptable tradeoff. Hopefully this will be cleared up in our
discussions.
This archive was generated by hypermail 2.1.6 : Wed Jan 14 2004 - 16:19:25 PST