Figure 2-1With KeyKOS, every application, and in fact the operating system itself, is divided into small, self-contained entities called objects. Objects, which combine programs and data, may communicate with selected other objects via explicitly authorized communication paths identified by keys.
Figure 2-1
A KeyKOS object serves much the same purpose as an address space or a virtual machine in today's systems: it provides a place for the program and its data to exist and to execute. One difference is that a KeyKOS application will typically consist of several objects, each containing a small subsystem (typically 50-1000 lines of source code) implementing a specific function.
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.
In addition to a program and some data, each object has a set of "keys" to some of the other objects. These keys will be given to the object by either its creator or by someone with the authority to connect the pieces of the application together. An object communicates with another object by invoking its key to the other object, passing whatever parameters are appropriate.
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.
Objects and the interactions between them are controlled by the KeyKOS Trusted Computer Base, or TCB (the kernel plus certain closely associated objects). The kernel serves somewhat the same purpose as the supervisor in conventional systems, but it is much smaller and simpler. It contains all the paging algorithms to create objects' virtual memory, and it implements and controls all interactions between objects.
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
This separation of policy definition from policy enforcement results in a substantial reduction in kernel size and complexity, as well as an increase in performance and reliability. The kernel is small and precisely defined, so that it may be possible to actually prove the correctness of both its design and its implementation. (As the technologies for these proofs are in their infancy, such a formal "mathematical" proof may take some time.) A second advantage of separating policy from its enforcement is that nearly all of the KeyKOS kernel may be easily incorporated into microcode, further enhancing performance, reliability, and security.
One of the most significant new features of KeyKOS is that nearly every component is user-replaceable with the proper authority. Command systems, file systems, debugging systems, transaction processing interfaces, all are replaceable. In fact, the system component that services the supervisor calls (SVCs) issued by any particular program is replaceable. Thus it is possible for an application to consist of three object programs, one developed to run under CMS, another under OS/360, and the third under a 370 version of UNIX. If the appropriate levels of simulation are available in each of the supervisor call servicing routines, none of the programs need be modified or recompiled to run under KeyKOS.
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:
Users and user groups may make their own decisions about these issues and implement their policies without involving KeyKOS system personnel. A group may only define policy for its own portion of the system resources and data because the scope of these policy decisions is limited to the group in question.
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.
KeyKOS provides considerable software compatibility with existing operating systems. The compatibility is similar to that offered by VM/CMS, in that many programs may run unchanged on KeyKOS even though KeyKOS has its own distinct architecture, file system, command language, debugging technologies, etc. Just as with VM/CMS, most programs written for OS/360 based systems will run unchanged, while others will require varying degrees of customization.