A. C. Bomberger and N. Hardy. The KeyKOS Nanokernel Architecture. In Proc. of the USENIX Workshop on Micro-kernels and Other Kernel Architectures, pages 95--112, Seattle, WA, Apr. 1992.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....of an extra layer of software in this manner can only have an adverse effect on performance. There are numerous examples of operating systems that support persistence in one form or another. Examples include Multics [5, 13, 37] MONADS [26, 39, 40] Eumul L3 [28] Clouds [14] Choices [9] KeyKOS [8, 24], and Grasshopper [17, 41] For the past five years, we have been involved in the design and implementation of the Grasshopper system, an overview of which is presented below. 3. Grasshopper Grasshopper is an operating system explicitly designed to support orthogonal persistence. To this end, it ....

A.C. Bomberger, N. Hardy, A.P. Frantz, C.R. Landau, W.S. Frantz, J.S. Shapiro, and A.C. Hardy. "The KeyKOS Nanokernel Architecture", in Proceedings of the USENIX Workshop on Micro-kernels and Other Kernel Architectures, 1992.

....to a remote node for execution is a form of ordinary remote evaluation [14] with our mobile code plane being responsible for its configuration. For work on handling software mobility at the level of native code only, we may also refer to [9] Beside general and older work on micro and nanokernels [7,10,4], Mach [1] Chorus [12] process migration [2] and Exokernel [6] we point to a paper that is closely related to our work and was published in 1985: in [3] Banino et al. describe activity messages which are a special form of messages sent between Chorus actors . They can influence how the ....

A. C. Bomberger, A. P. Frantz, W. S. Frantz, A. C. Hardy, N. Hardy, Landau C. R., and J. S. Shapiro. The KeyKOS Nanokernel Architecture. In Proceedings of the USENIX Workshop in Micro-Kernels and Other Kernel Architectures, pages 95--112. USENIX Association, April 1992.

....notion of restricted delegation; these are often called capability based systems. Capabilities in KeyKOS, Eros, and Mach are unforgeable because the kernel manages them. A process delegates its authorization by asking the kernel to pass a capability, possibly with restriction, to another process [6, 20, 4]. Amoeba capabilities, in contrast, are secret random numbers, and may be transmitted as raw data [22, 16] Amoeba must assume that a cluster is a secure network; we consider such a cluster a single administrative domain. Snowflake end to end authorization could integrate either sort of capability ....

A. Bomberger, A. Frantz, W. Frantz, A. Hardy, N. Hardy, C. Landau, and J. Shapiro. The KeyKOS nanokernel architecture. In Proceedings of the USENIX Workshop on Micro-Kernels and Other Kernel Architectures, pages 95--112, 1992.

....the kernel is copying the IPC message into or out of the user s address space; the IPC operation cannot be cleanly interrupted and restarted at this point, but handling the page fault may involve arbitrary delays due to communication with other user mode servers or even across a network. KeyKOS [6] comes very close to solving this problem by limiting all IPC operations to transfer at most one page of data and performing this data transfer atomically; however, in certain corner case situations it gains promptness by sacrificing correctness. 1 Amoeba [26] allows one user mode process (or ....

A. C. Bomberger and N. Hardy. The KeyKOS Nanokernel Architecture. In Proc. of the USENIX Workshop on Micro-kernels and Other Kernel Architectures, pages 95--112, Apr. 1992.

....kernel, thereby potentially improving operating system portability. Furthermore, the use of common underlying services provides support for the coexistence and interoperability of multiple operating system environments on a single host as user level programs [32] Mach [32] Chorus [197] KeyKOS [42], QNX [106] and BirLiX [208] are a few examples of micro kernel based operating systems. 2.8 Application specific Operating Systems Many application domains impose specific requirements on operating system functionality, performance, and structure. One blatant example of such requirements comes ....

A. Bomberger, N. Hardy, A. Frantz, C. Landau, W. Frantz, J. Shapiro, and A. Hardy. The keykos nanokernel architecture. In Proceedings of the USENIX Workshop on MicroKernels and Other Kernel Architectures, pages 95--112, April 1992.

....philosophy. The Mach microkernel was developed primarily for shared memory multi processors, while the Chorus developers laid great emphasis on inter node communication [89] The primary focus in Amoeba was the creation of an entirely transparent distributed system. Another microkernel, KeyKOS [14, 45], was developed with the aim of providing high reliability and availability. The QNX [46] mi7 crokernel was developed primarily to provide real time support. KeyKOS will also be examined briefly. 2.1.1 Mach The Mach microkernel was developed in Carnegie Mellon University. It was developed with the ....

....memory allocation. All kernel state is derived from information that persists across system restarts. Thus the kernel does not contain information that must be checkpointed. The system state, including all running processes can be restored, and resume, within thirty seconds of restoring power [14]. All data in KeyKOS resides in persistent virtual memory. This arrangement provides a single level storage model that is presented to the application layer. The system checkpoints periodically to guarantee persistence. Thus there are no requirements for an orderly startup or shutdown in KeyKOS. ....

[Article contains additional citation context not shown here]

Alan C. Bomberger, A. Peri Frantz, William S. Frantz, Ann C. Hardy, Norman Hardy, Charles R. Landau, and Jonathan A. Shapiro. The KeyKOS Nanokernel Architecture. In Proceedings of the 1992 USENIX Workshop on Micro-kernels and Other Kernel Architectures, pages 95--112, April 1992.

....typing to restrict the way a client (the program that uses an object) can interact with the object. Another claim that has been often repeated is that objects can be used as capabilities [17] Capabilities are kinds of permits for manipulating entities, they are mostly used in operating systems [4][6] 37] It is also common to see arguments to the effect that information hiding is a form of security mechanism [17] Morrison et al. argued that although objects may be used to implement capabilities, they are not in themselves equivalent to capabilities [29] On a more general note the ....

