[cap-talk] What sustained interest in capabilities

Mitsu Hadeishi mitsu at syntheticzero.com
Thu Jan 8 01:07:32 EST 2009


On Jan 8, 2009, at 12:55 AM, David-Sarah Hopwood wrote:
> Maybe, or maybe not. The difficulty of doing so will depend on the
> initial design. For instance, if the layer incorporates any APIs that
> depend too much on an existing non-capability OS (even if those APIs
> are by themselves consistent with capability security), then any such
> reimplementation is unlikely to happen.

You often make reference to this idea, in many of your emails on this  
subject, but as I keep saying this doesn't apply at all to the designs  
I have been involved with.  This is not to say they don't have other  
flaws --- in fact, the design Monty and I worked on I would now  
improve in a number of ways were I to do it over again --- but none of  
these flaws involve a mixing of capability security and ACLs in the  
sense you suggest.  In fact, as I've written before, I'm not sure how  
or why one would need to do this --- it would actually involve doing  
MORE work to conform the APIs to any aspect of the underlying legacy  
software that depended on an ACL-based design.

The fact that you keep raising this curious idea is why I feel you  
haven't thought through this idea.  In the case of the designs we have  
in mind, very few of the qualities you ascribe to it are remotely the  
case: there is no "impedance mismatch", no added complexity, and next  
to no performance overhead.  It's quite easy to wrap an ACL-based  
service in an object capability, and from then on it acts, talks,  
walks exactly like a "pure" capability in every respect.  I have no  
idea what hypothetical designs you have in mind that would violate  
this, nor why one would build a capability layer in that way.

In fact, the whole point of the design that Monty and I worked on was  
precisely to abstract away as much of the underlying implementation  
complexity as possible --- for which object capabilities were the  
perfect answer (not only for security reasons but for simplification  
reasons).

Mitsu
>
>
> -- 
> David-Sarah Hopwood ⚥
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk



More information about the cap-talk mailing list