[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: |
Tue, 18 Oct 2005 18:24:04 +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 13:01:04 -0400,
Jonathan S. Shapiro wrote:
>
> On Tue, 2005-10-18 at 14:55 +0100, Neal H. Walfield wrote:
> > At Tue, 18 Oct 2005 08:42:55 -0400,
> > Jonathan S. Shapiro wrote:
> > > In order to implement the protocol that you describe, the cap server
> > > requires:
> > >
> > > a) sufficient authority to inspect the content of every capability
> >
> > I am not sure that this much authority is required depending on the
> > design of the server. (See below.)
> >
> > > b) sufficient authority to fabricate any capability (because it
> > > must be able to exchange any capability).
> >
> > I take issue with the any "qualifier" here. The cap server needs to
> > be able to exchange any capability that is *manages*.
>
> Please name a capability that does not require this management?
Any capability for which we don't want a COPY made but only REVOCABLE
COPIES.
Also, I could instantiate my own capability server and create programs
which recognize it as authorative.
My point was that the cap server doesn't require special authority
(ala EROS's keybits or L4's root task). However, on reflection, by
its placement in the system (i.e. unprivileged tasks must use it to
get service), it effectively has the authority to create, as you note,
any capability.
> > [I]f there was a system call which allowed the caller to check if a
> > mapping was derived from another mapping in the same address space,
> > then we can use that to "unroll" mapping loops like the one in the
> > first scenario, i.e. Server -> Client -> Server, or in the second,
> > i.e. Server -> Reference Counter -> Client A -> Client B ->
> > Reference Counter.[1]
> >
> > The requirement is that capabilities which can be exchanged must be
> > registered with a mutually trusted capability server.
>
> I don't think that this is right. The capability server must have
> sufficient authority to obtain a capability that will not be invalidated
> when the process that instantiated the object exits.
I am confused by "when the process that instantiated the object
exits". The object instantiator is the client that made the RPC to
the server to bring the initial capability into existence, right?
I've extracted one of the scenarios from the cited email (reference
counting server = capability server). I think this allows a client,
A, to copy a capability to a second client, B, and then exit without B
having its capability invalidated.
[A] reference counting server positions
itself---mapping-wise---between a server and its clients. The
servers map capabilities to the reference counter which in turn maps
them to clients doing the necessary accounting along the way.
...
The server creates a communication end point and maps it to the
reference counter which receives it, at say, vaddr 23. The
reference counter writes in a table that vaddr 23 corresponds to
this server's capability. Now A gets a mapping, delegates it to B,
which in turn delegates it to the reference counter which receives
it at, for example, vaddr 127. The reference counter does:
map_lookup (127) -> 23
The map_lookup operation in the kernel starts with the mapping the
reference counter has from the client B. It then walks up the tree
first finding the mapping client B has from A, then the mapping
client A has from the reference counter and eventually the mapping
the reference counter has from the server. The reference counter
address space is found and thus the vaddr of this mapping from the
server is returned to the reference counter.
Do you agree?
Thanks,
Neal
- Re: Comparing "copy" and "map/unmap", (continued)
- Re: Comparing "copy" and "map/unmap", Matthieu Lemerre, 2005/10/21
- 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 <=
- 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, 2005/10/19
- 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