A small number of kinds of Keykos object, the primitive objects, are implemented by privileged code within the kernel. What do we do when we decide we need objects like those provided by the kernel but with modified behavior? We are not asking here how to make old objects behave differently, or even how to make the source of old objects begin delivering objects with a new behavior, but merely how to create a new source of objects that have the new behavior and so may be used mainly wherever the real primitive kernel objects can be used.

In Keykos, keys can be used in three different ways at the kernel level of abstraction:

Otherwise keys have in common that they can all be: The widely available invocable kernel object DISCRIM distinguishes among keys that can by their types provide memory or meter service.

User code can create new meters by the logic described here. User code can create new memory keys by the logic described here. In both these cases the resulting new keys are “official” as used here. When useful programs are added to Keykos they are almost always installed so that a domain can obey them. A “start key” to that domain may then be used to send requests to the new program. Invocations of the start key deliver the resulting message so that the new code has full access to the message and is fully responsible for any replies.

Most of the kernel objects are of use only by invocation. Keys to such objects can be faked by start keys to domains which obeys code that may be able to provide a function suitable to an altered situation. This is generally possible if the domain holds a key to the original kernel object. For instance a fake kernel key might attenuate the authority of a kernel object. It may be possible in other cases as well.

The memory function of a memory key bottoms out in the kernel and the kernel depends on memory keys being official when domains run and access their address space, which is the only ultimate use of a memory key. Some computer architectures would make it marginally feasible to add hair to the kernel which would cause the kernel to invoke a start key which was found in the context of a memory key. With a proper protocol domain code might play the role of RAM. It seems that this invocation would be needed for each reference to memory. We have not seen a case where this would be a profitable addition to the kernel. It has not been implemented. The kernel insists that meters be real.

There is another impediment to fake keys. Many services require and accept a start key to a space bank. The service often demands that the bank be official. Synergy in the form of branding lets the service verify that the key that it received is indeed to an official bank. This bank has probably been parameterized by the caller but it still obeys the official code that the service may rely upon to provide pages that the caller can’t see.

There are quite a few other cases where a proffered key must be to some one of a trusted class of objects. When the kernel forms a domain from nodes it requires that the nodes be real for it uses them in ways that transcend the mere invocation of the node key. The kernel is a ‘friend’ of the node logic in C++ parlance.