Re: cap exchange race with map/unmap

[Neal H. Walfield]

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