DOCSLIB.ORG

A Heterogeneous Microkernel OS for Rack-Scale Systems

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Heterogeneous Microkernel OS for Rack-Scale Systems A Heterogeneous Microkernel OS for Rack-Scale Systems Matthias Hille Nils Asmussen Technische Universität Dresden Barkhausen Institut [email protected] [email protected] Hermann Härtig Pramod Bhatotia Technische Universität Dresden The University of Edinburgh [email protected] [email protected] ABSTRACT 1 INTRODUCTION Datacenters are adopting heterogeneous hardware in the Heterogeneous hardware is finding its way into datacenters. form of different CPU ISAs and accelerators. Advances in Cloud vendors offer x86 and ARM general purpose cores, low-latency and high-bandwidth interconnects enable hard- GPUs, TPUs and FPGAs [20, 25, 26, 28]. Today these compo- ware vendors to tighten the coupling of multiple CPU servers nents are hosted in discrete servers which are bundled in a and accelerators. The closer connection of components fa- rack [16]. A server consists of multiple CPUs, memory and cilitates bigger machines, which pose a new challenge to extension cards including accelerator cards [38]. This design operating systems. We advocate to build a heterogeneous offers little flexibility regarding the ratio between general- OS for large heterogeneous systems by combining multiple purpose and specialized compute power, meaning CPUs and OS design principles to leverage the benefits of each design. accelerators, respectively. One could argue that there is flex- Because a security-oriented design, enabled by simplicity ibility within one server, namely whether or not accelerator and clear encapsulation, is vital in datacenters, we choose to cards are added and if so, which kind of accelerators. How- survey various design principles found in microkernel-based ever, this is not the granularity a datacenter operator thinks systems. We explain that heterogeneous hardware employs of. Companies which run large datacenters, like Facebook, different mechanisms to enforce access rights, for example are starting to build racks out of chassis which consist of dif- for memory accesses or communication channels. We outline ferent server types like compute blades and accelerators [4]. a way to combine enforcement mechanisms of CPUs and This shows, that in a datacenter the flexibility should rather accelerators in one system. A consequence of this is a hetero- be at the level of a whole rack to fit the demands of individ- geneous access rights management which is implemented as ual workloads and ease component composition. From this a heterogeneous capability system in a microkernel-based demand of flexibility we derive an architecture that brings OS. flexibility into a rack by means of different board types which make up a rack. ACM Reference Format: In a rack-scale design as depicted in Figure 1, a machine Matthias Hille, Nils Asmussen, Hermann Härtig, and Pramod Bhato- handled by the operating system comprises the whole rack. tia. 2020. A Heterogeneous Microkernel OS for Rack-Scale Systems. In ACM SIGOPS Asia-Pacific Workshop on Systems (APSys ’20), Au- Due to the amount of components and the size of the rack gust 24–25, 2020, Tsukuba, Japan. ACM, New York, NY, USA, 9 pages. the overhead for cache-coherence across the whole rack https://doi.org/10.1145/3409963.3410487 is prohibitive. Hence, we do not expect a rack to resem- ble a cache-coherent machine but rather a conglomeration of cache-coherent islands [37]. This leaves the OS with a Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not heterogeneous system containing various architectures and made or distributed for profit or commercial advantage and that copies bear communication schemes. On top of that, the enforcement of this notice and the full citation on the first page. Copyrights for components access rights, one of the main tasks of an OS, works differ- of this work owned by others than ACM must be honored. Abstracting with ently on diverse architectures. credit is permitted. To copy otherwise, or republish, to post on servers or to Various operating systems have been developed and op- redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. timized for a particular system type. One such system type APSys ’20, August 24–25, 2020, Tsukuba, Japan are cache coherent systems for which highly optimized oper- © 2020 Association for Computing Machinery. ating systems like Linux, Windows, XNU and Fiasco.OC [34] ACM ISBN 978-1-4503-8069-0/20/08...$15.00 have been developed. on the contrary, there are systems https://doi.org/10.1145/3409963.3410487 APSys ’20, August 24–25, 2020, Tsukuba, Japan Matthias Hille, Nils Asmussen, Hermann Härtig, and Pramod Bhatotia the severity of many errors compared to the same errors CPU NIC CPU NIC CPU NIC in a monolithic OS [9]. The least-privilege access policy is Accelerator NIC Accelerator NIC CPU NIC typically implemented by means of capabilities [34]. We propose to merge different microkernel-based OS de- CPU NIC Accelerator NIC CPU NIC signs into one OS to get the maximum out of both: CPUs Rack Rack Rack and accelerators. When combining different OS designs di- CPU NIC Accelerator NIC CPU NIC verse OS abstractions and therefore various capability types and hardware features are fused in one system. This raises Accelerator NIC Accelerator NIC Accelerator NIC the question how to design hardware that couples different Accelerator NIC Accelerator NIC Accelerator NIC hardware architectures in a system so it is modular, secure, and provides isolation which is configurable by software. The combination of different isolation mechanisms requires Figure 1: Architectural scheme for racks in a datacen- the OS to control these and mediate resources of different ter: A rack is equipped with two different board types: architectures. CPU boards and accelerator boards. Each board is con- In this work we present microkernel-based OS architecture nected with an intra-rack interconnect resembled by for a new hardware paradigm in large datacenter. We cover the blue boxes on the left. The unconstrained choice the hardware landscape and the resulting aspects for the OS between board types provides flexibility in this de- with an emphasis on microkernels. We give an outline how to sign. combine different isolation and communication mechanisms in an OS and the implications on the capability system. like Popcorn Linux [6] and M3 [5] designed to work without cache-coherence. The design of the Barrelfish multikernel [7] 2 DATACENTER ARCHITECTURE aims at a shared-nothing architecture, while its implementa- A modular and extensible hardware architecture is crucial tion still uses cache-coherence protocols to implement mes- for datacenters to facilitate fast exchange of components or saging. So far the requirements for different system types quick launches of new hardware. In the following we present were following from the integration of CPUs and memory, a hardware architecture of a rack derived from recent efforts but there are also accelerators which have been considered of hardware vendors like Dell and datacenter providers in- in OS designs like Omnix [45] and M3. They strive to elevate cluding Facebook, Microsoft and Amazon [16, 23, 36, 48]. We accelerators to first-class citizens in the OS design, giving further explain our view on how a suitable OS for such a them direct access to OS services as other systems also tried system can be built. for selected types of accelerators [46, 47]. Finally, an OS de- sign like LegoOS [43], considering disaggregated hardware resources, splits the OS into various components for each 2.1 Hardware Architecture resource type. We base our architecture on the trend that resources are be- In our opinion each of these OS designs solves a specific coming more numerous and accelerators gain importance [3, requirement, but in a flexible rack-scale datacenter design 13, 24, 28, 55] and also interconnects advance and enable as we envision it, multiple requirements exist in parallel like tighter coupling of servers [23, 48]. Figure 2 depicts a snip- architectural heterogeneity and the heterogeneity of com- pet of a rack. We choose a machine to span a whole rack, munication mechanisms. Hence, we propose to pick features however, the principles of our approach are also applicable to of the individual OS designs and combine them into one machines of smaller extent, for example a chassis comprising heterogeneous rack-scale OS. several boards. Besides the goals to improve flexibility, system perfor- All boards of a rack are interconnected with a fast fab- mance and integrate accelerators into the system, security ric which enables close collaboration between them. The is essential for datacenters. A cloud datacenter is constantly interconnect provides two main features: 1) configurable exposed via the network and security breaches due to er- communication channels for message passing and 2) a con- roneous software raise serious threats to a cloud vendor’s figurable access to memory ranges. This can be implemented business. Microkernel-based OS designs suit the increased by an interconnect like Gen-Z [15], CXL [1] as has been security requirements due to their small trusted computing showcased by Dell EMC recently [32]. Similar to these inter- base (TCB), clear encapsulation and least-privilege access connects M3 [5] introduced a component called data transfer policy. The small code base of the microkernel makes it unit (DTU) providing a configurable high-bandwidth inter- possible to verify the kernel [33]. Encapsulation and a least- connect. The interconnect between the boards is configured privilege access policy enable failure containment limiting by a central privileged entity labeled with rack kernel in A Heterogeneous Microkernel OS for Rack-Scale Systems APSys ’20, August 24–25, 2020, Tsukuba, Japan C DRA DRA are equipped with memory which is also accessible from other boards (via the board DTU). The system could also be extended with a memory or storage board type to in- DRAM DRAM U tegrate NVM and disks into the system.
Load more

