DOCSLIB.ORG

Arxiv:2005.02605V1 [Cs.CR] 6 May 2020

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Secure System Virtualization: End-to-End Verification of Memory Isolation HAMED NEMATI arXiv:2005.02605v1 [cs.CR] 6 May 2020 Doctoral Thesis Stockholm, Sweden 2017 TRITA-CSC-A-2017:18 KTH Royal Institute of Technology ISSN 1653-5723 School of Computer Science and Communication ISRN-KTH/CSC/A--17/18-SE SE-100 44 Stockholm ISBN 978-91-7729-478-8 SWEDEN Akademisk avhandling som med tillstånd av Kungl Tekniska högskolan framlägges till offentlig granskning för avläggande av teknologie doktorsexamen i datalogi fre- dagen den 20 oktober 2017 klockan 14.00 i Kollegiesalen, Kungl Tekniska högskolan, Brinellvägen 8, Stockholm. © Hamed Nemati, October 2017 Tryck: Universitetsservice US AB iii Abstract Over the last years, security kernels have played a promising role in re- shaping the landscape of platform security on today’s ubiquitous embedded devices. Security kernels, such as separation kernels, enable constructing high-assurance mixed-criticality execution platforms. They reduce the soft- ware portion of the system’s trusted computing base to a thin layer, which enforces isolation between low- and high-criticality components. The reduced trusted computing base minimizes the system attack surface and facilitates the use of formal methods to ensure functional correctness and security of the kernel. In this thesis, we explore various aspects of building a provably secure separation kernel using virtualization technology. In particular, we examine techniques related to the appropriate management of the memory subsystem. Once these techniques were implemented and functionally verified, they pro- vide reliable a foundation for application scenarios that require strong guar- antees of isolation and facilitate formal reasoning about the system’s overall security. We show how the memory management subsystem can be virtualized to enforce isolation of system components. Virtualization is done by using direct paging that enables a guest software under some circumstances to manage its own memory configuration. We demonstrate the soundness of our approach by verifying that the high-level model of the system fulfills the desired security properties. Through refinement, we then propagate these properties (semi-) automatically to the machine-code of the virtualization mechanism. An application of isolating platforms is to provide external protection to an untrusted guest operating system to restrict its attack surface. We show how a runtime monitor can be securely deployed alongside a Linux guest on a hypervisor to prevent code injection attacks targeting Linux. The monitor takes advantage of the provided separation to protect itself and to retain a complete view of the guest software. Separating components using a low-level software, while important, is not by itself enough to guarantee security. Indeed, current processors ar- chitecture involves features, such as caches, that can be utilized to violate the isolation of components. In this thesis, we present a new low noise at- tack vector constructed by measuring cache effects. The vector is capable of breaching isolation between components of different criticality levels, and it invalidates the verification of software that has been verified on a mem- ory coherent (cacheless) model. To restore isolation, we provide a number of countermeasures. Further, we propose a new methodology to repair the verification of the software by including data-caches in the statement of the top-level security properties of the system. Sammanfattning Inbyggda system finns överallt idag. Under senare år har utvecklingen av platformssäkerhet för inbyggda system spelat en allt större roll. Säker- hetskärnor, likt isoleringskärnor, möjliggör konstruktion av tillförlitliga exe- kveringsplatformar ämnade för både kritiska och icke-kritiska tillämpningar. Säkerhetskärnor reducerar systemets kritiska kodmängd i ett litet tunt mjuk- varulager. Detta mjukvarulager upprättar en tillförlitlig isolering mellan olika mjukvarukomponenter, där vissa mjukvarukomponenter har kritiska roller och andra inte. Det tunna mjukvarulagret minimerar systemets attackyta och un- derlättar användningen av formella metoder för att försäkra mjukvarulagrets funktionella korrekthet och säkerhet. I denna uppsats utforskas olika aspekter för att bygga en isoleringskärna med virtualiseringsteknik sådant att det går att bevisa att isoleringskärnan är säker. I huvudsak undersöks tekniker för säker hantering av minnessystemet. Implementering och funktionell verifiering av dessa minneshanteringstekniker ger en tillförlitlig grund för användningsområden med höga krav på isolering och underlättar formell argumentation om att systemet är säkert. Det visas hur minneshanteringssystemet kan virtualiseras i syfte om att isolera systemkomponenter. Virtualiseringstekniken bakom minnessystemet är direkt paging och möjliggör gästmjukvara, under vissa begränsningar, att konfigurera sitt eget minne. Denna metods sundhet demonstreras genom veri- fiering av att högnivåmodellen av systemet satisfierar de önskade säkerhetse- genskaperna. Genom förfining överförs dessa egenskaper (semi-) automatiskt till maskinkoden som utgör virtualiseringsmekanismen. En isolerad gästapplikation ger externt skydd för ett potentiellt angri- pet gästoperativsystem för att begränsa den senares attackyta. Det visas hur en körningstidsövervakare kan köras säkert i systemet ovanpå en hypervi- sor bredvid en Linuxgäst för att förhindra kodinjektionsattacker mot Linux. Övervakaren utnyttjar systemets isoleringsegenskaper för att skydda sig själv och för att ha en korrekt uppfattning av gästmjukvarans status. Isolering av mjukvarukomponenter genom lågnivåmjukvara är inte i sig tillräckligt för att garantera säkerhet. Dagens processorarkitekturer har funk- tioner, som exempelvis cacheminnen, som kan utnyttjas för att kringgå iso- leringen mellan mjukvarukomponenter. I denna uppsats presenteras en ny attack som inte är störningskänslig och som utförs genom att analysera cache- operationer. Denna attack kan kringgå isoleringen mellan olika mjukvarukom- ponenter, där vissa komponenter har kritiska roller och andra inte. Attacken ogiltigförklarar också verifiering av mjukvara om verifieringen antagit en min- neskoherent (cachefri) modell. För att motverka denna attack presenteras ett antal motmedel. Utöver detta föreslås också en ny metodik för att återvalidera mjukvaruverifieringen genom att inkludera data-cacheminnen i formuleringen av systemets säkerhetsegenskaper. v Acknowledgements I would like to express my sincere gratitude and appreciation to my main super- visor, Prof. Mads Dam for his encouragement and support, which brought to the completion of this thesis. Mads’ high standards have significantly enriched my research. I am deeply grateful to my colleagues Roberto Guanciale, Oliver Schwarz (you are one of “the best” ;)), Christoph Baumann, Narges Khakpour, Arash Vahidi, and Viktor Do for their supports, valuable comments, and advices during the entire progress of this thesis. I would also like to thank all people I met at TCS, especially Adam Schill Collberg, Andreas Lindner, Benjamin Greschbach, Cenny Wenner, Cyrille Artho (thanks for reading the thesis draft and providing good suggestions), Daniel Bosk (trevligt att träffas Daniel), Emma Enström, Hojat Khosrowjerdi, Ilario Bonacina, Jan Elffers, Jesús Giráldez Crú, Jonas Haglund (thanks for helping with the ab- stract), Joseph Swernofsky, Linda Kann, Marc Vinyals, Mateus de Oliveira Oliveira, Mika Cohen, Mladen Mikša, Muddassar Azam Sindhu, Musard Balliu, Pedro de Carvalho Gomes, Roelof Pieters (I like you too :)), Sangxia Huang, Susanna Figueiredo de Rezende, Thatchaphol Saranurak, Thomas Tuerk, and Xin Zhao for lunch company and making TCS a great place. I am truly thankful to my dear friends Vahid Mosavat, Mohsen Khosravi, Guillermo Rodríguez Cano, and Ali Jafari, who made my stay in Sweden more pleasant. Last but not the least, huge thanks to my parents, my sister and Razieh for their endless love, moral support and encouragement, without which I would have never been able to complete this important step of my life. Contents Contents vi I Introduction and Summary 1 Abbreviations 3 1 Introduction 5 1.1 Overview . 5 1.2 Thesis Statement . 7 1.3 Thesis Outline . 9 2 Background 11 2.1 Platform Security . 12 2.2 Formal Verification . 24 2.3 Summary . 36 3 Related Work 37 3.1 Verification of Security-Kernels . 37 3.2 Trustworthy Runtime Monitoring . 40 3.3 Attack On Isolation . 41 3.4 Summary . 41 4 Contributions 43 4.1 Summary of Included Papers . 43 4.2 Further Publications . 48 5 Conclusions 49 5.1 Contribution . 49 5.2 Concluding Remarks and Future Work . 50 vi CONTENTS vii II Included Papers 53 A Provably secure memory isolation for Linux on ARM 55 A.1 Introduction . 55 A.2 Related Work . 58 A.3 Verification Approach . 60 A.4 The ARMv7 CPU . 66 A.5 The Memory Virtualization API . 70 A.6 Formalizing the Proof Goals . 77 A.7 TLS Consistency . 83 A.8 Refinement . 87 A.9 Binary Verification . 88 A.10 Implementation . 98 A.11 Evaluation . 102 A.12 Applications . 103 A.13 Concluding Remarks . 107 B Trustworthy Prevention of Code Injection in Linux on Embed- ded Devices 109 B.1 Introduction . 109 B.2 Background . 111 B.3 Design . 116 B.4 Formal Model of MProsper . 118 B.5 Verification Strategy . 121 B.6 Evaluation . 124 B.7 Related Work . 125 B.8 Concluding Remarks . 126 C Cache Storage Channels: Alias-Driven Attacks and Verified Coun- termeasures 129 C.1 Introduction . 129 C.2 Background . 131 C.3 The New Attack Vectors: Cache Storage Channels . 133 C.4 Case Studies
Recommended publications
  • Real-Time, Safe and Certified OS

    Real-Time, Safe and Certified OS

    Real-Time, Safe and Certified OS Roman Kapl <[email protected]> drivers, customer projects, development Tomas Martinec <[email protected]> testing and certification © SYSGO AG · INTERNAL 1 Introduction • PikeOS – real-time, safety certified OS • Desktop and Server vs. • Embedded • Real-Time • Safety-Critical • Certified • Differences • Scheduling • Resource management • Features • Development © SYSGO AG · INTERNAL 2 Certification • Testing • Analysis • Lot of time • Even more paper • Required for safety-critical systems • Trains • Airplanes © SYSGO AG · INTERNAL 3 PikeOS • Embedded, real-time, certified OS • ~150 people (not just engineers) • Rail • Avionics • Space • This presentation is not about PikeOS specifically © SYSGO AG · INTERNAL 4 PikeOS technical • Microkernel • Inspired by L4 • Memory protection (MMU) • More complex than FreeRTOS • Virtualization hypervisor • X86, ARM, SPARC, PowerPC • Eclipse IDE for development © SYSGO AG · INTERNAL 5 Personalities • General • POSIX • Linux • Domain specific • ARINC653 • PikeOS native • Other • Ada, RT JAVA, AUTOSAR, ITRON, RTEMS © SYSGO AG · INTERNAL 6 PikeOS Architecture App. App. App. App. App. App. Volume Syste m Provider Partition PikeOS Para-Virtualized HW Virtualized File System (Native, POSIX, Guest OS PikeOS Native ARINC653, ...) Guest OS Linux, Android Linux, Android Device Driver User Space / Partitions Syste m PikeOS System Software ExtensionSyste m Extension PikeOS Microkernel Kernel Space / Hypervisor Architecture Platform Kernel Level Support Package Support Package Driver SoC /
  • Effective Virtual CPU Configuration with QEMU and Libvirt

    Effective Virtual CPU Configuration with QEMU and Libvirt

    Effective Virtual CPU Configuration with QEMU and libvirt Kashyap Chamarthy <[email protected]> Open Source Summit Edinburgh, 2018 1 / 38 Timeline of recent CPU flaws, 2018 (a) Jan 03 • Spectre v1: Bounds Check Bypass Jan 03 • Spectre v2: Branch Target Injection Jan 03 • Meltdown: Rogue Data Cache Load May 21 • Spectre-NG: Speculative Store Bypass Jun 21 • TLBleed: Side-channel attack over shared TLBs 2 / 38 Timeline of recent CPU flaws, 2018 (b) Jun 29 • NetSpectre: Side-channel attack over local network Jul 10 • Spectre-NG: Bounds Check Bypass Store Aug 14 • L1TF: "L1 Terminal Fault" ... • ? 3 / 38 Related talks in the ‘References’ section Out of scope: Internals of various side-channel attacks How to exploit Meltdown & Spectre variants Details of performance implications What this talk is not about 4 / 38 Related talks in the ‘References’ section What this talk is not about Out of scope: Internals of various side-channel attacks How to exploit Meltdown & Spectre variants Details of performance implications 4 / 38 What this talk is not about Out of scope: Internals of various side-channel attacks How to exploit Meltdown & Spectre variants Details of performance implications Related talks in the ‘References’ section 4 / 38 OpenStack, et al. libguestfs Virt Driver (guestfish) libvirtd QMP QMP QEMU QEMU VM1 VM2 Custom Disk1 Disk2 Appliance ioctl() KVM-based virtualization components Linux with KVM 5 / 38 OpenStack, et al. libguestfs Virt Driver (guestfish) libvirtd QMP QMP Custom Appliance KVM-based virtualization components QEMU QEMU VM1 VM2 Disk1 Disk2 ioctl() Linux with KVM 5 / 38 OpenStack, et al. libguestfs Virt Driver (guestfish) Custom Appliance KVM-based virtualization components libvirtd QMP QMP QEMU QEMU VM1 VM2 Disk1 Disk2 ioctl() Linux with KVM 5 / 38 libguestfs (guestfish) Custom Appliance KVM-based virtualization components OpenStack, et al.
  • Address Space Layout Permutation (ASLP): Towards Fine-Grained Randomization of Commodity Software

    Address Space Layout Permutation (ASLP): Towards Fine-Grained Randomization of Commodity Software

    Address Space Layout Permutation (ASLP): Towards Fine-Grained Randomization of Commodity Software Chongkyung Kil,∗ Jinsuk Jun,∗ Christopher Bookholt,∗ Jun Xu,† Peng Ning∗ Department of Computer Science∗ Google, Inc.† North Carolina State University {ckil, jjun2, cgbookho, pning}@ncsu.edu [email protected] Abstract a memory corruption attack), an attacker attempts to alter program memory with the goal of causing that program to Address space randomization is an emerging and behave in a malicious way. The result of a successful at- promising method for stopping a broad range of memory tack ranges from system instability to execution of arbitrary corruption attacks. By randomly shifting critical memory code. A quick survey of US-CERT Cyber Security Alerts regions at process initialization time, address space ran- between mid-2005 and 2004 shows that at least 56% of the domization converts an otherwise successful malicious at- attacks have a memory corruption component [24]. tack into a benign process crash. However, existing ap- Memory corruption vulnerabilities are typically caused proaches either introduce insufficient randomness, or re- by the lack of input validation in the C programming lan- quire source code modification. While insufficient random- guage, with which the programmers are offered the free- ness allows successful brute-force attacks, as shown in re- dom to decide when and how to handle inputs. This flex- cent studies, the required source code modification prevents ibility often results in improved application performance. this effective method from being used for commodity soft- However, the number of vulnerabilities caused by failures ware, which is the major source of exploited vulnerabilities of input validation indicates that programming errors of this on the Internet.
  • Sistemi Operativi Real-Time Marco Cesati Lezione R13 Sistemi Operativi Real-Time – II Schema Della Lezione

    Sistemi Operativi Real-Time Marco Cesati Lezione R13 Sistemi Operativi Real-Time – II Schema Della Lezione

    Sistemi operativi real-time Marco Cesati Lezione R13 Sistemi operativi real-time – II Schema della lezione Caratteristiche comuni VxWorks LynxOS Sistemi embedded e real-time QNX eCos Windows Linux come RTOS 15 gennaio 2013 Marco Cesati Dipartimento di Ingegneria Civile e Ingegneria Informatica Università degli Studi di Roma Tor Vergata SERT’13 R13.1 Sistemi operativi Di cosa parliamo in questa lezione? real-time Marco Cesati In questa lezione descriviamo brevemente alcuni dei più diffusi sistemi operativi real-time Schema della lezione Caratteristiche comuni VxWorks LynxOS 1 Caratteristiche comuni degli RTOS QNX 2 VxWorks eCos 3 LynxOS Windows Linux come RTOS 4 QNX Neutrino 5 eCos 6 Windows Embedded CE 7 Linux come RTOS SERT’13 R13.2 Sistemi operativi Caratteristiche comuni dei principali RTOS real-time Marco Cesati Corrispondenza agli standard: generalmente le API sono proprietarie, ma gli RTOS offrono anche compatibilità (compliancy) o conformità (conformancy) allo standard Real-Time POSIX Modularità e Scalabilità: il kernel ha una dimensione Schema della lezione Caratteristiche comuni (footprint) ridotta e le sue funzionalità sono configurabili VxWorks Dimensione del codice: spesso basati su microkernel LynxOS QNX Velocità e Efficienza: basso overhead per cambi di eCos contesto, latenza delle interruzioni e primitive di Windows sincronizzazione Linux come RTOS Porzioni di codice non interrompibile: generalmente molto corte e di durata predicibile Gestione delle interruzioni “separata”: interrupt handler corto e predicibile, ISR lunga
  • Security Enhancements in Red Hat Enterprise Linux (Beside Selinux)

    Security Enhancements in Red Hat Enterprise Linux (Beside Selinux)

    Security Enhancements in Red Hat Enterprise Linux (beside SELinux) Ulrich Drepper Red Hat, Inc. [email protected] December 9, 2005 Abstract Bugs in programs are unavoidable. Programs developed using C and C++ are especially in danger. If bugs cannot be avoided the next best thing is to limit the damage. This article will show improvements in Red Hat Enterprise Linux which achieve just that. 1 Introduction These problems are harder to protect against since nor- mally2 all of the OS’s functionality is available and the Security problems are one of the biggest concerns in the attacker might even be able to use self-compiled code. industry today. Providing services on networked comput- ers which are accessible through the intranet and/or Inter- Remotely exploitable problems are more serious since net potentially to untrusted individuals puts the installa- the attacker can be anywhere if the machine is available tion at risk. A number of changes have been made to the through the Internet. On the plus side, only applications Linux OS1 which help a lot to mitigate the risks. Up- accessible through the network services provided by the coming Red Hat Enterprise Linux versions will feature machine can be exploited, which limits the range of ex- the SELinux extensions, originally developed by the Na- ploits. Further limitations are the attack vectors. Usually tional Security Agency (NSA), with whom Red Hat now remote attackers can influence applications only by pro- collaborates to productize the developed code. SELinux viding specially designed input. This often means cre- means a major change in Linux and is a completely sep- ating buffer overflows, i.e., situations where the data is arate topic by itself.
  • Quantifying Security Impact of Operating-System Design

    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
  • Understanding Full Virtualization, Paravirtualization, and Hardware Assist

    Understanding Full Virtualization, Paravirtualization, and Hardware Assist

    VMware Understanding Full Virtualization, Paravirtualization, and Hardware Assist Contents Introduction .................................................................................................................1 Overview of x86 Virtualization..................................................................................2 CPU Virtualization .......................................................................................................3 The Challenges of x86 Hardware Virtualization ...........................................................................................................3 Technique 1 - Full Virtualization using Binary Translation......................................................................................4 Technique 2 - OS Assisted Virtualization or Paravirtualization.............................................................................5 Technique 3 - Hardware Assisted Virtualization ..........................................................................................................6 Memory Virtualization................................................................................................6 Device and I/O Virtualization.....................................................................................7 Summarizing the Current State of x86 Virtualization Techniques......................8 Full Virtualization with Binary Translation is the Most Established Technology Today..........................8 Hardware Assist is the Future of Virtualization, but the Real Gains Have
  • Introduction to Virtualization

    Introduction to Virtualization

    z Systems Introduction to Virtualization SHARE Orlando Linux and VM Program Romney White, IBM [email protected] z Systems Architecture and Technology © 2015 IBM Corporation Agenda ° Introduction to Virtualization – Concept – Server Virtualization Approaches – Hypervisor Implementation Methods – Why Virtualization Matters ° Virtualization on z Systems – Logical Partitions – Virtual Machines 2 z Systems Virtualization Technology © 2015 IBM Corporation Virtualization Concept Virtual Resources Proxies for real resources: same interfaces/functions, different attributes May be part of a physical resource or multiple physical resources Virtualization Creates virtual resources and "maps" them to real resources Primarily accomplished with software or firmware Resources Components with architecturally-defined interfaces/functions May be centralized or distributed - usually physical Examples: memory, disk drives, networks, servers Separates presentation of resources to users from actual resources Aggregates pools of resources for allocation to users as virtual resources 3 z Systems Virtualization Technology © 2015 IBM Corporation Server Virtualization Approaches Hardware Partitioning Bare-metal Hypervisor Hosted Hypervisor Apps ... Apps Apps ... Apps Apps ... Apps OS OS OS OS OS OS Adjustable partitions Hypervisor Hypervisor Partition Controller Host OS SMP Server SMP Server SMP Server Server is subdivided into fractions Hypervisor provides fine-grained Hypervisor uses OS services to each of which can run an OS timesharing of all resources
  • Improving the Reliability of Commodity Operating Systems

    Improving the Reliability of Commodity Operating Systems

    Improving the Reliability of Commodity Operating Systems MICHAEL M. SWIFT, BRIAN N. BERSHAD, and HENRY M. LEVY University of Washington Despite decades of research in extensible operating system technology, extensions such as device drivers remain a significant cause of system failures. In Windows XP, for example, drivers account for 85% of recently reported failures. This paper describes Nooks, a reliability subsystem that seeks to greatly enhance OS reliability by isolating the OS from driver failures. The Nooks approach is practical: rather than guaranteeing complete fault tolerance through a new (and incompatible) OS or driver architecture, our goal is to prevent the vast majority of driver-caused crashes with little or no change to existing driver and system code. Nooks isolates drivers within lightweight protection domains inside the kernel address space, where hardware and software prevent them from corrupting the kernel. Nooks also tracks a driver’s use of kernel resources to facilitate automatic clean-up during recovery. To prove the viability of our approach, we implemented Nooks in the Linux operating system and used it to fault-isolate several device drivers. Our results show that Nooks offers a substantial increase in the reliability of operating systems, catching and quickly recovering from many faults that would otherwise crash the system. Under a wide range and number of fault conditions, we show that Nooks recovers automatically from 99% of the faults that otherwise cause Linux to crash. While Nooks was designed for drivers, our techniques generalize to other kernel extensions. We demonstrate this by isolating a kernel-mode file system and an in-kernel Internet service.
  • Qualys Policy Compliance Getting Started Guide

    Qualys Policy Compliance Getting Started Guide

    Policy Compliance Getting Started Guide July 28, 2021 Verity Confidential Copyright 2011-2021 by Qualys, Inc. All Rights Reserved. Qualys and the Qualys logo are registered trademarks of Qualys, Inc. All other trademarks are the property of their respective owners. Qualys, Inc. 919 E Hillsdale Blvd Foster City, CA 94404 1 (650) 801 6100 Table of Contents Get Started ........................................................................................................ 5 Set Up Assets............................................................................................................................ 6 Start Collecting Compliance Data ............................................................... 8 Configure Authentication....................................................................................................... 8 Launch Compliance Scans ................................................................................................... 10 We recommend you schedule scans to run automatically .............................................. 12 How to configure scan settings............................................................................................ 12 Install Cloud Agents.............................................................................................................. 17 Evaluate Middleware Assets by Using Cloud Agent .......................................................... 17 Define Policies ................................................................................................. 21
  • The OKL4 Microvisor: Convergence Point of Microkernels and Hypervisors

    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.
  • Formal Modelling of Separation Kernels

    Formal Modelling of Separation Kernels

    The University of York Department of Computer Science Submitted in part fulfilment for the degree of MSc in Software Engineering. Formal Modelling of Separation Kernels Andrius Velykis 18th September 20091 Supervised by Dr Leo Freitas Number of words = 45327, as counted by detex <report.tex> j wc -w. This report consists of 98 pages in total. This includes the body of the report (without blank pages) and Appendix A, but not Appendices B, C, D, E and F. 1Updated transactional operation proofs, 21st September 2009. Abstract A separation kernel is an architecture for secure applications, which benefits from inherent security of distributed systems. Due to its small size and usage in high-integrity environments, it makes a good target for formal modelling and verification. This project presents results from mechanisation and modelling of separation kernel components: a process table, a process queue and a scheduler. The results have been developed as a part of the pilot project within the international Grand Challenge in Verified Software. This thesis covers full development life-cycle from project initiation through design and evaluation to successful completion. Important findings about kernel properties, formal modelling and design decisions are discussed. The developed formal specification is fully verified and contributes to the pilot project aim of creating a formal kernel model and refining it down to implementation code. Other reusable artefacts, such as general lemmas and a new technique of ensuring transactional properties of operations are defined. The results will be curated within the Verified Software Repository. i Robertai. Aˇci¯u. Acknowledgements I would like to thank Dr Leo Freitas for his supervision, encouragement and getting me hooked on formal methods.