DOCSLIB.ORG

Sel4: Verified Operating System for the Real World

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

seL4: Verified Operating System for the Real World Gernot Heiser [email protected] @GernotHeiser Born August 2009 1 seL4 – CODE Workshop – Munich – Nov'20 © Gernot Heiser 2020 What is seL4? seL4 is an open source, high-assurance, high-performance operating system microkernel World’s most comprehensive Available on GitHub World’s fastest Piece of software that mathematical proofs of under GPLv2 license microkernel runs at the heart of any correctness and security system and controls all accesses to resources software attack critical non-critical, untrusted s hardware 2 seL4 – CODE Workshop – Munich – Nov'20 © Gernot Heiser 2020 What is seL4? seL4 is the most trustworthy foundation for safety- and security-critical systems Already in use across many domains: automotive, aviation, space, defence, critical infrastructure, cyber-physical systems, IoT, industry 4.0, certified security... 3 seL4 – CODE Workshop – Munich – Nov'20 © Gernot Heiser 2020 The Performance Benchmark Latency (in cycles) of a round-trip cross-address-space IPC on x64 Source seL4 Fisco.OC Zircon Mi et al, 2019 986 2717 8157 World’s fastest microkernel! Gu et al, 2020 1450 3057 8151 seL4.systems, Nov’20 797 N/A N/A Temporary performance regression in Dec’19 Sources: • Zeyu Mi, Dingji Li, Zihan Yang, Xinran Wang, Haibo Chen: “SkyBridge: Fast and Secure Inter-Process Communication for Microkernels”, EuroSys, April 2020 • Jinyu Gu, Xinyue Wu, Wentai Li, Nian Liu, Zeyu Mi, Yubin Xia, Haibo Chen: “Harmonizing Performance and Isolation in Microkernels with Efficient Intra-kernel Isolation and Communication”, Usenix ATC, June 2020 • seL4 Performance, https://sel4.systems/About/Performance/, accessed 2020-11-08 4 seL4 – CODE Workshop – Munich – Nov'20 © Gernot Heiser 2020 Proofs • Interactive theorem proving Confidentiality Integrity Availability • Shows kernel can guarantee Proof Security security properties Proof Proof Enforcement Abstract Model Functional • Interactive theorem proving Proof Correctness Still only capaBility-based • Shows C code correctly OS kernel with functional C Imple- implements specification correctness proof mentation Translation Proof Correctness Binary code • Automated tool chain • Shows binary is correct translation of C 5 seL4 – CODE Workshop – Munich – Nov'20 © Gernot Heiser 2020 Functional Correctness Summary Can prove further Kinds of properties proved properties on • Behaviour of C code is fully captured by abstract model abstract level! • Behaviour of C code is fully captured by executable model • Kernel never fails, behaviour is always well-defined Bugs found: • assertions never fail • 16 in (shallow) testing • will never de-reference null pointer • 460 in verification • will never access array out of bounds • 160 in C, • cannot be subverted by misformed input • 150 in design, • All syscalls terminate, reclaiming memory is safe, ... • 150 in spec • Well typed references, aligned objects, kernel always mapped… • Access control is decidable 6 seL4 – CODE Workshop – Munich – Nov'20 © Gernot Heiser 2020 Verification Assumptions Confidentiality Integrity Availability Proof Proof 1. Hardware behaves as expected Proof Abstract Model • Formalised hardware-software contract (ISA) • Hardware implementation free of bugs, Trojans, … Proof C Implementation 2. Spec matches expectations Proof • Can only prove “security” if specify what “security” means Binary code • Spec may not be what we think it is 3. Proof checker is correct • Isabel/HOL checking core that validates proofs against logic With binary verification do not need to trust C compiler! 7 seL4 – CODE Workshop – Munich – Nov'20 © Gernot Heiser 2020 Verification Cost in Context $400 Green Hills INTEGRITY $1000 Fast! Slow! Assurance L4 Pistachio $100–150 100 250 500 750 1000 Cost ($/SLOC) 8 seL4 – CODE Workshop – Munich – Nov'20 © Gernot Heiser 2020 Real-World Use 9 seL4 – CODE Workshop – Munich – Nov'20 © Gernot Heiser 2020 DARPA HACMS Retrofit Autonomous trucks existing system! Unmanned Little Bird (ULB) Develop Off-the-shelf technology GVR-Bot Drone airframe 10 | seL4 – CODE Workshop – Munich – Nov'20 © Gernot Heiser 2020 ULB Architecture Ground Mission GPS Station Link Computer Camera Network Flight Sensors Motors Computer 11 | seL4 – CODE Workshop – Munich – Nov'20 © Gernot Heiser 2020 Incremental Cyber Retrofit Original Trusted Mission Trusted GS Lk Computer Mission Manager Miss Trusted Crypto Camera Mgr Mission Manager Local NW GPS Crypto Cam- era Crypto Camera Ground Stn Link GPS Local NW GPS Linux Linux Linux Local Ground Stn Link Virt-Mach Monitor NW VMM VMM Linux 12 | seL4 – CODE Workshop – Munich – Nov'20 © Gernot Heiser 2020 Incremental Cyber Retrofit Original Mission Trusted GS Lk Computer Miss Trusted Mgr Mission Manager Crypto Cam- Cam- era era Crypto Camera GPS Trusted Linux Crypto Mission Linux Local NW GPS Linux Mngr Local Local Ground Stn Link NW VMM VMM NW Comms GPS VMM Linux 13 | seL4 – CODE Workshop – Munich – Nov'20 © Gernot Heiser 2020 Incremental Cyber Retrofit Original [Klein et al, CACM, Oct’18] Mission Computer Cyber-secure Mission Trusted Computer Mission Manager Cam- era Crypto Camera Trusted Crypto Mission Linux Local NW GPS Mngr Local Ground Stn Link NW Comms GPS VMM Linux 14 | seL4 – CODE Workshop – Munich – Nov'20 © Gernot Heiser 2020 Issue: seL4 Objects are Low-Level A A BB Thread-Object CSpace CSpace VSpace A Thread-ObjectB CNode EP A1 CNodeB1 PDA PTA1 FRAME CNodeA2 Send ... CONTEXT CONTEXT Send ... Receive ... FRAME ... ... ... Receive VSpace >50 capabilities for trivial program! 15 | seL4 – CODE Workshop – Munich – Nov'20 © Gernot Heiser 2020 Simple But Non-Trivial System 16 | seL4 – CODE Workshop – Munich – Nov'20 © Gernot Heiser 2020 Component Middleware: CAmkES Higher-level abstractions of low-level seL4 constructs Interface Comp A Comp B RPC Component Connector Shared memory Semaphore Comp C 17 | seL4 – CODE Workshop – Munich – Nov'20 © Gernot Heiser 2020 HACMS UAV Architecture Security enforcement: Linux only sees encrypted data Radio Driver Data Link Uncritical/ untrusted, contained Wifi Crypto Camera Linux CAN Driver 18 | seL4 – CODE Workshop – Munich – Nov'20 © Gernot Heiser 2020 Enforcing the Architecture Radio Driver Data Link Uncritical/ CAmkES untrusted, Wifi contained Architecture Crypto component + Camera A B code specification CAN Driver Linux language LowcapDL-level access rights A B + proof glue Thread CSpace CSpace Thread code Object Object glue.c driver.c VMM.c CNode EP CNode + proof Send CONTEXT CONTEXT ... Receive ... VSpace VSpace Compiler/ Conditions Linker apply initialised systeminit.c+ proof binary 19 | seL4 – CODE Workshop – Munich – Nov'20 © Gernot Heiser 2020 Military-Grade Security Cross-Domain Desktop Compositor Multi-level secure terminal • Successful trials in AU, US, UK, CA • Commercialisation in progress Secure communication device in use in AU, UK defence forces 20 | seL4 – CODE Workshop – Munich – Nov'20 © Gernot Heiser 2020 Real-World Use Courtesy Boeing, DARPA 21 seL4 – CODE Workshop – Munich – Nov'20 © Gernot Heiser 2020.
Recommended publications
  • 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
  • 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.
  • Microkernel Vs

    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.
  • Operating Systems & Virtualisation Security Knowledge Area

    Operating Systems & Virtualisation Security Knowledge Area

    Operating Systems & Virtualisation Security Knowledge Area Issue 1.0 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 The Cyber Security Body Of Knowledge www.cybok.org COPYRIGHT © Crown Copyright, The National Cyber Security Centre 2019. This information is licensed under the Open Government Licence v3.0. To view this licence, visit: http://www.nationalarchives.gov.uk/doc/open-government-licence/ When you use this information under the Open Government Licence, you should include the following attribution: CyBOK © Crown Copyright, The National Cyber Security Centre 2018, li- censed under the Open Government Licence: http://www.nationalarchives.gov.uk/doc/open- government-licence/. The CyBOK project would like to understand how the CyBOK is being used and its uptake. The project would like organisations using, or intending to use, CyBOK for the purposes of education, training, course development, professional development etc. to contact it at con- [email protected] to let the project know how they are using CyBOK. Issue 1.0 is a stable public release of the Operating Systems & Virtualisation Security Knowl- edge Area. However, it should be noted that a fully-collated CyBOK document which includes all of the 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 KA Operating Systems & Virtualisation Security j October 2019 Page 1 The Cyber Security Body Of Knowledge www.cybok.org INTRODUCTION In this Knowledge Area, we introduce the principles, primitives and practices for ensuring se- curity at the operating system and hypervisor levels.
  • Login Dec 07 Volume 33

    Login Dec 07 Volume 33

    COMPUTER SECURITY IS AN OLD problem which has lost none of its rele - GERNOT HEISER vance—as is evidenced by the annual Secu - rity issue of ;login: . The systems research community has increased its attention to security issues in recent years, as can be Your system is seen by an increasing number of security- related papers published in the mainstream secure? Prove it! systems conferences SOSP, OSDI, and Gernot Heiser is professor of operating systems at USENIX. However, the focus is primarily on the University of New South Wales (UNSW) in Sydney and leads the embedded operating-systems group at desktop and server systems. NICTA, Australia’s Centre of Excellence for research in information and communication technology. In 2006 he co-founded the startup company Open Kernel I argued two years ago in this place that security of Labs (OK), which is developing and marketing operat - embedded systems, whether mobile phones, smart ing-system and virtualization technology for embed - ded systems, based on the L4 microkernel. cards, or automobiles, is a looming problem of even bigger proportions, yet there does not seem to [email protected] be a great sense of urgency about it. Although there are embedded operating-system (OS) vendors NICTA is funded by the Australian government’s Backing Australia’s Ability initiative, in part working on certifying their offerings to some of the through the Australian Research Council. highest security standards, those systems do not seem to be aimed at, or even suitable for, mobile wireless devices. Establishing OS Security The accepted way to establish system security is through a process called assurance .
  • Hype and Virtue

    Hype and Virtue

    Hype and Virtue Timothy Roscoe∗ Kevin Elphinstone† Gernot Heiser†‡ National ICT Australia Abstract a source of a new class of problem. We lay out some of these directions towards the end of this paper. In this paper, we question whether hypervisors are really A challenge with any technological development which acting as a disruptive force in OS research, instead argu- creates intense interest simultaneously in both academia ing that they have so far changed very little at a techni- and venture capital circles is separating the long-term sci- cal level. Essentially, we have retained the conventional entific and engineering questions traditionally relegated to Unix-like OS interface and added a new ABI based on PC academic research from the short-term issues closely tied hardware which is highly unsuitable for most purposes. to particular business models, contexts, and in some cases Despite commercial excitement, focus on hypervisor de- individual companies. sign may be leading OS research astray. However, adopt- This is an unashamedly academic paper, deliberately ing a different approach to virtualization and recognizing bracketing short-term commercial pressures to concen- its value to academic research holds the prospect of open- trate instead on longer-term research questions in OS de- ing up kernel research to new directions. sign. We do not wish to devalue short-term research strongly embedded in current products and markets, but we emphasize that it is not our concern here. 1 Introduction In the next section we compare hypervisors to other kernels from a long-term research perspective (rather than Are hypervisors really a disruptive technology? Both the focusing on their short-term applications) and in Section 3 IT industry and the academic OS research community critique the new system interface offered by hypervisors.
  • Flexible Task Management for Self-Adaptation of Mixed-Criticality Systems with an Automotive Example

    Flexible Task Management for Self-Adaptation of Mixed-Criticality Systems with an Automotive Example

    Fakultat¨ fur¨ Informatik Fachgebiet Vernetzte Rechensysteme Technische Universitat¨ Munchen¨ Flexible Task Management for Self-Adaptation of Mixed-Criticality Systems with an Automotive Example Daniel Andreas Krefft Vollst¨andigerAbdruck der von der Fakult¨atf¨urInformatik der Technischen Universit¨at M¨unchen zur Erlangung des akademischen Grades eines Doktors der Naturwissenschaften (Dr.rer.nat.) genehmigten Dissertation. Vorsitzende: Prof. Dr. Claudia Eckert Pr¨ufendeder Dissertation: Prof. Dr. Uwe Baumgarten Prof. Dr.-Ing. Andreas Herkersdorf Die Dissertation wurde am 22.08.2018 bei der Technischen Universit¨atM¨unchen eingereicht und durch die Fakult¨atf¨urInformatik am 11.12.2018 angenommen. Abstract With regard to future connected cars, there are two trends leading to consolidated hard- ware devices as well as an increasing software complexity within a car. In consequence, a rising number of software needs to use the provided resources of a few high-performance hardware devices. For an efficient resource usage, a flexible software management sup- porting the (self-)adaptation of a software system is getting more and more important - even within a car. This flexible software management therefore needs to consider the criticality and real-time properties of an application within this context. Corresponding to the hardware consolidation, the management approach should be combined with the actual application on one hardware device. With a recent advance of multi-core embed- ded systems, there exists a potential hardware platform which is able to support this combination in an embedded context. Especially, the usage of a flexible management supporting the self-adaptation of a mixed-criticality software system on an embedded hardware device during run-time is of interest.
  • From L3 to Sel4: What Have We Learnt in 20 Years of L4 Microkernels? Kevin Elphinstone, Gernot Heiser NICTA and University of New South Wales

    From L3 to Sel4: What Have We Learnt in 20 Years of L4 Microkernels? Kevin Elphinstone, Gernot Heiser NICTA and University of New South Wales

    From L3 to seL4: What Have We Learnt in 20 Years of L4 Microkernels? Kevin Elphinstone, Gernot Heiser NICTA and University of New South Wales SOSP'13 1993 Improving IPC by Kernel Design [SOSP] ©2013 Gernot Heiser, NICTA 2 SOSP'13 1993 IPC Performance [µs] 400 Mach i486 @ 50 MHz 300 200 115 µs Culprit: Cache L4 footprint 100 [SOSP’95] 5 µs raw copy 0 0 2000 4000 6000 Message Length [B] ©2013 Gernot Heiser, NICTA 3 SOSP'13 IPC Performance over 20 Years Name Year Processor MHz Cycles µs Original 1993 i486 50 250 5.00 Original 1997 Pentium 160 121 0.75 L4/MIPS 1997 R4700 100 86 0.86 L4/Alpha 1997 21064 433 45 0.10 Hazelnut 2002 Pentium 4 1,400 2,000 1.38 Pistachio 2005 Itanium 1,500 36 0.02 OKL4 2007 XScale 255 400 151 0.64 NOVA 2010 i7 Bloomfield (32-bit) 2,660 288 0.11 seL4 2013 i7 Haswell (32-bit) 3,400 301 0.09 seL4 2013 ARM11 532 188 0.35 seL4 2013 Cortex A9 1,000 316 0.32 ©2013 Gernot Heiser, NICTA 4 SOSP'13 Core Microkernel Principle: Minimality A concept is tolerated inside the microkernel only if moving it outside the kernel, i.e. permitting competing implementations, would prevent the implementation of the system’s required functionality. [SOSP’95] ©2013 Gernot Heiser, NICTA 5 SOSP'13 Minimality: Source Code Size Name Architecture C/C++ asm total kSLOC Original i486 0 6.4 6.4 L4/Alpha Alpha 0 14.2 14.2 L4/MIPS MIPS64 6.0 4.5 10.5 Hazelnut x86 10.0 0.8 10.8 Pistachio x86 22.4 1.4 23.0 L4-embedded ARMv5 7.6 1.4 9.0 OKL4 3.0 ARMv6 15.0 0.0 15.0 Fiasco.OC x86 36.2 1.1 37.6 seL4 ARMv6 9.7 0.5 10.2 ©2013 Gernot Heiser, NICTA 6 SOSP'13 L4 Family Tree API Inheritance Code Inheritance L4-embed.
  • Faults in Linux: Ten Years Later a Case for Reproducible Scientific Results

    Faults in Linux: Ten Years Later a Case for Reproducible Scientific Results

    A history lesson Fault Types Analysis Results Bibliography Faults in Linux: Ten years later A case for reproducible scientific results Nicolas Palix et. al ASPLOS 2011 But it's now been 10 years. Have things changed? A history lesson Fault Types Analysis Results Bibliography The story begins in 2001... Chou et al.: An empirical study of operating system bugs [CYC+01] Static analysis of bug evolution in Linux versions 1.0 - 2.4.1 Often condensed to the most important finding: \Drivers are the one major source of bugs in operating systems", which becomes the scientific fundament for a huge body of OS research: Mike Swift: Nooks [SABL06], Microdrivers [GRB+08], Carbon [KRS09] Tanenbaum: Minix 3 [HBG+06] UNSW: Dingo [RCKH09] + Termite [RCK+09] Gun Sirer: Reference Validation [WRW+08] TUD, UNSW and more: user-level drivers [LCFD+05], DDE UKA: DD/OS [LUSG04] Microsoft: Singularity + Signed Drivers [LH10] A history lesson Fault Types Analysis Results Bibliography The story begins in 2001... Chou et al.: An empirical study of operating system bugs [CYC+01] Static analysis of bug evolution in Linux versions 1.0 - 2.4.1 Often condensed to the most important finding: \Drivers are the one major source of bugs in operating systems", which becomes the scientific fundament for a huge body of OS research: Mike Swift: Nooks [SABL06], Microdrivers [GRB+08], Carbon [KRS09] Tanenbaum: Minix 3 [HBG+06] UNSW: Dingo [RCKH09] + Termite [RCK+09] Gun Sirer: Reference Validation [WRW+08] TUD, UNSW and more: user-level drivers [LCFD+05], DDE UKA: DD/OS [LUSG04] Microsoft: Singularity + Signed Drivers [LH10] But it's now been 10 years.
  • An Overview of Minix 3

    An Overview of Minix 3

    AN OVERVIEW OF MINIX 3 NICTA seminar, 20 Oct. 2008 Sydney, Australia Jorrit N. Herder Vrije Universiteit Amsterdam “Overview of MINIX 3” J.N. Herder <[email protected]> “There are no significant bugs in our released software that any significant number of users want fixed.” -- Bill Gates, 1995 “Overview of MINIX 3” J.N. Herder <[email protected]> ~26% of Windows XP crashes “Overview of MINIX 3” J.N. Herder <[email protected]> Talk outline ● Background and motivation ● MINIX 3 isolation architecture ● MINIX 3 self-repairing properties ● Experimental evaluation ● Discussion and conclusions “Overview of MINIX 3” J.N. Herder <[email protected]> Talk outline ● Background and motivation ● MINIX 3 isolation architecture ● MINIX 3 self-repairing properties ● Experimental evaluation ● Discussion and conclusions “Overview of MINIX 3” J.N. Herder <[email protected]> Even if OS were correct ... ● Plug-ins extend OS base functionality provided by untrusted third parties comprise up to 70% of entire OS 3-7x more bugs than other OS code ● Still, extensions run in kernel all powers of the system no proper fault isolation “Overview of MINIX 3” J.N. Herder <[email protected]> Bug fixing is infeasible ● Software is buggy by nature survey across languages found 1-6 bugs/KLoc e.g. FreeBSD: 3.35 post-release bugs/KLoC ● Continuously changing configurations e.g. 88 new Windows drivers/day in 2004 ● Code maintainability very hard changing kernel interfaces unwieldy growth of kernel code base “Overview of MINIX 3” J.N. Herder <[email protected]> Linux 2.6 kernel analysis ● Sustained growth of ~5% every 6 months 5,000 4,500 4,000 3,500 3,000 other 2,500 fs 2,000 KLoC net 1,500 drivers 1,000 arch 500 0 Dec Jun Dec Jul Jan Jul Jan Jul Jan 03 04 04 05 06 06 07 07 08 Release Date “Overview of MINIX 3” J.N.
  • A Secure Computing Platform for Building Automation Using Microkernel-Based Operating Systems Xiaolong Wang University of South Florida, Xiaolongw@Mail.Usf.Edu

    A Secure Computing Platform for Building Automation Using Microkernel-Based Operating Systems Xiaolong Wang University of South Florida, [email protected]

    University of South Florida Scholar Commons Graduate Theses and Dissertations Graduate School November 2018 A Secure Computing Platform for Building Automation Using Microkernel-based Operating Systems Xiaolong Wang University of South Florida, [email protected] Follow this and additional works at: https://scholarcommons.usf.edu/etd Part of the Computer Sciences Commons Scholar Commons Citation Wang, Xiaolong, "A Secure Computing Platform for Building Automation Using Microkernel-based Operating Systems" (2018). Graduate Theses and Dissertations. https://scholarcommons.usf.edu/etd/7589 This Dissertation is brought to you for free and open access by the Graduate School at Scholar Commons. It has been accepted for inclusion in Graduate Theses and Dissertations by an authorized administrator of Scholar Commons. For more information, please contact [email protected]. A Secure Computing Platform for Building Automation Using Microkernel-based Operating Systems by Xiaolong Wang A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Computer Science and Engineering Department of Computer Science and Engineering College of Engineering University of South Florida Major Professor: Xinming Ou, Ph.D. Jarred Ligatti, Ph.D. Srinivas Katkoori, Ph.D. Nasir Ghani, Ph.D. Siva Raj Rajagopalan, Ph.D. Date of Approval: October 26, 2018 Keywords: System Security, Embedded System, Internet of Things, Cyber-Physical Systems Copyright © 2018, Xiaolong Wang DEDICATION In loving memory of my father, to my beloved, Blanka, and my family. Thank you for your love and support. ACKNOWLEDGMENTS First and foremost, I would like to thank my advisor, Dr. Xinming Ou for his guidance, encouragement, and unreserved support throughout my PhD journey.
  • Systematic Setup of Compartmentalised Systems on the Sel4 Microkernel

    Systematic Setup of Compartmentalised Systems on the Sel4 Microkernel

    Diplomarbeit Systematic setup of compartmentalised systems on the seL4 microkernel Lukas Hänel February 26, 2010 Technische Universität Dresden Fakultät Informatik Institut für Systemarchitektur Professur Betriebssysteme Betreuender Hochschullehrer: Prof. Dr. rer. nat. Hermann Härtig Betreuender Mitarbeiter: Dr. Kevin Elphinstone Erklärung Hiermit erkläre ich, dass ich diese Arbeit selbstständig erstellt und keine anderen als die angegebenen Hilfsmittel benutzt habe. Dresden, den February 26, 2010 Lukas Hänel Acknowledgement I would like to thank everybody that made my overseas trip such a rich experience. My special thanks goes to Hermann Härtig for affording me the opportunity to study abroad and for his inspiring lectures that first awakened my interest in operating systems. I want to thank Gernot Heiser for the ERTOS group at NICTA. My thanks goes to Kevin Elphinstone and Peter Chubb for welcoming me in Australia and guiding my work. I would like to thank the many people who worked with me in the project, namely Ben Kalman for developing the build tools, Michael von Tessin for support on the seL4 microkernel, and Ihor Kuz for guidance on component architectures and proof-reading my thesis. Thanks to Robert Sison for asking for more features and Adam Walker for maturing my code. I would like to thank the people responsible for my decision to go overseas, namely Christian Helmuth for his supervision of my study project, the guys at ST Microelectronics for the opportunity of my internship, and my dear parents for supporting me in many ways. Contents 1 Introduction 1 1.1 Outline . .2 2 Background and Related Work 5 2.1 Information flow architectures .