A. C. Bomberger, A. P. Frantz, W. S. Frantz, A. C. Hardy, N. Hardy, C. R. Landau, and J. S. Shapiro. The KeyKos nanokernel architecture. In Proceedings of the USENIX Workshop on Micro-Kernels and Other Kernel Architectures, pages 95---112. USENIX Association, April 1992.

....We believe that the careful working out of domain specific inter layer protocols is complementary to our RVM work: the high level component of our VM (the common protocols ) could use those protocols for each class of functionality it provides. A few existing operating systems, such as KeyKOS[3] and L3[34] have implemented checkpointing on a wholemachine basis in the kernel. While this feature appears practical and useful in some situations, the checkpointing built into these systems is inflexibly tied to the machine boundary: it cannot be used on smaller scopes such as processes or ....

.... virtual machines based on raw hardware interfaces[4] 1 Second, a low level API [14] implemented by the microkernel) provides simple memory management, scheduling, and IPC primitives similar to those of conventional small microkernels such as the V CacheKernel[9] L3 L4[33, 35] and KeyKOS[20, 3]. This API is designed to support recursive virtual machines efficiently by ensuring that it is not necessary for every virtual machine layer to interpose on and simulate primitive operations such as I O instructions, page table management, etc. The fundamental properties required to achieve this ....

A. C. Bomberger and N. Hardy. The KeyKOS nanokernel architecture. In Proc. of the USENIX Workshop on Micro-kernels and Other Kernel Architectures, pages 95--112, Seattle, WA, Apr. 1992.

....was only an internal interface. The Pmap interface also does not consider multi mapping consistency support, as required for memory based messaging. In contrast to the caching of operating system objects in the Cache Kernel, which writes back the objects to untrusted application kernels, KeyKOS [10] writes back objects to protected disk pages. That is, it is only caching the objects in the sense of paging those data structures. A redesign of Multics [20] proposed the idea of virtual processes that were loaded and saved from a fixed number of real processes, similar to the thread caching ....

....Kernel such that it can be integrated with the PROM for further stability and reliability. They also provide application performance that is competitive with conventional monolithic operating systems. In contrast to the highly optimized, same CPU and crossaddress space IPC in L3 [12] and KeyKOS [10], the Cache Kernel supports inter CPU peer to peer horizontal communication through memory based messaging. The Cache Kernel trap forwarding facility most closely resembles the sort of same CPUIPC found in L3, providing efficient transfer of control in the special case of an application ....

A.C. Bomberger et al. The KeyKOS nanokernel architecture. In Proceedings of the USENIX Workshop on Micro-kernels and Other Kernel Architectures. USENIX, April 1992.

....In welldesigned servers providing system functions, we suspect that internal contention can be minimized so that the importance of RPC speed outweighs that of context switch speed. We point out that in many commercial microkernel based systems, including QNX[20] Chorus[26] and KeyKOS[6], OS servers do not generally multiplex user level threads over multiple kernel threads. Instead, these systems either provide multithreading purely with kernel threads, or their functions are sufficiently decomposed so that each server can be based on a single kernel thread, requiring no internal ....

Alan C. Bomberger and Norman Hardy. The KeyKOS nanokernel architecture. In Proc. of the USENIX Workshop on Micro-kernels and Other Kernel Architectures, pages 95--112, Seattle, WA, April 1992.

.... true when completely unknown, untrusted code is downloaded and run in a secure environment such as that provided by Java[13] or OmniWare[2] Schedulers have been designed that address this problem by providing flexible hierarchical control over CPU usage at different administrative boundaries[5, 14, 15, 30, 31, 32]. However, it is not yet clear how these algorithms will address other needs, such as those of hard real time applications; certainly it seems unlikely that a single holy grail of scheduling policies will be found. With the growing diversity of application needs and scheduling policies, it is ....

