DOCSLIB.ORG

A Functional Approach to Memory-Safe Operating Systems

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Functional Approach to Memory-Safe Operating Systems Portland State University PDXScholar Dissertations and Theses Dissertations and Theses 1-1-2011 A Functional Approach to Memory-Safe Operating Systems Rebekah Leslie Portland State University Follow this and additional works at: https://pdxscholar.library.pdx.edu/open_access_etds Let us know how access to this document benefits ou.y Recommended Citation Leslie, Rebekah, "A Functional Approach to Memory-Safe Operating Systems" (2011). Dissertations and Theses. Paper 499. https://doi.org/10.15760/etd.499 This Dissertation is brought to you for free and open access. It has been accepted for inclusion in Dissertations and Theses by an authorized administrator of PDXScholar. Please contact us if we can make this document more accessible: [email protected]. A Functional Approach to Memory-Safe Operating Systems by Rebekah Leslie A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Computer Science Dissertation Committee: Mark P. Jones, Chair James Hook Andrew Tolmach Jonathan Walpole Gernot Heiser Jeanette R. Palmiter Portland State University c 2011 i ABSTRACT Purely functional languages|with static type systems and dynamic memory man- agement using garbage collection|are a known tool for helping programmers to reduce the number of memory errors in programs. By using such languages, we can establish correctness properties relating to memory-safety through our choice of implementation language alone. Unfortunately, the language characteristics that make purely functional languages safe also make them more difficult to apply in a low-level domain like operating systems construction. The low-level features that support the kinds of hardware manipulations required by operating systems are not typically available in memory-safe languages with garbage collection. Those that are provided may have the ability to violate memory- and type-safety, destroying the guarantees that motivate using such languages in the first place. This work demonstrates that it is possible to bridge the gap between the require- ments of operating system implementations and the features of purely functional languages without sacrificing type- and memory-safety. In particular, we show that this can be achieved by isolating the potentially unsafe memory operations required by operating systems in an abstraction layer that is well integrated with a purely functional language. The salient features of this abstraction layer are that the operations it exposes are memory-safe and yet sufficiently expressive to support the implementation of realistic operating systems. The abstraction layer enables systems programmers to perform all of the low-level tasks necessary in an OS implementation, such as manipulating an MMU and executing user-level ii programs, without compromising the static memory-safety guarantees of program- ming in a purely functional language. A specific contribution of this work is an analysis of memory-safety for the abstraction layer by formalizing a meaning for memory-safety in the presence of virtual-memory using a novel application of non- interference security policies. In addition, we evaluate the expressiveness of the abstraction layer by implementing the L4 microkernel API, which has a flexible set of virtual memory management operations. iii DEDICATION For Joe Hurd, who inspires me every day and without whose loving support this work would not have been possible. iv ACKNOWLEDGMENTS This research could not have been accomplished without the help of countless others. First and foremost, I would like to thank my advisor, Mark Jones, for his unwavering support throughout my graduate school career. In my early days as a student his courses inspired and challenged me, and our initial projects together set the direction for my research career. In the years that followed, Mark has made every effort to be involved with my work and to help me succeed. This work has benefited immensely from his contributions, in both research content and in presentation. The members of the Hasp and Programatica research projects have always provided an intellectually stimulating and friendly climate in which to conduct research. Andrew Tolmach made significant contributions to the design of the ab- straction layer presented here, including the memory-safety analysis, and directly influenced its implementation through his work on the House operating system and the original H interface. James Hook has also been extremely supportive, encouraging me to see the bigger picture and the broader connections of my work. My fellow students have provided me with many valuable discussions and pointers over the years. I am particularly grateful to Iavor Diatchki and Emir Pa˘sali´c,who befriended me in those early days when graduate school was a frightening and overwhelming place. I am also very grateful to Tim Chevalier and John Ochsner for proofreading this document. I owe a great debt to my colleagues upon whose work my abstraction layer v is based, as well as the maintainers of the bare metal Haskell compiler. Thomas Hallgren made significant contributions to the House operating system and the first version of the H interface, and has always been available to answer questions and to help with debugging. Kenneth Graunke created the version of the Haskell run- time system that my implementation relies on, leveraging the work of Adam Wick. In addition to his technical contributions, Adam has been an excellent resource throughout the process of writing my dissertation, providing a rare example of person in the local functional programming community doing primarily low-level systems work. Don Stewart taught me about compiler pragmas in GHC and helped me to optimize my L4 implementation. I would also like to thank Rex Page at the University of Oklahoma. He gave me my first start in research and functional programming as an undergraduate and without his guidance I would not be where I am today. Finally, I would like to thank Joe Hurd. There are not words to express how valuable his love and support have been in enabling me to complete this process. Moreover, the quality of this work has benefited immeasurably from our countless discussions and from his proofreading efforts. vi CONTENTS Abstract ::::::::::::::::::::::::::::::::::::: i Dedication :::::::::::::::::::::::::::::::::::: iii Acknowledgments ::::::::::::::::::::::::::::::: iv List of Tables :::::::::::::::::::::::::::::::::: xi List of Figures ::::::::::::::::::::::::::::::::: xiv 1 Introduction ::::::::::::::::::::::::::::::::: 1 1.1 Correctness in Operating Systems . .3 1.2 Purely Functional Languages for Memory-Safety . .5 1.3 Example: Low-level Programming in Haskell . .7 1.4 Assurance Through A Small Trusted Computing Base . .7 1.5 This Work . .9 2 Background: Core Concepts of Intel IA32 Processors ::::::: 11 2.1 Execution Environment . 12 2.1.1 Registers . 12 2.1.2 Modes of Execution . 14 2.1.3 Faults and Interrupts . 15 2.1.4 Input/Output . 17 2.2 Virtual-Memory Management . 18 2.2.1 Address Translation Structures . 18 2.2.2 Protection . 21 2.2.3 Translation Table Formats . 23 2.2.4 Example: Adding a Virtual-To-Physical Mapping . 25 vii 3 Background: Fundamentals of Haskell Programming ::::::: 27 3.1 Datatypes . 29 3.2 Parameterized Datatypes . 33 3.3 Type Classes and Qualified Types . 36 3.4 Monads . 39 3.5 Modules . 46 4 A Memory-Safe Abstraction Layer for Operating System Con- struction in Haskell :::::::::::::::::::::::::::: 49 4.1 Characterizing Memory . 53 4.2 Example: Adding a Memory Mapping in H . 56 4.3 System Configuration . 60 4.3.1 Physical Memory Configuration . 60 4.3.2 User-Code Modules . 66 4.4 Virtual-Memory Management . 67 4.4.1 Address Spaces . 68 4.4.2 User Memory . 71 4.4.3 Kernel Memory . 74 4.5 User Process Execution . 77 4.6 Input/Output . 80 4.6.1 Ports . 80 4.6.2 Debugging . 81 5 Formalizing Operating System Memory-Safety as a Noninterfer- ence Property :::::::::::::::::::::::::::::::: 82 5.1 Background: Rushby's Noninterference Framework . 86 5.1.1 System Model . 86 5.1.2 Characterizing Domain Interactions . 88 5.1.3 Establishing Security . 91 5.2 Notation . 92 5.3 Machine Model . 94 5.3.1 Virtual and Physical Memory . 95 5.3.2 Memory Regions . 100 5.3.3 Machine State . 102 5.4 Protection Domains . 106 5.4.1 Domain Actions . 108 viii 5.5 Policy . 117 5.5.1 Modeling Approach . 118 5.5.2 Interference Between Domains . 122 5.6 Well-Formedness . 126 5.6.1 CR3 and Reference Page-Directory Are Page-Directories . 127 5.6.2 Reference Page-Directory Maps Kernel-Space Addresses . 127 5.6.3 Reference Page-Directory Maps Every Environment Page . 128 5.6.4 All Page-Directories Contain Reference Mappings . 129 5.6.5 Environment Pages Are Only Mapped to Addresses That Are Mapped in the Reference Page-Directory . 130 5.6.6 Mapped Pages Are Available . 131 5.6.7 Page-Table Pointers Are Page-Tables . 131 5.6.8 Regions Are Consistent and Disjoint From Environment . 132 5.6.9 Putting It All Together . 133 5.7 Connecting the Model and Implementation . 134 5.7.1 Specification of WriteE . 136 5.7.2 Specification of DeriveRegionH . 137 5.7.3 Specification of AllocatePageDirectoryH . 138 5.7.4 Specification of FreePageDirectoryH . 139 5.7.5 Specification of AddMappingH . 140 5.7.6 Specification of RemoveMappingH . 144 5.7.7 Specification of AddKernelMappingH . 146 5.7.8 Specification of ExecuteH . 147 5.7.9 Specification of WriteK . 148 5.7.10 Specification of WriteU . 149 5.8 Verifying Memory-Safety . 150 5.8.1 Completing the Rushby Instantiation . 150 5.8.2 Properties of the H Specification and System Model . 152 5.8.3 Proving the Unwinding Conditions . 156 5.8.4 Model Validation . 165 5.9 Summary . 167 6 Implementing the Abstraction Layer ::::::::::::::::: 169 6.1 Safely Encapsulating the Abstraction Layer Operations . 169 6.2 Type Classes for Fine-Grained Effect Tracking . 172 6.3 Booting . 176 ix 6.4 Precise Kernel Control Over Page-Map Memory .
Load more

