[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cap exchange race with map/unmap
From: |
Neal H. Walfield |
Subject: |
Re: cap exchange race with map/unmap |
Date: |
Wed, 19 Oct 2005 12:05:10 +0100 |
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI) |
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
- cap exchange race with map/unmap, (continued)
- cap exchange race with map/unmap, Neal H. Walfield, 2005/10/18
- Re: cap exchange race with map/unmap, Jonathan S. Shapiro, 2005/10/18
- Re: cap exchange race with map/unmap, Neal H. Walfield, 2005/10/18
- Re: cap exchange race with map/unmap, Jonathan S. Shapiro, 2005/10/18
- Re: cap exchange race with map/unmap, Marcus Brinkmann, 2005/10/18
- Re: cap exchange race with map/unmap, Jonathan S. Shapiro, 2005/10/18
- Re: cap exchange race with map/unmap, Neal H. Walfield, 2005/10/18
- Re: cap exchange race with map/unmap, Jonathan S. Shapiro, 2005/10/18
- Re: cap exchange race with map/unmap, Espen Skoglund, 2005/10/18
- Re: cap exchange race with map/unmap, Jonathan S. Shapiro, 2005/10/18
- Re: cap exchange race with map/unmap,
Neal H. Walfield <=
- Re: cap exchange race with map/unmap, Jonathan S. Shapiro, 2005/10/19
- Re: cap exchange race with map/unmap, Neal H. Walfield, 2005/10/19
- Re: cap exchange race with map/unmap, Marcus Brinkmann, 2005/10/18
- Re: cap exchange race with map/unmap, Jonathan S. Shapiro, 2005/10/18
- Re: cap exchange race with map/unmap, Ludovic Courtès, 2005/10/19
- Re: cap exchange race with map/unmap, Bas Wijnen, 2005/10/19
- Re: cap exchange race with map/unmap, Jonathan S. Shapiro, 2005/10/19
- Re: cap exchange race with map/unmap, Bas Wijnen, 2005/10/19
- Re: cap exchange race with map/unmap, Marcus Brinkmann, 2005/10/19
- Re: cap exchange race with map/unmap, Marcus Brinkmann, 2005/10/19