Wrapper design patterns (was: Revocation vs destruction)

[Jonathan S. Shapiro]

In a previous discussion, I promised to describe the wrapper-related
design patterns that occur in EROS. This interacts with the discussion
of sharing. The details of the mechanism will be slightly different in
Coyotos, but I do not expect the design patterns to change.

First, I should clarify that wrappers are used in EROS in two places:
they are used to associate a fault handler with a region of an address
space, and they can be used to wrap "start capabilities" (which are the
closest thing that EROS has to "endpoint capabilities". For the purposes
of this mail, I will simply use the term "endpoint capability", and I
will not be talking about fault handler binding at all.

Second, I should describe the wrapper object and how it functions in
EROS, so that everyone is clear on the mechanism.

Finally, I will describe how wrappers have actually been used in
practice. What this will mostly reveal is that selective revocation is a
VERY rare operation, and also why wrapper revocation is usually not a
trust issue in EROS at all.

THE WRAPPER MECHANISM

The EROS wrapper capability is actually a distinguished capability type
that names a Node. The significant state of a wrapper object consists
of:

  A capability field CF holding the endpoint capability
    that is wrapped 
  A "spare" capability field SCF
  A one word data field  DF
  A spare data field SDF
  A control field having three significant control bits:
    W -- indicates that value of the first data register
         should be stored in SDF, and then replaced by
         the value of DF before the message is delivered.
    C -- indicates that the value of the capability register
         1 (CR1) should be stored to SCF, and then replaced
         by the value of CF before the message is delivered.

  [Changes for Coyotos: SCF and SDF are eliminated, CF and DF
   are delivered to well-known slots in the receiving process state
   rather than overwriting.]

There are some other bits associated with various stale experiments.
These are the bits that matter here.

The most common use of CF is to hold the endpoint capability to a
server.

The most common use of DF/W is to hold a pointer to some in-memory
structure within the server that captures the state of some particular
server-implemented object.

The most common use of the C control bit is to allow a server to
re-obtain a node capability to a wrapper that it previously created.

When the wrapper capability is invoked, the message is forwarded to the
endpoint named by CF, and the substitutions implied by the control bits
are performed.

In the current EROS implementation, wrappers cannot be nested. In
previous implementations, wrapper nesting was permitted up to a depth of
20.

Note that *none* of these fields can be fetched using a wrapper
capability. In this sense, wrappers are opaque to their user.

[In Coyotos we will probably replace the wrapper mechanism with endpoint
forwarding.]

EXAMPLE:

In EROS, all of the space banks in the system are implemented by a
single (persistent) process known as the "prime space bank". A space
bank capability is actually a wrapper capability. Within this wrapper,
CF contains an endpoint capability to the prime space bank, and DF
contains a pointer to an in-memory Bank structure that lives in the
virtual address space of the prime space bank. Both DF and CD are set.

The first consequence of this is that the space bank always receives the
appropriate Bank structure pointer whenever a space bank capability
(remember: really the wrapper capability) is invoked.

The second consequence is that the space bank always receives a node
capability to the wrapper whenever the space bank capability is invoked.
This allows the bank destroy operation to destroy a single space bank
without destroying the entire prime bank process.



PATTERNS

The most common use of a wrapper is for the kind of selective object
revocation that the Space Bank performs. Every individually revocable
object has a minimum cost of one wrapper, and this pattern is used
whenever you have "one server, many objects".

The only other use of wrapper that I can think of was in the MLS
reference monitor for KeyNIX. The problem here is that we want to be
able to do a "send up" without permitting a "reply down". This is
accomplished by having the MLS monitor hold the real endpoint capability
and act as a copy agent for messages. The messages that are transferred
may not include any unconfined capabilities (described in one of my
previous notes).

In principle, we could do something similar for capabilities that travel
from one user to another -- any time a capability crosses this boundary
it's wrapper is replaced. This replacement is implemented by a reference
monitor.

In practice, I cannot think of *any* other places where we have actually
wanted a wrapper or selective revocation.

When the wrapper is really being used to capture object identity on
behalf of a server, you aren't concerned about the wrapper being
destroyed by an intermediary. Also, in this case there is a variant of
the "identify" operation that can be used.

COMMENT

The reason that this note took so long is that I couldn't really believe
that we didn't have any other wrapper patterns in practice. The truth is
that we do, but all of these relate to memory fault handling (which is a
completely separate issue).

shap