DOCSLIB.ORG

Quantifying Security Impact of Operating-System Design

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read 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 output Auth. Auth. Process Auth. ProcessProcess Server ServerServer Name Server File NameName ServerServer FileFile GPU Memory Server MemoryMemory Server IP Acc.Server Server NW Device Acc.Acc.Server Server NW NICDevice Server ServerServer Stack Control Stack Driver ControlControl Stack DriverDriver Hardware Hardware 4 COMP9242 2019T2 W09b: Local OS Research © Gernot Heiser 2019 – CC Attribution License 5 COMP9242 2019T2 W09b: Local OS Research © Gernot Heiser 2019 – CC Attribution License Analysing CVEs Analysing CVEs Map compromised component Map compromised component Example: to hypothetical OS to hypothetical OS Application Application Bug in page-table Not in TCB: management Operating system Attack defeated Operating system xyz xyz Auth. Auth. Auth. ProcessProcess Auth. ProcessProcess ServerServer ServerServer NameName ServerServer FileFile GPU NameName ServerServer FileFile GPU Server MemoryMemory Server IP Server MemoryMemory Server IP In microkernel: Acc.Acc.Server Server NW NICDevice Acc.Acc.Server Server NW NICDevice ServerServer Stack ServerServer Stack ControlControl Stack DriverDriver Example: ControlControl Stack DriverDriver Attack defeated USB driver bug by verifiation microkernel microkernel Hardware Hardware 6 COMP9242 2019T2 W09b: Local OS Research © Gernot Heiser 2019 – CC Attribution License 7 COMP9242 2019T2 W09b: Local OS Research © Gernot Heiser 2019 – CC Attribution License Analysing CVEs Analysing CVEs Map compromised component Map compromised component No full compromise to hypothetical OS to hypothetical OS Application Only crash essential Application but integrity or confi- service (DoS): dentiality violation: Operating system Strongly mitigated Operating system Weakly mitigated xyz xyz Auth. Auth. Auth. ProcessProcess Auth. ProcessProcess ServerServer ServerServer NameName ServerServer FileFile GPU NameName ServerServer FileFile GPU Server MemoryMemory Server IP Server MemoryMemory Server IP Acc.Acc.Server Server NW NICDevice Example: Acc.Acc.Server Server NW NICDevice Example: ServerServer Stack ServerServer Stack ControlControl Stack DriverDriver File system ControlControl Stack DriverDriver GPU compromised compromised microkernel microkernel Hardware Hardware 8 COMP9242 2019T2 W09b: Local OS Research © Gernot Heiser 2019 – CC Attribution License 9 COMP9242 2019T2 W09b: Local OS Research © Gernot Heiser 2019 – CC Attribution License Analysing CVEs All Critical Linux CVEs to 2017 Still full system Map compromised component Example: compromise: Not in TCB: to hypothetical OS Driver exploit hijacks Application No effect Attack defeated I2C bus, allowing firmware reflush Operating system 4% No full compromise, xyz 30% • 41% eliminated Auth. but violates integrity Auth. ProcessProcess Server or confidentiality: • 58% low severity NameNameServer ServerServer File GPU 38% MemoryMemory File • 96% not critical ServerServer Server IP Weakly mitigated Acc.Acc. ServerServer Server NW NICDevice Control StackStack Driver Control Driver Full system 11% compromise: Only crash essential microkernel No effect In microkernel: service (availability): 17% Attack defeated Hardware Strongly mitigated by verification 10 COMP9242 2019T2 W09b: Local OS Research © Gernot Heiser 2019 – CC Attribution License 11 COMP9242 2019T2 W09b: Local OS Research © Gernot Heiser 2019 – CC Attribution License Summary OS structure matters! • Microkernels definitely improve security • Monolithic OS design is fundamentally flawed from security point of view [Biggs et al., APSys’18] Cogent Use of a monolithic OS in security- or safety- critical scenarios is professional malpractice! 12 COMP9242 2019T2 W09b: Local OS Research © Gernot Heiser 2019 – CC Attribution License 13 COMP9242 2019T2 W09b: Local OS Research © Gernot Heiser 2019 – CC Attribution License Beyond the Kernel Cogent: Code & Proof Co-Generation Uncritical/ Aim: Reduce cost of 5 kLOC? 10 kLOC? untrusted Abstract Spec verified systems code Isabelle/HOL Apps 1 kLOC? 100 kLOC? Apps Apps 10 kLOC • Restricted, purely functional Manual, systems language equational 11 py Proof Device NW File Linux • Type- and memory safe, not Control Manual, driver stack system managed Cogent Proof one-off • Turing incomplete Auto- • File system case-studies: matic BilbyFs, ext2, F2FS, VFAT Proof Aim: Verified TCB at affordable cost! [O’Connor et al, ICFP’16; C ADTs (C) Amani et al, ASPLOS’16] 14 COMP9242 2019T2 W09b: Local OS Research © Gernot Heiser 2019 – CC Attribution License 15 | COMP9242 2019T2 W09b: Local OS Research © Gernot Heiser 2019 – CC Attribution License Manual Proof Effort Addressing Verification Cost BilbyFS EffortEffort IsabelleIsabelle CogentCogent CostCost LoP/ Abstract Abstract Dependability-cost tradeoff: functions LoPLoP SLoCSLoC $/$/SLoCSLoC SLOC Spec Spec • Reduced faults through safe language isync()()/ 9.259.259.25 pm 13,00013,000 1,3501,350 150150 10 • Property-based testing (QuickCheck) iget() pm 8 py • Model checking Spec library Proof? reuse! Proof • Full functional correctness proof sync()- 3.753.75 pm 5,7005,700 300300 260260 19 Cogent specific pm Executable Work in progress: iget()- 11 pm pm 1,8001,800 200200 100100 9 Spec • Language expressiveness specific 0 py • Reduce boiler-plate code seL4 1212 py py 180,000180,000 8,7008,700 C C 350350 20 3 py Proof Proof • Network stacks BilbyFS: 4,200 LoC Cogent C C • Device drivers 16 | COMP9242 2019T2 W09b: Local OS Research © Gernot Heiser 2019 – CC Attribution License 17 COMP9242 2019T2 W09b: Local OS Research © Gernot Heiser 2019 – CC Attribution License Refresh: Microarchitectural Timing Channels High Low Contention for shared hardware resources affects execution speed, Time Protection Shared resources leading to timing channels 18 COMP9242 2019T2 W09b: Local OS Research © Gernot Heiser 2019 – CC Attribution License 19 COMP9242 2019T2 W09b: Local OS Research © Gernot Heiser 2019 – CC Attribution License OS Must Enforce Time Protection Time Protection: No Sharing of HW State High Low Temporally High Low High Low partition Flush Cache Cache Spatially Shared hardware partition High Low What are the OS Preventing interference is core duty of the OS! mechanisms? • Memory protection is well established • Time protection is completely absent Cache 20 COMP9242 2019T2 W09b: Local OS Research © Gernot Heiser 2019 – CC Attribution License 21 COMP9242 2019T2 W09b: Local OS Research © Gernot Heiser 2019 – CC Attribution License Spatial Partitioning: Cache Colouring Spatial Partitioning: Cache Colouring Partitions • Partitions get frame pools of disjoint colours restricted to High Low coloured memory • seL4: userland supplies kernel memory System permanently ⇒ colouring userland colours kernel memory coloured TCB PT TCB PT High Low SD SD I+D I+D Cache Shared kernel image Initial process RAM Init I+D I+D RAM 22 | COMP9242 2019T2 W09b: Local OS Research © Gernot Heiser 2019 – CC Attribution License 23 | COMP9242 2019T2 W09b: Local OS Research © Gernot Heiser 2019 – CC Attribution License Channel Through Kernel Code Colouring the Kernel Ensure deterministic access! Remaining shared kernel data: 700 0.100000 datafile using 1:2:3 Each partition has Raw 600 0.010000 • Scheduler queue array & bitmap 500 0.001000 own kernel image channel 400 0.000100 • Few pointers to current thread state 300 LLC misses 0.000010 0 1 2 3 Resource Manager Resource Manager RM RM Kernel I+D I+D I+D I+D clone! Channel matrix: Conditional probability of observing output signal (time) given Global Resource Manager input signal (system-call number) RAM Init I+D I+D 24 | COMP9242 2019T2 W09b: Local OS Research © Gernot Heiser 2019 – CC Attribution License 25 | COMP9242 2019T2 W09b: Local OS Research © Gernot Heiser 2019 – CC Attribution License Spatial Partitioning: Cache Colouring Channel Through Kernel Code • Partitions get frame pools of disjoint colours High Low 700 0.100000 datafile using 1:2:3 • seL4: userland supplies kernel memory Raw 600 0.010000 ⇒ colouring userland colours kernel memory 500 0.001000 channel 400 0.000100
Load more

