DOCSLIB.ORG

What Have We Learnt in 20 Years of L4 Microkernels?

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
What Have We Learnt in 20 Years of L4 Microkernels? Lecture 6 From L3 to seL4: What Have We Learnt in 20 Years of L4 Microkernels? Kevin Elphinstone and Gernot Heiser Operating Systems Practical 12 November, 2014 OSP Lecture 6, L4 Microkernels 1/42 Contents Introduction and design principles Brief history of microkernels L4: Basic abstractions L4: Design and implementation choices Keywords Questions OSP Lecture 6, L4 Microkernels 2/42 Outline Introduction and design principles Brief history of microkernels L4: Basic abstractions L4: Design and implementation choices Keywords Questions OSP Lecture 6, L4 Microkernels 3/42 Context and terminology I Operating system I Kernel I Monolithic kernel I Microkernel OSP Lecture 6, L4 Microkernels 4/42 Operating system I abbrv. OS I Software (collection) to interface hardware with user I Components: I Kernel: Linux, FreeBSD, Windows NT, XNU, L4, ::: I Services/daemons: sysvinit, CUPS print server, udev, ::: I Utilities: ls, Windows Commander, top I Other applications OSP Lecture 6, L4 Microkernels 5/42 Kernel I Components directly interfacing with hardware I Examples? I \Core" of OS I No general definition of \core" OSP Lecture 6, L4 Microkernels 6/42 Monolithic vs. Micro-kernel Application Syscall User VFS "ode Uni File Server Device Server IPC, file system Application Driver Scheduler, virtual memory !ernel "ode Device drivers, dispatcher IPC, virtual memory IPC Hardware Hardware Source: http://www.cse.unsw.edu.au/ OSP Lecture 6, L4 Microkernels 7/42 Monolithic vs. Micro-kernel Monolithic kernel Microkernel I IPC, scheduling, I IPC, scheduling, memory management memory management I File systems I API closer to the I Drivers hardware I Higher-level API OSP Lecture 6, L4 Microkernels 8/42 Microkernel principles: minimality I If it's not critical, leave it out of the kernel I Pros: I Small code base I Easy to debug I Trusted Computing Base, feasible for formal verification I Cons: I Harder to find the \right" API design I Harder to optimize for high-performance OSP Lecture 6, L4 Microkernels 9/42 Microkernel principles: user-level services I Drivers, file systems, etc. as user space services I Pros: I Isolation ) limited attack surface I High availability, fault tolerance I Componentization, reusability I Cons: I Performance: IPC is a bottleneck OSP Lecture 6, L4 Microkernels 10/42 Microkernel principles: policy freedom I Kernel provides mechanisms, not policies I Policy definition is left up to the user space application I Pros: I Flexibility I Cons: I Hard to achieve, e.g. for scheduling I May lead to application bloat I Example: kernel provides user with memory, allocation algorithm depends on app I Example: cache maintenance is explicitly exposed to user space, to improve performance OSP Lecture 6, L4 Microkernels 11/42 Outline Introduction and design principles Brief history of microkernels L4: Basic abstractions L4: Design and implementation choices Keywords Questions OSP Lecture 6, L4 Microkernels 12/42 0th Generation (1970s) I Nucleus [Brinch Hansen '70] I Hydra [Wulf et al `74] I Issues I Lack of hardware support I Bad performance OSP Lecture 6, L4 Microkernels 13/42 1st Generation (1980s) I Mach I Chorus I Issues I Stripped-down monolithic kernels I Big I Bad performance: 100µs IPC OSP Lecture 6, L4 Microkernels 14/42 2nd Generation (1990s, early 2000s) I Minix I L3, L4 [Lietdke '95] I Performance-oriented I From scratch design I Architecture-dependent optimizations, e.g. reduced cache footprint I L3 was fully implemented in assembly I Issues I Security OSP Lecture 6, L4 Microkernels 15/42 L4 family tree Verifie CCC d L4%e./e*- seL4 Assember Caps #$L4%&$e'nel L4/ !P" #$L4% ic'o(iso' L4/Alpha Portable )o*eze'o Hazelnu L3→L4 “X” Pistachio t ,iasco ,iasco-#) 1 2/!3 /$a'ls'uhe 0o(a 40"5/0!)6A P4→ Pi+e#" 2'es*en 93 94 95 96 97 98 99 00 01 02 03 04 05 06 07 08 09 10 11 12 13 Source: http://www.cse.unsw.edu.au/ OSP Lecture 6, L4 Microkernels 16/42 L4 family tree Verifie C d L4%e./e*- seL4 Assember Asm+C Caps #$L4%&$e'nel L4/ !P" #$L4% ic'o(iso' L4/Alpha Portable )o*eze'o Hazelnu L3→L4 “X” Pistachio t ,iasco ,iasco-#) 1 2/!3 /$a'ls'uhe C++ 0o(a 40"5/0!)6A P4→ Pi+e#" 2'es*en 93 94 95 96 97 98 99 00 01 02 03 04 05 06 07 08 09 10 11 12 13 Source: http://www.cse.unsw.edu.au/ OSP Lecture 6, L4 Microkernels 17/42 3rd Generation (2007+) I OKL4 Microvisor [Heiser and Leslie '10] I Microkernel and hypervisor I Replaces some of the mechanisms with hypervisor mechanisms I Deployed in older Motorola phones OSP Lecture 6, L4 Microkernels 18/42 3rd Generation (2007+) I seL4 [Elphinstone et al '07, Klein et al '09] I Security-oriented I Capability-based access control I Strong isolation I Memory management policy fully exported to user space I Kernel objects are first class citizens I All memory is explicitly allocated I Formally verified [Klein et al '09] OSP Lecture 6, L4 Microkernels 19/42 Outline Introduction and design principles Brief history of microkernels L4: Basic abstractions L4: Design and implementation choices Keywords Questions OSP Lecture 6, L4 Microkernels 20/42 What mechanisms to abstract? I Bare minimum: I Processor I Memory I Interrupts/exceptions I Must replace memory isolation with communication protocols I Communication (IPC) I Synchronization OSP Lecture 6, L4 Microkernels 21/42 Hypervisor vs. microkernel Resource Hypervisor Microkernel Memory Virtual MMU (vMMU) Address space CPU Virtual CPU (vCPU) Thread or scheduler activation Interrupt Virtual IRQ (vIRQ) IPC message or signal Communication Virtual IC Message-passing IPC Synchronization Virtual IRQ IPC message Source: http://www.cse.unsw.edu.au/ OSP Lecture 6, L4 Microkernels 22/42 Abstracting memory I Address space, fundamentally: I A collection of virtual ! physical mappings I Ways to expose this to user: I Array of (physical) frames or (virtual) pages to be mapped I Cache for mappings which might vanish (Virtual TLB) OSP Lecture 6, L4 Microkernels 23/42 Abstracting execution I Threads, vCPUs I What defines a thread? I Migrating threads I Thread might be moved to different address space OSP Lecture 6, L4 Microkernels 24/42 Abstracting execution I Scheduling: map threads to CPUs I What is the scheduling policy? I Simple round-robin I Policy-free scheduling? OSP Lecture 6, L4 Microkernels 25/42 Communication abstraction I Inter-Process Communication (IPC) I Synchronous, asynchronous 6= blocking, non-blocking I Traditional L4 IPC is fully synchronous I Asynchronous notification I Sender asynchronous, receiver blocking and synchronous I Similar to Unix's select OSP Lecture 6, L4 Microkernels 26/42 Interrupt abstraction I Hardware faults are abstracted through IPC I Synchronous exceptions, page faults, etc. I Interrupts are asynchronous notifications I Thread must register as a pagefault/exception/interrupt handler OSP Lecture 6, L4 Microkernels 27/42 Access control How do we specify objects? I IDs in a global list I Provably insecure I Can DDoS, create covert channels, etc. I IDs in per-address space lists I Capabilities OSP Lecture 6, L4 Microkernels 28/42 Access control: capabilities I Developed in KeyKOS, Coyotos, Amoeba, L4 Pistachio, OKL4, seL4, ::: I A token I owned by the subject (e.g. a thread) I as proof that it has access rights to an object (e.g. a kernel object) I All inter-domain accesses are mediated by capabilities OSP Lecture 6, L4 Microkernels 29/42 Outline Introduction and design principles Brief history of microkernels L4: Basic abstractions L4: Design and implementation choices Keywords Questions OSP Lecture 6, L4 Microkernels 30/42 Implementation language I Initial L3 and L4: 100% x86 assembly I Pistachio, OKL4 microkernel: C, C++, assembly I OKL4 Microvisor, seL4: C I seL4: Haskell prototype for correctness proof OSP Lecture 6, L4 Microkernels 31/42 Inter-Process Communication I seL4, OKL4: \Endpoints" as IPC targets I Decouple target from actual service I Fully signal-like asynchronous IPC (OKL4 Microvisor) OSP Lecture 6, L4 Microkernels 32/42 Access control and resource management I seL4: access control based on delegable capabilities I Take-grant model I Provable security I Information leaks are impossible I ::: if the policy is correct I ::: and the implementation is correct I ::: and the compiler is correct I ::: and the hardware isn't faulty OSP Lecture 6, L4 Microkernels 33/42 Access control and resource management I seL4: resources are exposed as capabilities to physical memory I May be: I Mapped I Delegated to children domains I Delegated to kernel: \retyped" into kernel objects OSP Lecture 6, L4 Microkernels 34/42 Preemption in the kernel I Interrupts are disabled when running in kernel I Microkernel is in general non-preemptable I Preemption points for long-running operations OSP Lecture 6, L4 Microkernels 35/42 Scheduling I Scheduling contexts (Fiasco.OC) I Separate scheduling parameters from threads I Allow implementing hierarchical scheduling [Lackorzy´nskiet al '12] I Policy-free scheduling still unresolved OSP Lecture 6, L4 Microkernels 36/42 Multi-processors I Initial L4 design is uniprocessor I seL4: same, due to formal verification constraints I Possible approach: multikernels [M Von Tessin '12] OSP Lecture 6, L4 Microkernels 37/42 Outline Introduction and design principles Brief history of microkernels L4: Basic abstractions L4: Design and implementation choices Keywords Questions OSP Lecture 6, L4 Microkernels 38/42 Keywords I microkernel I inter-process communication I l4 I access control I thread I capability I address space I preemption OSP Lecture 6, L4 Microkernels 39/42 Resources I http://dl.acm.org/citation.cfm?id=224075 I http://www.cse.unsw.edu.au/~cs9242/13/lectures/ I http://os.inf.tu-dresden.de/L4/ I http://ssrg.nicta.com.au/projects/seL4/ I http://os.inf.tu-dresden.de/fiasco/ I http://www.ok-labs.com/products/okl4-microvisor OSP Lecture 6, L4 Microkernels 40/42 Outline Introduction and design principles Brief history of microkernels L4: Basic abstractions L4: Design and implementation choices Keywords Questions OSP Lecture 6, L4 Microkernels 41/42 Questions ? OSP Lecture 6, L4 Microkernels 42/42.
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]
  • On the Construction of Reliable Device Drivers Leonid Ryzhyk
    On the Construction of Reliable Device Drivers Leonid Ryzhyk Ph.D. 2009 ii iii ‘I hereby declare that this submission is my own work and to the best of my knowledge it contains no materials previously pub- lished or written by another person, or substantial proportions of material which have been accepted for the award of any other degree or diploma at UNSW or any other educational institution, except where due acknowledgement is made in the thesis. Any contribution made to the research by others, with whom I have worked at UNSW or elsewhere, is explicitly acknowledged in the thesis. I also declare that the intellectual content of this the- sis is the product of my own work, except to the extent that as- sistance from others in the project’s design and conception or in style, presentation, and linguistic expression is acknowledged.’ Signed .................................. Date .................................. iv Abstract This dissertation is dedicated to the problem of device driver reliability. Software defects in device drivers constitute the biggest source of failure in operating systems, causing sig- nificant damage through downtime and data loss. Previous research on driver reliability has concentrated on detecting and mitigating defects in existing drivers using static analysis or runtime isolation. In contrast, this dissertation presents an approach to reducing the number of defects through an improved device driver architecture and development process. In analysing factors that contribute to driver complexity and induce errors, I show that a large proportion of errors are due to two key shortcomings in the device-driver architecture enforced by current operating systems: poorly-defined communication protocols between drivers and the operating system, which confuse developers and lead to protocol violations, and a multithreaded model of computation, which leads to numerous race conditions and deadlocks.
    [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]
  • Microkernels Meet Recursive Virtual Machines
    Microkernels Meet Recursive Virtual Machines Bryan Ford Mike Hibler Jay Lepreau Patrick Tullmann Godmar Back Stephen Clawson Department of Computer Science, University of Utah Salt Lake City, UT 84112 [email protected] http://www.cs.utah.edu/projects/flux/ Abstract ªverticallyº by implementing OS functionalityin stackable virtual machine monitors, each of which exports a virtual Thispaper describes a novel approach to providingmod- machine interface compatible with the machine interface ular and extensible operating system functionality and en- on which it runs. Traditionally,virtual machines have been capsulated environments based on a synthesis of micro- implemented on and export existing hardware architectures kernel and virtual machine concepts. We have developed so they can support ªnaiveº operating systems (see Fig- a software-based virtualizable architecture called Fluke ure 1). For example, the most well-known virtual machine that allows recursive virtual machines (virtual machines system, VM/370 [28, 29], provides virtual memory and se- running on other virtual machines) to be implemented ef- curity between multiple concurrent virtual machines, all ®ciently by a microkernel running on generic hardware. exporting the IBM S/370 hardware architecture. Further- A complete virtual machine interface is provided at each more, special virtualizable hardware architectures [22, 35] level; ef®ciency derives from needing to implement only have been proposed, whose design goal is to allow virtual new functionality at each level. This infrastructure allows machines to be stacked much more ef®ciently. common OS functionality, such as process management, demand paging, fault tolerance, and debugging support, to This paper presents a new approach to OS extensibil- be provided by cleanly modularized, independent, stack- ity which combines both microkernel and virtual machine able virtual machine monitors, implemented as user pro- concepts in one system.
    [Show full text]
  • Executive Summary
    Mobile Commerce Security: Legal & Technological Perspectives Michael Triguboff Table of Contents EXECUTIVE SUMMARY 4 INTRODUCTION 7 The Need for Security 11 PART I TECHNOLOGY 12 Client-Side Vulnerabilities 12 Browser Software 13 Java Applets 14 ActiveX controls 16 JavaScript 18 Plug-Ins and Graphic Files 18 Push technology 18 Web Server Security 19 Front-end 20 Firewalls 22 Back-end Database vulnerabilities 23 Server- Side Middleware 24 Operating System Problems 25 Hardened versions of Operating Systems 36 Distributed systems 37 Software Testing 38 Mobile Commerce Issues 43 Device Properties 43 Wireless Communication 45 Wireless Communication Protocols 47 Ad Hoc Networks 49 Ad Hoc Networks and Key Management 51 Network Protection in Ad Hoc Networks 54 Location Dependent Information and Mobile Computing 55 Mobile Agents 56 Protecting the Host from the Mobile Agent 59 Safe Code Interpretation 61 Digital Signatures 63 Proof Carrying Code 63 Path Histories 64 Software-Based Fault Isolation [“Sandboxing”] 64 Protecting the Agent From the Host and Other Agents 64 Secure Control of Remote Agents 65 Read-Only/Append-Only 65 Partial Results Encapsulation 66 Code Obfuscation 67 Computing with Encrypted Functions 67 Environmental Key Generation 68 Execution Tracing 68 Itinerary Recording 69 Security Through Shared Secrets and Interlocking 69 Other Approaches 69 Attacks Based on Device Limitations 71 2 Prevention, Detection and Reaction 71 Intrusion Detection 72 Intrusion Detection and Mobile Agents 75 Part I Conclusion 76 PART 11 THE LEGAL PERSPECTIVE 80 The Debate: A Confluence of Two Streams 81 Uniform Electronic Transactions Act 85 Article 2B of the Uniform Commercial Code 85 The Electronic Signatures in Global and National Commerce Act [“E-Sign Act”] 88 Jurisdiction Selection 90 Reaction- Criminal Law 96 Convention on Cyber-Crime 97 Evidentiary or Procedural Law 99 Practical Considerations 100 Part II Conclusion 101 APPENDIX 103 Digital Millennium Copyright Act 103 BIBLIOGRAPHY 107 3 EXECUTIVE SUMMARY The objectives of this project are twofold.
    [Show full text]
  • All Computer Applications Need to Store and Retrieve Information
    MyFS: An Enhanced File System for MINIX A Dissertation Submitted in partial fulfillment of the requirement for the award of the degree of MASTER OF ENGINEERING ( COMPUTER TECHNOLOGY & APPLICATIONS ) By ASHISH BHAWSAR College Roll No. 05/CTA/03 Delhi University Roll No. 3005 Under the guidance of Prof. Asok De Department Of Computer Engineering Delhi College Of Engineering, New Delhi-110042 (University of Delhi) July-2005 1 CERTIFICATE This is to certify that the dissertation entitled “MyFS: An Enhanced File System for MINIX” submitted by Ashish Bhawsar in the partial fulfillment of the requirement for the award of degree of Master of Engineering in Computer Technology and Application, Delhi College of Engineering is an account of his work carried out under my guidance and supervision. Professor D. Roy Choudhury Professor Asok De Head of Department Head of Department Department of Computer Engineering Department of Information Technology Delhi College of Engineering Delhi College of Engineering Delhi Delhi 2 ACKNOWLEDGEMENT It is a great pleasure to have the opportunity to extent my heartiest felt gratitude to everybody who helped me throughout the course of this project. I would like to express my heartiest felt regards to Dr. Asok De, Head of the Department, Department of Information Technology for the constant motivation and support during the duration of this project. It is my privilege and owner to have worked under the supervision. His invaluable guidance and helpful discussions in every stage of this thesis really helped me in materializing this project. It is indeed difficult to put his contribution in few words. I would also like to take this opportunity to present my most sincere regards to Dr.
    [Show full text]
  • Composing Abstractions Using the Null-Kernel
    Composing Abstractions using the null-Kernel James Litton Deepak Garg University of Maryland Max Planck Institute for Software Systems Max Planck Institute for Software Systems [email protected] [email protected] Peter Druschel Bobby Bhattacharjee Max Planck Institute for Software Systems University of Maryland [email protected] [email protected] CCS CONCEPTS hardware, such as GPUs, crypto/AI accelerators, smart NICs/- • Software and its engineering → Operating systems; storage devices, NVRAM etc., and to efficiently support new Layered systems; • Security and privacy → Access control. application requirements for functionality such as transac- tional memory, fast snapshots, fine-grained isolation, etc., KEYWORDS that demand new OS abstractions that can exploit existing hardware in novel and more efficient ways. Operating Systems, Capability Systems At its core, the null-Kernel derives its novelty from being ACM Reference Format: able to support and compose across components, called Ab- James Litton, Deepak Garg, Peter Druschel, and Bobby Bhattachar- stract Machines (AMs) that provide programming interfaces jee. 2019. Composing Abstractions using the null-Kernel. In Work- at different levels of abstraction. The null-Kernel uses an ex- shop on Hot Topics in Operating Systems (HotOS ’19), May 13–15, 2019, Bertinoro, Italy. ACM, New York, NY, USA, 6 pages. https: tensible capability mechanism to control resource allocation //doi.org/10.1145/3317550.3321450 and use at runtime. The ability of the null-Kernel to support interfaces at different levels of abstraction accrues several 1 INTRODUCTION benefits: New hardware can be rapidly deployed using rela- tively low-level interfaces; high-level interfaces can easily Abstractions imply choice, one that OS designers must con- be built using low-level ones; and applications can benefit front when designing a programming interface to expose.
    [Show full text]
  • Open Ongtang-Phd-Dissertation.Pdf
    The Pennsylvania State University The Graduate School SECURING MOBILE PHONES IN THE EVOLVING MOBILE ECOSYSTEM A Dissertation in Computer Science and Engineering by Machigar Ongtang © 2010 Machigar Ongtang Submitted in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy August 2010 The dissertation of Machigar Ongtang was reviewed and approved∗ by the following: Patrick D. McDaniel Associate Professor of Computer Science and Engineering Dissertation Advisor, Chair of Committee Thomas F. La Porta Distinguished Professor of Computer Science and Engineering Trent Jaeger Associate Professor of Computer Science and Engineering Ling Rothrock Associate Professor of Industrial and Manufacturing Engineering Raj Acharya Professor of Computer Science and Engineering Department Head ∗Signatures are on file in the Graduate School. Abstract The revolution of mobile phone industry has been altering our life and business practices over the past few decades. Driven by user demands and technological advancement, we now experience rich mobile phone applications and sophisticated cellular services ranging from mobile payment, stock trading, to social networking, vehicle tracking to in-car control. As more players joining the community, this mobile phone environment has transformed into a complex network of interacting companies, known as mobile ecosystem. Unfortunately, this opening and converging mobile ecosystem has brought in more opportunities for more attacks on mobile phones, a key element of the system. This dissertation aims to achieve mobile phone security. We reveal two main chal- lenges that we need to overcome, namely developing a clear definition of secure phones, and building security infrastructure that imposes such definition on the phones. We also identify three key elements that contribute to the fidelity of mobile phones, namely, mobile phone platforms, mobile phone applications, and mobile content.
    [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]
  • Harvard Cs252r Fa'13
    Type Enforcement & Pluggable MAC Harvard CS252r Fa’13 Tuesday, October 22, 13 1 Practical Domain and Type Enforcement for UNIX • Badger, et al. 1995 • Trusted Information Systems Tuesday, October 22, 13 2 Domain and Type Enforcement • Every Subject is associated with a Domain • Every Object is associated with a Type Tuesday, October 22, 13 3 Boebart and Kain ’85 [7], page 23 introduces this a given user could have multiple subjects operating in diferent domains dynamically, it seems a subject and an object are associated with just one, statically: could be anything Domain and Type Enforcement • Domain Definition Table • Domain’s Access Rights to each Type • read, write, etc. • Domain Interaction Table • Domain’s Access Rights to other Domains • signal, create, destroy, etc. Tuesday, October 22, 13 4 Domain and Type Enforcement • Strict Superset of Lattice-Expressible Security Policies Tuesday, October 22, 13 5 Domain and Type Enforcement Manager budget designs Accountant Engineer salary Tuesday, October 22, 13 6 DTEL Domain and Type Enforcement Language • Encompasses Existing Security Policies • Hierarchical Types • Simple, Declarative Language Tuesday, October 22, 13 7 DTEL Operating System Entities File Hierarchy Process Hierarchy Figure 1: Mismatch Between Policy Concepts and System Structures trol configurations. A DTE specification includes ration: the type statement, the domain statement, the security attribute associations such as typelfile tnitial-domain statement, and the assign statement.’ associations as well as other access control in- The purpose of this section is not to fully document Tuesday,formation. October 22, 13 The language provides a high-level DTEL, but to demonstrate through a small example 8 view of information traditionally enurnerated in that a meaningful DTEL policy can be expressed com- type enforcement tables and includes facilities pletely in a form simple and concise enough to be ad- for superimposing security attribute bindings and ministered at reasonable cost.
    [Show full text]