[coyotos-dev] Capability Exchange

Jonathan S. Shapiro shap at eros-os.org
Thu Jun 1 12:05:59 EDT 2006


On Thu, 2006-06-01 at 17:36 +0200, Neal H. Walfield wrote:
> At Thu, 01 Jun 2006 10:42:42 -0400,
> Jonathan S. Shapiro wrote:
> > There is a *proposed* operation to do what I have referred to as an
> > "object exchange" between space banks.
> 
> This is the second operation I was referring to.
> 
> 
> > The idea is that two space banks
> > get together and do an even swap of *ownership* of k objects for k
> > objects. This doesn't require finding the objects or swapping their
> > content. It merely requires knowing the *identity* of the objects (which
> > is stored inside their capabilities and is accessible to space bank via
> > the range capability). The space bank internally tracks these identities
> > already so that it knows what to revoke when the space bank is
> > destroyed.
> 
> > In the special case where the "k objects" from one side (or both) are
> > "all of the objects associated with some sub-bank" we can re-parent the
> > bank as well.
> 
> This is the first operation I was referring to.
> 
> > I don't think that any of this relates to rights amplification, but if
> > you can expand on that part of your question I'll try to respond.
> 
> It seems to me that these operations requires more than one
> capability: one of the space banks is invoked (the can) and the second
> is passed as an argument (the can opener).  Since the object state is
> usually associated with the receive FCRB, how does the server find the
> receive FCRB (so that it can find the object associated with the can
> opener) given the sender FCRB it was passed as an argument?  Or would
> something completely different happen?

Ah. I see the problem.

In the case of the space bank, this is actually very easy, because given
an arbitrary capability the space bank can obtain it's object ID using
the range capability. It can also fabricate an FCRB capability (i.e. not
an FCRB sender capability) and examine the second FCRB directly.

This solution does not generalize to other servers -- other servers have
to make use of the DISCRIM service (indirectly, through a constructor)
for this purpose with the same end result. Fortunately, this pattern is
quite rare.

shap



More information about the coyotos-dev mailing list