Synthetic Kernel Objects

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:

“Memory keys” can be placed in a memory context so as to define a range of memory addresses, ultimately in some address space. Several key types known to the kernel are memory keys.
“Meter keys” can be put in a meter context and then provide access to the resources of a CPU. The meter key is one of the key types known to the kernel.
Keys can be invoked which sends a message to the object designated by the key. Typically this will result in another message being returned to the sender. Most kernel objects are accessed by such a key.

Otherwise keys have in common that they can all be:

stored in a slot of a node,
invoked,
included in a message.

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.