Operating System Protection for Fine-Grained Programs

Total Page:16

File Type:pdf, Size:1020Kb

Operating System Protection for Fine-Grained Programs The following paper was originally published in the Proceedings of the 7th USENIX Security Symposium San Antonio, Texas, January 26-29, 1998 Operating System Protection for Fine-Grained Programs Trent Jaeger, Jochen Liedtke, and Nayeem Islam IBM T.J. Watson Research Center For more information about USENIX Association contact: 1. Phone: 510 528-8649 2. FAX: 510 548-5738 3. Email: [email protected] 4. WWW URL:http://www.usenix.org/ Op erating System Protection for Fine-Grained Programs Trent Jaeger Jo chen Liedtke Nayeem Islam IBM T. J. Watson Research Center Hawthorne, NY 10532 Emails:fjaegertjjo [email protected] m.comg Abstract numb er of protection domain crossings must b e han- dled securely i.e., correctly with resp ect to the secu- We present an op erating system-level security mo del rity requirements to prevent attacks and eciently for controlling ne-grained programs, suchasdown- to minimize p erformance degradation. In this pap er, loaded executable content, and compare this security we show that a security mo del implemented on a fast mo del's implementation to that of language-based and exible IPC mechanism can enforce security re- security mo dels. Language-based security has well- quirements that language-based systems cannot with known limitations, such as the lack of complete me- little p erformance impact. diation e.g., for compiled programs or race condi- Several op erating systems use hardware-based tion attacks and faulty self-protection e ective secu- protection to prevent pro cesses from inadvertently rity is unproven. Op erating system-level mo dels are and/or maliciously mo difying one another. Each capable of complete mediation and self-protection, pro cess has an address space that de nes a set of but some researchers argue that op erating system- memory segments and the pro cess's access rights to level security mo dels are unlikely to supplant such those segments. A pro cess can only access memory language-based mo dels b ecause they lack p ortability in its own address space. In addition, the op erating and p erformance. In this pap er, we detail an op er- system has a security mo del that asso ciates pro cesses ating system-level security mo del built on the Lava with their access rights to system resources. Using Nucleus, a minimal, fast -kernel op erating system. address spaces of suitable granularity and pro cess ac- We showhow it can enforce security requirements cess rights to controlled resources, an op erating sys- for ne-grained programs and show that its p erfor- tem can control a pro cess's op erations as desired. mance overhead with the additional security can However, op erating system security mo dels have b e virtually negligible when compared to language- b een deemed to lack the p erformance and exibility based mo dels. Given the sucient p erformance and necessary to control ne-grained programs. While security, the p ortability issue should b ecome mo ot some systems have b een built that eciently con- b ecause other vendors will have to meet the higher trol pro cesses in dynamically-de ned protection do- security and p erformance exp ectations of their cus- mains [3,8, 14], these systems have b een applied tomers. only to more traditional applications e.g., PostScript interpreters. In an application comp osed of ne- grained programs, programs with di erent protection 1 Intro duction domains interact often p erhaps as much as on each metho d invo cation. In a recent pap er, Wallach et We demonstrate how op erating system protection can al. [25] discard address space-based protection from b e used to control ne-grained programs exibly and consideration for applications with ne-grained pro- eciently. Op erating systems use hardware-based grams by noting that IPC b etween two COM ob jects protection to isolate pro cesses from one another. on Windows NT takes 1000 times longer than a pro- However, the way that current op erating systems cedure call 230 sto0.2s. We claim that this implement this protection has caused researchers to discrepancy can b e virtually eliminated while gaining deem them to o slow and in exible for controlling ne- security and maintaining exibility. grained programs. Fine-grained programs have dif- ferent protection domains and mayinteract often in Wehave develop ed a prototyp e implementation of the course of a computation. The e ect of a large a exible security mo del for controlling downloaded content. This mo del is implemented on the Lava Nu- individual content. The securitykernel must b e able cleus. The Lava Nucleus provides address spaces, to mediate all controlled op erations. To enforce least threads, fast IPC, exible paging, and IPC inter- privilege on content p ermissions may b e based on ap- ception that enable ecient and exible control of plication state and evolve as application state evolves. pro cesses. In this pap er, we primarily concentrate on The securitykernel must b e able to control this evolu- the e ectiveness of the Lavanucleus for implement- tion within reasonable limits. Lastly, the kernel must ing a exible security mo del and its resultant p er- b e able to protect itself from mo di cations that may formance. We show that fast IPC and IPC intercep- result in tamp ering with its b ehavior. tion enable the implementationof dynamical ly autho- A question that has re-app eared recently is whether rized IPC that can b e p erformed in as little as 9.5 s. language-based or op erating system-based protection We b elieve further ro om for optimziation is p ossible, is b etter suited for e ectively and eciently control- given an ideal estimate for dynamically authorized ling such ne-grained programs. Or otherwise stated: IPC is ab out 4 s. Also, exible page mapping in the to what extent can op erating system protection e- Lava Nucleus enables ob jects of size greater than the ciently provide e ective security and to what extent hardware page size to b e shared among pro cesses, so can language protection e ectively provide ecient coarse-grained sharing of memory b etween pro cesses security? As describ ed b elow, op erating system pro- is p ossible. tection has several advantages over language protec- The structure of this pap er is as follows. In Sec- tion from a security p ersp ective, but the cost of do- tion 2, we compare language-based and op erating main crossings make it questionable whether ecient system-based security mo dels. In Section 3, we de- op erating system protection for ne-grained pro cesses scrib e an op erating system security mo del for down- is p ossible. On the other hand, language protection loaded executable content. In Section 4, we describ e can b e implemented eciently, but some key security the implementation of this mo del on the Lava Nu- safeguards are weakened such that e ective security cleus. In Section 5, we examine the p erformance of may b e lost. the prototyp e implementation and compare its p er- Traditionally, op erating systems have enforced sys- formance to language-based mo dels for ne-grained tem security requirements b ecause hardware-based programs of the sort discussed byWallach et al. In protection provides signi cant advantages in the key Section 6, we conclude and present future work. areas of economy of mechanism, fail-safe defaults, and complete mediation [23]. The op erating system's TCB can protect pro cesses by restricting them to 2 Language vs. O/S Protection their own address spaces which can b e enforced by a simple mechanism at least compared to a com- The basic problem is to implement a securitykernel piler. Since only the program requested is placed in that e ectively and eciently enforces the security the address space, other, indep endent programs are requirements of downloaded executable content. The not a ected by its failure assuming the op erating basic requirements of any security infrastructure are 1 system adequately protects itself from such failures. that it can adapted from [2]: Also, since the op erating system can intercept any in- terpro cess communication IPC b etween pro cesses, assign p ermissions dynamically to individual controlled op erations by a program including com- content, piled ones can b e completely mediated by the op er- mediate all controlled op erations using such p er- ating system. missions i.e., an op eration that a pro cess is not Language-based protection has gained favor in re- unconditionally trusted to invoke, centyears, however. We attribute this p opularity to three factors: 1 improvements in the develop- manage the evolution of p ermissions as content ment of \safe" languages; 2 the p erception that is executed, programs will b ecome increasingly ne-grained, and protect itself from tamp ering ne-grained domains are prohibitively exp ensiveto enforce; and 3 lack of exibility in op erating system For a system that uses dynamically downloaded ex- security mo dels. \Typ e-safe" languages are strongly- ecutable content, p ermissions must b e assignable to typ ed i.e., all data is typ ed and casting is restricted 1 There is an additional requirement that any \securityker- or prohibited and do not p ermit direct addressing nel" b e simple enough that indep endentevaluators can assess of the system's memory i.e., no p ointers. There- whether it will op erate prop erly. While we will not prove such fore, all data is accessed according to its interface, so a feature ab out our system here we do attempt to keep the security mo del as simple as is feasible.
Recommended publications
  • Improving Learning of Programming Through E-Learning by Using Asynchronous Virtual Pair Programming
    Improving Learning of Programming Through E-Learning by Using Asynchronous Virtual Pair Programming Abdullah Mohd ZIN Department of Industrial Computing Faculty of Information Science and Technology National University of Malaysia Bangi, MALAYSIA Sufian IDRIS Department of Computer Science Faculty of Information Science and Technology National University of Malaysia Bangi, MALAYSIA Nantha Kumar SUBRAMANIAM Open University Malaysia (OUM) Faculty of Information Technology and Multimedia Communication Kuala Lumpur, MALAYSIA ABSTRACT The problem of learning programming subjects, especially through distance learning and E-Learning, has been widely reported in literatures. Many attempts have been made to solve these problems. This has led to many new approaches in the techniques of learning of programming. One of the approaches that have been proposed is the use of virtual pair programming (VPP). Most of the studies about VPP in distance learning or e-learning environment focus on the use of the synchronous mode of collaboration between learners. Not much research have been done about asynchronous VPP. This paper describes how we have implemented VPP and a research that has been carried out to study the effectiveness of asynchronous VPP for learning of programming. In particular, this research study the effectiveness of asynchronous VPP in the learning of object-oriented programming among students at Open University Malaysia (OUM). The result of the research has shown that most of the learners have given positive feedback, indicating that they are happy with the use of asynchronous VPP. At the same time, learners did recommend some extra features that could be added in making asynchronous VPP more enjoyable. Keywords: Pair-programming; Virtual Pair-programming; Object Oriented Programming INTRODUCTION Delivering program of Information Technology through distance learning or E- Learning is indeed a very challenging task.
    [Show full text]
  • The Joe-E Language Specification (Draft)
    The Joe-E Language Specification (draft) Adrian Mettler David Wagner famettler,[email protected] February 3, 2008 Disclaimer: This is a draft version of the Joe-E specification, and is subject to change. Sections 5 - 7 mention some (but not all) of the aspects of the Joe-E language that are future work or current works in progress. 1 Introduction We describe the Joe-E language, a capability-based subset of Java intended to make it easier to build secure systems. The goal of object capability languages is to support the Principle of Least Authority (POLA), so that each object naturally receives the least privilege (i.e., least authority) needed to do its job. Thus, we hope that Joe-E will support secure programming while remaining familiar to Java programmers everywhere. 2 Goals We have several goals for the Joe-E language: • Be familiar to Java programmers. To minimize the barriers to adoption of Joe-E, the syntax and semantics of Joe-E should be familiar to Java programmers. We also want Joe-E programmers to be able to use all of their existing tools for editing, compiling, executing, debugging, profiling, and reasoning about Java code. We accomplish this by defining Joe-E as a subset of Java. In general: Subsetting Principle: Any valid Joe-E program should also be a valid Java program, with identical semantics. This preserves the semantics Java programmers will expect, which are critical to keeping the adoption costs manageable. Also, it means all of today's Java tools (IDEs, debuggers, profilers, static analyzers, theorem provers, etc.) will apply to Joe-E code.
    [Show full text]
  • 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].
    [Show full text]
  • Tahoe-LAFS Documentation Release 1.X
    Tahoe-LAFS Documentation Release 1.x The Tahoe-LAFS Developers January 19, 2017 Contents 1 Welcome to Tahoe-LAFS! 3 1.1 What is Tahoe-LAFS?..........................................3 1.2 What is “provider-independent security”?................................3 1.3 Access Control..............................................4 1.4 Get Started................................................4 1.5 License..................................................4 2 Installing Tahoe-LAFS 5 2.1 First: In Case Of Trouble.........................................5 2.2 Pre-Packaged Versions..........................................5 2.3 Preliminaries...............................................5 2.4 Install the Latest Tahoe-LAFS Release.................................6 2.5 Running the tahoe executable.....................................8 2.6 Running the Self-Tests..........................................8 2.7 Common Problems............................................9 2.8 Using Tahoe-LAFS............................................9 3 How To Run Tahoe-LAFS 11 3.1 Introduction............................................... 11 3.2 Do Stuff With It............................................. 12 3.3 Socialize................................................. 13 3.4 Complain................................................. 13 4 Configuring a Tahoe-LAFS node 15 4.1 Node Types................................................ 16 4.2 Overall Node Configuration....................................... 16 4.3 Connection Management........................................
    [Show full text]
  • Comparative Studies of 10 Programming Languages Within 10 Diverse Criteria Revision 1.0
    Comparative Studies of 10 Programming Languages within 10 Diverse Criteria Revision 1.0 Rana Naim∗ Mohammad Fahim Nizam† Concordia University Montreal, Concordia University Montreal, Quebec, Canada Quebec, Canada [email protected] [email protected] Sheetal Hanamasagar‡ Jalal Noureddine§ Concordia University Montreal, Concordia University Montreal, Quebec, Canada Quebec, Canada [email protected] [email protected] Marinela Miladinova¶ Concordia University Montreal, Quebec, Canada [email protected] Abstract This is a survey on the programming languages: C++, JavaScript, AspectJ, C#, Haskell, Java, PHP, Scala, Scheme, and BPEL. Our survey work involves a comparative study of these ten programming languages with respect to the following criteria: secure programming practices, web application development, web service composition, OOP-based abstractions, reflection, aspect orientation, functional programming, declarative programming, batch scripting, and UI prototyping. We study these languages in the context of the above mentioned criteria and the level of support they provide for each one of them. Keywords: programming languages, programming paradigms, language features, language design and implementation 1 Introduction Choosing the best language that would satisfy all requirements for the given problem domain can be a difficult task. Some languages are better suited for specific applications than others. In order to select the proper one for the specific problem domain, one has to know what features it provides to support the requirements. Different languages support different paradigms, provide different abstractions, and have different levels of expressive power. Some are better suited to express algorithms and others are targeting the non-technical users. The question is then what is the best tool for a particular problem.
    [Show full text]
  • Scalability of Microkernel-Based Systems
    Scalability of Microkernel-Based Systems Zur Erlangung des akademischen Grades eines DOKTORS DER INGENIERWISSENSCHAFTEN von der Fakultat¨ fur¨ Informatik der Universitat¨ Fridericiana zu Karlsruhe (TH) genehmigte DISSERTATION von Volkmar Uhlig aus Dresden Tag der mundlichen¨ Prufung:¨ 30.05.2005 Hauptreferent: Prof. Dr. rer. nat. Gerhard Goos Universitat¨ Fridericiana zu Karlsruhe (TH) Korreferent: Prof. Dr. sc. tech. (ETH) Gernot Heiser University of New South Wales, Sydney, Australia Karlsruhe: 15.06.2005 i Abstract Microkernel-based systems divide the operating system functionality into individ- ual and isolated components. The system components are subject to application- class protection and isolation. This structuring method has a number of benefits, such as fault isolation between system components, safe extensibility, co-existence of different policies, and isolation between mutually distrusting components. How- ever, such strict isolation limits the information flow between subsystems including information that is essential for performance and scalability in multiprocessor sys- tems. Semantically richer kernel abstractions scale at the cost of generality and mini- mality–two desired properties of a microkernel. I propose an architecture that al- lows for dynamic adjustment of scalability-relevant parameters in a general, flex- ible, and safe manner. I introduce isolation boundaries for microkernel resources and the system processors. The boundaries are controlled at user-level. Operating system components and applications can transform their semantic information into three basic parameters relevant for scalability: the involved processors (depending on their relation and interconnect), degree of concurrency, and groups of resources. I developed a set of mechanisms that allow a kernel to: 1. efficiently track processors on a per-resource basis with support for very large number of processors, 2.
    [Show full text]
  • Concepts of Programming Languages, Eleventh Edition, Global Edition
    GLOBAL EDITION Concepts of Programming Languages ELEVENTH EDITION Robert W. Sebesta digital resources for students Your new textbook provides 12-month access to digital resources that may include VideoNotes (step-by-step video tutorials on programming concepts), source code, web chapters, quizzes, and more. Refer to the preface in the textbook for a detailed list of resources. Follow the instructions below to register for the Companion Website for Robert Sebesta’s Concepts of Programming Languages, Eleventh Edition, Global Edition. 1. Go to www.pearsonglobaleditions.com/Sebesta 2. Click Companion Website 3. Click Register and follow the on-screen instructions to create a login name and password Use a coin to scratch off the coating and reveal your access code. Do not use a sharp knife or other sharp object as it may damage the code. Use the login name and password you created during registration to start using the digital resources that accompany your textbook. IMPORTANT: This access code can only be used once. This subscription is valid for 12 months upon activation and is not transferable. If the access code has already been revealed it may no longer be valid. For technical support go to http://247pearsoned.custhelp.com This page intentionally left blank CONCEPTS OF PROGRAMMING LANGUAGES ELEVENTH EDITION GLOBAL EDITION This page intentionally left blank CONCEPTS OF PROGRAMMING LANGUAGES ELEVENTH EDITION GLOBAL EDITION ROBERT W. SEBESTA University of Colorado at Colorado Springs Global Edition contributions by Soumen Mukherjee RCC Institute
    [Show full text]
  • PROGRAMMING LANGUAGES TENTH EDITION This Page Intentionally Left Blank CONCEPTS of PROGRAMMING LANGUAGES TENTH EDITION
    CONCEPTS OF PROGRAMMING LANGUAGES TENTH EDITION This page intentionally left blank CONCEPTS OF PROGRAMMING LANGUAGES TENTH EDITION ROBERT W. SEBESTA University of Colorado at Colorado Springs Boston Columbus Indianapolis New York San Francisco Upper Saddle River Amsterdam Cape Town Dubai London Madrid Milan Munich Paris Montreal Toronto Delhi Mexico City Sao Paulo Sydney Hong Kong Seoul Singapore Taipei Tokyo Vice President and Editorial Director, ECS: Senior Production Project Manager: Marilyn Lloyd Marcia Horton Manufacturing Manager: Nick Sklitsis Editor in Chief: Michael Hirsch Operations Specialist: Lisa McDowell Executive Editor: Matt Goldstein Cover Designer: Anthony Gemmellaro Editorial Assistant: Chelsea Kharakozova Text Designer: Gillian Hall Vice President Marketing: Patrice Jones Cover Image: Mountain near Pisac, Peru; Marketing Manager: Yez Alayan Photo by author Marketing Coordinator: Kathryn Ferranti Media Editor: Dan Sandin Marketing Assistant: Emma Snider Full-Service Vendor: Laserwords Vice President and Director of Production: Project Management: Gillian Hall Vince O’Brien Printer/Binder: Courier Westford Managing Editor: Jeff Holcomb Cover Printer: Lehigh-Phoenix Color This book was composed in InDesign. Basal font is Janson Text. Display font is ITC Franklin Gothic. Copyright © 2012, 2010, 2008, 2006, 2004 by Pearson Education, Inc., publishing as Addison-Wesley. All rights reserved. Manufactured in the United States of America. This publication is protected by Copy- right, and permission should be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. To obtain permission(s) to use material from this work, please submit a written request to Pearson Education, Inc., Permissions Department, One Lake Street, Upper Saddle River, New Jersey 07458, or you may fax your request to 201-236-3290.
    [Show full text]
  • Genode Operating System Framework Platforms
    GENODE Operating System Framework 21.05 Platforms Norman Feske Contents Contents 1 Introduction3 2 Porting Genode to a new SoC4 2.1 Preparatory steps................................9 2.1.1 Licensing considerations........................9 2.1.2 Selecting a suitable SoC........................ 10 2.1.3 Start by taking the known-good path................ 11 2.1.4 Setting up an efficient development workflow........... 12 2.2 Getting acquainted with the target platform................. 14 2.2.1 Getting a first impression....................... 15 2.2.2 The U-Boot boot loader........................ 19 2.3 Bare-metal serial output............................ 24 2.4 Kernel skeleton................................. 34 2.4.1 A tour through the code base..................... 34 2.4.2 A new home for the board support.................. 41 2.4.3 Getting to grips using meaningful numbers............. 48 2.4.4 A first life sign of the kernel...................... 55 2.5 Low-level debugging.............................. 57 2.5.1 Option 1: Walking the source code.................. 58 2.5.2 Option 2: One step of ground truth at a time............ 60 2.5.3 Option 3: Backtraces.......................... 62 2.6 Excursion to the user land........................... 64 2.7 Device access from the user level....................... 73 2.7.1 Using a GPIO pin for sensing a digital signal............ 74 2.7.2 Driving an LED via a GPIO pin.................... 81 2.7.3 Responding to device interrupts................... 84 2.8 One Platform driver to rule them all..................... 90 2.8.1 Platform driver............................. 90 2.8.2 Session interfaces for accessing pins................. 95 2.8.3 PIO device driver............................ 96 2.8.4 Dynamic configuration testing...................
    [Show full text]
  • Genode Operating System Framework Foundations
    GENODE Operating System Framework 15.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........................ 30 2.5.4. Defining a system scenario...................... 31 3. Architecture 33 3.1. Capability-based security........................... 35 3.1.1. Capability spaces, object identities, and RPC objects........ 35 3.1.2. Delegation of authority and ownership............... 36 3.1.3. Capability invocation......................... 37 3.1.4. Capability delegation through capability invocation........ 40 3.2. Recursive system structure........................... 42 3.2.1. Component ownership......................... 42 3.2.2. Tree of components........................... 43 3.2.3. Services and sessions.......................... 43 3.2.4. Client-server relationship....................... 46 3.3. Resource trading................................ 50 3.3.1. Resource
    [Show full text]
  • Cloud Services in the Guifi.Net Community Network
    “NOTICE: this is the author’s version of a work that was accepted for publication in <Computer networks>. Changes resulting from the publishing process, such as peer review, editing, corrections, structural formatting, and other quality control mechanisms may not be reflected in this document. Changes may have been made to this work since it was submitted for publication. A definitive version was subsequently published in COMPUTER NETWORKS, [VOL 93, PART 2, (24 December 2015)] DOI 10.1016/j.comnet.2015.09.007 Cloud Services in the Guifi.net Community Network Mennan Selimia,∗, Amin M. Khana, Emmanouil Dimogerontakisa, Felix Freitaga, Roger Pueyo Centellesb a Department of Computer Architecture, Universitat Politècnica de Catalunya BarcelonaTech, Spain b Fundació Privada per a la Xarxa Oberta, Lliure i Neutral Guifi.net, Catalonia, Spain Abstract Internet and communication technologies have lowered the costs to collaborate for communities, leading to new services like user-generated content and social computing and, through collaboration, collectively built infrastructures, such as community networks. Community networks are formed when individuals and local organisations from a geographic area team up to create and run a community-owned IP network to satisfy the community’s demand for ICT. Internet access is often considered the main service of community networks, but the provision of services of local interest within the network is a unique opportunity for community networks, which is currently predominantly unexplored. The consolidation of today’s cloud technologies offers community networks the possibility to collectively build community clouds, building upon user-provided networks, and extending towards an ecosystem of cloud services. We propose a framework for building a collaborative distributed community cloud system that employs resources contributed by the members of the community network for provisioning infrastructure and software services.
    [Show full text]
  • An Interpreted Operating System
    Faculty for Computer Science Operating Systems Group Master Thesis Summer semester 2018 PylotOS - an interpreted Operating System Submitted by: Naumann, Stefan [email protected] Programme of study: Master Informatik 3rd semester Matriculation number: XXXXXX Supervisors: Christine Jakobs Dr. Peter Tröger Prof. Dr. Matthias Werner Submission deadline: 11th July 2018 Contents 1. Introduction 1 2. Preliminary Considerations 3 2.1. Textbook Operating System Architecture . 3 2.1.1. Processes and Interprocess Communication . 4 2.1.2. Driver Model . 6 2.2. Platform Considerations . 9 2.2.1. Intel x86 . 9 2.2.2. Raspberry Pi . 11 3. Existing Implementations 13 3.1. Related Work . 13 3.2. The C subroutine library . 15 3.2.1. Device drivers and files . 15 3.2.2. Process Management . 16 3.3. 4.3BSD . 16 3.3.1. Process Management . 16 3.3.2. Interprocess Communication . 19 3.3.3. Driver Architecture . 21 3.3.4. System Start-up . 23 3.4. Linux 2.6 . 26 3.4.1. Handling Interrupts and Exceptions . 26 3.4.2. Linux I/O Architecture and device drivers . 30 3.4.3. Levels of kernel support for a device . 33 3.5. Windows 2000 . 34 3.5.1. Interrupt Handling . 34 3.5.2. I/O System . 36 3.5.3. I/O Manager . 37 3.5.4. Structure of a Driver . 39 3.5.5. Plug and Play . 40 3.5.6. Power Manager . 41 3.5.7. I/O Data Structures (ntddk.h) . 42 3.6.JX ................................................... 43 3.6.1. Architectural Overview . 44 3.6.2.
    [Show full text]