Recommended publications
  • Improving Learning of Programming Through E-Learning by Using Asynchronous Virtual Pair Programming
    Improving Learning of Programming Through E-Learning by Using Asynchronous Virtual Pair Programming Abdullah Mohd ZIN Department of Industrial Computing Faculty of Information Science and Technology National University of Malaysia Bangi, MALAYSIA Sufian IDRIS Department of Computer Science Faculty of Information Science and Technology National University of Malaysia Bangi, MALAYSIA Nantha Kumar SUBRAMANIAM Open University Malaysia (OUM) Faculty of Information Technology and Multimedia Communication Kuala Lumpur, MALAYSIA ABSTRACT The problem of learning programming subjects, especially through distance learning and E-Learning, has been widely reported in literatures. Many attempts have been made to solve these problems. This has led to many new approaches in the techniques of learning of programming. One of the approaches that have been proposed is the use of virtual pair programming (VPP). Most of the studies about VPP in distance learning or e-learning environment focus on the use of the synchronous mode of collaboration between learners. Not much research have been done about asynchronous VPP. This paper describes how we have implemented VPP and a research that has been carried out to study the effectiveness of asynchronous VPP for learning of programming. In particular, this research study the effectiveness of asynchronous VPP in the learning of object-oriented programming among students at Open University Malaysia (OUM). The result of the research has shown that most of the learners have given positive feedback, indicating that they are happy with the use of asynchronous VPP. At the same time, learners did recommend some extra features that could be added in making asynchronous VPP more enjoyable. Keywords: Pair-programming; Virtual Pair-programming; Object Oriented Programming INTRODUCTION Delivering program of Information Technology through distance learning or E- Learning is indeed a very challenging task.
    [Show full text]
  • The Joe-E Language Specification (Draft)
    The Joe-E Language Specification (draft) Adrian Mettler David Wagner famettler,[email protected] February 3, 2008 Disclaimer: This is a draft version of the Joe-E specification, and is subject to change. Sections 5 - 7 mention some (but not all) of the aspects of the Joe-E language that are future work or current works in progress. 1 Introduction We describe the Joe-E language, a capability-based subset of Java intended to make it easier to build secure systems. The goal of object capability languages is to support the Principle of Least Authority (POLA), so that each object naturally receives the least privilege (i.e., least authority) needed to do its job. Thus, we hope that Joe-E will support secure programming while remaining familiar to Java programmers everywhere. 2 Goals We have several goals for the Joe-E language: • Be familiar to Java programmers. To minimize the barriers to adoption of Joe-E, the syntax and semantics of Joe-E should be familiar to Java programmers. We also want Joe-E programmers to be able to use all of their existing tools for editing, compiling, executing, debugging, profiling, and reasoning about Java code. We accomplish this by defining Joe-E as a subset of Java. In general: Subsetting Principle: Any valid Joe-E program should also be a valid Java program, with identical semantics. This preserves the semantics Java programmers will expect, which are critical to keeping the adoption costs manageable. Also, it means all of today's Java tools (IDEs, debuggers, profilers, static analyzers, theorem provers, etc.) will apply to Joe-E code.
    [Show full text]
  • Access Control and Operating System
    Outline (may not finish in one lecture) Access Control and Operating Access Control Concepts Secure OS System Security • Matrix, ACL, Capabilities • Methods for resisting • Multi-level security (MLS) stronger attacks OS Mechanisms Assurance • Multics • Orange Book, TCSEC John Mitchell – Ring structure • Common Criteria • Amoeba • Windows 2000 – Distributed, capabilities certification • Unix Some Limitations – File system, Setuid • Information flow • Windows • Covert channels – File system, Tokens, EFS • SE Linux – Role-based, Domain type enforcement Access control Access control matrix [Lampson] Common Assumption Objects • System knows who the user is File 1 File 2 File 3 … File n – User has entered a name and password, or other info • Access requests pass through gatekeeper User 1 read write - - read – OS must be designed monitor cannot be bypassed User 2 write write write - - Reference Subjects monitor User 3 - - - read read User process ? Resource … User m read write read write read Decide whether user can apply operation to resource Two implementation concepts Capabilities Access control list (ACL) File 1 File 2 … Operating system concept • “… of the future and always will be …” • Store column of matrix User 1 read write - Examples with the resource User 2 write write - • Dennis and van Horn, MIT PDP-1 Timesharing Capability User 3 - - read • Hydra, StarOS, Intel iAPX 432, Eros, … • User holds a “ticket” for … • Amoeba: distributed, unforgeable tickets each resource User m read write write • Two variations References – store
    [Show full text]
  • Research Purpose Operating Systems – a Wide Survey
    GESJ: Computer Science and Telecommunications 2010|No.3(26) ISSN 1512-1232 RESEARCH PURPOSE OPERATING SYSTEMS – A WIDE SURVEY Pinaki Chakraborty School of Computer and Systems Sciences, Jawaharlal Nehru University, New Delhi – 110067, India. E-mail: [email protected] Abstract Operating systems constitute a class of vital software. A plethora of operating systems, of different types and developed by different manufacturers over the years, are available now. This paper concentrates on research purpose operating systems because many of them have high technological significance and they have been vividly documented in the research literature. Thirty-four academic and research purpose operating systems have been briefly reviewed in this paper. It was observed that the microkernel based architecture is being used widely to design research purpose operating systems. It was also noticed that object oriented operating systems are emerging as a promising option. Hence, the paper concludes by suggesting a study of the scope of microkernel based object oriented operating systems. Keywords: Operating system, research purpose operating system, object oriented operating system, microkernel 1. Introduction An operating system is a software that manages all the resources of a computer, both hardware and software, and provides an environment in which a user can execute programs in a convenient and efficient manner [1]. However, the principles and concepts used in the operating systems were not standardized in a day. In fact, operating systems have been evolving through the years [2]. There were no operating systems in the early computers. In those systems, every program required full hardware specification to execute correctly and perform each trivial task, and its own drivers for peripheral devices like card readers and line printers.
    [Show full text]
  • Mixed-Criticality Scheduling and Resource Sharing for High-Assurance Operating Systems
    Mixed-Criticality Scheduling and Resource Sharing for High-Assurance Operating Systems Anna Lyons Submitted in fulfilment of the requirements for the degree of Doctor of Philosophy School of Computer Science and Engineering University of New South Wales Sydney, Australia September 2018 Abstract Criticality of a software system refers to the severity of the impact of a failure. In a high-criticality system, failure risks significant loss of life or damage to the environ- ment. In a low-criticality system, failure may risk a downgrade in user-experience. As criticality of a software system increases, so too does the cost and time to develop that software: raising the criticality also raises the assurance level, with the highest levels requiring extensive, expensive, independent certification. For modern cyber-physical systems, including autonomous aircraft and other vehicles, the traditional approach of isolating systems of different criticality by using completely separate physical hardware, is no longer practical, being both restrictive and inefficient. The result is mixed-criticality systems, where software applications with different criticalities execute on the same hardware. Sufficient mechanisms are required to ascertain that software in mixed-criticality systems is sufficiently isolated, otherwise, all software on that hardware is promoted to the highest criticality level, driving up costs to impractical levels. For mixed-criticality systems to be viable, both spatial and temporal isolation are required. Current aviation standards allow for mixed-criticality systems where temporal and spatial resources are strictly and statically partitioned in time and space, allowing some improvement over fully isolated hardware. However, further improvements are not only possible, but required for future innovation in cyber-physical systems.
    [Show full text]
  • The Nizza Secure-System Architecture
    Appears in the proceedings of CollaborateCom 2005, San Jose, CA, USA The Nizza Secure-System Architecture Hermann Härtig Michael Hohmuth Norman Feske Christian Helmuth Adam Lackorzynski Frank Mehnert Michael Peter Technische Universität Dresden Institute for System Architecture D-01062 Dresden, Germany [email protected] Abstract rely on a standard OS (including the kernel) to assure their security properties. The trusted computing bases (TCBs) of applications run- To address the conflicting requirements of complete ning on today’s commodity operating systems have become functionality and the protection of security-sensitive data, extremely large. This paper presents an architecture that researchers have devised system architectures that reduce allows to build applications with a much smaller TCB. It the system’s TCB by running kernels in untrusted mode is based on a kernelized architecture and on the reuse of in a secure compartment on top of a small security kernel; legacy software using trusted wrappers. We discuss the de- security-sensitive services run alongside the OS in isolated sign principles, the architecture and some components, and compartments of their own. This architecture is widely re- a number of usage examples. ferred to as kernelized standard OS or kernelized system. In this paper, we describe Nizza, a new kernelized- system architecture. In the design of Nizza, we set out to answer the question of how small the TCB can be made. 1 Introduction We have argued in previous work that the (hardware and software) technologies needed to build small secure-system Desktop and hand-held computers are used for many platforms have become much more mature since earlier at- functions, often in parallel, some of which are security tempts [8].
    [Show full text]
  • Tahoe-LAFS Documentation Release 1.X
    Tahoe-LAFS Documentation Release 1.x The Tahoe-LAFS Developers January 19, 2017 Contents 1 Welcome to Tahoe-LAFS! 3 1.1 What is Tahoe-LAFS?..........................................3 1.2 What is “provider-independent security”?................................3 1.3 Access Control..............................................4 1.4 Get Started................................................4 1.5 License..................................................4 2 Installing Tahoe-LAFS 5 2.1 First: In Case Of Trouble.........................................5 2.2 Pre-Packaged Versions..........................................5 2.3 Preliminaries...............................................5 2.4 Install the Latest Tahoe-LAFS Release.................................6 2.5 Running the tahoe executable.....................................8 2.6 Running the Self-Tests..........................................8 2.7 Common Problems............................................9 2.8 Using Tahoe-LAFS............................................9 3 How To Run Tahoe-LAFS 11 3.1 Introduction............................................... 11 3.2 Do Stuff With It............................................. 12 3.3 Socialize................................................. 13 3.4 Complain................................................. 13 4 Configuring a Tahoe-LAFS node 15 4.1 Node Types................................................ 16 4.2 Overall Node Configuration....................................... 16 4.3 Connection Management........................................
    [Show full text]
  • Operating System Verification—An Overview
    Sadhan¯ a¯ Vol. 34, Part 1, February 2009, pp. 27–69. © Printed in India Operating system verification—An overview GERWIN KLEIN Sydney Research Laboratory, NICTA,∗ Australia, School of Computer Science and Engineering, University of New South Wales, Sydney, Australia e-mail: [email protected] Abstract. This paper gives a high-level introduction to the topic of formal, interactive, machine-checked software verification in general, and the verification of operating systems code in particular. We survey the state of the art, the advantages and limitations of machine-checked code proofs, and describe two specific ongoing larger-scale verification projects in more detail. Keywords. Formal software verification; operating systems; theorem proving. 1. Introduction The fastest, cheapest and easiest way to build something is properly the first time (Parker 2007). This engineer’s credo has made it into popular literature, but it seems to be largely ignored in the world of software development. In the late 1960s a software crisis was diagnosed on a summit in the Bavarian Alps (Naur & Randell 1969): Software was getting more and more complex, and we had no structured way of building it. We ended up with projects that took significantly longer than planned, were more expensive than planned, delivered results that did not fully address customer needs, or at worst were useless. This summit in the late 1960s is widely seen as the birth of the discipline of software engineering. Now, almost 40 years later, we have come a long way. There are numerous books on software engineering, a plenitude of methodologies, programming languages, and processes to choose from.
    [Show full text]
  • Comparative Studies of 10 Programming Languages Within 10 Diverse Criteria Revision 1.0
    Comparative Studies of 10 Programming Languages within 10 Diverse Criteria Revision 1.0 Rana Naim∗ Mohammad Fahim Nizam† Concordia University Montreal, Concordia University Montreal, Quebec, Canada Quebec, Canada [email protected] [email protected] Sheetal Hanamasagar‡ Jalal Noureddine§ Concordia University Montreal, Concordia University Montreal, Quebec, Canada Quebec, Canada [email protected] [email protected] Marinela Miladinova¶ Concordia University Montreal, Quebec, Canada [email protected] Abstract This is a survey on the programming languages: C++, JavaScript, AspectJ, C#, Haskell, Java, PHP, Scala, Scheme, and BPEL. Our survey work involves a comparative study of these ten programming languages with respect to the following criteria: secure programming practices, web application development, web service composition, OOP-based abstractions, reflection, aspect orientation, functional programming, declarative programming, batch scripting, and UI prototyping. We study these languages in the context of the above mentioned criteria and the level of support they provide for each one of them. Keywords: programming languages, programming paradigms, language features, language design and implementation 1 Introduction Choosing the best language that would satisfy all requirements for the given problem domain can be a difficult task. Some languages are better suited for specific applications than others. In order to select the proper one for the specific problem domain, one has to know what features it provides to support the requirements. Different languages support different paradigms, provide different abstractions, and have different levels of expressive power. Some are better suited to express algorithms and others are targeting the non-technical users. The question is then what is the best tool for a particular problem.
    [Show full text]
  • Scalability of Microkernel-Based Systems
    Scalability of Microkernel-Based Systems Zur Erlangung des akademischen Grades eines DOKTORS DER INGENIERWISSENSCHAFTEN von der Fakultat¨ fur¨ Informatik der Universitat¨ Fridericiana zu Karlsruhe (TH) genehmigte DISSERTATION von Volkmar Uhlig aus Dresden Tag der mundlichen¨ Prufung:¨ 30.05.2005 Hauptreferent: Prof. Dr. rer. nat. Gerhard Goos Universitat¨ Fridericiana zu Karlsruhe (TH) Korreferent: Prof. Dr. sc. tech. (ETH) Gernot Heiser University of New South Wales, Sydney, Australia Karlsruhe: 15.06.2005 i Abstract Microkernel-based systems divide the operating system functionality into individ- ual and isolated components. The system components are subject to application- class protection and isolation. This structuring method has a number of benefits, such as fault isolation between system components, safe extensibility, co-existence of different policies, and isolation between mutually distrusting components. How- ever, such strict isolation limits the information flow between subsystems including information that is essential for performance and scalability in multiprocessor sys- tems. Semantically richer kernel abstractions scale at the cost of generality and mini- mality–two desired properties of a microkernel. I propose an architecture that al- lows for dynamic adjustment of scalability-relevant parameters in a general, flex- ible, and safe manner. I introduce isolation boundaries for microkernel resources and the system processors. The boundaries are controlled at user-level. Operating system components and applications can transform their semantic information into three basic parameters relevant for scalability: the involved processors (depending on their relation and interconnect), degree of concurrency, and groups of resources. I developed a set of mechanisms that allow a kernel to: 1. efficiently track processors on a per-resource basis with support for very large number of processors, 2.
    [Show full text]
  • Introduction Course Outline Why Does This Fail? Lectures Tutorials
    Course Outline • Prerequisites – COMP2011 Data Organisation • Stacks, queues, hash tables, lists, trees, heaps,…. Introduction – COMP2021 Digital Systems Structure • Assembly programming • Mapping of high-level procedural language to assembly COMP3231/9201/3891/9283 language – or the postgraduate equivalent (Extended) Operating Systems – You are expected to be competent Kevin Elphinstone programmers!!!! • We will be using the C programming language – The dominant language for OS implementation. – Need to understand pointers, pointer arithmetic, explicit 2 memory allocation. Why does this fail? Lectures • Common for all courses (3231/3891/9201/9283) void func(int *x, int *y) • Wednesday, 2-4pm { • Thursday, 5-6pm *x = 1; *y = 2; – All lectures are here (EE LG03) – The lecture notes will be available on the course web site } • Available prior to lectures, when possible. void main() – The lecture notes and textbook are NOT a substitute for { attending lectures. int *a, *b; func(a,b); } 3 4 Tutorials Assignments • Assignments form a substantial component of • Start in week 2 your assessment. • A tutorial participation mark will • They are challenging!!!! – Because operating systems are challenging contribute to your final assessment. • We will be using OS/161, – Participation means participation, NOT – an educational operating system attendance. – developed by the Systems Group At Harvard – Comp9201/3891/9283 students excluded – It contains roughly 20,000 lines of code and comments • You will only get participation marks in your enrolled tutorial. 5 6 1 Assignments Assignments • Assignments are in pairs • Don’t under estimate the time needed to do the – Info on how to pair up available soon assignments. • We usually offer advanced versions of the – ProfQuotes: [About the midterm] "We can't keep you working assignments on it all night, it's not OS.“ Ragde, CS341 – Available bonus marks are small compared to amount of • If you start a couple days before they are due, you will be late.
    [Show full text]
  • A Look at the EROS Operating System Jonathan S
    A Look at the EROS Operating System Jonathan S. Shapiro Johns Hopkins University Abstract EROS is a capability-based, secure operating system originally designed to address the needs of shared computing utilities involving mutually suspicious users. The deploy­ ment plan for the original design was to provide leased compute service to competing business entities, potentially running on a single machine. As a result, the system was structured to preserve security in the face of both hostile dynamic content and hostile users. While the EROS platform can support the efficient deployment of multilevel se­ cure environments, it is primarily focused on business security requirements. These re­ quirements often address integrity as well as security concerns. An EROS-based deploy­ ment can ensure that business-critical data is manipulated exclusively by authorized ap­ plication software, which in turn is guarded against user tampering. Simultaneously, EROS enables users to run untrusted utility software, hand private or proprietary data to that software, and be assured (within reason) that the data cannot be disclosed to the out­ side world. This paper gives a general overview of the EROS system and what it can do. The EROS research project has now ended. Further work based on the EROS system is being pursued under the CapROS project (www.capros.org). The EROS team has moved on to a successor system: Coyotos (www.coyotos.org). 1 Introduction in other publications. Others result from chains of reasoning that are omitted for reasons of space. A This paper accompanies a talk for the 2005 Libre few are opinions derived from years of in-depth Software Meeting in Dijon, France.
    [Show full text]