[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