[cap-talk] Another "core" principle - Brinkmann

[Jonathan S. Shapiro]

On Thu, 2006-12-28 at 18:19 -0800, Jed Donnelley wrote:
> One level down I can explain my dismay with such nuances by
> noting that it will be difficult to impossible to map any
> such variations into a common network-wide object-capability
> communication scheme.

Another way to say this is that capabilities should be "virtualizable",
in the sense that one can build a service implementing a facet that is
functionally interchangeable with the "real" capability. The trivial
example, of course, is a user-level "wrapper" object.

This is not as simple as it appears, for two unrelated reasons:

 1. In systems that are built from unidirectional messaging, there may
    not be any one place that the wrapper can be inserted, because
    negotiation of the communication channel can occur in a different
    place from invocation of the simulated capability.

 2. In OS-based systems, virtualization breaks down for memory object
    capabilities. It is not possible to fully virtualize a "page",
    because the hardware MMU cannot process entry capabilities.

I can already here Charlie Landau warming up his keyboard on point (2).
Yes, we can have a keeper on a single page and play games with mappings,
though I quibble that virtualizing a page by using a page doesn't seem
very much like virtualization. The real failure is that the keeper lacks
the ability to respond to a fault by saying "single step the process
that trapped and invoke me again, meanwhile don't give anybody else
access to this page".

That is: what needs to be virtualized in order to fully virtualize
memory objects is the load/store instruction, not the page fault trap
interface. This can be done, but it requires kernel support and it is so
slow as to be useful only in very restricted circumstances (though it is
VERY useful in those circumstances, e.g. debugging).

shap