This publication describes facilities available to the program running in KeyKOS.
KeyKOS, as described herein, is a specific implementation of the KeyKOS architecture for IBM System/370 architecture computers. The KeyKOS architecture was designed to satisfy the security, sharing, pricing, reliability, and extensibility requirements of a commercial computer service. This architecture is sufficiently different from other operating systems that a description relative to them is infeasible. A description in the style of a computer architecture is possible, and is used in this publication.
KeyKOS consists of a small, privileged-mode kernel, which completely specifies the KeyKOS architecture, and which supports other, non-privileged programs executing in domains. The KeyKOS kernel does not include such "kernel functions" as file directories, files, or command languages; however it circumscribes and completely defines the things that the domain programs can do. The KeyKOS kernel allows domain programs total access to the non-privileged instructions, but completely controls CPU allocation, main and secondary storage, communication between the system components, and use of the privileged instructions.
This publication, along with parts of the IBM System/370 Principles of Operation, provides an architectural reference for KeyKOS. Those sections of the IBM System/370 Principles of Operation needed to complete the description of KeyKOS are the descriptions of the unprivileged execution mode. This specifically does not include Machine-Check Handling, Interruptions, Dynamic Address Translation, and all semi-privileged and privileged instructions. Input/Output Operation descriptions are needed to complete the description of the device I/O key.
KeyKOS domains directly support the concept of objects and thus of abstract data types. The KeyKOS kernel provides primitive objects for use by domain programs.
The kernel objects and a set of objects realized in domains make up the KeyKOS system. These objects collectively provide the functions normally expected in an operating system and are described in KeyKOS Object Reference (KL230).
Unlike the kernel, domains have compartmentalized authority. For example, the printer driver object (which is in a domain) can print the wrong data; however, it cannot affect any domain that does not involve the printer.
Initial Domain Load (IDL) is the KeyKOS system initialization procedure. A predefined set of domains is started. All of the permanent storage of the system is available in a single pool, or a set of pools, as determined by the system administrator. The process of creating environments suitable for application development or execution is performed by the predefined domains, according to rules specified by the system administrator. The IDL process is rather self-contained, and is likely to be customized at some sites.
Once the system has completed the IDL process, it will run continuously (at least as seen by the domain programs inside it). Service interruptions resulting from almost all system hardware and many software failures, as well as modifications to the hardware configuration and the kernel software, are hidden from KeyKOS domain programs via a system-wide checkpoint and restart mechanism. (See the section in Chapter 2 entitled "Checkpoint-Restart Facility"). A checkpoint saves the total state of a KeyKOS system - all data, all programs, all processes - everything.
A KeyKOS system takes a checkpoint at regular intervals in time (typically 5 minutes), and whenever certain system resources become depleted. The checkpoint process appears to happen instantaneously, with no impact on executing programs other than a slight delay. The checkpoint process is an integral part of the KeyKOS paging mechanisms, and does not introduce excessive system overhead.
If a KeyKOS system does crash for any reason, an automatic recovery procedure is initiated (assuming the computer hardware is operational) to restart all domain programs that were running at the time of the most recent checkpoint. All data associated with the programs is also restored to its state at the time of the checkpoint, maintaining complete program/data synchronization in spite of the failure.
To employ another kernel or to modify the system hardware configuration, a system checkpoint is taken, and all domain programs are suspended. When the checkpoint has completed, the hardware configuration can be changed, and/or a different version of the kernel installed and/or invoked. A given kernel is associated with a given checkpoint region. When the system resumes operation, each domain program that was running at the time the associated checkpoint was taken will resume operation with the instruction it was about to execute at the time of the checkpoint.
To modify some domain program or algorithm, logic must be provided that has the authority to make the modification. Since a domain-realized object may be arbitrarily complex, it does not appear possible to provide a system-wide facility for installing such upgrades. In fact, KeyKOS users may deliberately choose not to employ new versions of domain-realized objects if their primary concern is stability.
The system-wide checkpoint facility assures consistency between domain programs and data over system failures. A logical checkpoint facility, called the system journal, is provided for those applications that require synchronization with entities outside of the KeyKOS system, such as users at terminals, other computers, or printers. The journaling facility is immune to the system-wide backup (due to the restart) that occurs after a failure, and allows application-dependent code to reestablish consistency with the universe external to KeyKOS.
The kernel provides a single level store - no program beyond the kernel is aware of the distinction between main and secondary storage.
The kernel provides permanent pages for domain program and data storage, and permanent nodes for key (or "capability") storage. Pages and nodes are kernel-implemented objects, and (like all objects in KeyKOS) are referenced by keys. The kernel provides a mechanism to rescind all keys to pages or nodes so they may be reused securely. Recently used pages and nodes are kept in main storage; others are kept in secondary storage.
The kernel supports replicated storage to allow recovery from storage errors and to improve performance. The maximum degree of storage replication, an implementation parameter, is large.
The kernel provides checkpoint and restart facilities - programs beyond the kernel may be unaware of system outages, scheduled or unscheduled.
The kernel provides a journalizing primitive (pages which are immune to checkpoint/restart) - domain programs may maintain a record of transactions to re-apply after a system restart.
The kernel builds all real channel programs and initially services all interrupts. Other than the secondary storage devices for the single level store, an I/O device is controlled by the kernel in direct response to the holder of a key for that device. Some device capabilities are created and rescinded by even more powerful capabilities.
The kernel directly supports many domains - it switches the real processor(s) to serve the many concurrent activities.
The kernel provides interpretive access to keys to enforce the rules described in chapter 2. Problem state instructions have no direct access to keys.
The kernel directly supports several types of keys (called primary keys) - no programs beyond the kernel are involved with implementing these fundamental functions.
The kernel defines and implements the nature of domains, meters, and segments - including the nature of invocations as described in Chapter 2.