l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cap exchange race with map/unmap


From: Marcus Brinkmann
Subject: Re: cap exchange race with map/unmap
Date: Wed, 19 Oct 2005 15:10:58 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Wed, 19 Oct 2005 09:52:40 +0200,
address@hidden (Ludovic Courtès) wrote:
> 
> Hello,
> 
> Marcus Brinkmann <address@hidden> writes:
> 
> > At Tue, 18 Oct 2005 14:27:56 -0400,
> > "Jonathan S. Shapiro" <address@hidden> wrote:
> >
> > [A broken protocol snipped]
> >
> >> I believe that the only possible protocol that could be correct is for
> >> all object servers to return by way of CapServer.
> >
> > I agree.  This is exactly what I proposed in my talk in Dijon.
> >
> > The server maps a revocable copy to the cap server.  The cap server
> > maps another revocable copy to each client.
> 
> Marcus, how is this different from what Jonathan described in
> <address@hidden>, that is:
> 
>   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
 
Here, A and B are clients.  Let me draw you a picture of the only
solution I know, which also Shapiro mentioned above:

Before copy operation:

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

After A initiated the copy operation to B:

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

After B initiated the copy operation from the cap server.

           RevCopy               RevCopy        RevCopy
Server S ----------> CapServer -----------> A ----------> B
                             ^                            |
                             |           RevCopy          |
                             +----------------------------+

The revocable copy from B to the cap server proves to the cap server
that B possesses the capability, and furthermore allows the cap server
to identify the capability to copy in the first place!

At the end of copy operation:

           RevCopy               RevCopy        RevCopy
Server S ----------> CapServer -----------> A ----------> B
                             |                            ^
                             |           RevCopy          |
                             +----------------------------+

The copy from B to the cap server has been removed.  It's not needed
anymore.

After the copy operation:

           RevCopy               RevCopy
Server S ----------> CapServer -----------> A
                             |
                             |   RevCopy
                             +------------> B

The copy from A to B has been removed.  It is not needed anymore.  Now
A and B have a co-equal copy.

Thanks,
Marcus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]