Exo-core: Application-level Resource Management Operating System Architecture

    Hi, Habrauser!
    Today I want to please you with a translation of part of the article by Dawson Engler, Frans Kaashoeek and James O'Tull Jr. from the MIT Computer Science Laboratory (Dawson R. Engler, M. Frans Kaashoek, James O'Toole Jr., MIT Laboratory of Computer Science ) about exonuclear operating systems. The article itself is quite voluminous, so I will translate it in parts, unless, of course, it will be interesting to you.

    annotation


    Traditional operating systems limit application performance, flexibility, and functionality by using fixed interfaces and providing operating system abstractions such as interprocess communication and virtual memory. The architecture of exoder operating systems solves these problems by moving the management of hardware resources to the application level. Using this architecture, the small kernel of the OS safely transfers all hardware resources to an untrusted library of the operating system through low-level interfaces. Operating system library This library implements system objects and policies. Separating the protection of hardware resources from managing them allows you to implement application-specific abstractions of the operating system, expanding, specializing, or even replacing system libraries.
    We made a prototype of an exonuclear operating system. Studies show that the simplest operations, such as catching exceptions or passing control, are 10 to 100 times faster than Ultrix, the completely monolithic version of UNIX. In addition, we have demonstrated that the exo core allows applications to manage machine resources in a way that is simply unacceptable in traditional operating systems. For example, virtual memory and interprocess communication were implemented using application-level libraries. Studies show that the primitives of virtual memory and interprocess interaction at the user level work 5 to 40 times faster than similar primitives at the kernel level of the Ultrix OS. Comparing with the data given in the literature,

    1. Introduction


    Operating systems define the interface between applications and hardware resources. Unfortunately, well-defined interfaces can significantly reduce performance, as well as the convenience of developing applications. Traditionally, operating systems hide information about machine resources behind such high-level abstractions as processes, files, address space, and interprocess communication. Such abstractions, in fact, define the virtual machine within which the application runs - they cannot be replaced or modified by untrusted applications. A rigid definition of such abstractions is unsatisfactory for three main reasons: this deprives the application of the benefits of domain-specific optimization, it does not allow changes to existing implementations of abstractions,
    We believe that these problems can be solved by transferring resource management to the application level, i.e. make it untrusted. To prove this, we developed a new kernel architecture, an ex core, in which traditional abstractions of the operating system such as virtual memory (VM), interprocess communication (IPC) are implemented at the application level by untrusted software. Using this architecture, a minimal core safely multiplexes available hardware resources. Operating system libraries that operate above the exo-core infrastructure implement high-level abstractions. Application authors choose the libraries they need, or write their own. The use of new libraries is implemented by simply linking executable files.
    Our research has shown that applications can greatly benefit from the fact that there will be a mechanism for controlling how abstractions that manage hardware resources are implemented. Apple and Lee [5] argue that existing general-purpose primitives that access virtual memory slow down the performance of garbage collectors and shared memory systems. Cao [10] says that taking file caching control to the application tier can reduce application uptime by 45%. Hartley and Cheriton [26] and Krueger [30] show that application-dependent virtual memory policies can increase application execution speed. Stonebreaker [47] argues that unsuitable solutions when implementing file systems can significantly affect database spillovers. Taekkot and Levy [50] show
    To provide applications with control over hardware resources, the exo core defines a low-level interface. The architecture of the exo-core is based on one old and simple observation: the lower the level of primitive, the more efficiently it can be used, and the more free it provides for the implementation of high-level abstractions.
    To implement the lowest possible interface (ideally, a hardware interface), the exo-core architects set one goal: to separate protection from control. For example, an exo-core should protect framebuffers, not knowing about the window system, and protect the disk, not having an idea of ​​the file system. One solution is to provide each application with its own virtual machine. As we show later in Section 8, virtual machines can reduce performance. In addition, the exo-core does not emulate hardware resources, but provides them, which makes it possible to use an effective and simple solution. The ex kernel provides three ways to securely provision resources. Firstly, it is a secure binding - applications can be safely connected to hardware resources, and handle events. Secondly,
    We developed a prototype exo-nuclear system based on secure binding, visible resource impairment, and a cancellation protocol. It contains an exo core (Aegis), and untrusted libraries of the operating system (ExOS). We use this system to demonstrate several important properties of exonuclear architecture:
    • exo-kernels can be very effective, due to the small number of primitives that need to be implemented;
    • low-level secure resource multiplexing can be provided with very low latency;
    • traditional abstractions, such as VM and IPC, can be efficiently implemented at the application level, where they can be expanded, specialized, or replaced;
    • applications can create more specialized implementations of abstractions, depending on their needs.

    In practice, our prototype exo-nuclear system provides greater flexibility in developing applications, and also provides greater performance than systems with a monolithic or microkernel. The low-level Aegis kernel interface allows application-level software to use resources more efficiently. Aegis kernel's secure transfer of control is almost 7 times faster than any of the claimed implementations. Exception hooks are five times faster.
    Our core also provides ExOS (and all other application-level software) flexibility not available in microkernel systems. For example, a VM implemented at the application level can easily be integrated with a shared memory system and garbage collectors. The control transfer protocol used by Aegis allows applications to implement a large number of IPC primitives, choosing between performance and usability. For example, microkernel systems such as Amoeba [48], Chorus [43], Mach [2], V [15] do not allow untrusted applications to implement IPC primitives, since virtual memory and message transfer services are implemented in the kernel by trusted servers. Also, abstractions such as the structure of the table of memory pages, abstractions of processes cannot be modified in the microkernel. Finally, many hardware resources, such as a network, an information output system, hard drives, are encapsulated in heavy servers that cannot be bypassed, or optimized for the needs of applications. Such heavy servers, in fact, are kernel subsystems that operate at the application level.
    This article focuses on the architecture and design of the exo-core, as well as on how it can be safely and efficiently implemented. The second part describes the exucleus in more detail. The third is a discussion of the problems that we encountered in the development of design and architecture. In the fourth, we describe the state of the prototype and how we tested it. Parts 5 and 6 represent the implementation. Part seven contains an experiment report in which we demonstrate the flexibility of exonuclear architecture. Part 8 describes the work done, and part 9 summarizes.

    You can familiarize yourself with the original here .

    Also popular now: