Figure 2-1
Each object is completely protected from unauthorized access or modification by programs in other objects and from unauthorized programmers. In effect, each object must be considered a "black box" by other objects and by unauthorized programmers. An object's inputs and outputs are documented as part of its external specification. However, the internal data structures, program organization, and algorithms are visible only to a programmer with explicit, authorized access to the contents of the object.
All components of an application exist in objects. Conventional systems differentiate between permanent file storage and temporary working storage. This distinction does not exist in KeyKOS. All permanent data is stored in objects, compiled programs are stored in an executable format in objects, uncompiled source programs are stored in objects, directories are stored in objects, help facilities are stored in objects. Many objects are provided as part of the KeyKOS system; others will be written for a particular application.
An object may only interact with those objects for which it has a key. It is not possible for a program to counterfeit a key. The interaction between two objects may only be of the form specified by the key. For example, an object with a read-only key to a file may not write into the file.
Under KeyKOS, the application described in chapter one might be organized into separate objects.
Figure 2-2
Each object performs a specific function, well protected and isolated from all other objects. The graphics object is the only part of the application that can access the terminal. The data- base manager appears as a single object to the rest of the objects that hold the key to invoke it. Yet as the figure shows, it actually contains three separate components. Note that it is impossible to bypass the data base manager and access the data base directly.
The kernel does not include many functions normally associated with supervisors. For example, it does not process program interrupts or supervisor service requests. It does not contain scheduling algorithms or allocation mechanisms for either virtual memory or external storage. Furthermore, it does not define any policy of resource sharing or protection. Although these functions are all provided as part of the KeyKOS system, they are not part of the kernel itself.
The mechanism for defining these functions has been removed from the kernel and placed in objects. Users, with the proper authority (represented by keys), can modify the function without assistance from kernel programmers. The security policy defines which objects may interact with other objects, and in what manner. It is expressed to the kernel by the distribution of keys. If an object holds a key, it has the right to invoke the key. There is no need for passwords, access lists, or any other mechanism of describing access policy.
Resource allocation policy is also expressed to the kernel by the distribution of keys. For example, one of the keys an object may have is the ability to use resources at a certain rate. This particular kind of key is called a meter key. The control of meters, which in turn controls the rate at which objects may run, may be assigned to one or more individuals within an organization. Each individual may specify how the resources allocated to him are to be distributed. These policies may be modified without involving anyone on the operating systems support or operations staff.
Because the security and access policy has been removed from the kernel, the kernel becomes merely an enforcement mechanism, which is
In KeyKOS all the policy decisions normally associated with an operating system are also user replaceable, on a per user or user group basis. Two common classes of policy deal with:
Another significant new feature of KeyKOS is that programs running in KeyKOS objects are perpetual. Once a program has been placed into an object, it continues to exist in that object forever unless some explicit action is taken to alter or delete the object. Objects survive scheduled or unscheduled system outages, and moves to different hardware configurations. This permanence means that whenever someone needs to invoke a program, the program may be called directly, without the need to explicitly transfer it from permanent storage to temporary working storage (often called loading the program), with assurance that it will be ready to function.
Perpetual programs are made possible by the implementation of virtual reliability. Virtual reliability allows KeyKOS programs to experience software and hardware reliability far in excess of that provided by the basic system upon which they run.
Every KeyKOS system takes periodic checkpoints of the entire system - all data, all programs, all processes, and all working storage. In the event of a system failure of any kind, the entire system and all of the programs within it are restarted from the most recent system checkpoint. This technology allows KeyKOS to give the appearance of continuous operation for all programs, even though the actual execution of the program may be interrupted by system failures or the need to reconfigure onto a smaller or larger processor. It also allows for simpler applications development, since restart-recovery logic is in the operating system instead of in the application program.