Recommended publications
  • Automatic Sandboxing of Unsafe Software Components in High Level Languages
    Master Thesis Automatic Sandboxing of Unsafe Software Components in High Level Languages Benjamin Lamowski Technische Universität Dresden Fakultät Informatik Institut für Systemarchitektur Professur Betriebssysteme Betreuender Hochschullehrer: Prof. Dr. rer. nat. Hermann Härtig Betreuender Mitarbeiter: Dr. Carsten Weinhold 3. Mai 2017 Aufgabenstellung Neue “sichere“ Programmiersprachen wie Go, Swift oder Rust wurden nicht nur für die normale Anwendungsentwicklung entworfen, sondern sie zielen auch auf eine hochper- formante Ausführung und Programmierung vergleichsweise systemnaher Funktionalität ab. Eine attraktive Eigenschaft beispielsweise von Rust ist das gegenüber C und C++ deutlich strengere Speicherverwaltungsmodell, bei dem bereits zur Kompilierzeit der Lebenszyklus und die Erreichbarkeit von Objekten sowie die Zuständigkeit für deren Allokation und Deallokation wohldefiniert sind. Ganze Klassen von Programmfehlern wie etwa Buffer Overflows oder Dereferenzierung ungültige Zeiger werden dadurch eliminiert und die Programme mithin sicherer und robuster. Aus diversen Gründen müssen Programme, die in sicheren Sprachen geschriebenen wurden, aber oftmals auf “unsicheren“ Legacy-Code zurückgreifen. So bietet etwa Rust über das “unsafe“-Sprachelement die Möglichkeit, Funktionen innerhalb von Bibliotheken aufzurufen, die in fehleranfälligem C geschrieben sind. Leider werden die vom Com- piler durchgesetzten Garantien der sicheren Sprache hinfällig, sobald im Code einer C-Bibliothek ein Speicherfehler auftritt. Ein Schreibzugriff etwa durch
    [Show full text]
  • A Microkernel API for Fine-Grained Decomposition
    A Microkernel API for Fine-Grained Decomposition Sebastian Reichelt Jan Stoess Frank Bellosa System Architecture Group, University of Karlsruhe, Germany freichelt,stoess,[email protected] ABSTRACT from the microkernel APIs in existence. The need, for in- Microkernel-based operating systems typically require spe- stance, to explicitly pass messages between servers, or the cial attention to issues that otherwise arise only in dis- need to set up threads and address spaces in every server for tributed systems. The resulting extra code degrades per- parallelism or protection require OS developers to adopt the formance and increases development effort, severely limiting mindset of a distributed-system programmer rather than to decomposition granularity. take advantage of their knowledge on traditional OS design. We present a new microkernel design that enables OS devel- Distributed-system paradigms, though well-understood and opers to decompose systems into very fine-grained servers. suited for physically (and, thus, coarsely) partitioned sys- We avoid the typical obstacles by defining servers as light- tems, present obstacles to the fine-grained decomposition weight, passive objects. We replace complex IPC mecha- required to exploit the benefits of microkernels: First, a nisms by a simple function-call approach, and our passive, lot of development effort must be spent into matching the module-like server model obviates the need to create threads OS structure to the architecture of the selected microkernel, in every server. Server code is compiled into small self- which also hinders porting existing code from monolithic sys- contained files, which can be loaded into the same address tems. Second, the more servers exist | a desired property space (for speed) or different address spaces (for safety).
    [Show full text]
  • A Practical UNIX Capability System
    A Practical UNIX Capability System Adam Langley <[email protected]> 22nd June 2005 ii Abstract This report seeks to document the development of a capability security system based on a Linux kernel and to follow through the implications of such a system. After defining terms, several other capability systems are discussed and found to be excellent, but to have too high a barrier to entry. This motivates the development of the above system. The capability system decomposes traditionally monolithic applications into a number of communicating actors, each of which is a separate process. Actors may only communicate using the capabilities given to them and so the impact of a vulnerability in a given actor can be reasoned about. This design pattern is demonstrated to be advantageous in terms of security, comprehensibility and mod- ularity and with an acceptable performance penality. From this, following through a few of the further avenues which present themselves is the two hours traffic of our stage. Acknowledgments I would like to thank my supervisor, Dr Kelly, for all the time he has put into cajoling and persuading me that the rest of the world might have a trick or two worth learning. Also, I’d like to thank Bryce Wilcox-O’Hearn for introducing me to capabilities many years ago. Contents 1 Introduction 1 2 Terms 3 2.1 POSIX ‘Capabilities’ . 3 2.2 Password Capabilities . 4 3 Motivations 7 3.1 Ambient Authority . 7 3.2 Confused Deputy . 8 3.3 Pervasive Testing . 8 3.4 Clear Auditing of Vulnerabilities . 9 3.5 Easy Configurability .
    [Show full text]
  • UG1046 Ultrafast Embedded Design Methodology Guide
    UltraFast Embedded Design Methodology Guide UG1046 (v2.3) April 20, 2018 Revision History The following table shows the revision history for this document. Date Version Revision 04/20/2018 2.3 • Added a note in the Overview section of Chapter 5. • Replaced BFM terminology with VIP across the user guide. 07/27/2017 2.2 • Vivado IDE updates and minor editorial changes. 04/22/2015 2.1 • Added Embedded Design Methodology Checklist. • Added Accessing Documentation and Training. 03/26/2015 2.0 • Added SDSoC Environment. • Added Related Design Hubs. 10/20/2014 1.1 • Removed outdated information. •In System Level Considerations, added information to the following sections: ° Performance ° Clocking and Reset 10/08/2014 1.0 Initial Release of document. UltraFast Embedded Design Methodology Guide Send Feedback 2 UG1046 (v2.3) April 20, 2018 www.xilinx.com Table of Contents Chapter 1: Introduction Embedded Design Methodology Checklist. 9 Accessing Documentation and Training . 10 Chapter 2: System Level Considerations Performance. 13 Power Consumption . 18 Clocking and Reset. 36 Interrupts . 41 Embedded Device Security . 45 Profiling and Partitioning . 51 Chapter 3: Hardware Design Considerations Configuration and Boot Devices . 63 Memory Interfaces . 69 Peripherals . 76 Designing IP Blocks . 94 Hardware Performance Considerations . 102 Dataflow . 108 PL Clocking Methodology . 112 ACP and Cache Coherency. 116 PL High-Performance Port Access. 120 System Management Hardware Assistance. 124 Managing Hardware Reconfiguration . 127 GPs and Direct PL Access from APU . 133 Chapter 4: Software Design Considerations Processor Configuration . 137 OS and RTOS Choices . 142 Libraries and Middleware . 152 Boot Loaders . 156 Software Development Tools . 162 UltraFast Embedded Design Methodology GuideSend Feedback 3 UG1046 (v2.3) April 20, 2018 www.xilinx.com Chapter 5: Hardware Design Flow Overview .
    [Show full text]
  • An In-Depth Study with All Rust Cves
    Memory-Safety Challenge Considered Solved? An In-Depth Study with All Rust CVEs HUI XU, School of Computer Science, Fudan University ZHUANGBIN CHEN, Dept. of CSE, The Chinese University of Hong Kong MINGSHEN SUN, Baidu Security YANGFAN ZHOU, School of Computer Science, Fudan University MICHAEL R. LYU, Dept. of CSE, The Chinese University of Hong Kong Rust is an emerging programing language that aims at preventing memory-safety bugs without sacrificing much efficiency. The claimed property is very attractive to developers, and many projects start usingthe language. However, can Rust achieve the memory-safety promise? This paper studies the question by surveying 186 real-world bug reports collected from several origins which contain all existing Rust CVEs (common vulnerability and exposures) of memory-safety issues by 2020-12-31. We manually analyze each bug and extract their culprit patterns. Our analysis result shows that Rust can keep its promise that all memory-safety bugs require unsafe code, and many memory-safety bugs in our dataset are mild soundness issues that only leave a possibility to write memory-safety bugs without unsafe code. Furthermore, we summarize three typical categories of memory-safety bugs, including automatic memory reclaim, unsound function, and unsound generic or trait. While automatic memory claim bugs are related to the side effect of Rust newly-adopted ownership-based resource management scheme, unsound function reveals the essential challenge of Rust development for avoiding unsound code, and unsound generic or trait intensifies the risk of introducing unsoundness. Based on these findings, we propose two promising directions towards improving the security of Rust development, including several best practices of using specific APIs and methods to detect particular bugs involving unsafe code.
    [Show full text]
  • Project Snowflake: Non-Blocking Safe Manual Memory Management in .NET
    Project Snowflake: Non-blocking Safe Manual Memory Management in .NET Matthew Parkinson Dimitrios Vytiniotis Kapil Vaswani Manuel Costa Pantazis Deligiannis Microsoft Research Dylan McDermott Aaron Blankstein Jonathan Balkind University of Cambridge Princeton University July 26, 2017 Abstract Garbage collection greatly improves programmer productivity and ensures memory safety. Manual memory management on the other hand often delivers better performance but is typically unsafe and can lead to system crashes or security vulnerabilities. We propose integrating safe manual memory management with garbage collection in the .NET runtime to get the best of both worlds. In our design, programmers can choose between allocating objects in the garbage collected heap or the manual heap. All existing applications run unmodified, and without any performance degradation, using the garbage collected heap. Our programming model for manual memory management is flexible: although objects in the manual heap can have a single owning pointer, we allow deallocation at any program point and concurrent sharing of these objects amongst all the threads in the program. Experimental results from our .NET CoreCLR implementation on real-world applications show substantial performance gains especially in multithreaded scenarios: up to 3x savings in peak working sets and 2x improvements in runtime. 1 Introduction The importance of garbage collection (GC) in modern software cannot be overstated. GC greatly improves programmer productivity because it frees programmers from the burden of thinking about object lifetimes and freeing memory. Even more importantly, GC prevents temporal memory safety errors, i.e., uses of memory after it has been freed, which often lead to security breaches. Modern generational collectors, such as the .NET GC, deliver great throughput through a combination of fast thread-local bump allocation and cheap collection of young objects [63, 18, 61].
    [Show full text]
  • Ensuring the Spatial and Temporal Memory Safety of C at Runtime
    MemSafe: Ensuring the Spatial and Temporal Memory Safety of C at Runtime Matthew S. Simpson, Rajeev K. Barua Department of Electrical & Computer Engineering University of Maryland, College Park College Park, MD 20742-3256, USA fsimpsom, [email protected] Abstract—Memory access violations are a leading source of dereferencing pointers obtained from invalid pointer arith- unreliability in C programs. As evidence of this problem, a vari- metic; and dereferencing uninitialized, NULL or “manufac- ety of methods exist that retrofit C with software checks to detect tured” pointers.1 A temporal error is a violation caused by memory errors at runtime. However, these methods generally suffer from one or more drawbacks including the inability to using a pointer whose referent has been deallocated (e.g. with detect all errors, the use of incompatible metadata, the need for free) and is no longer a valid object. The most well-known manual code modifications, and high runtime overheads. temporal violations include dereferencing “dangling” point- In this paper, we present a compiler analysis and transforma- ers to dynamically allocated memory and freeing a pointer tion for ensuring the memory safety of C called MemSafe. Mem- more than once. Dereferencing pointers to automatically allo- Safe makes several novel contributions that improve upon previ- ous work and lower the cost of safety. These include (1) a method cated memory (stack variables) is also a concern if the address for modeling temporal errors as spatial errors, (2) a compati- of the referent “escapes” and is made available outside the ble metadata representation combining features of object- and function in which it was defined.
    [Show full text]
  • Quantifying Security Impact of Operating-System Design
    Copyright Notice School of Computer Science & Engineering COMP9242 Advanced Operating Systems These slides are distributed under the Creative Commons Attribution 3.0 License • You are free: • to share—to copy, distribute and transmit the work • to remix—to adapt the work • under the following conditions: 2019 T2 Week 09b • Attribution: You must attribute the work (but not in any way that Local OS Research suggests that the author endorses you or your use of the work) as @GernotHeiser follows: “Courtesy of Gernot Heiser, UNSW Sydney” The complete license text can be found at http://creativecommons.org/licenses/by/3.0/legalcode 1 COMP9242 2019T2 W09b: Local OS Research © Gernot Heiser 2019 – CC Attribution License Quantifying OS-Design Security Impact Approach: • Examine all critical Linux CVEs (vulnerabilities & exploits database) • easy to exploit 115 critical • high impact Linux CVEs Quantifying Security Impact of • no defence available to Nov’17 • confirmed Operating-System Design • For each establish how microkernel-based design would change impact 2 COMP9242 2019T2 W09b: Local OS Research © Gernot Heiser 2019 – CC Attribution License 3 COMP9242 2019T2 W09b: Local OS Research © Gernot Heiser 2019 – CC Attribution License Hypothetical seL4-based OS Hypothetical Security-Critical App Functionality OS structured in isolated components, minimal comparable Trusted inter-component dependencies, least privilege to Linux Application computing App requires: base • IP networking Operating system Operating system • File storage xyz xyz • Display
    [Show full text]
  • The OKL4 Microvisor: Convergence Point of Microkernels and Hypervisors
    The OKL4 Microvisor: Convergence Point of Microkernels and Hypervisors Gernot Heiser, Ben Leslie Open Kernel Labs and NICTA and UNSW Sydney, Australia ok-labs.com ©2010 Open Kernel Labs and NICTA. All rights reserved. Microkernels vs Hypervisors > Hypervisors = “microkernels done right?” [Hand et al, HotOS ‘05] • Talks about “liability inversion”, “IPC irrelevance” … > What’s the difference anyway? ok-labs.com ©2010 Open Kernel Labs and NICTA. All rights reserved. 2 What are Hypervisors? > Hypervisor = “virtual machine monitor” • Designed to multiplex multiple virtual machines on single physical machine VM1 VM2 Apps Apps AppsApps AppsApps OS OS Hypervisor > Invented in ‘60s to time-share with single-user OSes > Re-discovered in ‘00s to work around broken OS resource management ok-labs.com ©2010 Open Kernel Labs and NICTA. All rights reserved. 3 What are Microkernels? > Designed to minimise kernel code • Remove policy, services, retain mechanisms • Run OS services in user-mode • Software-engineering and dependability reasons • L4: ≈ 10 kLOC, Xen ≈ 100 kLOC, Linux: ≈ 10,000 kLOC ServersServers ServersServers Apps Servers Device AppsApps Drivers Microkernel > IPC performance critical (highly optimised) • Achieved by API simplicity, cache-friendly implementation > Invented 1970 [Brinch Hansen], popularised late ‘80s (Mach, Chorus) ok-labs.com ©2010 Open Kernel Labs and NICTA. All rights reserved. 4 What’s the Difference? > Both contain all code executing at highest privilege level • Although hypervisor may contain user-mode code as well > Both need to abstract hardware resources • Hypervisor: abstraction closely models hardware • Microkernel: abstraction designed to support wide range of systems > What must be abstracted? • Memory • CPU • I/O • Communication ok-labs.com ©2010 Open Kernel Labs and NICTA.
    [Show full text]
  • The Flask Security Architecture: System Support for Diverse Security Policies
    The Flask Security Architecture: System Support for Diverse Security Policies Ray Spencer Secure Computing Corporation Stephen Smalley, Peter Loscocco National Security Agency Mike Hibler, David Andersen, Jay Lepreau University of Utah http://www.cs.utah.edu/flux/flask/ Abstract and even many types of policies [1, 43, 48]. To be gen- erally acceptable, any computer security solution must Operating systems must be flexible in their support be flexible enough to support this wide range of security for security policies, providing sufficient mechanisms for policies. Even in the distributed environments of today, supporting the wide variety of real-world security poli- this policy flexibility must be supported by the security cies. Such flexibility requires controlling the propaga- mechanisms of the operating system [32]. tion of access rights, enforcing fine-grained access rights and supporting the revocation of previously granted ac- Supporting policy flexibility in the operating system is cess rights. Previous systems are lacking in at least one a hard problem that goes beyond just supporting multi- of these areas. In this paper we present an operating ple policies. The system must be capable of supporting system security architecture that solves these problems. fine-grained access controls on low-level objects used to Control over propagation is provided by ensuring that perform higher-level functions controlled by the secu- the security policy is consulted for every security deci- rity policy. Additionally, the system must ensure that sion. This control is achieved without significant perfor- the propagation of access rights is in accordance with mance degradation through the use of a security decision the security policy.
    [Show full text]
  • Extensible Distributed Operating System for Reliable Control Systems
    194 Extensible Distributed Operating System for Reliable Control Systems Katsumi Maruyama, Kazuya Kodama, Soichiro Hidaka, Hiromichi Hashizume National Institute of Informatics, 2-1-2 Hitotsubashi, Chiyoda-ku, Tokyo, Japan Email:{maruyama,kazuya,hidaka,has}@nii.ac.jp Abstract small monitor-like OSs are used. However, these monitor- like OSs lack program protection mechanisms, and program Since most control systems software is hardware-related, development is difficult. real-time-oriented and complex, adaptable OSs which help Therefore, an extensible/adaptable OS for control sys- program productivity and maintainability improvement are tems is required . We are developing a new OS character- in strong demand. ized by: We are developing an adaptable and extensible OS based on micro-kernel and multi-server scheme: each server runs • Use of an efficient and flexible micro-kernel (L4-ka). • Multi-server based modular OS. (Each OS service is in a protected mode interacting only via messages, and implemented as individual user-level process.) could be added/extended/deleted easily. Since this OS is • Robustness. Only the micro-kernel runs in kernel highly modularized, inter-process messaging overhead is a mode and in kernel space. Other modules run in a pro- concern. Our implementation proved good efficiency and tected user space and mode. maintainability. • Hardware driver programs in user-level process. • Flexible distributed processing by global message passing. 1. Introduction This OS structure proved to enhance OS modularity and ease of programming. However, inter-process messaging Most systems, from large scale public telephone switch- overhead should be considered . We measured the overhead, ing systems to home electronics, are controlled by software, and the overhead was proved to be small enough.
    [Show full text]
  • Microkernel Vs
    1 VIRTUALIZATION: IBM VM/370 AND XEN CS6410 Hakim Weatherspoon IBM VM/370 Robert Jay Creasy (1939-2005) Project leader of the first full virtualization hypervisor: IBM CP-40, a core component in the VM system The first VM system: VM/370 Virtual Machine: Origin 3 IBM CP/CMS CP-40 CP-67 VM/370 Why Virtualize 4 Underutilized machines Easier to debug and monitor OS Portability Isolation The cloud (e.g. Amazon EC2, Google Compute Engine, Microsoft Azure) IBM VM/370 Specialized Conversation Mainstream VM al Monitor OS (MVS, Another Virtual subsystem System DOS/VSE copy of VM machines (RSCS, RACF, (CMS) etc.) GCS) Hypervisor Control Program (CP) Hardware System/370 IBM VM/370 Technology: trap-and-emulate Problem Application Privileged Kernel Trap Emulate CP Classic Virtual Machine Monitor (VMM) 7 Virtualization: rejuvenation 1960’s: first track of virtualization Time and resource sharing on expensive mainframes IBM VM/370 Late 1970’s and early 1980’s: became unpopular Cheap hardware and multiprocessing OS Late 1990’s: became popular again Wide variety of OS and hardware configurations VMWare Since 2000: hot and important Cloud computing Docker containers Full Virtualization 9 Complete simulation of underlying hardware Unmodified guest OS Trap and simulate privileged instruction Was not supported by x86 (Not true anymore, Intel VT-x) Guest OS can’t see real resources Paravirtualization 10 Similar but not identical to hardware Modifications to guest OS Hypercall Guest OS registers handlers Improved performance VMware ESX Server 11 Full virtualization Dynamically rewrite privileged instructions Ballooning Content-based page sharing Denali 12 Paravirtualization 1000s of VMs Security & performance isolation Did not support mainstream OSes VM uses single-user single address space 13 Xen and the Art of Virtualization Xen 14 University of Cambridge, MS Research Cambridge XenSource, Inc.
    [Show full text]