Capbility Concepts

[Jonathan S. Shapiro]

> I have used "segrated" much as you use "partitioned". ...I need an
> adjective to modify "capability" that means its bits are hidden! There is
> too much good text devoted to that plan.

In most of the capability literature, the term for this has been
"partitioned". Gehringer has a good discussion of this, and I think that
Levy also uses this term.

> There is yet another difference lurking here. IBM's System 38 devoted a
> hardware bit in memory for each 16 memory bits to mark a location as
> holding part of a capability. Capabilities were 64 bits long and allocated
> admidst other user data but "hidden" by the extra bit so as to make the
> bits therein unreadable and unmodifiable by "user code". The System 38 was
> not the first to protect capabilities admist user data but it may have
been
> the last. AS/400 is in some sense a descendent of the System 38. The 38
> provided a language called "MI" (Machine Interface) that, like Java byte
> codes, was translated before execution. The translator was trusted but not
> enough to dispense with the hardware to protect the capability bits.

This example is why I was distinguishing between detectability and the
transitive read only problem. In the S/38 you can find all of the
capabilities -- it is effectively a type system. However, there is no
provision in the architecture that is equivalent to the sense capability.
Therefore, deep copy is still required where confinement must be enforced.

Deep copy with identity preservation (i.e. there is a one to one
correspondance between objects in the original and objects in the copy in
spite of multiple references) requires a widely available "keybits"
equivalent in order to perform the necessary identity tests.

My point here is that in addition to having a partitioned mechanism, we also
wish to consider whether the mechanism provides efficient state sharing
across a confinement boundary.


shap