Safe and Automatic Live Update

Total Page:16

File Type:pdf, Size:1020Kb

Safe and Automatic Live Update Safe and Automatic Live Update Ph.D. Thesis Cristiano Giuffrida VU University Amsterdam, 2014 This work was funded by European Research Council under ERC Advanced Grant 227874. This work was carried out in the ASCI graduate school. ASCI dissertation series number 300. Copyright © 2014 by Cristiano Giuffrida. ISBN 978-90-5383-072-7 Cover design by Dirk Vogt. Printed by Wöhrmann Print Service. VRIJE UNIVERSITEIT SAFE AND AUTOMATIC LIVE UPDATE ACADEMISCH PROEFSCHRIFT ter verkrijging van de graad Doctor aan de Vrije Universiteit Amsterdam, op gezag van de rector magnificus prof.dr. F.A. van der Duyn Schouten, in het openbaar te verdedigen ten overstaan van de promotiecommissie van de Faculteit der Exacte Wetenschappen op donderdag 10 april 2014 om 13.45 uur in de aula van de universiteit, De Boelelaan 1105 door CRISTIANO GIUFFRIDA geboren te Rome, Italië promotor: prof.dr. A.S. Tanenbaum “All problems in computer science can be solved by another level of indirection.” Butler Lampson, quoting David Wheeler. Acknowledgements “Yesterday I learned that I received a 3-million euro grant from the EU—all for myself [. ]. Might you be interested?”. This is the email that started it all, on the now-distant date of August 15, 2008. I cannot recall many more details from that email, but I do recall that glancing over its first and last sentence was enough for me to conclude that my spam filter was far less aggressive than I had hoped for. I was literally about to discard the message, when the signature at the bottom caught my attention. It read “Andy Tanenbaum”, which initially only reinforced my belief that targeted phishing attacks had grown to become astonishingly common and sophisticated. After a sudden epiphany, I finally decided to keep on reading. That was the beginning of my Ph.D. journey at the Vrije Universiteit Amsterdam. A challenging and rewarding journey which ultimately culminated in this disserta- tion, but which would not have been possible without the help of others. First and foremost, I would like to thank my supervisor, Andy Tanenbaum, for his constant guidance and support during all these years. Not only did he teach me how to do research and write papers, but he helped me develop passion for simple and elegant solutions and showed me that critical thinking, dedication, and perseverance can take you a long way. I am deeply indebted to him for providing me with an excellent topic, while allowing me, at the same time, to independently explore many exciting research directions that have gradually shaped my scientific interests over the years. Next, I would like to express my gratitude to all the members of my Ph.D. thesis committee: Herbert Bos, Cristian Cadar, Bruno Crispo, Orran Krieger, and Liuba Shira. Their valuable comments greatly contributed to improving the quality of this dissertation. I am especially grateful to Orran Krieger, for his extensive and in- sightful comments on the text, and Cristian Cadar, for fruitful early discussions and feedback on the techniques presented in this dissertation. A special mention is in or- der for my internal referees. I am extremely grateful to Herbert Bos, for his constant vii viii ACKNOWLEDGEMENTS support and excellent suggestions throughout my research work, and Bruno Crispo, for strongly encouraging me to expand my research interests into systems security. I would also like to acknowledge the many other people I had the pleasure to work or spend time with at the Vrije Universiteit Amsterdam. First, I would like to thank those who shared their Ph.D. journeys with me, especially Stefano Ortolani, for his friendship and engagement in many joint “not-so-side” research projects, and my P4.69 office mates, Raja Appuswamy, Jorrit Herder, Tomas Hruby, Erik van der Kouwe, David van Moolenbroek, and Dirk Vogt, for creating an inspiring and enjoyable work environment. Next, I would like to thank all the other members of the MINIX 3 team, including Ben Gras, Philip Homburg, Lionel Sambuc, Arun Thomas, and Thomas Veerman, for their ability to challenge my most ambitious ideas and provide very valuable support on short notice. Needless to say, I will never forget the movie nights and the other team events we shared together. I am also grateful to the many excellent students who contributed to our research projects, especially Calin Iorgulescu and Anton Kuijsten, with whom I shared many sleepless nights before a paper deadline. Finally, I would like to thank all the other people from the Computer Systems group, who substantially contributed to making my doctoral years special both professionally and personally, Willem de Bruijn, Albana Gaba, Ana Oprescu, Georgios Portokalidis, Asia Slowinska, and Spyros Voulgaris, in particular. I am also grateful to Divyesh Shah, for inviting me to join the kernel memory team at Google and for providing me with all the necessary support during my in- ternship time in Mountain View, California. I would also like to thank all the other members of the kernel memory team, especially Ying Han and Greg Thelen, for their dedication and support. My experience at Google has further strengthened my interest in operating systems and memory management, while providing much in- spiration for the RCU-based quiescence detection protocol presented in Chapter 7. I would also like to extend my gratitude to the many friends who provided the much needed distraction and support during my Ph.D. journey, including: all my fellow “Djangonians”, especially the pioneers, Albana, Christian, Dirk, Stefano, and Steve, for the unforgettable moments shared together; Raja, for the way-too- many “Lost” evenings; Flavio, for being always there for me in the difficult times. Last but not least, I would like to thank my family for supporting me all these years. My mother, among so many other things, for being a constant source of inspi- ration throughout my life, encouraging me to pursue my passion for research, and getting me interested in computers at a young age—despite her passion for archeol- ogy. My uncle and aunt, for guiding me through important decisions in my life. My cousins, Chiara and Matteo, for joining me on so many adventures. Finally, Laura, for her love, support, and much needed patience throughout this endeavor. Cristiano Giuffrida Amsterdam, The Netherlands, December 2013 Contents Acknowledgements vii Contents ix List of Figures xv List of Tables xvii Publications xix 1 Introduction 1 2 Safe and Automatic Live Update for Operating Systems 9 2.1 Introduction . 10 2.1.1 Contribution . 12 2.2 Background . 12 2.2.1 Safe Update State . 12 2.2.2 State Transfer . 13 2.2.3 Stability of the update process . 15 2.3 Overview . 16 2.3.1 Architecture . 16 2.3.2 Update example . 17 2.3.3 Limitations . 18 2.4 Live Update Support . 19 2.4.1 Programming model . 19 2.4.2 Virtual IPC endpoints . 20 2.4.3 State filters . 20 ix x ACKNOWLEDGEMENTS 2.4.4 Interface filters . 21 2.4.5 Multicomponent updates . 21 2.4.6 Hot rollback . 22 2.5 State Management . 22 2.5.1 State transfer . 23 2.5.2 Metadata instrumentation . 24 2.5.3 Pointer transfer . 25 2.5.4 Transfer strategy . 26 2.5.5 State checking . 27 2.6 Evaluation . 28 2.6.1 Experience . 28 2.6.2 Performance . 31 2.6.3 Service disruption . 34 2.6.4 Memory footprint . 34 2.7 Related work . 35 2.8 Conclusion . 37 2.9 Acknowledgments . 37 3 Enhanced Operating System Security Through Efficient and Fine-grained Address Space Randomization 39 3.1 Introduction . 40 3.1.1 Contributions . 41 3.2 Background . 41 3.2.1 Attacks on code pointers . 41 3.2.2 Attacks on data pointers . 42 3.2.3 Attacks on nonpointer data . 42 3.3 Challenges in OS-level ASR . 42 3.3.1 W⊕X............................. 42 3.3.2 Instrumentation . 43 3.3.3 Run-time constraints . 43 3.3.4 Attack model . 43 3.3.5 Information leakage . 44 3.3.6 Brute forcing . 44 3.4 A design for OS-level ASR . 45 3.5 ASR transformations . 47 3.5.1 Code randomization . 48 3.5.2 Static data randomization . 49 3.5.3 Stack randomization . 51 3.5.4 Dynamic data randomization . 52 3.5.5 Kernel modules randomization . 52 3.6 Live rerandomization . 53 3.6.1 Metadata transformation . 53 3.6.2 The rerandomization process . 54 ACKNOWLEDGEMENTS xi 3.6.3 State migration . 55 3.6.4 Pointer migration . 56 3.7 Evaluation . 57 3.7.1 Performance . 57 3.7.2 Memory usage . 60 3.7.3 Effectiveness . 60 3.8 Related work . 63 3.8.1 Randomization . 63 3.8.2 Operating system defenses . 64 3.8.3 Live rerandomization . 64 3.9 Conclusion . 65 3.10 Acknowledgments . 65 4 Practical Automated Vulnerability Monitoring Using Program State In- variants 67 4.1 Introduction . 68 4.2 Program State Invariants . 69 4.3 Architecture . 70 4.3.1 Static Instrumentation . 71 4.3.2 Indexing pointer casts . 72 4.3.3 Indexing value sets . 72 4.3.4 Memory management instrumentation . 73 4.3.5 Metadata Framework . 73 4.3.6 Dynamic Instrumentation . 74 4.3.7 Run-time Analyzer . 75 4.3.8 State introspection . 76 4.3.9 Invariants analysis . 76 4.3.10 Recording . 77 4.3.11 Reporting . 77 4.3.12 Feedback generation . 78 4.3.13 Debugging . 78 4.4 Memory Errors Detected . 78 4.4.1 Dangling pointers . 78 4.4.2 Off-by-one pointers . 78 4.4.3 Overflows/underflows . 79 4.4.4 Double and invalid frees . 79 4.4.5 Uninitialized reads .
Recommended publications
  • 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]
  • 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]
  • Performance Best Practices for Vmware Workstation Vmware Workstation 7.0
    Performance Best Practices for VMware Workstation VMware Workstation 7.0 This document supports the version of each product listed and supports all subsequent versions until the document is replaced by a new edition. To check for more recent editions of this document, see http://www.vmware.com/support/pubs. EN-000294-00 Performance Best Practices for VMware Workstation You can find the most up-to-date technical documentation on the VMware Web site at: http://www.vmware.com/support/ The VMware Web site also provides the latest product updates. If you have comments about this documentation, submit your feedback to: [email protected] Copyright © 2007–2009 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies. VMware, Inc. 3401 Hillview Ave. Palo Alto, CA 94304 www.vmware.com 2 VMware, Inc. Contents About This Book 5 Terminology 5 Intended Audience 5 Document Feedback 5 Technical Support and Education Resources 5 Online and Telephone Support 5 Support Offerings 5 VMware Professional Services 6 1 Hardware for VMware Workstation 7 CPUs for VMware Workstation 7 Hyperthreading 7 Hardware-Assisted Virtualization 7 Hardware-Assisted CPU Virtualization (Intel VT-x and AMD AMD-V)
    [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]
  • 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]
  • Inspecting Data from the Safety of Your Trusted Execution Environment
    Inspecting data from the safety of your trusted execution environment John Williams johnwwil [at] u.washington.edu June, 2015 Abstract: This paper presents a proof of concept that uses ARM TrustZone to perform introspection of a Linux kernel running in the normal world from within a secure-world system. Techniques from existing volatile-memory analysis applications are repurposed for application in real-time through asynchronous introspection of the normal world. The solution presented here leverages open-source software that is actively being developed to support additional architectures. 1 INTRODUCTION As technology becomes more prevalent in our day-to-day lives, we increasingly rely on mobile devices for both business and personal purposes. Emerging security threats, such as rootkits that can scan memory for protected PCI information, have been responsible for large-scale breaches. It has been predicted that targeted exploit kits and attack services will soon exist for mobile platforms, which could enable the exploitation of mobile devices on an unprecedented scale [1]. Techniques for mitigating such threats to mobile devices have largely evolved in parallel with industry demand for them. While some companies have indeed made progress through continued addition of product features that increase the security of devices, other companies have simply pivoted their marketing efforts to emphasize or recast certain aspects of their existing capabilities. In order to select the right products and features for protecting sensitive data and activities, effective segmentation is key. While segmentation within devices has traditionally been implemented at the operating system level, in recent years architectural modification at the chip level has emerged as a way to provide hard segmentation between execution environments.
    [Show full text]
  • Leveraging ARM Trustzone and Verifiable Computing to Provide Auditable Mobile Functions Nuno O
    Leveraging ARM TrustZone and Verifiable Computing to Provide Auditable Mobile Functions Nuno O. Duarte Sileshi Demesie Yalew INESC-ID / IST, University of Lisbon KTH Royal Institute of Technology [email protected] [email protected] Nuno Santos Miguel Correia INESC-ID / IST, University of Lisbon INESC-ID / IST, University of Lisbon [email protected] [email protected] ABSTRACT 1 INTRODUCTION The increase of personal data on mobile devices has been fol- For over 30 years [5], an important problem that has fasci- lowed by legislation that forces service providers to process nated the research community is about trusting the result of and maintain users’ data under strict data protection policies. computations performed on untrusted platforms. Since the In this paper, we propose a new primitive for mobile applica- advent of cloud computing, this interest has further grown tions called auditable mobile function (AMF) to help service in obtaining proofs of code execution on untrusted clouds. providers enforcing such policies by enabling them to process An approach to address this problem that has garnered sensitive data within users’ devices and collecting proofs of particular attention is verifiable computing. At a high-level, function execution integrity. We present SafeChecker, a com- verifiable computing consists of studying how a prover can putation verification system that provides mobile application convince a verifier of a mathematical assertion. The main support for AMFs, and evaluate the practicality of different obstacle faced by this field has been practicality, as the costs usage scenario AMFs on TrustZone-enabled hardware. of computing and verifying proofs over general computa- tions tend to be very high [21].
    [Show full text]
  • Zenon Manual Programming Interfaces
    zenon manual Programming interfaces v.7.11 ©2014 Ing. Punzenberger COPA-DATA GmbH All rights reserved. Distribution and/or reproduction of this document or parts thereof in any form are permitted solely with the written permission of the company COPA-DATA. The technical data contained herein has been provided solely for informational purposes and is not legally binding. Subject to change, technical or otherwise. Contents 1. Welcome to COPA-DATA help ...................................................................................................... 6 2. Programming interfaces ............................................................................................................... 6 3. Process Control Engine (PCE) ........................................................................................................ 9 3.1 The PCE Editor ............................................................................................................................................. 9 3.1.1 The Taskmanager ....................................................................................................................... 10 3.1.2 The editing area .......................................................................................................................... 10 3.1.3 The output window .................................................................................................................... 11 3.1.4 The menus of the PCE Editor .....................................................................................................
    [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]
  • Operating System Architectures
    Operating System Architectures • Learning objectives: • Explain how OS functionality is orthogonal to where you place services relative to processor modes. • Describe some alternative ways to structure the operating system. • Operating systems evolve over time, but that evolution is frequently in terms of their architecture: how they structure functionality relative to protection boundaries. • We’ll review some of the basic architectures: • Executives • Monolithic kernels • Micro kernels • Exo kernels • Extensible operating systems 2/3/15 CS161 Spring 2015 1 OS Executives • Think MS-DOS: With no hardware protection, the OS is simply a set of services: • Live in memory • Applications can invoke them • Requires a software trap to invoke them. • Live in same address space as application 1-2-3 QBasic WP Applications Command Software Traps Operating System routlines 2/3/15 CS161 Spring 2015 2 Monolithic Operating System • Traditional architecture • Applications and operating system run in different address spaces. • Operating system runs in privileged mode; applications run in user mode. Applications Operating System file system processes networking Device drivers virtual memory 2/3/15 CS161 Spring 2015 3 Microkernels (late 80’s and on) • Put as little of OS as possible in privileged mode (the microkernel). • Implement most core OS services as user-level servers. • Only microkernel really knows about hardware • File system, device drivers, virtual memory all implemented in unprivileged servers. • Must use IPC (interprocess communication) to communicate among different servers. Applications Process Virtual management memory file system networking Microkernel 2/3/15 CS161 Spring 2015 4 Microkernels: Past and Present • Much research and debate in late 80’s early 90’s • Pioneering effort in Mach (CMU).
    [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]
  • Sel4: Formal Verification of an Operating-System Kernel
    seL4: Formal Verification of an Operating-System Kernel Gerwin Klein1;2, June Andronick1;2, Kevin Elphinstone1;2, Gernot Heiser1;2;3 1 1 1;2 1;2 David Cock , Philip Derrin ∗, Dhammika Elkaduwe ,z Kai Engelhardt 1;2 1;4 1 1;2 1;2 Rafal Kolanski , Michael Norrish , Thomas Sewell , Harvey Tuch y, Simon Winwood 1 NICTA, 2 UNSW, 3 Open Kernel Labs, 4 ANU [email protected] ABSTRACT We report on the formal, machine-checked verification of the seL4 microkernel from an abstract specification down to its C implementation. We assume correctness of compiler, assembly code, hardware, and boot code. seL4 is a third-generation microkernel of L4 provenance, comprising 8,700 lines of C and 600 lines of assembler. Its performance is comparable to other high-performance L4 kernels. We prove that the implementation always strictly follows our high-level abstract specification of kernel behaviour. This encompasses traditional design and implementation safety properties such as that the kernel will never crash, and it will never perform an unsafe operation. It also implies much more: we can predict precisely how the kernel will behave in every possible situation. 1. INTRODUCTION Almost every paper on formal verification starts with the observation that software complexity is increasing, that this Figure 1: Call graph of the seL4 microkernel. Ver- leads to errors, and that this is a problem for mission and tices represent functions, and edges invocations. safety critical software. We agree, as do most. Here, we report on the full formal verification of a critical system from a high-level model down to very low-level C kernel, and every single bug can potentially cause arbitrary code.
    [Show full text]