A. C. Bomberger and N. Hardy. The KeyKOS Nanokernel Architecture. In Proc. of the USENIX Workshop on Micro-kernels and Other Kernel Architectures, pages 95--112, Seattle, WA, Apr. 1992.

....overall, but they do not allow us to catch memory errors in dirty user pages. We expect that these will eventually become the dominant source of data corruption on current commodity hardware, and can be prevented only with hardware support. Related Efforts EROS is closely related to KeyKOS [Har85, Bom92], a system developed by Key Logic, Inc. to support reliable time sharing services among mutually suspicious users. The EROS microkernel design borrows heavily from their experiences. The implementation is completely new, and EROS departs from the KeyKOS architecture in two ways. First, we have ....

Allen C. Bomberger, A. Peri Frantz, William S. Frantz, Ann C. Hardy, Norman Hardy, Charles R. Landau, Jonathan S. Shapiro. "The KeyKOS NanoKernel Architecture," Proceedings of the USENIX Workshop on MicroKernels and Other Kernel Architectures. USENIX Association. April 1992. pp 95-112.

....into the kernel. Protection domains aid with the principle of least privilege, which means that applications should have access to only and exactly those services and objects that are necessary to their operation, minimizing the failure scope of the application, simplifying security arguments [Bom92], enforcing encapsulation[Wul81] and easing software maintainance[Lyc78] Objects The system provides a virtual world composed of objects [Lam76] These objects come in a variety of 2 types, which are described in Section 4. Objects are encapsulated: each object defines a set of operations that ....

