Re: cap exchange race with map/unmap

[Bas Wijnen]

On Wed, Oct 19, 2005 at 09:52:40AM +0200, 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

I hope you don't mind if I answer instead of Marcus. :-)

What Marcus described was that A wants a capability from a server, and gets it
via the cap server.  Then we have:

Server->CapServer->A

Then A copies its capability to B via the capability server.  Then it is
Server->CapServer-->A
                 `->B

So both A and B have their capability mapped by the capability server.  In
fact any capability which may be copied must be mapped by the capability
server (or the server itself must implement the copy operation, this is what
was the original idea.  The code for that is in libhurd-cap-server).

> It feels like the CapServer thing is anyway quite complex compared to
> having a primitive COPY operation.

If both REVOCABLE COPY and COPY are available, then of course we use COPY if
we want to copy.  I don't know how complex it is to add that to L4, and how
much overhead it gives (to COPY itself, but perhaps also to REVOCABLE COPY).

My intuition says that in most cases we don't care if the copy is revocable or
not.  Therefore in most cases we just use whatever is the primitive operation.
If the capability server is a library, to be used by any process which wants
to serve capabilities, we can easily add copy support in there.  No need for
an extra process.  Of course, when the server dies, the capability dies with
it.  But that's no problem, as the object dies with it as well, so the
capability was invalid anyway.

I note that the capability server as a library approach isn't being discussed
at the moment.  Is there something wrong with it?

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature