[cap-talk] Another "core" principle - virtualize capabilities

Marcus Brinkmann marcus.brinkmann at ruhr-uni-bochum.de
Thu Jan 4 14:24:09 CST 2007


At Thu, 04 Jan 2007 09:39:02 -0500,
"Jonathan S. Shapiro" <shap at eros-os.com> wrote:
> 
> On Thu, 2007-01-04 at 06:20 -0800, Mark S. Miller wrote:
> > Marcus Brinkmann wrote:
> > > [...]   I optimistically believe
> > > that functional membrances can be implement in the kernel efficiently
> > > as a fundamental mechanism.  Furthermore, Neal has a proposal for
> > > fine-grained resource delegation without interposition, so that
> > > resource management can be done without many domain changes per
> > > request as well.
> > 
> > This sounds like a big deal. Has this proposal been explained? Did I miss it?
> 
> I don't believe it at all. Membranes must implement an MxN structure.
> Such a structure cannot be implemented in O(M+N) memory. Therefore
> membranes must allocate. Therefore they cannot be implemented in-kernel
> in a robust design.

I am not sure I understand what structure you are referring to.  But
we may think of different types of "membranes", and in this case I
should try to find a distinct terminology.

My requirement would be revocable delegation, where capabilities
fetched through a delegated capability invocation have a durability
that is subordinate to the original delegation.

Let's start with the L4 mapping hierarchy model.  In this case, there
exists exactly one mapping tree per delegated resource.  To allow for
the above additional requirement, we would need to admit for a
"cross-link" from the invoked capability to the fetched resource.

The costs for this seems to be one additional pointer plus constant
overhead per delegated resource.  This would be accounted together
with the other data from the delegation.

There are a number questions one would have to answer to see if this
can really work.  But it seems to me that in principle the overhead
per delegation compared to existing L4 models is constant.

Thanks,
Marcus




More information about the cap-talk mailing list