DOCSLIB.ORG

Mmapx: Uniform Memory Protection in a Heterogeneous World

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Mmapx: Uniform Memory Protection in a Heterogeneous World mmapx: Uniform memory protection in a heterogeneous world Reto Achermann* David Cock* Roni Haecki* University of British Columbia ETH Zurich ETH Zurich Vancouver, Canada Zurich, Switzerland Zurich, Switzerland Nora Hossle* Lukas Humbel* Timothy Roscoe* ETH Zurich ETH Zurich ETH Zurich Zurich, Switzerland Zurich, Switzerland Zurich, Switzerland Daniel Schwyn* ETH Zurich Zurich, Switzerland ABSTRACT CCS CONCEPTS Modern Systems-on-Chip (SoCs) are networks of hetero- • Software and its engineering ! Operating systems; Mem- geneous cores, intelligent devices, and memory, connected ory management; Virtual memory. through multiple configurable address translation and protec- tion units like IOMMUs and System MMUs. KEYWORDS Modern OS kernels like Linux are based on traditional operating systems, memory management, address spaces MMUs and have no clear abstractions to represent this com- plexity, mostly leaving IOMMU configuration to device dri- ACM Reference Format: vers. This has led to a recent spate of serious bugs, and increas- Reto Achermann, David Cock, Roni Haecki, Nora Hossle, Lukas ing concern over “cross-SoC” attacks on memory security. Humbel, Timothy Roscoe, and Daniel Schwyn. 2021. mmapx: Uni- Workshop To address this, we propose a new kernel primitive, mmapx, form memory protection in a heterogeneous world. In on Hot Topics in Operating Systems (HotOS ’21), May 31–June 2, based on a decoding net a rich and detailed representation of 2021, Ann Arbor, MI, USA. ACM, New York, NY, USA, 8 pages. the memory addressing semantics of a complex SoC from the https://doi.org/10.1145/3458336.3465273 recent formal methods literature. mmapx provides a uniform facility for securely configuring all the address translation facilities in a system. 1 INTRODUCTION mmapx leverages existing Unix facilities wherever possi- Memory management in a modern operating system provides ble: the file system for naming, discovery, and coarse-grained protection via a simple model: client software (either a user- access control, and file descriptors for fine-grained autho- space process or an in-kernel driver) requests access to a rization. We show how mmapx can eliminate bugs caused by physical resource (either memory or device registers) by iden- device drivers programming IOMMUs directly, but also the tifying its location in the system-wide physical address space. detail captured by the underlying model has further benefits The OS checks authorization, and then maps the appropriate while incurring minimal overhead. physical region into the client’s virtual address space. Un- fortunately, these days this appealingly simple model just *Authors are in alphabetical order doesn’t work. Modern SoCs have complex interconnects and peripheral Permission to make digital or hard copies of part or all of this work for devices, and much of what Linux models as devices are really personal or classroom use is granted without fee provided that copies are not complete processors with their own firmware or independent made or distributed for profit or commercial advantage and that copies bear operating systems, often incorporating their own memory this notice and the full citation on the first page. Copyrights for third-party translation units. For protection to be useful, these devices components of this work must be honored. For all other uses, contact the must be sandboxed behind a correctly-configured IOMMU owner/author(s). (or System MMU). HotOS ’21, May 31–June 2, 2021, Ann Arbor, MI, USA © 2021 Copyright held by the owner/author(s). However, programming IOMMUs is complex and error- ACM ISBN 978-1-4503-8438-4/21/05. prone, and is often delegated to individual device drivers, https://doi.org/10.1145/3458336.3465273 which have ambient authority in the kernel. The task is made 159 HotOS ’21, May 31–June 2, 2021, Ann Arbor, MI, USA Achermann, et al. worse by the need to enforce a changing partial correspon- QuRT Linux dence between the virtual address space seen by the device, and that seen by a process, since the OS needs to share datas- A57 DSP DSP tructures with devices as much as protect itself from them. Registers MMU The result is that buggy, compromised, or just plain malicious devices or drivers can do an end-run around the OS protection MMU SMMU model by exploiting holes in the IOMMU-based protection domain [14, 22]. DRAM System Address Space Surprisingly, modern OSes provide no good abstractions for uniformly handling this problem, leaving low-level con- figuration of protection up to individual device drivers. This Figure 1: Relevant actors (A57 and DSP), translation is in contrast to, e.g. access control in file systems or au- units (MMU, SMMU) and memory regions (gray) of the thority over process address space, where well-established Qualcomm SoC. Note that the DSP MMU is not con- subsystems enforce OS policy. trolled by the host Linux, but the SMMU is. We propose a new primitive, mmapx, for clients to request general memory mappings. Unlike existing interfaces, mmapx is explicit about which address space it is mapping a region between the model of hardware behavior baked into the OS from, and which address space it is mapping a region into. kernel, and the reality of modern SoC platforms. This allows clients to be precise in specifying what memory QualPwn affects mobile SoCs running Android and starts is exposed to devices or coprocessors via IOMMUs. Like with a bug in the WLAN process running not on the CPU but mmap(), mmapx refers to memory regions using file descrip- a DSP core on the chip, which runs the proprietary QuRT OS. tors, which provide capability-like protection. However, re- A series of exploits allows compromise of another process on gions for mmapx are acquired using a file system (/dev/as), the DSP, which itself communicates with its corresponding which captures the memory topology of the machine in detail, device driver in the Linux kernel on the application cores and allows basic authorization to leverage the full Unix file using DMA. Since the driver trusts the device, it can be tricked system protection model via two different rights on an address into granting the device full access to application memory by space: map and grant. reprogramming the system MMU. We describe mmapx here from the point of view of user- Our focus in this paper is preventing incorrect granting of space Linux programs but the basic model works in a micro- memory access rights to devices and drivers. A simplified kernel architecture, or within a monolithic kernel. In the latter view of the hardware is shown in Figure 1: two processors, case, protection within the kernel is only advisory, unless running a different OS, with different MMUs, but sharing a mechanism like Nooks [28] is available. Crucially, how- the same memory. The Linux kernel driver is tasked with ever, even in this case mmapx provides a policy framework configuring the SMMU to only allow legitimate access to for protecting the kernel itself from malicious or buggy dri- buffers shared between the two cores, and it fails to do this. vers, device firmware, or other cores not running the kernel Linux offers little functionality to help with this task. In- itself by ensuring that IOMMUs and other translation units stead, it relies on a naive model where a set of process vir- are correctly programmed. tual address spaces are mapped to a single physical address Moreover, while mmapx resembles a high-level primitive space, and protection against DMA-capable devices using like mmap(), this belies its true power. mmapx builds on our an IOMMU or SMMU is delegated to drivers. Indeed, the existing work on formalizing address translation and decod- SMMU is often programmed to give a device the same view ing, and its concept of an “address space” region is flexible of memory as that of the corresponding software process, and powerful enough to capture the functionality of the full whether in user space or the kernel. range of TLBs, and even individual levels of a multi-level For example, the recent Linux Heterogeneous Memory page table. This allows mmapx to express “delegation” of Manager [29] attempts to unify device memory management MMU page table structures to virtual machines, for example, using a specialized page structure to replicate translation as in Arrakis [24] and Ix [6]. across device and CPU address spaces, in order to simplify programming with GPU and FPGA accelerators. We argue this is inappropriate for devices: access by the device should be restricted as much as possible, rather than 2 MOTIVATION giving the device free rein over application memory [22]. The “QualPwn” exploit [14] is emblematic of the problem However, Linux provides no help in maintaining partially we address in this paper. It makes brutally clear the mismatch replicated mappings between heterogeneous devices or cores: 160 mmapx: Uniform memory protection in a heterogeneous world HotOS ’21, May 31–June 2, 2021, Ann Arbor, MI, USA there are simply no abstractions for explicitly changing SMMU base asid right z }| { z}|{ z }| { mappings. /dev/as /0 /{grant,map,info} We are not first to point this out[13], and so-called “cross- SoC” attacks [4, 14, 26] and other DMA-related vulnerabili- ties [18, 21, 23, 25, 32] which exploit the fact that the OS is Figure 2: The path structure of /dev/as not in control of software running on other cores on the SoC is becoming a serious security concern. Neither does moving the device driver out of the kernel solve the problem, whether decoding net representation of the hardware using standard into Linux user space or using a microkernel-oriented design. device discovery and Devicetree representations [20]. Our solution to this is to provide a single primitive for con- For example, the Linux kernel running on the A57 in Fig- figuring any translation hardware in the system, with a clear ure 1 would detect the presence of the modem coprocessor and secure authorization framework that leverages existing from a Devicetree entry, and would create the corresponding mechanisms in the kernel.
Load more

