DOCSLIB.ORG

Improvement of the Virtualization Support in the Fiasco.OC Microkernel

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Improvement of the Virtualization Support in the Fiasco.OC Microkernel Technische Universität Berlin Master’s Thesis Chair for Security in Telecommunications (SecT) School IV — Electrical Engineering and Computer Science Technische Universität Berlin Improving Virtualization Support in the Fiasco.OC Microkernel Author: Julius Werner (#310341) Major: Computer Science (Informatik) Email: [email protected] Primary Advisor: Prof. Dr. Jean-Pierre Seifert Secondary Advisor: Prof. Dr. Hans-Ulrich Heiß Tutor: Dipl.-Inf. Matthias Lange April – August 2012 Abstract This thesis aims to improve the memory virtualization efficiency of the Fiasco.OC mi- crokernel on processors with the Intel VMX hardware-assisted virtualization architecture, which is plagued by severe performance degradation. After discussing possible approaches, this goal is accomplished by implementing support for Intel’s nested paging mechanism (EPT). Fiasco.OC’s memory management system is enhanced to allow a new kind of task whose address space is stored in the EPT page attribute format while staying compati- ble with the existing shared memory mapping interface through dynamic page attribute translation. This enhancement is complemented with support for tagged TLB entries (VPIDs), independently providing another minor performance increase. The kernel’s external virtualization API and the experimental userland VMM Karma are adapted to support these changes. The final implementation is evaluated and analyzed in the context of several benchmarks, achieving near-native performance on real-world workloads while only constituting a minor increase in complexity for the microkernel. Zusammenfassung Diese Arbeit zielt darauf ab die Speichervirtualisierungseffizienz des Fiasco.OC Mikro- kerns auf Prozessoren mit der hardwareunterstützten Virtualisierungsarchitektur Intel VMX zu verbessern, welche von schweren Performanzverlusten geplagt wird. Nach der Diskussion möglicher Lösungsansätze wird dieses Ziel mit der Unterstützung von Intels Mechanismus für verschachtelte Seitentabellen (EPT) umgesetzt. Fiasco.OCs Speicherver- waltungssystem wird um eine neue Art von Prozess erweitert, dessen Adressraum im EPT-Seitenattributsformat gespeichert wird, der aber durch dynamische Übersetzung der Seitenattribute dennoch kompatibel mit der existierenden Schnittstelle für geteilte Speicher- abbildungen bleibt. Diese Verbesserung wird durch die Unterstützung von ausgezeichneten TLB-Einträgen (VPIDs) komplementiert, welche unabhängig davon einen weiteren kleinen Performanzvorteil einbringen. Die externe Virtualisierungs-API des Kerns und der experi- mentelle Userland-VMM Karma werden angepasst um diese Änderungen zu unterstützen. Die endgültige Implementation wird im Rahmen mehrerer Benchmarks ausgewertet und analysiert, wobei sie nahezu native Performanz bei realistischen Arbeitspaketen erreicht und nur einen geringen Komplexitätszuwachs für den Mikrokern bedeutet. Die selbstständige und eigenhändige Ausfertigung versichert an Eides statt: Berlin, den 30. August 2012 Julius Werner 1 Fakultät Elektrotechnik und Informatik Aufgabenstellung für die Masterarbeit Name des Studenten: Julius Werner Studiengang: Informatik Matrikel: 310341 Thema: Verbesserung der Virtualisierungsunterstützung auf dem Fiasco­Mikrokern Zielstellung: Die Anforderungen an Betriebssysteme hinsichtlich Verfügbarkeit, Robustheit gegen Angriff und Unterstützung zahlreicher Legacy­Anwendungen steigen kontinuierlich. Die Implementierung von Virtualisierungsunterstützung auf Mikrokernsystemen konnte diese Anforderungen überzeugend befriedigen. Fiasco.OC ist ein Mikrokern der dritten Generation und bietet Unterstützung für die Virtualisierungsfunktionen aktueller AMD (SVM) und Intel (VT­x) x86­Prozessoren. Die aktuelle Implementierung für VT­x leidet jedoch unter Leistungsdefiziten, insbesondere bei speicherintensiven Anwendungen. Karma ist ein VMM der als Userlevel­Anwendung auf Fiasco.OC läuft. Momentan wird nur Linux als Gastsystem unterstützt. In dieser Masterarbeit soll untersucht werden, wie die bestehenden Leistungs­ und Effizienzdefizite in der derzeitigen VT­x­Implementierung beseitigt werden können. Als Arbeitslast ist dabei ein Linux­ System anzunehmen. Die einzelnen Varianten sind dabei hinsichtlich ihrer Auswirkungen auf Leistungsumfang, Entwicklungsaufwand und Kompatibilität zu bestehender Software zu bewerten. Die am besten beurteilte Variante soll implementiert und anhand von Testszenarien bewertet werden. Verantwortlicher Hochschullehrer: Prof. Dr. Jean­Pierre Seifert Betreuer: Dipl.­Inf. Matthias Lange Institut: Security in Telecommunications (FG SecT) Berlin, 08.05.2012 Unterschrift des verantwortlichen Hochschullehrers 2 Contents 1 Introduction 6 1.1 Goal . 7 1.2 Structure . 8 2 Background 10 2.1 Virtualization . 10 2.1.1 Hardware-Assisted Processor Virtualization . 12 2.1.2 Memory Virtualization and Nested Paging . 15 2.2 Microkernels . 18 2.2.1 Fiasco.OC . 19 3 Related Work 21 3.1 Existing Implementation . 21 3.1.1 Fiasco.OC . 21 3.1.2 Karma . 22 3.1.3 SVM Kernel Shadow Paging . 22 3.2 Comparable Projects . 23 3.2.1 L4Ka::Pistachio . 23 3.2.2 NOVA . 23 3.2.3 KVM . 24 3.2.4 Turtles . 24 4 Design 26 4.1 General Approach . 26 4.2 Fiasco.OC . 27 4.2.1 Page Table Handling . 28 4.2.2 VPID Support . 29 4.3 Karma . 30 5 Implementation 31 5.1 Fiasco.OC . 31 5.1.1 Feature Reporting and Sanitization . 31 5.1.2 Page Table Handling . 32 5.1.3 VPID Support . 33 5.2 Karma . 34 5.2.1 Unpaged Mode Emulation . 34 3 Contents 6 Evaluation 36 6.1 Measurements . 36 6.1.1 Microbenchmark: Fibonacci . 37 6.1.2 Microbenchmark: Forkwait . 38 6.1.3 Microbenchmark: Sockxmit . 39 6.1.4 Microbenchmark: Touchmem . 40 6.1.5 Macrobenchmark: Compiling the Linux Kernel . 41 6.2 Analysis . 42 6.3 Complexity . 43 7 Conclusion 45 7.1 Future Work . 45 Appendix A: Code 47 Glossary 48 Bibliography 50 4 List of Figures 1 Comparison of Type I and Type II hypervisor models . 13 2 Comparison of page table setup in nested and shadow paging . 16 3 Simplified depiction of memory hierarchy in an exemplary Fiasco.OC-based system . 19 4 Comparison of traditional and Intel Extended page table entry format . 27 5 Evaluation results from the Fibonacci microbenchmark . 37 6 Evaluation results from the Forkwait microbenchmark . 38 7 Evaluation results from the Sockxmit microbenchmark . 39 8 Evaluation results from the Touchmem microbenchmark . 40 9 Evaluation results from the Linux kernel compilation macrobenchmark . 41 List of Tables 1 Virtual machine feature reporting bit field format . 28 2 Opcode in bits 11 to 0 of VPID flush control VMCS field . 30 5 1 Introduction As computer systems keep becoming more prevalent in our daily life, their security and reliability is more important than ever. Be it personal computers, mobile and embedded devices, or industrial and financial information systems: most of today’s computers are connected to hostile networks or otherwise exposed to attacks. In addition to that, the multitude of software and hardware components from different vendors with varying quality assurance concepts that work together in a system form a large surface for possible vulnerabilities or defects. Although security and reliability are always dependent on the whole system stack, the operating system is the most critical component: while a vulnerability or defect in a single application may cause that component to fail or be subverted, good operating systems isolate their components from another, thus making the difference between a single loss of functionality and breakdown or subversion of the whole system. Sadly, most mass-market operating systems of today are severely lacking in regards to this isolation. While memory protection between userland processes has long been commonplace, other domains such as the file system allow attacks to easily spread through the system: bound by conventions from a time before malware became prevalent, they often allow every process write access to all resources of its user, regardless of whether it would actually need to do so under normal operation. This clearly violates the principle of least privilege, but the coarse-grained access control lists usually employed by such systems are inherently unsuited to efficiently enforce minimalist permissions on a process level. Therefore, even the most mundane programs often constitute prime targets for attack, as they can be used as a stepping stone to infect more important applications. Realizing this danger, more and more established operating systems expand their security models to provide tighter isolation on request. An increasingly common strategy for this is sandboxing, ranging from the already more than a decade old jail mechanism in FreeBSD to the recently added Seatbelt framework in Mac OS X [1]. Systems like these artificially restrict the resources a process may use, effectively expanding the access control list principle to a per-process basis. However, even this level of granularity may not be precise enough with attack scenarios such as the confused deputy problem: service processes with broad access rights can be tricked by malicious requests to use a valid permission for a different purpose than it was intended for. Preventing this kind of attack requires delegating permissions on a per-request level, as it is possible with other security models such as object capabilities. While there are attempts to graft that model onto existing operating systems, such as the Capsicum framework for FreeBSD [2], they will always be encumbered by the fact that they are late and unexpected additions to an existing environment. Both security
Load more

Recommended publications
  • Extensible Distributed Operating System for Reliable Control Systems
    194 Extensible Distributed Operating System for Reliable Control Systems Katsumi Maruyama, Kazuya Kodama, Soichiro Hidaka, Hiromichi Hashizume National Institute of Informatics, 2-1-2 Hitotsubashi, Chiyoda-ku, Tokyo, Japan Email:{maruyama,kazuya,hidaka,has}@nii.ac.jp Abstract small monitor-like OSs are used. However, these monitor- like OSs lack program protection mechanisms, and program Since most control systems software is hardware-related, development is difficult. real-time-oriented and complex, adaptable OSs which help Therefore, an extensible/adaptable OS for control sys- program productivity and maintainability improvement are tems is required . We are developing a new OS character- in strong demand. ized by: We are developing an adaptable and extensible OS based on micro-kernel and multi-server scheme: each server runs • Use of an efficient and flexible micro-kernel (L4-ka). • Multi-server based modular OS. (Each OS service is in a protected mode interacting only via messages, and implemented as individual user-level process.) could be added/extended/deleted easily. Since this OS is • Robustness. Only the micro-kernel runs in kernel highly modularized, inter-process messaging overhead is a mode and in kernel space. Other modules run in a pro- concern. Our implementation proved good efficiency and tected user space and mode. maintainability. • Hardware driver programs in user-level process. • Flexible distributed processing by global message passing. 1. Introduction This OS structure proved to enhance OS modularity and ease of programming. However, inter-process messaging Most systems, from large scale public telephone switch- overhead should be considered . We measured the overhead, ing systems to home electronics, are controlled by software, and the overhead was proved to be small enough.
    [Show full text]
  • Capabilities
    CS 261, Fall 2015 Scribe notes September 8: Capabilities Scribe: Riyaz Faizullabhoy 1 Motivation for Capabilities In The Confused Deputy, the compiler had two sets of rights: one from the user to access user files such as source code to compile, and another set granted to the compiler intended to access a special statistics file that would collect information about language feature usage. The compiler was installed in the SYSX directory, where it was granted access to write to any file in this directory. Naturally, the statistics file SYSX/STAT was also located in this directory such that the compiler (SYSX/FORT) could add language feature information. To achieve this, the compiler's privileges were set with a home files license that was allowed by the operating system to write to any file in the SYSX directory. A billing information file SYSX/BILL was also stored in SYSX { due to its sensitive nature, this billing file was not directly accessible to users. However, since the compiler was granted access to the entire SYSX directory, users could subvert their access restrictions on the billing information file by using the compiler like so: SYSX/FORT foo.f -o SYSX/BILL The above user-invoked command to the compiler would allow the compiler to first read the user's source code in foo.f, but then the compiler's privilege to SYSX would cause the SYSX/BILL file to be overwritten with the user's binary. In effect, the compiler is the confused deputy having to reconcile both its own and the user's set of privileges, but unfortunately allows for unintended behavior.
    [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]
  • 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]
  • Runtime Data Driven Partitioning of Linux Code
    This is the author's version of an article that has been published in this journal. Changes were made to this version by the publisher prior to publication. The final version of record is available at http://dx.doi.org/10.1109/TDSC.2017.2745574 1 How to Fillet a Penguin: Runtime Data Driven Partitioning of Linux Code Oliver Schwahn, Stefan Winter, Nicolas Coppik, and Neeraj Suri Abstract—In many modern operating systems (OSs), there exists no isolation between different kernel components, i.e., the failure of one component can affect the whole kernel. While microkernel OSs introduce address space separation for large parts of the OS, their improved fault isolation comes at the cost of performance. Despite significant improvements in modern microkernels, monolithic OSs like Linux are still prevalent in many systems. To achieve fault isolation in addition to high performance and code reuse in these systems, approaches to move only fractions of kernel code into user mode have been proposed. These approaches solely rely on static code analyses for deciding which code to isolate, neglecting dynamic properties like invocation frequencies. We propose to augment static code analyses with runtime data to achieve better estimates of dynamic properties for common case operation. We assess the impact of runtime data on the decision what code to isolate and the impact of that decision on the performance of such “microkernelized” systems. We extend an existing tool chain to implement automated code partitioning for existing monolithic kernel code and validate our approach in a case study of two widely used Linux device drivers and a file system.
    [Show full text]
  • 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.
    [Show full text]
  • Capsicum Slides
    Capsicum Capability-Based Sandboxing David Drysdale Google UK Features Current LXC uses the following kernel features to contain processes: ● Kernel namespaces (ipc, uts, mount, pid, network and user) ● Apparmor and SELinux profiles ● Seccomp policies ● Chroots (using pivot_root) ● Kernel capabilities ● CGroups (control groups) Agenda ● Ideas ○ Privilege Separation ○ Capabilities ● Capsicum ○ Hybrid with POSIX ○ Application changes ● Linux container features ● Status/Outlook Check Your Privileges ● Drop unnecessary privileges ○ Just because a process starts as root, doesn't have to stay that way Check Your Privileges ● Drop unnecessary privileges ○ Just because a process starts as root, doesn't have to stay that way ● Divide up software according to what privileges are needed ○ E.g. separate media processing from credentials processing Check Your Privileges ● Drop unnecessary privileges ○ Just because a process starts as root, doesn't have to stay that way ● Divide up software according to what privileges are needed ○ E.g. separate media processing from credentials processing ● Examples: ○ OpenSSH: credential checking process ○ Chrome: renderer processes ● Design impact: ○ Do privileged operations first ○ Pass resources down a privilege gradient Capability-Based Security ● Make the privileges that a process holds more explicit Capability-Based Security ● Make the privileges that a process holds more explicit ● Access objects via unforgeable token: the capability ○ Identifies the object ○ Accompanying rights give allowed operations ○ Can only reduce, not increase rights ○ Can pass capabilities around Capability-Based Security ● Make the privileges that a process holds more explicit ● Access objects via unforgeable token: the capability ○ Identifies the object ○ Accompanying rights give allowed operations ○ Can only reduce, not increase rights ○ Can pass capabilities around ● Remove other ways of accessing objects ○ No access by name, i.e.
    [Show full text]
  • Semperos: a Distributed Capability System
    SemperOS: A Distributed Capability System Matthias Hille† Nils Asmussen† ∗ Pramod Bhatotia‡ Hermann Härtig† ∗ †Technische Universität Dresden ‡The University of Edinburgh ∗ Barkhausen Institut Abstract systems have received renewed attention recently to provide Capabilities provide an efficient and secure mechanism for an efficient and secure mechanism for resource management fine-grained resource management and protection. However, in modern hardware architectures [5, 24, 30, 36, 44, 64, 67]. as the modern hardware architectures continue to evolve Today the main improvements in compute capacity with large numbers of non-coherent and heterogeneous cores, are achieved by either adding more cores or integrating we focus on the following research question: can capability accelerators into the system. However, the increasing core systems scale to modern hardware architectures? counts exacerbate the hardware complexity required for global In this work, we present a scalable capability system to drive cache coherence. While on-chip cache coherence is likely to future systems with many non-coherent heterogeneous cores. remain a feature of future hardware architectures [45], we see More specifically, we have designed a distributed capability characteristics of distributed systems added to the hardware system based on a HW/SW co-designed capability system. by giving up on global cache coherence across a whole We analyzed the pitfalls of distributed capability operations machine [6, 28]. Additionally, various kinds of accelerators running concurrently and built the protocols in accordance are added like the Xeon Phi Processor, the Matrix-2000 accel- with the insights. We have incorporated these distributed erator, GPUs, FPGAs, or ASICs, which are used in numerous capability management protocols in a new microkernel-based application fields [4,21,32,34,43,60].
    [Show full text]
  • L4 Microkernel
    L4 Microkernel See final slide for sources Presented by Michael LeMay L4 Advantages ● Recursive construction of memory spaces – Allows construction of memory managers in userspace that just use memory mapping – Kernel provides map, grant, and flush ● Blazing fast IPC – Passes short messages in registers – Avoids copying large messages and thus avoids TLB flushes and cache misses – Lazy scheduling of thread queues improves small message IPC around 25% L4 Performance OS Microseconds Instructions Mach 115 1150 L4 5 50 Exokernel 1.4 30 SPIN 102 1100 (Exokernel runs on MIPS R2000, which operates more efficiently than the x86 for L4, and has a tagged TLB. It also does not provide a portable API.) L4 Conceptual Contributions ● The author of the L4 paper, Jochen Liedtke, showed that microkernels do not inherently: – Exhibit slow IPC – Impose significant processor overhead ● Instead, he showed that particular implementations are to blame: – Mach was causing lots of cache misses because it's fat, making it look like microkernels have high overhead Microkernel Non-portability ● Liedtke argues that microkernels should be non- portable, but present a uniform API: – Abstract microkernels require additional hardware abstraction layer – Can't take advantage of specific performance-enhancing hardware features – Can't protect against peculiar hardware performance pitfalls L4 Subprojects http://www.dakotacountyswcd.org/treetype.htm ● L3 – Predecessor to L4 ● FIASCO – C++ implementation of L4, poor performer in comparison to “Pip” series ● L4Ka – Most active
    [Show full text]
  • The L4 Ecosystem
    Faculty of Computer Science, Operating Systems Group The L4 ecosystem Berlin, Dec 2004 System Issues ● Convential systems are ● Complex ● Linux kernel at least 500,000 LoC ● Prone to errors ● Drivers ● All system components run in privileged mode ● Inflexible ● Global policies ● Large Trusted Computing Base (TCB) 27.12.04 Adam Lackorzynski, Michael Peter Folie 2 Insights Observation: Most kernel functionality does not need CPU privileges, like: – Filesystems – Driver functionality – User management 27.12.04 Adam Lackorzynski, Michael Peter Folie 3 What is really needed Jochen Liedtke: “A microkernel does no real work” Kernel provides only inevitable mechanisms No policies enforced by the kernel What is inevitable? Abstractions Mechanisms . Threads . Communication . Scheduling . Address Spaces . Safe construction This should be sufficient for everything 27.12.04 Adam Lackorzynski, Michael Peter Folie 4 The Marred Perception of Microkernels • Supposed to be slow – Not true any more • No obvious benefit – Infamous dispute Torvalds vs. Tannenbaum – How much worth is manageability of complexity? • GNU Hurd – Late – Slow – Constantly lagging behind other OS in functionality 27.12.04 Adam Lackorzynski, Michael Peter Folie 5 The Case for Microkernels • Complexity needs to be handled – Structure beyond monolithic kernels are needed – Several candidates • Virtualisation • Paravirtualisation • Microkernel • Implementation of some functionality is even simplified – Real time • DROPS • RTLinux – Security • Substantially smaller trusted computing
    [Show full text]
  • Rust and IPC on L4re”
    Rust and Inter-Process Communication (IPC) on L4Re Implementing a Safe and Efficient IPC Abstraction Name Sebastian Humenda Supervisor Dr. Carsten Weinhold Supervising Professor Prof. Dr. rer. nat. Hermann Härtig Published at Technische Universität Dresden, Germany Date 11th of May 2019 Contents 1 Introduction 5 2 Fundamentals 8 2.1 L4Re . 8 2.2 Rust....................................... 11 2.2.1 Language Basics . 11 2.2.2 Ecosystem and Build Tools . 14 2.2.3 Macros . 15 3 Related Work 17 3.1 Rust RPC Libraries . 17 3.2 Rust on Other Microkernels . 18 3.3 L4Re IPC in Other Languages . 20 3.4 Discussion . 21 3.4.1 Remote Procedure Call Libraries . 21 3.4.2 IDL-based interface definition . 22 3.4.3 L4Re IPC Interfaces In Other Programming Languages . 23 4 L4Re and Rust Infrastructure Adaptation 24 4.1 Build System Adaptation . 25 4.1.1 Libraries . 26 4.1.2 Applications . 27 4.2 L4rust Libraries . 29 4.2.1 L4 Library Split . 29 4.2.2 Inlining vs. Reimplementing . 30 4.3 Rust Abstractions . 31 4.3.1 Error Handling . 31 4.3.2 Capabilities . 32 5 IPC Framework Implementation 35 5.1 A Brief Overview of the C++ Framework . 36 5.2 Rust Interface Definition . 37 5.2.1 Channel-based Communication . 37 5.2.2 Macro-based Interface Definition . 39 5.3 Data Serialisation . 43 2 5.4 Server Loop . 46 5.4.1 Vector-based Service Registration . 46 5.4.2 Pointer-based Service Registration . 48 5.5 Interface Export . 52 5.6 Implementation Tests .
    [Show full text]
  • KOS - Principles, Design, and Implementation
    KOS - Principles, Design, and Implementation Martin Karsten, University of Waterloo Work In Progress - September 29, 2015 Abstract KOS is an experimental operating system kernel that is designed to be simple and accessible to serve as a platform for research, experimen- tation, and teaching. The overall focus of this project is on system-level infrastructure software, in particular runtime systems. 1 Introduction KOS (pronounce "Chaos") is an experimental operating system kernel that is designed to be simple and accessible to serve as a platform for research, ex- perimentation, and teaching. It is focused on building a nucleus kernel that provides the basic set of operating system functionality, primarily for resource mediation, that must realistically be implemented for execution in privileged mode. While being simple KOS is not simplistic and avoids taking design shortcuts that would prohibit adding more sophisticated resource management strategies later on { inside the kernel or at higher software layers. The nu- cleus kernel is augmented with several prototype subsystems typically found in an operating system to eventually support running realistic applications. The entire code base is written in C++, except for small assembler parts. The C++ code makes use of advanced language features, such as code reuse with efficient strong type safety using templates, the C++ library for data struc- ture reuse, as well as (limited) polymorphism. Existing open-source software is reused for non-nucleus subsystems as much as possible. The project is hosted at https://git.uwaterloo.ca/mkarsten/KOS 2 Motivation In principle, an operating system has two basic functions. First, it consolidates low-level hardware interfaces and provides higher-level software abstractions to facilitate and alleviate application programming.
    [Show full text]