Furthermore, the KeyKOS kernel is structured, compact, tamper resistant, and cannot be circumvented. It is the exclusive user of privileged instructions (the only portion of the system which has any code allowed to run in privileged mode). It is therefore the only code ever executed in the hardware's "Supervisor" state. Additionally, the KeyKOS kernel runs in its own address space and is not mapped into any user process space. All other code, whether trusted or untrusted, runs in "Problem" state, a hardware enforced unprivileged mode. This unprivileged code is further isolated into individual domains (virtual address spaces) which are established and maintained by the kernel, and supported by the object oriented and capability-based concepts described below.
Additionally, object oriented systems encourage the design and development of individual entities to support each process or function required, and the consistent use and re-use of these "common" processes. This allows for natural structuring into "well defined, largely independent modules". Each "module" (a KeyKOS object) exhibits well-defined interfaces, and its function is "accessible" only through a small, finite set of well-defined paths. These paths exist via capabilities (or KeyKOS "keys") and are all regulated by the kernel. Additionally, principles of modularity and abstraction can also be directly applied. For example, object orientation supports the design of a set of abstract data types and a set of operations that know about or can manipulate instances of each type. This isolation also allows safer and simpler changes to data types due to the level of abstraction, the limited set of affected operations, and the limitation of the effects of those operations.
Traditional systems must rely on only a small, finite number of hardware states or layers. Although there is some protection between layers, programs on such systems still share the same execution environment and must utilize a more monolithic design. In a capability-based system, pieces of the operating system and all applications programs can be "partitioned" into tens, hundreds, or thousands of isolated entities (KeyKOS objects) which can communicate only through explicit, pre-defined, pre-authorized, and controlled interfaces. KeyKOS objects are used to implement major portions of the TCB and of the operating system functions themselves, as well as for all guest systems, applications, tools and utilities. Each of these KeyKOS objects have separate, kernel maintained and hardware enforced address spaces, helping further to enforce isolation, encapsulation, the Principle of Least Privilege, and the integrity of data and code.
Capabilities help in the enforcement of access rights and the identification of authority, as well as the strict enforcement of the Principle of Least Privilege. No KeyKOS object is aware of any other KeyKOS object, function, or privilege unless it "holds" a capability (key) to that other object. Thus, capabilities are said to convey authority over objects that they represent. Capabilities are "invoked" by one KeyKOS object to "access" or obtain the services of another KeyKOS object. The logical result of a key invocation is the sending of a message from the invoking object to the object represented by that key.
KeyKOS objects that invoke keys are called domains. Domains are entities which are scheduled; they are the things in which processes run. They implement a wide variety of object types in a KeyKOS system. Domains are further discussed in the section on TCB components.
Keys which can be invoked by a domain's program are considered "held" by that domain. Those keys are the only "access rights" which can be directly invoked by that domain. Therefore, instead of potentially having all the privileges of supervisor state or the ability to access any process or data that its user may have access to in some capacity, each KeyKOS object has just the capabilities (privileges and access rights) which it requires in order to perform its specific function. The key itself is required; knowledge of the "name" of some object is no help whatsoever. In conventional systems, all objects belonging to a user are typically accessible to any program or process that the user runs. In a capability based system, the set of capabilities held by an object determines (explicitly and implicitly) all the privileges of that object - a strict implementation of the Principle of Least Privilege.
While capabilities provide the basis for access and thus for protection, integrity is ensured by prohibiting any program manipulation of capabilities and by controlling the dissemination of capabilities. Keys in KeyKOS are inscrutable and cannot be forged; they can not be counterfeited by assembling some bit string in the memory of some KeyKOS object. There is a complete level of abstraction between the capabilities themselves (which are physically stored in the kernel's address space and only viewed and interpreted by kernel code) and the ability of a domain to reference any capability that it "holds" (i.e., that the kernel associates with that particular domain). Domains cannot give themselves new capabilities or "upgrade" the authority of any capabilities they hold.
Single level store allows secondary (disk) memory to appear as one large, flat, and persistent virtual memory to the user or application program. Main memory is used by the KeyKOS kernel as a cache for that virtual memory. Thus, users and programs are independent of external storage. Programs do not do I/O, but rather access data in their virtual memory or obtain data from other objects. All program execution and data access is handled through internal memory management only, solely and completely under the control of the kernel, which cannot be circumvented.
The primary KeyKOS data storage objects are called "segments", which can be up to 2^48 bytes in size. Individual "pages" of a segment are 4096 bytes in length. They hold referenced user programs and/or data, and are mapped as required into a domain's address space by the kernel. Hardware protection mechanisms are utilized by the mapping process to further ensure (at every subsequent reference) read-only enforcement for code or other read-only segments. The System/370 paging hardware is used by the kernel to migrate pages of segments transparently between main memory and disk.
Capabilities are stored in nodes, which are treated similarly to pages. Both pages and nodes have permanent locations on disk and are read into main store on demand. The set of all nodes and the set of all pages in a system completely describes a KeyKOS system. There is no other static data.
All memory and disk storage is managed and controlled totally by the kernel. The KeyKOS checkpoint facility ensures that at periodic intervals all modified pages and nodes are copied to a checkpoint area on "non-volatile" storage. The process alternates checkpoints between two checkpoint work areas to ensure that at least one recent complete image is always available.
Checkpoints are initiated automatically at a default interval of five minutes and can be manually initiated at any time by suitably authorized personnel or processes. The restart from checkpoint is totally automated (no operator intervention is required), so it is fast and secure. The checkpoint process also assists data integrity and high availability since it ensures that there are copies of current state information stored on non-volatile disk storage, protecting against power or CPU failures in which main memory is lost.
Because the checkpoint image is both complete and consistent, it ensures that an exact copy of the entire, internally consistent, secure state is available if needed for restart. Thus the TCB can easily identify all information related to any "permanent" data and state of the entire system at fixed points in time.
KeyKOS also provides an option for maintaining multiple copies of all data on the disks, therefore providing protection against potential media failures. System storage is always duplexed; user storage may be simplexed or "n-plexed" for whatever degree of redundancy is required. A complete image (checkpoint) of the current system state can also be dumped to tape to provide for off- site storage and/or a later recovery or restart (on the same or different CPU).