Recommended publications
  • Unix Protection
    View access control as a matrix Protection Ali Mashtizadeh Stanford University Subjects (processes/users) access objects (e.g., files) • Each cell of matrix has allowed permissions • 1 / 39 2 / 39 Specifying policy Two ways to slice the matrix Manually filling out matrix would be tedious • Use tools such as groups or role-based access control: • Along columns: • - Kernel stores list of who can access object along with object - Most systems you’ve used probably do this dir 1 - Examples: Unix file permissions, Access Control Lists (ACLs) Along rows: • dir 2 - Capability systems do this - More on these later. dir 3 3 / 39 4 / 39 Outline Example: Unix protection Each process has a User ID & one or more group IDs • System stores with each file: • 1 Unix protection - User who owns the file and group file is in - Permissions for user, any one in file group, and other Shown by output of ls -l command: 2 Unix security holes • user group other owner group - rw- rw- r-- dm cs140 ... index.html 3 Capability-based protection - Eachz}|{ groupz}|{ z}|{ of threez}|{ lettersz }| { specifies a subset of read, write, and execute permissions - User permissions apply to processes with same user ID - Else, group permissions apply to processes in same group - Else, other permissions apply 5 / 39 6 / 39 Unix continued Non-file permissions in Unix Directories have permission bits, too • Many devices show up in file system • - Need write permission on a directory to create or delete a file - E.g., /dev/tty1 permissions just like for files Special user root (UID 0) has all
    [Show full text]
  • Operating Systems and Virtualisation Security Knowledge Area (Draft for Comment)
    OPERATING SYSTEMS AND VIRTUALISATION SECURITY KNOWLEDGE AREA (DRAFT FOR COMMENT) AUTHOR: Herbert Bos – Vrije Universiteit Amsterdam EDITOR: Andrew Martin – Oxford University REVIEWERS: Chris Dalton – Hewlett Packard David Lie – University of Toronto Gernot Heiser – University of New South Wales Mathias Payer – École Polytechnique Fédérale de Lausanne © Crown Copyright, The National Cyber Security Centre 2019. Following wide community consultation with both academia and industry, 19 Knowledge Areas (KAs) have been identified to form the scope of the CyBOK (see diagram below). The Scope document provides an overview of these top-level KAs and the sub-topics that should be covered under each and can be found on the project website: https://www.cybok.org/. We are seeking comments within the scope of the individual KA; readers should note that important related subjects such as risk or human factors have their own knowledge areas. It should be noted that a fully-collated CyBOK document which includes issue 1.0 of all 19 Knowledge Areas is anticipated to be released by the end of July 2019. This will likely include updated page layout and formatting of the individual Knowledge Areas. Operating Systems and Virtualisation Security Herbert Bos Vrije Universiteit Amsterdam April 2019 INTRODUCTION In this knowledge area, we introduce the principles, primitives and practices for ensuring security at the operating system and hypervisor levels. We shall see that the challenges related to operating system security have evolved over the past few decades, even if the principles have stayed mostly the same. For instance, when few people had their own computers and most computing was done on multiuser (often mainframe-based) computer systems with limited connectivity, security was mostly focused on isolating users or classes of users from each other1.
    [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]
  • Openvms Record Management Services Reference Manual
    OpenVMS Record Management Services Reference Manual Order Number: AA-PV6RD-TK April 2001 This reference manual contains general information intended for use in any OpenVMS programming language, as well as specific information on writing programs that use OpenVMS Record Management Services (OpenVMS RMS). Revision/Update Information: This manual supersedes the OpenVMS Record Management Services Reference Manual, OpenVMS Alpha Version 7.2 and OpenVMS VAX Version 7.2 Software Version: OpenVMS Alpha Version 7.3 OpenVMS VAX Version 7.3 Compaq Computer Corporation Houston, Texas © 2001 Compaq Computer Corporation Compaq, AlphaServer, VAX, VMS, the Compaq logo Registered in U.S. Patent and Trademark Office. Alpha, PATHWORKS, DECnet, DEC, and OpenVMS are trademarks of Compaq Information Technologies Group, L.P. in the United States and other countries. UNIX and X/Open are trademarks of The Open Group in the United States and other countries. All other product names mentioned herein may be the trademarks of their respective companies. Confidential computer software. Valid license from Compaq required for possession, use, or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor’s standard commercial license. Compaq shall not be liable for technical or editorial errors or omissions contained herein. The information in this document is provided "as is" without warranty of any kind and is subject to change without notice. The warranties for Compaq products are set forth in the express limited warranty statements accompanying such products. Nothing herein should be construed as constituting an additional warranty.
    [Show full text]
  • System Calls System Calls
    System calls We will investigate several issues related to system calls. Read chapter 12 of the book Linux system call categories file management process management error handling note that these categories are loosely defined and much is behind included, e.g. communication. Why? 1 System calls File management system call hierarchy you may not see some topics as part of “file management”, e.g., sockets 2 System calls Process management system call hierarchy 3 System calls Error handling hierarchy 4 Error Handling Anything can fail! System calls are no exception Try to read a file that does not exist! Error number: errno every process contains a global variable errno errno is set to 0 when process is created when error occurs errno is set to a specific code associated with the error cause trying to open file that does not exist sets errno to 2 5 Error Handling error constants are defined in errno.h here are the first few of errno.h on OS X 10.6.4 #define EPERM 1 /* Operation not permitted */ #define ENOENT 2 /* No such file or directory */ #define ESRCH 3 /* No such process */ #define EINTR 4 /* Interrupted system call */ #define EIO 5 /* Input/output error */ #define ENXIO 6 /* Device not configured */ #define E2BIG 7 /* Argument list too long */ #define ENOEXEC 8 /* Exec format error */ #define EBADF 9 /* Bad file descriptor */ #define ECHILD 10 /* No child processes */ #define EDEADLK 11 /* Resource deadlock avoided */ 6 Error Handling common mistake for displaying errno from Linux errno man page: 7 Error Handling Description of the perror () system call.
    [Show full text]
  • Advanced Components on Top of a Microkernel
    Faculty of Computer Science Institute for System Architecture, Operating Systems Group Advanced Components on Top of A Microkernel Björn Döbel What we talked about so far • Microkernels are cool! • Fiasco.OC provides fundamental mechanisms: – Tasks (address spaces) • Container of resources – Threads • Units of execution – Inter-Process Communication • Exchange Data • Timeouts • Mapping of resources TU Dresden, 2012-07-24 L4Re: Advanced Components Slide 2 / 54 Lecture Outline • Building a real system on top of Fiasco.OC • Reusing legacy libraries – POSIX C library • Device Drivers in user space – Accessing hardware resources – Reusing Linux device drivers • OS virtualization on top of L4Re TU Dresden, 2012-07-24 L4Re: Advanced Components Slide 3 / 54 Reusing Existing Software • Often used term: legacy software • Why? – Convenience: • Users get their “favorite” application on the new OS – Effort: • Rewriting everything from scratch takes a lot of time • But: maintaining ported software and adaptions also does not come for free TU Dresden, 2012-07-24 L4Re: Advanced Components Slide 4 / 54 Reusing Existing Software • How? – Porting: • Adapt existing software to use L4Re/Fiasco.OC features instead of Linux • Efficient execution, large maintenance effort – Library-level interception • Port convenience libraries to L4Re and link legacy applications without modification – POSIX C libraries, libstdc++ – OS-level interception • Wine: implement Windows OS interface on top of new OS – Hardware-level: • Virtual Machines TU Dresden, 2012-07-24 L4Re:
    [Show full text]
  • CHERI Instruction-Set Architecture
    UCAM-CL-TR-876 Technical Report ISSN 1476-2986 Number 876 Computer Laboratory Capability Hardware Enhanced RISC Instructions: CHERI Instruction-Set Architecture Robert N. M. Watson, Peter G. Neumann, Jonathan Woodruff, Michael Roe, Jonathan Anderson, David Chisnall, Brooks Davis, Alexandre Joannou, Ben Laurie, Simon W. Moore, Steven J. Murdoch, Robert Norton, Stacey Son September 2015 15 JJ Thomson Avenue Cambridge CB3 0FD United Kingdom phone +44 1223 763500 http://www.cl.cam.ac.uk/ c 2015 Robert N. M. Watson, Peter G. Neumann, Jonathan Woodruff, Michael Roe, Jonathan Anderson, David Chisnall, Brooks Davis, Alexandre Joannou, Ben Laurie, Simon W. Moore, Steven J. Murdoch, Robert Norton, Stacey Son, SRI International Approved for public release; distribution is unlimited. Sponsored by the Defense Advanced Research Projects Agency (DARPA) and the Air Force Research Laboratory (AFRL), under contracts FA8750-10-C-0237 (“CTSRD”) and FA8750-11-C-0249 (“MRC2”) as part of the DARPA CRASH and DARPA MRC research programs. The views, opinions, and/or findings contained in this report are those of the authors and should not be interpreted as representing the official views or policies, either expressed or implied, of the Department of Defense or the U.S. Government. Additional support was received from St John’s College Cambridge, the SOAAP Google Focused Research Award, the RCUK’s Horizon Digital Economy Research Hub Grant (EP/G065802/1), the EPSRC REMS Programme Grant (EP/K008528/1), the Isaac Newton Trust, the UK Higher Education Innovation Fund (HEIF), and Thales E-Security. Technical reports published by the University of Cambridge Computer Laboratory are freely available via the Internet: http://www.cl.cam.ac.uk/techreports/ ISSN 1476-2986 Abstract This technical report describes CHERI ISAv4, the fourth version of the Capability Hardware Enhanced RISC Instructions (CHERI) Instruction-Set Architecture (ISA)1 being developed by SRI International and the University of Cambridge.
    [Show full text]
  • Lecture Notes in Assembly Language
    Lecture Notes in Assembly Language Short introduction to low-level programming Piotr Fulmański Łódź, 12 czerwca 2015 Spis treści Spis treści iii 1 Before we begin1 1.1 Simple assembler.................................... 1 1.1.1 Excercise 1 ................................... 2 1.1.2 Excercise 2 ................................... 3 1.1.3 Excercise 3 ................................... 3 1.1.4 Excercise 4 ................................... 5 1.1.5 Excercise 5 ................................... 6 1.2 Improvements, part I: addressing........................... 8 1.2.1 Excercise 6 ................................... 11 1.3 Improvements, part II: indirect addressing...................... 11 1.4 Improvements, part III: labels............................. 18 1.4.1 Excercise 7: find substring in a string .................... 19 1.4.2 Excercise 8: improved polynomial....................... 21 1.5 Improvements, part IV: flag register ......................... 23 1.6 Improvements, part V: the stack ........................... 24 1.6.1 Excercise 12................................... 26 1.7 Improvements, part VI – function stack frame.................... 29 1.8 Finall excercises..................................... 34 1.8.1 Excercise 13................................... 34 1.8.2 Excercise 14................................... 34 1.8.3 Excercise 15................................... 34 1.8.4 Excercise 16................................... 34 iii iv SPIS TREŚCI 1.8.5 Excercise 17................................... 34 2 First program 37 2.1 Compiling,
    [Show full text]
  • A VLSI Architecture for Enhancing Software Reliability Kanad Ghose Iowa State University
    Iowa State University Capstones, Theses and Retrospective Theses and Dissertations Dissertations 1988 A VLSI architecture for enhancing software reliability Kanad Ghose Iowa State University Follow this and additional works at: https://lib.dr.iastate.edu/rtd Part of the Computer Sciences Commons Recommended Citation Ghose, Kanad, "A VLSI architecture for enhancing software reliability " (1988). Retrospective Theses and Dissertations. 9345. https://lib.dr.iastate.edu/rtd/9345 This Dissertation is brought to you for free and open access by the Iowa State University Capstones, Theses and Dissertations at Iowa State University Digital Repository. It has been accepted for inclusion in Retrospective Theses and Dissertations by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. INFORMATION TO USERS The most advanced technology has been used to photo­ graph and reproduce this manuscript from the microfilm master. UMI films the original text directly from the copy submitted. Thus, some dissertation copies are in typewriter face, while others may be from a computer printer. In the unlikely event that the author did not send UMI a complete manuscript and there are missing pages, these will be noted. Also, if unauthorized copyrighted material had to be removed, a note will indicate the deletion. Oversize materials (e.g., maps, drawings, charts) are re­ produced by sectioning the original, beginning at the upper left-hand comer and continuing from left to right in equal sections with small overlaps. Each oversize page is available as one exposure on a standard 35 mm slide or as a 17" x 23" black and white photographic print for an additional charge.
    [Show full text]
  • Chapter 1. Origins of Mac OS X
    1 Chapter 1. Origins of Mac OS X "Most ideas come from previous ideas." Alan Curtis Kay The Mac OS X operating system represents a rather successful coming together of paradigms, ideologies, and technologies that have often resisted each other in the past. A good example is the cordial relationship that exists between the command-line and graphical interfaces in Mac OS X. The system is a result of the trials and tribulations of Apple and NeXT, as well as their user and developer communities. Mac OS X exemplifies how a capable system can result from the direct or indirect efforts of corporations, academic and research communities, the Open Source and Free Software movements, and, of course, individuals. Apple has been around since 1976, and many accounts of its history have been told. If the story of Apple as a company is fascinating, so is the technical history of Apple's operating systems. In this chapter,[1] we will trace the history of Mac OS X, discussing several technologies whose confluence eventually led to the modern-day Apple operating system. [1] This book's accompanying web site (www.osxbook.com) provides a more detailed technical history of all of Apple's operating systems. 1 2 2 1 1.1. Apple's Quest for the[2] Operating System [2] Whereas the word "the" is used here to designate prominence and desirability, it is an interesting coincidence that "THE" was the name of a multiprogramming system described by Edsger W. Dijkstra in a 1968 paper. It was March 1988. The Macintosh had been around for four years.
    [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]