/ data / serial / jhu-paper

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.

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.