DOCSLIB.ORG

Genode Operating System Framework Foundations

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

GENODE Operating System Framework 16.05 Foundations Norman Feske Contents Contents 1. Introduction9 1.1. Operating-system framework......................... 14 1.2. Licensing and commercial support...................... 16 1.3. About this document.............................. 17 I. Foundations 18 2. Getting started 19 2.1. Obtaining the source code........................... 20 2.2. Source-tree structure.............................. 21 2.3. Using the build system............................. 24 2.4. A simple system scenario........................... 26 2.5. Hello world................................... 29 2.5.1. Using a custom source-code repository............... 29 2.5.2. Source code and build description.................. 29 2.5.3. Building the component........................ 31 2.5.4. Defining a system scenario...................... 31 3. Architecture 34 3.1. Capability-based security........................... 36 3.1.1. Capability spaces, object identities, and RPC objects........ 36 3.1.2. Delegation of authority and ownership............... 37 3.1.3. Capability invocation......................... 38 3.1.4. Capability delegation through capability invocation........ 41 3.2. Recursive system structure........................... 43 3.2.1. Component ownership......................... 43 3.2.2. Tree of components........................... 44 3.2.3. Services and sessions.......................... 44 3.2.4. Client-server relationship....................... 47 3.3. Resource trading................................ 51 3.3.1. Resource assignment.......................... 51 3.3.2. Trading memory between clients and servers............ 55 3.3.3. Component-local heap partitioning................. 57 3.3.4. Dynamic resource balancing..................... 59 3.4. Core - the root of the component tree..................... 61 3.4.1. Dataspaces................................ 61 3.4.2. Region maps.............................. 62 3.4.3. Physical memory allocation (RAM)................. 62 3.4.4. Access to boot modules (ROM).................... 63 2 Contents 3.4.5. Protection domains (PD)........................ 63 3.4.6. Region-map management (RM).................... 64 3.4.7. Processing-time allocation (CPU)................... 65 3.4.8. Access to device resources (IO_MEM, IO_PORT, IRQ)....... 65 3.4.9. Logging (LOG)............................. 67 3.4.10. Event tracing (TRACE)......................... 67 3.5. Component creation.............................. 68 3.5.1. Obtaining the child’s ROM and RAM sessions........... 68 3.5.2. Constructing the child’s address space................ 69 3.5.3. Creating the initial thread....................... 71 3.6. Inter-component communication....................... 74 3.6.1. Synchronous remote procedure calls (RPC)............. 75 3.6.2. Asynchronous notifications...................... 83 3.6.3. Shared memory............................. 86 3.6.4. Asynchronous state propagation................... 88 3.6.5. Synchronous bulk transfer....................... 88 3.6.6. Asynchronous bulk transfer - packet streams............ 90 4. Components 93 4.1. Device drivers.................................. 95 4.1.1. Platform driver............................. 96 4.1.2. Interrupt handling........................... 97 4.1.3. Direct memory access (DMA) transactions............. 97 4.2. Protocol stacks.................................. 101 4.3. Resource multiplexers............................. 103 4.4. Runtime environments and applications................... 105 4.5. Common session interfaces.......................... 107 4.5.1. Read-only memory (ROM)...................... 107 4.5.2. Report.................................. 109 4.5.3. Terminal and UART.......................... 109 4.5.4. Input................................... 110 4.5.5. Framebuffer............................... 111 4.5.6. Nitpicker GUI.............................. 113 4.5.7. Platform................................. 114 4.5.8. Block................................... 114 4.5.9. Regulator................................ 114 4.5.10. Timer................................... 114 4.5.11. NIC.................................... 115 4.5.12. Audio output.............................. 115 4.5.13. File system................................ 118 4.5.14. Loader.................................. 119 4.6. Component configuration........................... 120 3 Contents 4.6.1. Configuration format.......................... 120 4.6.2. Server-side policy selection...................... 120 4.6.3. Dynamic component reconfiguration at runtime.......... 121 4.7. Component composition............................ 122 4.7.1. Sandboxing............................... 122 4.7.2. Component-level and OS-level virtualization............ 124 4.7.3. Interposing individual services.................... 128 4.7.4. Ceding the parenthood........................ 129 4.7.5. Publishing and subscribing...................... 131 4.7.6. Enslaving services........................... 133 5. Development 135 5.1. Source-code repositories............................ 136 5.2. Integration of 3rd-party software....................... 138 5.3. Build system................................... 139 5.3.1. Build directories............................ 139 5.3.2. Target descriptions........................... 140 5.3.3. Library descriptions.......................... 141 5.3.4. Platform specifications......................... 142 5.3.5. Building tools to be executed on the host platform......... 143 5.3.6. Building 3rd-party software...................... 143 5.4. System integration and automated testing.................. 145 5.4.1. Run tool................................. 145 5.4.2. Run-tool configuration examples................... 146 5.4.3. Meaningful default behaviour.................... 148 5.4.4. Run scripts............................... 148 5.4.5. The run mechanism explained.................... 149 5.4.6. Using run scripts to implement test cases.............. 150 5.4.7. Automated testing across base platforms.............. 151 5.5. Git flow...................................... 152 5.5.1. Master and staging........................... 152 5.5.2. Development practice......................... 153 6. System configuration 156 6.1. Nested configuration concept......................... 158 6.2. The init component............................... 161 6.2.1. Session routing............................. 161 6.2.2. Resource quota saturation....................... 164 6.2.3. Handing out slack resources..................... 164 6.2.4. Multiple instantiation of a single ELF binary............ 164 6.2.5. Nested configuration.......................... 165 6.2.6. Assigning subsystems to CPUs.................... 167 4 Contents 6.2.7. Priority support............................. 168 6.2.8. Init verbosity.............................. 168 7. Under the hood 169 7.1. Component-local startup code and linker scripts.............. 170 7.1.1. Linker scripts.............................. 170 7.1.2. Startup code............................... 171 7.2. C++ runtime................................... 175 7.2.1. Rationale behind using exceptions.................. 175 7.2.2. Bare-metal C++ runtime........................ 177 7.3. Interaction of core with the underlying kernel................ 178 7.3.1. Bootstrapping and allocator setup.................. 178 7.3.2. Kernel-object creation......................... 179 7.3.3. Page-fault handling.......................... 180 7.4. Asynchronous notification mechanism.................... 182 7.5. Dynamic linker................................. 185 7.5.1. Building dynamically-linked programs............... 185 7.5.2. Startup of dynamically-linked programs.............. 185 7.5.3. Address-space management..................... 186 7.6. Execution on bare hardware (base-hw).................... 187 7.6.1. Bootstrapping of base-hw....................... 187 7.6.2. Kernel entry and exit.......................... 189 7.6.3. Interrupt handling and preemptive multi-threading........ 189 7.6.4. Split kernel interface.......................... 189 7.6.5. Public part of the kernel interface................... 190 7.6.6. Core-private part of the kernel interface............... 191 7.6.7. Scheduler of the base-hw kernel................... 192 7.6.8. Sparsely populated core address space............... 193 7.6.9. Multi-processor support of base-hw................. 193 7.6.10. Asynchronous notifications on base-hw............... 194 7.7. Execution on the NOVA microhypervisor (base-nova)........... 195 7.7.1. Integration of NOVA with Genode.................. 195 7.7.2. Bootstrapping of a NOVA-based system............... 195 7.7.3. Log output on modern PC hardware................. 196 7.7.4. Relation of NOVA’s kernel objects to Genode’s core services... 197 7.7.5. Page-fault handling on NOVA.................... 199 7.7.6. Asynchronous notifications on NOVA................ 199 7.7.7. IOMMU support............................ 200 7.7.8. Genode-specific modifications of the NOVA kernel........ 201 7.7.9. Known limitations of NOVA..................... 205 5 Contents II. Reference 206 8. Functional specification 207 8.1. API primitives.................................. 209 8.1.1. Capability types............................ 209 8.1.2. Sessions and connections....................... 211 8.1.3. Dataspace interface........................... 214 8.2. Component execution environment..................... 218 8.2.1. Interface to the component’s environment............. 218 8.2.2. Parent interface............................
Recommended publications
  • UG1046 Ultrafast Embedded Design Methodology Guide

    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 .
  • Improving the Reliability of Commodity Operating Systems

    Improving the Reliability of Commodity Operating Systems

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

    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.
  • Operating System Support for Run-Time Security with a Trusted Execution Environment

    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
  • Legacy Reuse

    Legacy Reuse

    Faculty of Computer Science Institute for System Architecture, Operating Systems Group LEGACY REUSE CARSTEN WEINHOLD THIS LECTURE ... ■ So far ... ■ Basic microkernel concepts ■ Drivers, resource management ■ Today: ■ How to provide legacy OS personalities ■ How to reuse existing infrastructure ■ How to make applications happy TU Dresden Legacy Reuse 2 VIRTUALIZATION ■ Virtualization: ■ Reuse legacy OS + applications ■ Run applications in natural environment ■ Problem: Applications trapped in VMs ■ Different resource pools, namespaces ■ Cooperation is cumbersome (network, ...) ■ Full legacy OS in VM adds overhead ■ Multiple desktops? Bad user experience TU Dresden Legacy Reuse 3 MAKING THE CUT ■ Hardware level: Next week ■ Virtualize legacy OS on top of new OS ■ Operating System Personality: ■ Legacy OS interfaces reimplemented on top of – or ported to – new OS ■ Hybrid operating systems: Today ■ Run legacy OS virtualized … ■ … but tightly integrated with new OS TU Dresden Legacy Reuse 4 OPERATING SYSTEM PERSONALITIES TU Dresden Legacy Reuse 5 OS PERSONALITY ■ Idea: Adapt OS / application boundary ■ (Re-)Implement legacy APIs, not whole OS ■ May need to recompile application ■ Benefits: ■ Get desired application, established APIs ■ Good integration (namespaces, files, ...) ■ Smaller overhead than virtualization ■ Flexible, configurable, but more effort? TU Dresden Legacy Reuse 6 MONOLITHIC KERNELS App App Monolithic Kernel System Call Entry Ext2 VFAT IP Stack Disk Driver NIC Driver TU Dresden Legacy Reuse 7 DECOMPOSITION App App App App Monolithic
  • Kernel Architectures

    Kernel Architectures

    A short history of kernels n Early kernel: a library of device drivers, support for threads (QNX) Operating System Kernels n Monolithic kernels: Unix, VMS, OS 360… n Unstructured but fast… n Over time, became very large Ken Birman n Eventually, DLLs helped on size n Pure microkernels: Mach, Amoeba, Chorus… (borrowing some content from n OS as a kind of application Peter Sirokman) n Impure microkernels: Modern Windows OS n Microkernel optimized to support a single OS n VMM support for Unix on Windows and vice versa The great m-kernel debate Summary of First Paper n How big does it need to be? n The Performance of µ-Kernel-Based Systems (Hartig et al. 16th SOSP, Oct 1997) n With a m-kernel protection-boundary crossing forces us to n Evaluates the L4 microkernel as a basis for a full operating system n Change memory -map n Ports Linux to run on top of L4 and compares n Flush TLB (unless tagged) performance to native Linux and Linux running on n With a macro-kernel we lose structural the Mach microkernel protection benefits and fault-containment n Explores the extensibility of the L4 microkernel n Debate raged during early 1980’s Summary of Second Paper In perspective? n The Flux OSKit: A Substrate for Kernel and n L4 seeks to validate idea that a m-kernel Language Research (Ford et al. 16th SOSP, can support a full OS without terrible 1997) cost penalty n Describes a set of OS components designed to be used to build custom operating systems n Opened the door to architectures like the n Includes existing code simply using “glue code” Windows
  • The Nizza Secure-System Architecture

    The Nizza Secure-System Architecture

    Appears in the proceedings of CollaborateCom 2005, San Jose, CA, USA The Nizza Secure-System Architecture Hermann Härtig Michael Hohmuth Norman Feske Christian Helmuth Adam Lackorzynski Frank Mehnert Michael Peter Technische Universität Dresden Institute for System Architecture D-01062 Dresden, Germany [email protected] Abstract rely on a standard OS (including the kernel) to assure their security properties. The trusted computing bases (TCBs) of applications run- To address the conflicting requirements of complete ning on today’s commodity operating systems have become functionality and the protection of security-sensitive data, extremely large. This paper presents an architecture that researchers have devised system architectures that reduce allows to build applications with a much smaller TCB. It the system’s TCB by running kernels in untrusted mode is based on a kernelized architecture and on the reuse of in a secure compartment on top of a small security kernel; legacy software using trusted wrappers. We discuss the de- security-sensitive services run alongside the OS in isolated sign principles, the architecture and some components, and compartments of their own. This architecture is widely re- a number of usage examples. ferred to as kernelized standard OS or kernelized system. In this paper, we describe Nizza, a new kernelized- system architecture. In the design of Nizza, we set out to answer the question of how small the TCB can be made. 1 Introduction We have argued in previous work that the (hardware and software) technologies needed to build small secure-system Desktop and hand-held computers are used for many platforms have become much more mature since earlier at- functions, often in parallel, some of which are security tempts [8].
  • Separating Protection and Management in Cloud Infrastructures

    Separating Protection and Management in Cloud Infrastructures

    SEPARATING PROTECTION AND MANAGEMENT IN CLOUD INFRASTRUCTURES A Dissertation Presented to the Faculty of the Graduate School of Cornell University in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy by Zhiming Shen December 2017 c 2017 Zhiming Shen ALL RIGHTS RESERVED SEPARATING PROTECTION AND MANAGEMENT IN CLOUD INFRASTRUCTURES Zhiming Shen, Ph.D. Cornell University 2017 Cloud computing infrastructures serving mutually untrusted users provide se- curity isolation to protect user computation and resources. Additionally, clouds should also support flexibility and efficiency, so that users can customize re- source management policies and optimize performance and resource utiliza- tion. However, flexibility and efficiency are typically limited due to security requirements. This dissertation investigates the question of how to offer flexi- bility and efficiency as well as strong security in cloud infrastructures. Specifically, this dissertation addresses two important platforms in cloud in- frastructures: the containers and the Infrastructure as a Service (IaaS) platforms. The containers platform supports efficient container provisioning and execut- ing, but does not provide sufficient security and flexibility. Different containers share an operating system kernel which has a large attack surface, and kernel customization is generally not allowed. The IaaS platform supports secure shar- ing of cloud resources among mutually untrusted users, but does not provide sufficient flexibility and efficiency. Many powerful management primitives en- abled by the underlying virtualization platform are hidden from users, such as live virtual machine migration and consolidation. The main contribution of this dissertation is the proposal of an approach in- spired by the exokernel architecture that can be generalized to any multi-tenant system to improve security, flexibility, and efficiency.
  • Research on Virtualisation Technlogy for Real-Time Reconfigurable Systems Tian Xia

    Research on Virtualisation Technlogy for Real-Time Reconfigurable Systems Tian Xia

    Research on virtualisation technlogy for real-time reconfigurable systems Tian Xia To cite this version: Tian Xia. Research on virtualisation technlogy for real-time reconfigurable systems. Electronics. INSA de Rennes, 2016. English. NNT : 2016ISAR0009. tel-01418453 HAL Id: tel-01418453 https://tel.archives-ouvertes.fr/tel-01418453 Submitted on 16 Dec 2016 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. THESE INSA Rennes présentée par sous le sceau de l’Université Bretagne Loire pour obtenir le titre de Tian Xia DOCTEUR DE L’INSA RENNES ECOLE DOCTORALE : MATISSE Spécialité : Electronique et Télécommunications LABORATOIRE : IETR Thèse soutenue le 05.07.2016 Research on devant le jury composé de : Virtualization Technology François Verdier Professeur, Université de Nice, Nice / Président for Real-time Emmanuel Grolleau Professeur, ISAE-ENSMA, Chasseneuil-Futuroscope / Rapporteur Reconfigurable Systems Guy Gogniat Professeur, Université de Bretagne-Sud, Lorient / Rapporteur Jean-Luc Bechennec Chargé de Recherche, Ecole Centrale de Nantes, Nantes / Examinateur Jean-Christophe Prévotet Maître de Conférence, INSA, Rennes / Co-encadrant de thèse Fabienne Nouvel Maître de Conférence HDR, INSA, Rennes / Directrice de thèse Research on Virtualization Technology for Real-time Reconfigurable Systems Tian Xia Résumé de la Thèse Aujourd’hui, les systèmes embarqués jouent un rôle prépondérant dans la vie quo- tidienne des utilisateurs.
  • L4 – Virtualization and Beyond

    L4 – Virtualization and Beyond

    L4 – Virtualization and Beyond Hermann Härtig!," Michael Roitzsch! Adam Lackorzynski" Björn Döbel" Alexander Böttcher! #!Department of Computer Science# "GWT-TUD GmbH # Technische Universität Dresden# 01187 Dresden, Germany # 01062 Dresden, Germany {haertig,mroi,adam,doebel,boettcher}@os.inf.tu-dresden.de Abstract Mac OS X environment, using full hardware After being introduced by IBM in the 1960s, acceleration by the GPU. Virtual machines are virtualization has experienced a renaissance in used to test potentially malicious software recent years. It has become a major industry trend without risking the host environment and they in the server context and is also popular on help developers in debugging crashes with back- consumer desktops. In addition to the well-known in-time execution. benefits of server consolidation and legacy In the server world, virtual machines are used to preservation, virtualization is now considered in consolidate multiple services previously located embedded systems. In this paper, we want to look on dedicated machines. Running them within beyond the term to evaluate advantages and virtual machines on one physical server eases downsides of various virtualization approaches. management and helps saving power by We show how virtualization can be increasing utilization. In server farms, migration complemented or even superseded by modern of virtual machines between servers is used to operating system paradigms. Using L4 as the balance load with the potential of shutting down basis for virtualization and as an advanced completely unloaded servers or adding more to microkernel provides a best-of-both-worlds increase capacity. Lastly, virtual machines also combination. Microkernels can contribute proven isolate different customers who can purchase real-time capabilities and small trusted computing virtual shares of a physical server in a data center.
  • Partitioned System with Xtratum on Powerpc

    Partitioned System with Xtratum on Powerpc

    Tesina de M´asteren Autom´aticae Inform´aticaIndustrial Partitioned System with XtratuM on PowerPC Author: Rui Zhou Advisor: Prof. Alfons Crespo i Lorente December 2009 Contents 1. Introduction1 1.1. MILS......................................2 1.2. ARINC 653..................................3 1.3. PikeOS.....................................6 1.4. ADEOS....................................7 2. Overview of XtratuM 11 2.1. Virtualization and Hypervisor........................ 11 2.2. XtratuM.................................... 12 3. Overview of PowerPC 16 3.1. POWER.................................... 16 3.2. PowerPC.................................... 17 3.3. PowerPC in Safety-critical.......................... 19 4. Main PowerPC Drivers to Virtualize 20 4.1. Processors................................... 20 4.2. Timer..................................... 21 4.3. Interrupt.................................... 23 4.4. Memory.................................... 24 5. Porting Implementation 25 5.1. Hypercall................................... 26 5.2. Timer..................................... 27 5.3. Interrupt.................................... 28 5.4. Memory.................................... 31 5.5. Partition.................................... 32 6. Benchmark 34 7. Conclusions and Future Work 38 Abstract Nowadays, the diversity of embedded applications has been developed into a new stage with the availability of various new high-performance processors and low cost on-chip memory. As the result of these new advances in hardware, there is a