[cap-talk] On revocation and the use of wrappers and In Defenseof Identities

Marcus Brinkmann marcus.brinkmann at ruhr-uni-bochum.de
Tue Dec 12 16:44:39 CST 2006


At Tue, 12 Dec 2006 09:47:55 -0500,
"Jonathan S. Shapiro" <shap at eros-os.com> wrote:
> 
> On Tue, 2006-12-12 at 03:15 +0000, David Hopwood wrote:
> > Jonathan S. Shapiro wrote:
> > > In order for the OS to have bounded-time operations, it MUST set a bound
> > > on the number of steps it will take in any given operation.
> > 
> > Right, but isn't traversing wrapper chains in the kernel just an optimization?
> > If the chain would be too long to traverse in a single kernel op, split it into
> > more than one kernel op, each handling a fixed maximum number of wrapping levels.
> > That doesn't sound as though it would be difficult to arrange.
> 
> I believe that if you think about it you will conclude that this
> violates atomicity. The problem is that you have cached the result of a
> partial traversal, and if that result is violated in between steps you
> need to start over.
> 
> Marcus Brinkmann has suggested a variant in which the partial traversal
> is cached within the wrappers themselves. I like this variant.

I have to say I start to get confused juggeling around all those
variants :)

> Unfortunately, it is not straightforward to implement cycle detection in
> either variant.

This is something I wanted to mention before, but I forgot about it.
It seems to me easy to ensure that the delegations form a tree
structure, with the endpoint at the root (there is another tree for
the receive right of the endpoint, of course).  One way to do this is
to not allow changing the wrapped capability in a wrapper once it is
created.  Cycle creation requires that you can insert a name for a
capability derived from the wrapper into the wrapper: If wrapper
creation is implicit, only non-derived names exist to be put into the
wrapper.  What am I missing?

Thanks,
Marcus






More information about the cap-talk mailing list