....any of the advantages of the new system. If what you want to do is run UNIX, you should run UNIX. Equally important, both our own past experience and that of others suggests that this evaluation strategy does not lend itself to a correct understanding of the performance of the respective systems [Che93, Bom92]. 8 8.1 Issues in Comparison Three differences in semantics between UNIX and EROS make direct comparisons of certain operations difficult: accountability, persistence, and the absence of the fork( primitive. Neither of these features has a direct equivalent in conventional systems, and each ....

[Article contains additional citation context not shown here]

Allen C. Bomberger, A. Peri Frantz, William S. Frantz, Ann C. Hardy, Norman Hardy, Charles R. Landau, Jonathan S. Shapiro. "The KeyKOS NanoKernel Architecture," Proceedings of the USENIX Workshop on Micro-Kernels and Other Kernel Architectures. USENIX Association. April 1992. pp 95-112.

....formal speci cation. 1 Introduction EROS [18] is a pure capability system that provides a mechanism for creating and instantiating con ned subsystems: the constructor. This mechanism is part of the system s trusted computing base. EROS is a clean room reimplementation of the KeyKOS architecture [2, 6] (originally called GNOSIS [3] It adopts the KeySafe [13] design as the basis for mandatory security policy enforcement. The security enforcement provided by KeySafe is predicated on the correctness of the constructor. Boebert [1] and Karger [8] have argued that unmodi ed capability systems ....

A. C. Bomberger, A. P. Frantz, W. S. Frantz, A. C. Hardy, N. Hardy, C. R. Landau, and J. S. Shapiro. The KeyKOS NanoKernel Architecture. In Proc. USENIX Workshop on MicroKernels and Other Kernel Architectures, pages 95-112. USENIX Association, Apr. 1992.

....system; all TPF applications ran in supervisor mode, and were mutually trusted. The Motorola implementation of KeyKOS included a full binary compatible POSIX emulation. A limited performance evaluation was made against Omron s Mach 2. 5 implementation (a monolithic kernel) for the same machine [5]. Performance was mixed, ranging from 3.89 times slower than Mach performance on opening and closing files to 14 times faster on memory manipulation. The open close result reflects a naive implementation, as noted in the paper. 6.6 Performance summary The benchmark results are summarized ....

.... level benchmarks. The construction of a native EROS execution environment is expected to take several people another year, after which it will be possible to perform such measurements. The conclusion at this stage is that building such an environment is worth pursuing. Experience with KeyKOS [5, 16] suggests that the microbenchmark results reported here approximately predict real system performance. The design presented here incorporates both user level fault handling, which is not uncommon in modern microkernels, and, uniquely as far as we know, user level storage allocation. Performance ....

A. C. Bomberger, A. P. Frantz, W. S. Frantz, A. C. Hardy, N. Hardy, C. R. Landau, and J. S. Shapiro. The KeyKOS nanokernel architecture. In Proc. USENIX Workshop on Micro-Kernels and Other Kernel Architectures, pages 95--112. USENIX Association, Apr. 1992.

....to model all real capability systems known to support the confinement property, and to exclude all known systems that do not. Perhaps more important, the Metagap e family is known to include two members that deliver respectable performance. The KeyKOS system runs on the S 370 and MC88000 families [Har85, Bom92]. It has been used to process VISA transactions, and exhibits unusual stability in this class of applications [Lan93] EROS, a research system at the University of Pennsylvania, has shown that the performance of capability systems can match that of access list based architectures [Sha97a, Sha96c] ....

Allen C. Bomberger, A. Peri Frantz, William S. Frantz, Ann C. Hardy, Norman Hardy, Charles R. Landau, Jonathan S. Shapiro. "The KeyKOS NanoKernel Architecture," Proceedings of the USENIX Workshop on Micro-Kernels and Other Kernel Architectures. USENIX Association. April 1992. pp 95-112.

....system overall, but they do not allow us to catch memory errors in dirty user pages. We expect that these will eventually become the dominant source of data corruption on current commodity hardware, and can be prevented only with hardware support. Related Efforts EROS is closely related to KeyKOS [Hardy85, Bomberger92], a system developed by Key Logic, Inc. to support reliable time sharing services among mutually suspicious users. The EROS microkernel design borrows heavily from their experiences. The implementation is completely new, and EROS departs from the KeyKOS architecture in two ways. First, we have ....

Allen C. Bomberger, A. Peri Frantz, William S. Frantz, Ann C. Hardy, Norman Hardy, Charles R. Landau, Jonathan S. Shapiro. "The KeyKOS NanoKernel Architecture, " Proceedings of the USENIX Workshop on Micro-Kernels and Other Kernel Architectures. USENIX Association. April 1992. pp 95-112.

....into the kernel. Protection domains aid with the principle of least privilege, which means that applications should have access to only and exactly those services and objects that are necessary to their operation, minimizing the failure scope of the application, simplifying security arguments [Bom92], enforcing encapsulation[Wul81] and easing software maintainance[Lyc78] Objects The system provides a virtual world composed of objects [Lam76] These objects come in a variety of types, which are described in Section 4. Objects are encapsulated: each object defines a set of operations that ....

....any of the advantages of the new system. If what you want to do is run UNIX, you should run UNIX. Equally important, both our own past experience and that of others suggests that this evaluation strategy does not lend itself to a correct understanding of the performance of the respective systems [Che93, Bom92]. 8 8.1 Issues in Comparison Three differences in semantics between UNIX and EROS make direct comparisons of certain operations difficult: accountability, persistence, and the absence of the fork( primitive. Neither of these features has a direct equivalent in conventional systems, and each has ....

[Article contains additional citation context not shown here]

Allen C. Bomberger, A. Peri Frantz, William S. Frantz, Ann C. Hardy, Nor10 man Hardy, Charles R. Landau, Jonathan S. Shapiro. "The KeyKOS NanoKernel Architecture, " Proceedings of the USENIX Workshop on Micro-Kernels and Other Kernel Architectures. USENIX Association. April 1992. pp 95-112.

....users. Like KeyKOS, EROS implements global orthogonal persistence based on a simple fundamental object model; all system state, including processes, are checkpointed on a periodic basis. Also like KeyKOS, EROS is designed as a small microkernel with a high performance message passing subsystem [Bomberger92]. Unlike KeyKOS, EROS is designed as a distributed, real time system. Threads in EROS are first class objects associated with a particular compute resource. KeyKOS meters have been abandoned in favor of schedule capabilities, which distribute more easily and are better suited to real time ....

Allen C. Bomberger, A. Peri Frantz, William S. Frantz, Ann C. Hardy, Norman Hardy, Charles R. Landau, Jonathan S. Shapiro. "The KeyKOS NanoKernel Architecture, " Proceedings of the USENIX Workshop on Micro-Kernels and Other Kernel Architectures. USENIX Association. April 1992. pp 95-112.

No context found.

A. C. Bomberger and N. Hardy. The KeyKOS Nanokernel Architecture. In Proc. of the USENIX Workshop on Micro-kernels and Other Kernel Architectures, pages 95--112, Seattle, WA, Apr. 1992.

No context found.

A. C. Bomberger and N. Hardy. The KeyKOS Nanokernel Architecture. In Proc. of the USENIX Workshop on Micro-kernels and Other Kernel Architectures, pages 95--112, Seattle, WA, Apr. 1992.

No context found.

Bomberger, A., Hardy, N., Frantz, A. P., Landau, C. R., Frantz, W. S., Shapiro, J. S. and Hardy, A. C. The KeyKOS nanokernel architecture. In Proceedings of the USENIX Micro-Kernels and Other Kernel Architectures Workshop, Seattle, Washington, USENIX, 95-112, 1992.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC