Layering and Sensory Keys

This note is to describe sensory keys and how they relate to factories. The adjective “sensory” does not refer to a type of key, but is a property of a key that may be directly and instantly sensed by the kernel. There is a broadly available key to a kernel object, DISCRIM, that will make this make this test on any key passed to it and report the result. To bootstrap the intuition a read-write key to a page is not sensory but a read-only key to a page is sensory.

Sensory keys and factory yields are a similar mechanisms at a two levels. At either level a system component may vouch for a key being unable to produce side effects (such as exfiltration of secrets shown to it). Sensory keys are described here in the context of more jargon, and defined most completely here. Sensory keys make the factories much more practical. The VCSK style segment keeper uses sensory keys strategically. As the sense key design provides assurance from the kernel that no side effects will result from use of certain keys to objects defined in the kernel, so may the factory assure that keys that it produces are to objects defined by user mode code will produce no side effects.

The situation of sensory keys vis-à-vis factories is an interesting manifestation of abstraction layering. Here we discuss layering of abstractions built outside the Keykos kernel. There are a few layers below even these.

The Keykos world bottoms out with Pages, Nodes and a few miscellaneous kernel objects. None of those can be profitably viewed as composed of yet more fundamental things. Three special types, Domains, segments and meters, however, are implemented by code in the kernel and yet, are each conceptually composed of pages and nodes. The manner of composition involves keys (capabilities) even though it is the kernel that defines these special objects. Here the kernel conforms to capability discipline as well as enforcing it. There are many reasons for this but one is that it makes security arguments much easier.

Factories are implemented outside of the kernel as absolutely normal user-mode objects. Sensory keys were implemented, in the kernel, at the same time and the factory was about the first user of the logic of sensory keys. Factories are not the oldest, or most primitive objects outside the kernel. Factories invoke such primitive objects as domain creators and banks that are implemented outside the kernel. The kernel does not depend on the logic of any domain code for its integrity.

The yield of a factory is known to be discreet mainly because of the discreetness of the things of which it is built, such as the factory components, or their yield. In this bottoming out we get to things that do not come from factories because they are more primitive than factories. Domain creators are known to be discreet. I just found this in the manual: “Official domain creators without destroy rights are also treated as hole free factories.” The factory is able to recognize a domain creator key by consulting the source of domain creators: the DCC. Space banks are not allowed as components. The requestor must provide space banks. Perhaps the domain creator creator should be allowed, but is not. Only the kernel can vouch for the various sensory keys. The swiss army knife called “DISCRIM” was enhanced to do the job.

Charlie Landau would argue, I think, that the order of layers should not be apparent as they are here. I don’t know whether he would object to this description or design.

There seems to be an incompleteness here. Factories have invested in the design and mechanism to assure a certain kind of side-effect free object. This mechanism is unavailable to other domain code that plays by the rules and is in thus side-effect free. But what rules? The factory made up its own rules, published them and along with arguments that the results were side-effect free. There is no other reason to believe that factories are free of side-effects.

Are kernel hooks necessary?