ERights Home data / serial / jhu-paper 
Back to: Selective Transparency within the Subgraph On to: Persistence and Upgrade

Manipulating Identity
at the Entries


Lessons of Manipulating Identity at the Entries

(*** To be written)


*** incoherent notes here to the end of this file. Do Not Read ****

 

In the conventional use of serialization, this issue is trivial: Of the incoming references, there's only one entry -- the reference to the rootObj given as argument to the serializer (reference to A1). All other incoming references are ignored -- indeed, the serializer has no means to even be aware of them (reference to B1). The unserializer returns to its caller a new reference to the reconstructed rootObj, thereby giving it a new identity (A2). The new rootObj may be a replica and heir to the original, but it does not have the identity of the original. Messages sent on references to the original will not somehow be redirected to the reconstructed rootObj. For most purposes, this is the desired behavior.

Conventional object systems are local in space and time. They enable one to create a graph of objects and references limited to a single address-space, and living only so long as their hosting OS process lives. Within such a conventional system, reincarnation would seem to be impossible. So long as there remain references to the original object, it will continue to exist and receive messages directed to it, preventing the reallocation of its identity to a desired reincarnation.

Reincarnation becomes both possible and necessary once we transcends these limits of space and time by building distributed persistent secure object-capability systems.

Transcending Space and Time

All problems in computer science can be
solved few more levels of indirection.

--Anon

At the layer of description created by the primitives of a conventional object system, reincarnation is indeed impossible. However, within such a system one can create a new layer of description, in which message routing objects create virtual references (such as a message-forwarding "proxy" object). A primitive reference to a router could be described at this new layer as the first leg of virtual reference designating whoever the router causes messages to be routed to.

Actually, this is not yet true. At the time of this writing, CapTP is still implemented in Java rather than E, and so must be counted among E's primitives. However, E was designed so that CapTP could be written purely in E without use of undue privileges. Once we do so, the assumptions made in this chapter will be valid.

For both language and OS design, if persistence is designed to be primitive, the reincarnation issue may be avoided. For both, if persistence is to be build at the user-level and distribution is to be supported somehow, then reincarnation is necessary.

E is built in layers in precisely this way. The primitively implemented part of E is a single-process non-persistent object system, conventional in most ways but for the absence of those non-object primitives that would violate capability discipline. At the next level of abstraction up, E is a distributed persistent system, in which object-capability secure computation has been extended across space and time by code written in E operating without undue privilege. E's distributed cryptographic capability-object protocol, CapTP, and E's persistence system each use serialization in ways that raise rather different issues covered in this paper.

These issues converge when recovering from the crash of an OS process. Such a crash destroys all original objects hosted by that process, and, conveniently for us, also destroys all primitive non-redirectable references to those objects. There remain the virtual references created by CapTP held by objects in other processes designating the original objects that just got destroyed. Following a crash, the reconstructed objects must reclaim the identity of the originals. Distant objects holding virtual references must be able to continue to use these references to send messages, and these messages must be received by the reconstructed objects. To reconnect these entries is to determine who an objects within the reconstructed subgraph is. When all surviving references to the original are rerouted to designate a new entry object, we say the new object is a reincarnation of the identity of the original. This logic must apply to many objects in the subgraph -- not just the distinguished rootObj.

6.1. What is Object Identity?

6.1.1. Rights to invoke, be, compare

6.2. Secure Distributed Objects:
Islands of Partitioned Capabilities, Hooked Together by a Sea of Password Capabilities

6.2.1. CapTP's Encoding of a Capability

6.2.2. Knowledge is Power

6.2.3. The Logic of Telling Secrets

6.2.4. SturdyRefs: Guarding the Boundary between the Worlds

SturdyRefs are data + a capability to a LocatorUnum, which provides it the power to turn bits into a capability. The LocatorUnum is normally not serialized, but rather replaced by a GraphParam("LocatorUnum"), to be resolved by the unserializer into a fresh LocatorUnum; provided of course that the unserializer is willing and able to extend this comity to those (such as serialized SturdyRefs) whose previous incarnation allegedly had access to the LocatorUnum of their world.

6.3. Hash Chaining Identity Rights

6.3.1. Immediate Reincarnation

SwissNumber := hash(SwissBase)

6.3.2. Example: persist-echat.e-awt

For when you'd rather rebuild it than save and restore it.

6.3.3. Reincarnation On-Demand


*** Unprivileged fault handlers [ref XOF]

6.3.4. Example: Mints with Purses

*** Purses are naturally stored in databases. Potentially massive number of Purses, but most stay dormant for long periods.

 

 
Unless stated otherwise, all text on this page which is either unattributed or by Mark S. Miller is hereby placed in the public domain.
ERights Home data / serial / jhu-paper 
Back to: Selective Transparency within the Subgraph On to: Persistence and Upgrade
Download    FAQ    API    Mail Archive    Donate

report bug (including invalid html)

Golden Key Campaign Blue Ribbon Campaign