Re: cap exchange race with map/unmap

[Neal H. Walfield]

At Tue, 18 Oct 2005 20:44:26 -0400,
Jonathan S. Shapiro wrote:
> 
> On Tue, 2005-10-18 at 23:14 +0200, Espen Skoglund wrote:
> > [Jonathan S Shapiro]
> > > In the absence of any authority to fabricate new capabilities, the
> > > following chain of mappings is now in effect after the exchange:
> > 
> > >       RevCopy                RevCopy
> > >    A ----------> CapServer -----------> B
> > 
> > > If process A now exits, all of its capabilities are revoked. In
> > > consequence the Cap held by CapServer is revoked. In consequence the
> > > Cap held by B is revoked.
> > 
> > > Can somebody explain what authority or feature in the system design
> > > gives the CapServer sufficient power that it can create a capability
> > > that does not depend on A's continued existence?
> > 
> > If CapServer can identify that it posesses an identical capability it
> > can map this capability to B.
> 
> How does CapServer obtain this capability if it is not the original
> creator of the object?

One way to achieve this is to have the server give CapServer the
capability and derive all RevCopies from CapServer's RevCopy.

An illustration might help.  Consider a task, A, which wants to pass a
COPY capability to a second task, B.  The initial mapping hierarchy
looks like this:

        RevCopy         RevCopy
  Server ----> CapServer ----> A

That is, a server implementing an object has given a revocable copy to
CapServer which in turn has given a revocable copy to A.

A now wants to give B a COPY of the capability.  It first gives B a
RevCopy of the capability in question:

        RevCopy         RevCopy RevCopy
  Server ----> CapServer ----> A ----> B

B then invokes the make_copy method on a capability to its capability
server passing the capability it received from A as an argument to it.

        RevCopy         RevCopy RevCopy RevCopy
  Server ----> CapServer ----> A ----> B ----> CapServer

CapServer calls map_lookup (recall from a previous message in this
thread that the map_lookup system call takes a capability as an
argument and returns the name of the first ancestor (with respect to
the mapping hierarchy) of that capability in the same address space
or, if none is found, failure) providing the capability it received
from B.  map_lookup returns the name of the capability that Server
mapped to it which it can now map to B.  The resulting map hierarchy
is:

                 Server
         RevCopy   |
                   v
               CapServer
        RevCopy  /   \  RevCopy
                v     v
                A     B

Thus B's capability is now immune from A's exit.

For quick reference, a more detailed description can be found here
[1].

Thanks,
Neal


[1] http://os.inf.tu-dresden.de/pipermail/l4-hackers/2005/002140.html