The Logic of Capabilities

Capability theory with a mathematical slant.

I hope that I am saying nothing here that the capabilities community will find surprising; the goal is to gather and make precise some common assumptions. Of course if there are really no surprises then this note will have been be of little value. These rules are rather arbitrary and other rule sets would be different but equivalent in some sense that I might try to make exact. Some of these equivalence classes are different and that is of real interest.

There are objects and there are capabilities to objects. I will speak of capabilities like floating point numbers wherein I say that there is a floating point number which designates 25/8 even when there are at the moment no values in the machine at hand with that value. Thus a capability to object comes into existence simultaneously with object coming into existence. A floating point register holds some particular floating point number, just as a slot (element of a C-list) holds a capability. This is more a grammatical convention than on ontological stance.

Part of an object is its C-list. A C-list is a zero based array of slots. At a moment in time a slot holds a capability to some object.

Two other parts of an object is its behavior and state which we will initially consider inscrutable. The state of an object typically changes when it acts.

Acts of objects are arranged in a partial ordering (time) which relativity physics describes.

One distinction, perhaps without a difference is that in Keykos it is possible for an object to cease to exist whereupon all slots with capabilities thereto are changed to the null cap (DK(0) in the jargon) which is situation that the object’s behavior may sense and depend upon. (Of course this is all kernel legerdemain.)

The above is very vague as I try to situate ideas of computers, and especially objects, into a mathematical or physics framework. As time passes objects act and may cause new objects to arise or disappear. (This is in contrast to the timelessness of a mathematical group.) Causality is another collection of notions involving a partial ordering of events. Laws of causality apply in the world of objects.

At the ‘bottom’ we have rules for objects and capabilities. Whatever ‘behavior’ turns out to be it is vital that the capabilities held by an object are individually known by the behavior. One rule that captures this connection is the C-list that arranges the capabilities held by an object into a zero indexed array of slots. The behavior deals in array indexes. The behavior can cause messages to be sent that include capabilities and data, addressed by capabilities. The behavior specifies which capabilities are included and which capability serves as the address by specifying C-list indexes. For instance there is no support in the foundation for ‘the most recent capability’ except as provided by the logic of the behavior.

Another distinction perhaps without a difference is who assigns C-list indexes. It is the platform in Unix and Mach but object behavior in Keykos.

The most worrisome distinction, with regards to making a difference is the issue of ‘facets’. In some presentations it is very convenient to say that there are distinct capabilities to the same object and when the object receives a message that it may depend on which of those capabilities the message was addressed with. Most of the pages on this site use that convention. The various capabilities to the same object are known as facets to the object. This note, by contrast, declares that there is just one capability to an object.

More subjects: What levers does the behavior have to pull?
There are some magic primordial objects that bring things about that cannot be build by providing a behavior but without magic objects.
How does new behavior get incorporated into an object?
Combinations of behavior and state

This is a note saying merely that capabilities should be the foundation upon which security is built.