Re: Why COPY != SIMULATED COPY

[Jonathan S. Shapiro]

This is a followup. My original note has not returned to me, so I cannot
reply. This note may arrive out of sequence.

TYPO ALERT: I wrote

        c..x-y.z is okay

which should have been:

        c..x=y.z is okay

STRANGE NOTATION: A clarification on my notation. When I wrote

        c..x=y..z

I was trying to express the idea that we had a dominating capability
c..x and a capability being exchanged c..y..z such that

        depth(c..x) = depth(c..y)

The equality notation was a bad choice. What I meant was that c..x and
c..y have a common parent in the revocation hierarchy.

TWO IMPORTANT REFINEMENTS:

There is an error in my analysis about the CapServer protocols. Actually
two:

1. In many cases, the five IPC exchange used in SimCOPY can be reduced
   to two: A can sent to CapServer, which can forward the message to B
   directly.

   This is only safe if the underlying message transport has an upper
   bound on total message state, so that the the message from A to
   CapServer can be transmitted atomically.

   Credit for this observation goes to one of my students: Swaroop
   Sridhar.

2. There is a lookup problem in CapServer. Given a capability
   cap.1...x...y.z, CapServer must have a way to locate its
   dominating capability cap.1. The easiest way to do this is
   for CapServer to hold a special capability, CapBits, that
   allows it to learn
     a) the object named by cap.1...x...y.z
     b) the depth of cap.1...x...y.z in the revocation hierarchy
   it is not actually necessary to know the string |1...x...y.z|.

   Given this primitive, it is fairly easy for CapServer to
   maintain its own translation table. but note that CapServer
   is now EXTREMELY privileged!


shap