Recommended publications
  • 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]
  • 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]
  • 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.
    [Show full text]
  • 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 .
    [Show full text]
  • 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.
    [Show full text]
  • 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.
    [Show full text]
  • 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.
    [Show full text]
  • 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.
    [Show full text]
  • 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.
    [Show full text]
  • 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.
    [Show full text]
  • 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 .
    [Show full text]
  • Intel SGX Explained
    Intel SGX Explained Victor Costan and Srinivas Devadas [email protected], [email protected] Computer Science and Artificial Intelligence Laboratory Massachusetts Institute of Technology ABSTRACT Data Owner’s Remote Computer Computer Intel’s Software Guard Extensions (SGX) is a set of Untrusted Software extensions to the Intel architecture that aims to pro- vide integrity and confidentiality guarantees to security- Computation Container Dispatcher sensitive computation performed on a computer where Setup Computation Setup all the privileged software (kernel, hypervisor, etc) is Private Code Receive potentially malicious. Verification Encrypted This paper analyzes Intel SGX, based on the 3 pa- Results Private Data pers [14, 79, 139] that introduced it, on the Intel Software Developer’s Manual [101] (which supersedes the SGX Owns Manages manuals [95, 99]), on an ISCA 2015 tutorial [103], and Trusts Authors on two patents [110, 138]. We use the papers, reference Trusts manuals, and tutorial as primary data sources, and only draw on the patents to fill in missing information. Data Owner Software Infrastructure This paper does not reflect the information available Provider Owner in two papers [74, 109] that were published after the first Figure 1: Secure remote computation. A user relies on a remote version of this paper. computer, owned by an untrusted party, to perform some computation This paper’s contributions are a summary of the on her data. The user has some assurance of the computation’s Intel-specific architectural and micro-architectural details integrity and confidentiality. needed to understand SGX, a detailed and structured pre- sentation of the publicly available information on SGX, uploads the desired computation and data into the secure a series of intelligent guesses about some important but container.
    [Show full text]