The OKL4 Microvisor: Convergence Point of Microkernels and Hypervisors

Total Page:16

File Type:pdf, Size:1020Kb

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 Open Kernel Labs University of New South Wales Sydney, Australia Sydney, Australia [email protected] [email protected] ABSTRACT high-performance OKL4 microkernel for mobile devices [OKL4] We argue that recent hypervisor-vs-microkernel discussions com- (with more than 750 million instances shipped to date). pletely miss the point. Fundamentally, the two classes of systems Curiously, this did not stop a new debate starting a number have much in common, and provide similar abstractions. We assert of years back, this time pitting microkernels against hypervisors, as if they were disjoint classes of systems. Some of these ar- that the requirements for both types of systems can be met with a + single set of abstractions, a single design, and a single implementa- guments [HWF 05] we have earlier shown to be based on false tion. We present partial proof of the existence of this convergence premises [HUL06], others [AG09] are based on an outdated, 1980’s point, in the guise of the OKL4 microvisor, an industrial-strength view of microkernels, oblivious to the last 15+ years of microkernel system designed as a highly-efficient hypervisor for use in embed- research. ded systems. It is also a third-generation microkernel that aims We assert that these arguments completely miss the point. Mi- to support the construction of similarly componentised systems as crokernels and hypervisors are both designed as low-level founda- classical microkernels. Benchmarks show that the microvisor’s vir- tions for larger systems, although with different objectives. This tualization performance is highly competitive. does not mean that these objectives are irreconcilably at odds. In fact, we argue that we can construct a type of kernel that satisfies the combined objectives of microkernels and hypervisors. We call Categories and Subject Descriptors such a kernel a microvisor, and present the OKL4 microvisor as a D.4.7 [Operating Systems]: Organization and Design—Real-time representative. systems and embedded systems In the next section we revisit the motivations for microkernels and hypervisors, and the resulting objectives and designs. In Sec- General Terms tion 3 we explore the intersection of these objectives and present the OKL4 microvisor as a representative. Section 4 presents initial Design, Performance performance data and Section 5 discusses related work. Keywords Microkernels, hypervisors, virtual machines, real-time systems and 2. MICROKERNELS AND HYPERVISORS embedded systems 2.1 Microkernels 1. INTRODUCTION While the term microkernel was not coined until a decade and a The merits of microkernels have been debated for a long time. half later, the basic concept goes back to Brinch Hansen’s nucleus Popular in the 1980s, they fell into disrepute in the early ’90s as [BH70]. The basic idea is to reduce the kernel code to fundamental systems built on top failed to perform. Arguments that the perfor- mechanisms, and implement actual system services (and policies) mance problems were inherent in the microkernel approach [CB93] in user-level servers. The microkernel is supposed to be general were refuted by Liedtke [Lie95] identifying design and imple- enough to support the construction of arbitrary systems on top. mentation shortcomings of these first-generation kernels, and it The modern microkernel concept is captured in Liedtke’s Mini- was demonstrated that the second-generation (2G) L4 microkernel mality Principle: A concept is tolerated inside the microkernel only could be used as a hypervisor to virtualize Linux with an over- + if moving it outside the kernel, i.e. permitting competing imple- head of about 5–7% [HHL 97]. Commercial microkernels are mentations, would prevent implementation of the system’s required now deployed at a large scale, including QNX [LG09] for high- functionality [Lie95]. availability, Green Hills Integrity [GHS] for high security, and the The original driver behind microkernels is generality and flexi- bility, based on a separation of policy and mechanisms [LCC+75]. A more modern motivation is the design of systems with a minimal Permission to make digital or hard copies of all or part of this work for trusted computing base, in order to aid assurance of safety- and personal or classroom use is granted without fee provided that copies are security-critical systems [HPHS04]. The formal verification of the not made or distributed for profit or commercial advantage and that copies seL4 microkernel [KEH+09] shows that microkernels can be small bear this notice and the full citation on the first page. To copy otherwise, to enough make a formal proof of functional correctness feasible. republish, to post on servers or to redistribute to lists, requires prior specific Moving services out of the kernel into servers makes client- permission and/or a fee. APSys 2010, August 30, 2010, New Delhi, India. server communication performance-critical, and as such a micro- Copyright 2010 ACM 978-1-4503-0195-4/10/08 ...$10.00. kernel needs a very fast inter-process communication (IPC) mech- 19 anism. Consequently, IPC performance used to be the focus of the actual device driver residing inside the hypervisor—this microkernel research [Lie93]. approach supports multiplexing the device (like other re- sources). Sometimes a device is made directly accessible to 2.2 Hypervisors the guest by mapping device registers into the guest’s mem- Hypervisors are even older, they go back to the 1960s. The orig- ory and virtualizing interrupts (the hypervisor up-calls the inal motivation was an early form of legacy re-use: With the ad- guest’s interrupt handler routine). This makes multiplexing vent of more powerful computers, the original single-user single- of stateful devices difficult or impossible and, in the case of task model of operating systems was no longer sufficient. Virtual- DMA-capable devices, can only be done securely with addi- ization supported the concurrent execution of programs by putting tional hardware support (I/O MMU). each into a separate virtual machine (VM), together with its single- Microkernels, in contrast, tend to run device drivers as sep- tasking executive. Virtualization went out of fashion in the ’70s arate user-level processes, which communicate with the rest with the widespread availability of multitasking and multi-user of the system using IPC. This is effectively a combination of OSes, until its renaissance in the last decade, mostly driven by the the approaches discussed for hypervisors, and supports de- resource-management deficiencies of most modern OSes. vice sharing without making drivers part of the microkernel, According to the classic definition, a VM is an efficient, isolated but comes at the expense of additional context switches. duplicate of a real machine [PG74]. The VM is implemented by a hypervisor (or virtual-machine monitor, VMM) which provides Communication Subsystems need to communicate. VMs com- virtual resources either by (temporarily) mapping them to physical municate like real machines—via networks. Hence, hypervi- resources, or emulating them. The former is efficient, the latter sors traditionally provide virtual networks, which are based results in overhead, and so is avoided where possible. on the existing virtual-device abstraction, running standard While originally virtualization was understood to be pure (vir- networking stacks. Microkernels, in contrast, are designed tual resources are essentially indistinguishable from real ones), for systems decomposed at a much finer granularity, and hardware limitations and efficiency reasons led to widespread use therefore offer highly-optimised message-based IPC primi- of para-virtualization, which presents a modified hardware ABI tives. Following Liedtke [Lie93], 2G microkernels typically to which the guest OS is ported. A hypervisor supporting para- minimise overheads by providing a synchronous (blocking virtualization provides extra APIs, called hypercalls, which gener- and unbuffered) IPC primitive. ally are more high-level than the hardware ABI. 2.3 Comparison In summary, there is not much difference in the first three points. As far as I/O is concerned, hypervisors have in recent years moved In summary, microkernels aim to provide a minimal layer of closer to microkernels. Xen [BDF+03], for example, runs its ad- privileged software, while hypervisors aim to replicate and mul- ministrative functions in a privileged VM called Domain0, which tiplex hardware resources. Both have an inherent need to abstract hosts a Linux guest. Domain0 is also used as a source of de- the hardware, although with different emphasis. vice drivers, which therefore run in user mode, as with a micro- For a hypervisor it is fundamentally important that the abstract kernel (although all the Domain0 drivers run in the same address (“virtual”) resources look as much like the concrete (“real”) ones space, that of the Linux guest). The driver (excuse the pun) behind as possible, while implementation size is not a primary concern. this development is the cost of re-implementing or adapting device For a microkernel, similarity of real and abstract resources is not drivers: Domain0 uses unmodified drivers from the Linux guest. a driver, but in reality the semantic gap cannot become very large This in turn puts pressure on inter-VM communication costs. without violating the minimality requirement. Only a few years back, hypervisor proponents belittled the mi- It should now not be overly surprising that the abstractions end crokernel community [HWF+05] for their efforts in optimising up being quite similar. Fundamentally, both types of kernels must IPC. During the discussion following the presentation of that pa- provide abstractions for: per, a prediction was made that within two years the hypervi- Memory: The hardware managing memory is the MMU, and hy- sor community would be publishing papers on improving inter- pervisors provide a virtual MMU, or virtualize the MMU’s VM communication overheads. In fact, a string of papers have software interface, the page tables.
Recommended publications
  • A Microkernel API for Fine-Grained Decomposition
    A Microkernel API for Fine-Grained Decomposition Sebastian Reichelt Jan Stoess Frank Bellosa System Architecture Group, University of Karlsruhe, Germany freichelt,stoess,[email protected] ABSTRACT from the microkernel APIs in existence. The need, for in- Microkernel-based operating systems typically require spe- stance, to explicitly pass messages between servers, or the cial attention to issues that otherwise arise only in dis- need to set up threads and address spaces in every server for tributed systems. The resulting extra code degrades per- parallelism or protection require OS developers to adopt the formance and increases development effort, severely limiting mindset of a distributed-system programmer rather than to decomposition granularity. take advantage of their knowledge on traditional OS design. We present a new microkernel design that enables OS devel- Distributed-system paradigms, though well-understood and opers to decompose systems into very fine-grained servers. suited for physically (and, thus, coarsely) partitioned sys- We avoid the typical obstacles by defining servers as light- tems, present obstacles to the fine-grained decomposition weight, passive objects. We replace complex IPC mecha- required to exploit the benefits of microkernels: First, a nisms by a simple function-call approach, and our passive, lot of development effort must be spent into matching the module-like server model obviates the need to create threads OS structure to the architecture of the selected microkernel, in every server. Server code is compiled into small self- which also hinders porting existing code from monolithic sys- contained files, which can be loaded into the same address tems. Second, the more servers exist | a desired property space (for speed) or different address spaces (for safety).
    [Show full text]
  • UG1046 Ultrafast Embedded Design Methodology Guide
    UltraFast Embedded Design Methodology Guide UG1046 (v2.3) April 20, 2018 Revision History The following table shows the revision history for this document. Date Version Revision 04/20/2018 2.3 • Added a note in the Overview section of Chapter 5. • Replaced BFM terminology with VIP across the user guide. 07/27/2017 2.2 • Vivado IDE updates and minor editorial changes. 04/22/2015 2.1 • Added Embedded Design Methodology Checklist. • Added Accessing Documentation and Training. 03/26/2015 2.0 • Added SDSoC Environment. • Added Related Design Hubs. 10/20/2014 1.1 • Removed outdated information. •In System Level Considerations, added information to the following sections: ° Performance ° Clocking and Reset 10/08/2014 1.0 Initial Release of document. UltraFast Embedded Design Methodology Guide Send Feedback 2 UG1046 (v2.3) April 20, 2018 www.xilinx.com Table of Contents Chapter 1: Introduction Embedded Design Methodology Checklist. 9 Accessing Documentation and Training . 10 Chapter 2: System Level Considerations Performance. 13 Power Consumption . 18 Clocking and Reset. 36 Interrupts . 41 Embedded Device Security . 45 Profiling and Partitioning . 51 Chapter 3: Hardware Design Considerations Configuration and Boot Devices . 63 Memory Interfaces . 69 Peripherals . 76 Designing IP Blocks . 94 Hardware Performance Considerations . 102 Dataflow . 108 PL Clocking Methodology . 112 ACP and Cache Coherency. 116 PL High-Performance Port Access. 120 System Management Hardware Assistance. 124 Managing Hardware Reconfiguration . 127 GPs and Direct PL Access from APU . 133 Chapter 4: Software Design Considerations Processor Configuration . 137 OS and RTOS Choices . 142 Libraries and Middleware . 152 Boot Loaders . 156 Software Development Tools . 162 UltraFast Embedded Design Methodology GuideSend Feedback 3 UG1046 (v2.3) April 20, 2018 www.xilinx.com Chapter 5: Hardware Design Flow Overview .
    [Show full text]
  • Quantifying Security Impact of Operating-System Design
    Copyright Notice School of Computer Science & Engineering COMP9242 Advanced Operating Systems These slides are distributed under the Creative Commons Attribution 3.0 License • You are free: • to share—to copy, distribute and transmit the work • to remix—to adapt the work • under the following conditions: 2019 T2 Week 09b • Attribution: You must attribute the work (but not in any way that Local OS Research suggests that the author endorses you or your use of the work) as @GernotHeiser follows: “Courtesy of Gernot Heiser, UNSW Sydney” The complete license text can be found at http://creativecommons.org/licenses/by/3.0/legalcode 1 COMP9242 2019T2 W09b: Local OS Research © Gernot Heiser 2019 – CC Attribution License Quantifying OS-Design Security Impact Approach: • Examine all critical Linux CVEs (vulnerabilities & exploits database) • easy to exploit 115 critical • high impact Linux CVEs Quantifying Security Impact of • no defence available to Nov’17 • confirmed Operating-System Design • For each establish how microkernel-based design would change impact 2 COMP9242 2019T2 W09b: Local OS Research © Gernot Heiser 2019 – CC Attribution License 3 COMP9242 2019T2 W09b: Local OS Research © Gernot Heiser 2019 – CC Attribution License Hypothetical seL4-based OS Hypothetical Security-Critical App Functionality OS structured in isolated components, minimal comparable Trusted inter-component dependencies, least privilege to Linux Application computing App requires: base • IP networking Operating system Operating system • File storage xyz xyz • Display
    [Show full text]
  • 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]
  • Run-Time Reconfigurable RTOS for Reconfigurable Systems-On-Chip
    Run-time Reconfigurable RTOS for Reconfigurable Systems-on-Chip Dissertation A thesis submited to the Faculty of Computer Science, Electrical Engineering and Mathematics of the University of Paderborn and to the Graduate Program in Electrical Engineering (PPGEE) of the Federal University of Rio Grande do Sul in partial fulfillment of the requirements for the degree of Dr. rer. nat. and Dr. in Electrical Engineering Marcelo G¨otz November, 2007 Supervisors: Prof. Dr. rer. nat. Franz J. Rammig, University of Paderborn, Germany Prof. Dr.-Ing. Carlos E. Pereira, Federal University of Rio Grande do Sul, Brazil Public examination in Paderborn, Germany Additional members of examination committee: Prof. Dr. Marco Platzner Prof. Dr. Urlich R¨uckert Dr. Mario Porrmann Date: April 23, 2007 Public examination in Porto Alegre, Brazil Additional members of examination committee: Prof. Dr. Fl´avioRech Wagner Prof. Dr. Luigi Carro Prof. Dr. Altamiro Amadeu Susin Prof. Dr. Leandro Buss Becker Prof. Dr. Fernando Gehm Moraes Date: October 11, 2007 Acknowledgements This PhD thesis was carried out, in his great majority, at the Department of Computer Science, Electrical Engineering and Mathematics of the University of Paderborn, during my time as a fellow of the working group of Prof. Dr. Franz J. Rammig. Due to a formal agreement between Federal University of Rio Grande do Sul (UFRGS) and University of Paderborn, I had the opportunity to receive a bi-national doctoral degree. Therefore, I had to accomplished, in addition, the PhD Graduate Program in Electrical Engineering of UFRGS. So, I hereby acknowledge, without mention everyone personally, all persons involved in making this agreement possible.
    [Show full text]
  • Introduction
    1 INTRODUCTION A modern computer consists of one or more processors, some main memory, disks, printers, a keyboard, a mouse, a display, network interfaces, and various other input/output devices. All in all, a complex system.oo If every application pro- grammer had to understand how all these things work in detail, no code would ever get written. Furthermore, managing all these components and using them optimally is an exceedingly challenging job. For this reason, computers are equipped with a layer of software called the operating system, whose job is to provide user pro- grams with a better, simpler, cleaner, model of the computer and to handle manag- ing all the resources just mentioned. Operating systems are the subject of this book. Most readers will have had some experience with an operating system such as Windows, Linux, FreeBSD, or OS X, but appearances can be deceiving. The pro- gram that users interact with, usually called the shell when it is text based and the GUI (Graphical User Interface)—which is pronounced ‘‘gooey’’—when it uses icons, is actually not part of the operating system, although it uses the operating system to get its work done. A simple overview of the main components under discussion here is given in Fig. 1-1. Here we see the hardware at the bottom. The hardware consists of chips, boards, disks, a keyboard, a monitor, and similar physical objects. On top of the hardware is the software. Most computers have two modes of operation: kernel mode and user mode. The operating system, the most fundamental piece of soft- ware, runs in kernel mode (also called supervisor mode).
    [Show full text]
  • Sel4: Formal Verification of an Operating-System Kernel
    seL4: Formal Verification of an Operating-System Kernel Gerwin Klein1;2, June Andronick1;2, Kevin Elphinstone1;2, Gernot Heiser1;2;3 1 1 1;2 1;2 David Cock , Philip Derrin ∗, Dhammika Elkaduwe ,z Kai Engelhardt 1;2 1;4 1 1;2 1;2 Rafal Kolanski , Michael Norrish , Thomas Sewell , Harvey Tuch y, Simon Winwood 1 NICTA, 2 UNSW, 3 Open Kernel Labs, 4 ANU [email protected] ABSTRACT We report on the formal, machine-checked verification of the seL4 microkernel from an abstract specification down to its C implementation. We assume correctness of compiler, assembly code, hardware, and boot code. seL4 is a third-generation microkernel of L4 provenance, comprising 8,700 lines of C and 600 lines of assembler. Its performance is comparable to other high-performance L4 kernels. We prove that the implementation always strictly follows our high-level abstract specification of kernel behaviour. This encompasses traditional design and implementation safety properties such as that the kernel will never crash, and it will never perform an unsafe operation. It also implies much more: we can predict precisely how the kernel will behave in every possible situation. 1. INTRODUCTION Almost every paper on formal verification starts with the observation that software complexity is increasing, that this Figure 1: Call graph of the seL4 microkernel. Ver- leads to errors, and that this is a problem for mission and tices represent functions, and edges invocations. safety critical software. We agree, as do most. Here, we report on the full formal verification of a critical system from a high-level model down to very low-level C kernel, and every single bug can potentially cause arbitrary code.
    [Show full text]
  • 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]
  • Operating System Support for Run-Time Security with a Trusted Execution Environment
    Operating System Support for Run-Time Security with a Trusted Execution Environment - Usage Control and Trusted Storage for Linux-based Systems - by Javier Gonz´alez Ph.D Thesis IT University of Copenhagen Advisor: Philippe Bonnet Submitted: January 31, 2015 Last Revision: May 30, 2015 ITU DS-nummer: D-2015-107 ISSN: 1602-3536 ISBN: 978-87-7949-302-5 1 Contents Preface8 1 Introduction 10 1.1 Context....................................... 10 1.2 Problem....................................... 12 1.3 Approach...................................... 14 1.4 Contribution.................................... 15 1.5 Thesis Structure.................................. 16 I State of the Art 18 2 Trusted Execution Environments 20 2.1 Smart Cards.................................... 21 2.1.1 Secure Element............................... 23 2.2 Trusted Platform Module (TPM)......................... 23 2.3 Intel Security Extensions.............................. 26 2.3.1 Intel TXT.................................. 26 2.3.2 Intel SGX.................................. 27 2.4 ARM TrustZone.................................. 29 2.5 Other Techniques.................................. 32 2.5.1 Hardware Replication........................... 32 2.5.2 Hardware Virtualization.......................... 33 2.5.3 Only Software............................... 33 2.6 Discussion...................................... 33 3 Run-Time Security 36 3.1 Access and Usage Control............................. 36 3.2 Data Protection................................... 39 3.3 Reference
    [Show full text]
  • Microkernel Construction Introduction
    Microkernel Construction Introduction Nils Asmussen 04/06/2017 1 / 28 Outline Introduction Goals Administration Monolithic vs. Microkernel Overview About L4/NOVA 2 / 28 Goals 1 Provide deeper understanding of OS mechanisms 2 Look at the implementation details of microkernels 3 Make you become enthusiastic microkernel hackers 4 Propaganda for OS research at TU Dresden 3 / 28 Administration Thursday, 4th DS, 2 SWS Slides: www.tudos.org ! Teaching ! Microkernel Construction Subscribe to our mailing list: www.tudos.org/mailman/listinfo/mkc2017 In winter term: Microkernel-based operating systems (MOS) Various labs 4 / 28 Outline Introduction Monolithic vs. Microkernel Kernel design comparison Examples for microkernel-based systems Vision vs. Reality Challenges Overview About L4/NOVA 5 / 28 Monolithic Kernel System Design u s Application Application Application e r k Kernel e r File Network n e Systems Stacks l m Memory Process o Drivers Management Management d e Hardware 6 / 28 Monolithic Kernel OS (Propaganda) System components run in privileged mode No protection between system components Faulty driver can crash the whole system Malicious app could exploit bug in faulty driver More than 2=3 of today's OS code are drivers No need for good system design Direct access to data structures Undocumented and frequently changing interfaces Big and inflexible Difficult to replace system components Difficult to understand and maintain Why something different? ! Increasingly difficult to manage growing OS complexity 7 / 28 Microkernel System Design Application
    [Show full text]