DOCSLIB.ORG

FAULT ISOLATION 37 3.1 Isolationprinciples

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
FAULT ISOLATION 37 3.1 Isolationprinciples VU Research Portal Building a dependable operating system: fault tolerance in MINIX 3 Herder, J.N. 2010 document version Publisher's PDF, also known as Version of record Link to publication in VU Research Portal citation for published version (APA) Herder, J. N. (2010). Building a dependable operating system: fault tolerance in MINIX 3. General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal ? Take down policy If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim. E-mail address: [email protected] Download date: 02. Oct. 2021 BUILDING A DEPENDABLE OPERATING SYSTEM: FAULT TOLERANCE IN MINIX 3 VRIJE UNIVERSITEIT BUILDING A DEPENDABLE OPERATING SYSTEM: FAULT TOLERANCE IN MINIX 3 ACADEMISCH PROEFSCHRIFT ter verkrijging van de graad Doctor aan de Vrije Universiteit Amsterdam, op gezag van de rector magnificus prof.dr. L.M. Bouter, in het openbaar te verdedigen ten overstaan van de promotiecommissie van de faculteit der Exacte Wetenschappen op donderdag 9 september 2010 om 13.45 uur in de aula van de universiteit, De Boelelaan 1105 door JORRIT NIEK HERDER geboren te Alkmaar promotor: prof.dr. A.S. Tanenbaum copromotor: dr.ir. H.J. Bos Advanced School for Computing and Imaging This work was carried out in the ASCI graduate school. ASCI dissertation series number 208. This research was supported by the Netherlands Organisation for Scientific Research (NWO) under project number 612-060-420. “We’re getting bloated and huge. Yes, it’s a problem. ... I’d like to say we have a plan.” Linus Torvalds on the Linux kernel, 2009 Copyright © 2010 by Jorrit N. Herder ISBN 978-94-6108-058-5 Parts of this thesis have been published before: ACM SIGOPS Operating System Review, 40(1) and 40(3) USENIX ;login:, 31(2), 32(1), and 35(3) IEEE Computer, 39(5) Springer Lecture Notes in Computer Science, 4186 Springer Real-Time Systems, 43(2) Proc. 6th European Dependable Computing Conf. (EDCC’06) Proc. 37th IEEE/IFIP Int’l Conf. on Dependable Systems and Networks (DSN’07) Proc. 14th IEEE Pacific Rim Int’l Symp. on Dependable Computing (PRDC’08) Proc. 39th IEEE/IFIP Int’l Conf. on Dependable Systems and Networks (DSN’09) Proc. 4th Latin-American Symp. on Dependable Computing (LADC’09) Contents ACKNOWLEDGEMENTS xiii SAMENVATTING xv 1 GENERAL INTRODUCTION 1 1.1 TheNeedforDependability . 2 1.2 TheProblemwithDeviceDrivers . 4 1.3 WhydoSystemsCrash? ........................ 6 1.3.1 SoftwareComplexity. 6 1.3.2 DesignFlaws.......................... 8 1.4 ImprovingOSDependability. 9 1.4.1 AModularOSDesign . 10 1.4.2 Fault-toleranceStrategies . 12 1.4.3 OtherBenefitsofModularity. 13 1.5 PreviewofRelatedWork . 14 1.6 FocusofthisThesis........................... 16 1.7 OutlineofthisThesis. 18 2 ARCHITECTURAL OVERVIEW 19 2.1 TheMINIX OperatingSystem ..................... 19 2.1.1 HistoricalPerspective . 19 2.1.2 MultiserverOSStructure. 21 2.1.3 InterprocessCommunication. 22 2.2 DriverManagement........................... 24 2.3 IsolatingFaultyDrivers. 26 2.3.1 IsolationArchitecture . 26 2.3.2 HardwareConsiderations . 30 2.4 RecoveringFailedDrivers . 32 2.4.1 DefectDetectionandRepair . 32 2.4.2 AssumptionsandLimitations . 34 2.5 FaultandFailureModel . 35 vii viii CONTENTS 3 FAULT ISOLATION 37 3.1 IsolationPrinciples ........................... 37 3.1.1 ThePrincipleofLeastAuthority. 37 3.1.2 ClassificationofPrivilegedOperations . 38 3.1.3 GeneralRulesforIsolation. 41 3.2 User-level Driver Framework . 42 3.2.1 MovingDriverstoUserLevel . 42 3.2.2 SupportingUser-levelDrivers . 43 3.3 IsolationTechniques . 44 3.3.1 RestrictingCPUUsage. 44 3.3.2 RestrictingMemoryAccess . 45 3.3.3 RestrictingDeviceI/O . 50 3.3.4 RestrictingIPC ......................... 51 3.4 CaseStudy:LivinginIsolation. 54 4 FAILURE RESILIENCE 57 4.1 DefectDetectionTechniques . 57 4.1.1 UnexpectedProcessExits . 58 4.1.2 PeriodicStatusMonitoring. 58 4.1.3 ExplicitUpdateRequests . 59 4.2 On-the-flyRepair ............................ 60 4.2.1 RecoveryScripts ........................ 60 4.2.2 RestartingFailedComponents . 61 4.2.3 StateManagement . 63 4.3 EffectivenessofRecovery . 65 4.3.1 RecoveringDeviceDrivers. 66 4.3.2 RecoveringSystemServers . 70 4.4 CaseStudy:MonitoringDriverCorrectness . 70 4.5 CaseStudy:AutomatingServerRecovery . 73 5 EXPERIMENTAL EVALUATION 75 5.1 Software-implementedFaultInjection . 75 5.1.1 SWIFITestMethodology . 75 5.1.2 Network-deviceDriverResults . 79 5.1.3 Block-deviceDriverResults . 85 5.1.4 Character-device Driver Results . 87 5.2 PerformanceMeasurements . 89 5.2.1 CostsofFaultIsolation. 89 5.2.2 CostsofFailureResilience. 94 5.3 Source-codeAnalysis. 96 5.3.1 Evolution of MINIX 3 ..................... 96 5.3.2 EvolutionofLinux2.6 . 99 CONTENTS ix 6 RELATED WORK 101 6.1 In-kernelSandboxing. .101 6.1.1 Hardware-enforced Protection . 102 6.1.2 Software-basedIsolation . .104 6.2 VirtualizationTechniques. .107 6.2.1 FullVirtualization . .107 6.2.2 Paravirtualization. .109 6.3 FormalMethods.............................111 6.3.1 Language-basedProtection . .112 6.3.2 DriverSynthesis . .115 6.4 User-levelFrameworks . .117 6.4.1 ProcessEncapsulation . .117 6.4.2 Split-driverArchitectures . .120 6.5 Comparison...............................123 7 SUMMARY AND CONCLUSION 125 7.1 SummaryofthisThesis. .125 7.1.1 ProblemStatementandApproach . 125 7.1.2 Fault-toleranceTechniques. 128 7.2 LessonsLearned ............................130 7.2.1 DependabilityChallenges . .131 7.2.2 PerformancePerspective . .132 7.2.3 EngineeringEffort . .133 7.3 Epilogue.................................135 7.3.1 ContributionofthisThesis . .135 7.3.2 ApplicationofthisResearch . 136 7.3.3 DirectionsforFutureResearch. 137 7.4 Availability of MINIX 3 .........................139 REFERENCES 141 ABBREVIATIONS 161 PUBLICATIONS 163 BIOGRAPHY 165 List of Figures 1.1 FundamentalroleoftheOSinacomputersystem. ... 3 1.2 Growth of the Linux 2.6 kernel and its major subsystems . ..... 7 1.3 Lackoffaultisolationinamonolithicdesign . ...... 9 1.4 Independentprocessesinamultiserverdesign. .... 11 2.1 Multiserver design of the MINIX 3 operatingsystem . 20 2.2 IPC primitives implemented by the MINIX 3 kernel............ 23 2.3 Format of fixed-length IPC messages in MINIX 3 ............. 23 2.4 Parameterssupportedbytheserviceutility . .. 25 2.5 Startingnewdriversisdonebythedrivermanager . .. 25 2.6 Resources that can be configured via isolation policies . ....... 28 2.7 HardwareprotectionprovidedbyMMUandIOMMU . 30 2.8 Failed drivers can be automatically restarted . ... 33 3.1 Classificationofprivilegeddriveroperations . ..... 38 3.2 Asymmetric trust and vulnerabilities in synchronous IPC . ..... 41 3.3 Overview of new kernel calls for device drivers . 44 3.4 Structure of memory grants and grant flags . 47 3.5 Hierarchical structure of memory grants . 48 3.6 IPCpatternstodealwithasymmetrictrust. 53 3.7 Per-driver policy definition is done using simple text files ........ 54 3.8 InteractionsofanisolateddriverandtherestoftheOS . ..... 55 4.1 Classification of defect detection techniques in MINIX 3 ......... 58 4.2 Example of a parameterized, generic recovery script . .. 61 4.3 Procedure for restarting a failed device driver . .. 62 4.4 SummaryofthedatastoreAPIforstatemanagement . .. 63 4.5 Driver I/O properties and recovery support . 66 4.6 Components that have to be aware of driver recovery . .. 67 4.7 Afilterdrivercancheckfordriverprotocolviolations . ..... 71 4.8 On-diskchecksumminglayoutusedbythefilterdriver . ..... 72 4.9 Dedicated recovery script for the network server (INET) . 74 xi xii LIST OF FIGURES 5.1 FaulttypesandcodemutationsusedforSWIFItesting . ..... 77 5.2 DriverconfigurationssubjectedtoSWIFItesting . .... 79 5.3 Networkdriverfailurecountsforeachfaulttype . ... 80 5.4 Network driver failure reasons for each fault type . ... 81 5.5 Unauthorized access attempts found in the system logs . ...... 82 5.6 FaultsneededtodisruptandcrashtheDP8390driver . .... 83 5.7 FaultsneededtodisruptandcrashtheRTL8139driver . .... 83 5.8 SelectedbugsfoundduringSWIFItesting. 84 5.9 ResultsofsevenSWIFItestswiththeATWINIdriver . .. 86 5.10 AudioplaybackwhiletestingtheES1371driver . ..... 88 5.11 System call times for in-kernel versus user-level drivers . ..... 90 5.12 Raw reads for in-kernel versus user-level drivers . 91 5.13 File reads for in-kernel versus user-level drivers . ... 91 5.14 Application-level benchmarks using the filter driver . ....... 92 5.15 Cross-platform comparison of disk read performance . 93 5.16 Network throughput with and without driver recovery . ... 94 5.17 Diskthroughputwithandwithoutdriverrecovery . .... 95 5.18 Evolution of the MINIX 3 kernel, drivers, and servers . 96 5.19 Line counts for the most important MINIX 3 components. 97 5.20 EvolutionoftheLinux2.6kernelanddevicedrivers . ..... 99 5.21 Linux2.6drivergrowthinlinesofexecutablecode . ......100 6.1 Hardware-enforced protection domains in Nooks . 103 6.2 Software-based fault-isolation procedure in BGI . 106 6.3 Full
Load more

Recommended publications
  • Ebook - Informations About Operating Systems Version: August 15, 2006 | Download
    eBook - Informations about Operating Systems Version: August 15, 2006 | Download: www.operating-system.org AIX Internet: AIX AmigaOS Internet: AmigaOS AtheOS Internet: AtheOS BeIA Internet: BeIA BeOS Internet: BeOS BSDi Internet: BSDi CP/M Internet: CP/M Darwin Internet: Darwin EPOC Internet: EPOC FreeBSD Internet: FreeBSD HP-UX Internet: HP-UX Hurd Internet: Hurd Inferno Internet: Inferno IRIX Internet: IRIX JavaOS Internet: JavaOS LFS Internet: LFS Linspire Internet: Linspire Linux Internet: Linux MacOS Internet: MacOS Minix Internet: Minix MorphOS Internet: MorphOS MS-DOS Internet: MS-DOS MVS Internet: MVS NetBSD Internet: NetBSD NetWare Internet: NetWare Newdeal Internet: Newdeal NEXTSTEP Internet: NEXTSTEP OpenBSD Internet: OpenBSD OS/2 Internet: OS/2 Further operating systems Internet: Further operating systems PalmOS Internet: PalmOS Plan9 Internet: Plan9 QNX Internet: QNX RiscOS Internet: RiscOS Solaris Internet: Solaris SuSE Linux Internet: SuSE Linux Unicos Internet: Unicos Unix Internet: Unix Unixware Internet: Unixware Windows 2000 Internet: Windows 2000 Windows 3.11 Internet: Windows 3.11 Windows 95 Internet: Windows 95 Windows 98 Internet: Windows 98 Windows CE Internet: Windows CE Windows Family Internet: Windows Family Windows ME Internet: Windows ME Seite 1 von 138 eBook - Informations about Operating Systems Version: August 15, 2006 | Download: www.operating-system.org Windows NT 3.1 Internet: Windows NT 3.1 Windows NT 4.0 Internet: Windows NT 4.0 Windows Server 2003 Internet: Windows Server 2003 Windows Vista Internet: Windows Vista Windows XP Internet: Windows XP Apple - Company Internet: Apple - Company AT&T - Company Internet: AT&T - Company Be Inc. - Company Internet: Be Inc. - Company BSD Family Internet: BSD Family Cray Inc.
    [Show full text]
  • Performance Best Practices for Vmware Workstation Vmware Workstation 7.0
    Performance Best Practices for VMware Workstation VMware Workstation 7.0 This document supports the version of each product listed and supports all subsequent versions until the document is replaced by a new edition. To check for more recent editions of this document, see http://www.vmware.com/support/pubs. EN-000294-00 Performance Best Practices for VMware Workstation You can find the most up-to-date technical documentation on the VMware Web site at: http://www.vmware.com/support/ The VMware Web site also provides the latest product updates. If you have comments about this documentation, submit your feedback to: [email protected] Copyright © 2007–2009 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies. VMware, Inc. 3401 Hillview Ave. Palo Alto, CA 94304 www.vmware.com 2 VMware, Inc. Contents About This Book 5 Terminology 5 Intended Audience 5 Document Feedback 5 Technical Support and Education Resources 5 Online and Telephone Support 5 Support Offerings 5 VMware Professional Services 6 1 Hardware for VMware Workstation 7 CPUs for VMware Workstation 7 Hyperthreading 7 Hardware-Assisted Virtualization 7 Hardware-Assisted CPU Virtualization (Intel VT-x and AMD AMD-V)
    [Show full text]
  • Chapter 1. Origins of Mac OS X
    1 Chapter 1. Origins of Mac OS X "Most ideas come from previous ideas." Alan Curtis Kay The Mac OS X operating system represents a rather successful coming together of paradigms, ideologies, and technologies that have often resisted each other in the past. A good example is the cordial relationship that exists between the command-line and graphical interfaces in Mac OS X. The system is a result of the trials and tribulations of Apple and NeXT, as well as their user and developer communities. Mac OS X exemplifies how a capable system can result from the direct or indirect efforts of corporations, academic and research communities, the Open Source and Free Software movements, and, of course, individuals. Apple has been around since 1976, and many accounts of its history have been told. If the story of Apple as a company is fascinating, so is the technical history of Apple's operating systems. In this chapter,[1] we will trace the history of Mac OS X, discussing several technologies whose confluence eventually led to the modern-day Apple operating system. [1] This book's accompanying web site (www.osxbook.com) provides a more detailed technical history of all of Apple's operating systems. 1 2 2 1 1.1. Apple's Quest for the[2] Operating System [2] Whereas the word "the" is used here to designate prominence and desirability, it is an interesting coincidence that "THE" was the name of a multiprogramming system described by Edsger W. Dijkstra in a 1968 paper. It was March 1988. The Macintosh had been around for four years.
    [Show full text]
  • Zenon Manual Programming Interfaces
    zenon manual Programming interfaces v.7.11 ©2014 Ing. Punzenberger COPA-DATA GmbH All rights reserved. Distribution and/or reproduction of this document or parts thereof in any form are permitted solely with the written permission of the company COPA-DATA. The technical data contained herein has been provided solely for informational purposes and is not legally binding. Subject to change, technical or otherwise. Contents 1. Welcome to COPA-DATA help ...................................................................................................... 6 2. Programming interfaces ............................................................................................................... 6 3. Process Control Engine (PCE) ........................................................................................................ 9 3.1 The PCE Editor ............................................................................................................................................. 9 3.1.1 The Taskmanager ....................................................................................................................... 10 3.1.2 The editing area .......................................................................................................................... 10 3.1.3 The output window .................................................................................................................... 11 3.1.4 The menus of the PCE Editor .....................................................................................................
    [Show full text]
  • Research Purpose Operating Systems – a Wide Survey
    GESJ: Computer Science and Telecommunications 2010|No.3(26) ISSN 1512-1232 RESEARCH PURPOSE OPERATING SYSTEMS – A WIDE SURVEY Pinaki Chakraborty School of Computer and Systems Sciences, Jawaharlal Nehru University, New Delhi – 110067, India. E-mail: [email protected] Abstract Operating systems constitute a class of vital software. A plethora of operating systems, of different types and developed by different manufacturers over the years, are available now. This paper concentrates on research purpose operating systems because many of them have high technological significance and they have been vividly documented in the research literature. Thirty-four academic and research purpose operating systems have been briefly reviewed in this paper. It was observed that the microkernel based architecture is being used widely to design research purpose operating systems. It was also noticed that object oriented operating systems are emerging as a promising option. Hence, the paper concludes by suggesting a study of the scope of microkernel based object oriented operating systems. Keywords: Operating system, research purpose operating system, object oriented operating system, microkernel 1. Introduction An operating system is a software that manages all the resources of a computer, both hardware and software, and provides an environment in which a user can execute programs in a convenient and efficient manner [1]. However, the principles and concepts used in the operating systems were not standardized in a day. In fact, operating systems have been evolving through the years [2]. There were no operating systems in the early computers. In those systems, every program required full hardware specification to execute correctly and perform each trivial task, and its own drivers for peripheral devices like card readers and line printers.
    [Show full text]
  • Operating System Architectures
    Operating System Architectures • Learning objectives: • Explain how OS functionality is orthogonal to where you place services relative to processor modes. • Describe some alternative ways to structure the operating system. • Operating systems evolve over time, but that evolution is frequently in terms of their architecture: how they structure functionality relative to protection boundaries. • We’ll review some of the basic architectures: • Executives • Monolithic kernels • Micro kernels • Exo kernels • Extensible operating systems 2/3/15 CS161 Spring 2015 1 OS Executives • Think MS-DOS: With no hardware protection, the OS is simply a set of services: • Live in memory • Applications can invoke them • Requires a software trap to invoke them. • Live in same address space as application 1-2-3 QBasic WP Applications Command Software Traps Operating System routlines 2/3/15 CS161 Spring 2015 2 Monolithic Operating System • Traditional architecture • Applications and operating system run in different address spaces. • Operating system runs in privileged mode; applications run in user mode. Applications Operating System file system processes networking Device drivers virtual memory 2/3/15 CS161 Spring 2015 3 Microkernels (late 80’s and on) • Put as little of OS as possible in privileged mode (the microkernel). • Implement most core OS services as user-level servers. • Only microkernel really knows about hardware • File system, device drivers, virtual memory all implemented in unprivileged servers. • Must use IPC (interprocess communication) to communicate among different servers. Applications Process Virtual management memory file system networking Microkernel 2/3/15 CS161 Spring 2015 4 Microkernels: Past and Present • Much research and debate in late 80’s early 90’s • Pioneering effort in Mach (CMU).
    [Show full text]
  • A Complete Bibliography of Publications in Software—Practice and Experience
    A Complete Bibliography of Publications in Software|Practice and Experience Nelson H. F. Beebe University of Utah Department of Mathematics, 110 LCB 155 S 1400 E RM 233 Salt Lake City, UT 84112-0090 USA Tel: +1 801 581 5254 FAX: +1 801 581 4148 E-mail: [email protected], [email protected], [email protected] (Internet) WWW URL: http://www.math.utah.edu/~beebe/ 23 July 2021 Version 3.26 Title word cross-reference [Bar82a, Bar82c, Bar84b]. < [SMGMOFM07a, SMGMOFM07b]. > [SMGMOFM07a, SMGMOFM07b]. 2 [MST13, MDB19]. 3 [DS09]. 4 [MSR+07]. \ 0 [GW96]. 1 [GW96]. $1.50 [Bar78d]. $11 [PK04]. TM [MZB00, Win02]. 8 [DB21b]. k [Bar84a]. $12.00 [Rob72]. $13 [Bar84a]. [AW93, Mer93]. κ [MG94]. µ $13.00 [Rob72]. $18.50 [Jon74]. $185 [BS90c, BDS+92, SMNB21]. N [Bar79b]. $19.30 [Lan74a]. $19.50 [Dav78]. [MS98, Coh98, KST94, YAVHC21]. P 3 $25.00 [Pet77, And78]. 3 [BE02, FMA02]. [DC03]. PM [CLD+17]. q [GSR17]. τ $31-25 [Pet77]. $31.35 [Bri82]. 32 [VED06]. 2:5 [TSZ14, UDS+07]. $35.00 [Inc86]. $39.50 [Sim83]. 5 [CPMAH+20]. $58.50 [Wal81a]. $6.95 -ary [MS98]. -bit [AM10, SF85, VED06]. [Tho74]. 64 [AM10, VED06]. 68 -gram [Coh98, KST94, YAVHC21]. -grams [Ear76, Hol77]. $68.25 [Pit82]. $7.00 [GSR17]. -level [FM77]. -queens [Plu74]. [Bar72a]. $7.50 [Bar78d]. $7.95 -R [Ear76, Hol77]. -shortest-paths [MG94]. [Bar76a, Lav77]. $78.50 [Sim83]. 8 -System [BS90c]. [Plu74, SF85]. $8.95 [Bar82a, Bar82c, Bar84b]. $9.75 . [Bis81b]. .NET [Coo04, Han04]. [Bar77e, Mul76]. $9.80 [Atk79a]. $9.95 1 2 0 [Bar81, Edw98a, Edw98b, Gru83, Llo82, 2 [Bar74a, Bar74b, Bar80b, Bud85, Cor88b, Val77a, Val78, Wal83b].
    [Show full text]
  • Access Control for the SPIN Extensible Operating System
    Access Control for the SPIN Extensible Operating System Robert Grimm Brian N. Bershad Dept. of Computer Science and Engineering University of Washington Seattle, WA 98195, U.S.A. Extensible systems, such as SPIN or Java, raise new se- on extensions and threads, are enforced at link time (when curity concerns. In these systems, code can be added to a an extension wants to link against other extensions) and at running system in almost arbitrary fashion, and it can inter- call time (when a thread wants to call an extension). Ac- act through low latency (but type safe) interfaces with other cess restrictions on objects are enforced by the extension code. Consequently, it is necessary to devise and apply that provides an object’s abstraction (if an extension is not security mechanisms that allow the expression of policies trusted to enforce access control on its objects but is ex- controlling an extension’s access to other extensions and its pected to do so, DTE can be used to prevent other exten- ability to extend, or override, the behavior of already exist- sions from linking against the untrusted extension). ing services. In the SPIN operating system [3, 4] built at the Due to the fine grained composition of extensions in University of Washington, we are experimenting with a ver- SPIN, it is important to minimize the performance overhead sion of domain and type enforcement (DTE) [1, 2] that has of call time access control. We are therefore exploring opti- been extended to address the security concerns of extensible mization that make it possible to avoid some dynamic ac- systems.
    [Show full text]
  • The Symbian OS Architecture Sourcebook
    The Symbian OS Architecture Sourcebook The Symbian OS Architecture Sourcebook Design and Evolution of a Mobile Phone OS By Ben Morris Reviewed by Chris Davies, Warren Day, Martin de Jode, Roy Hayun, Simon Higginson, Mark Jacobs, Andrew Langstaff, David Mery, Matthew O’Donnell, Kal Patel, Dominic Pinkman, Alan Robinson, Matthew Reynolds, Mark Shackman, Jo Stichbury, Jan van Bergen Symbian Press Head of Symbian Press Freddie Gjertsen Managing Editor Satu McNabb Copyright 2007 Symbian Software, Ltd John Wiley & Sons, Ltd The Atrium, Southern Gate, Chichester, West Sussex PO19 8SQ, England Telephone (+44) 1243 779777 Email (for orders and customer service enquiries): [email protected] Visit our Home Page on www.wileyeurope.com or www.wiley.com All Rights Reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except under the terms of the Copyright, Designs and Patents Act 1988 or under the terms of a licence issued by the Copyright Licensing Agency Ltd, 90 Tottenham Court Road, London W1T 4LP, UK, without the permission in writing of the Publisher. Requests to the Publisher should be addressed to the Permissions Department, John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex PO19 8SQ, England, or emailed to [email protected], or faxed to (+44) 1243 770620. Designations used by companies to distinguish their products are often claimed as trademarks. All brand names and product names used in this book are trade names, service marks, trademarks or registered trademarks of their respective owners.
    [Show full text]
  • Sealing OS Processes to Improve Dependability and Security
    Sealing OS Processes to Improve Dependability and Safety Galen Hunt, Mark Aiken, Manuel Fähndrich, Chris Hawblitzel, Orion Hodson, James Larus, Steven Levi, Bjarne Steensgaard, David Tarditi, and Ted Wobber Microsoft Research One Microsoft Way Redmond, WA 98052 USA [email protected] ABSTRACT General Terms In most modern operating systems, a process is a Design, Reliability, Experimentation. hardware-protected abstraction for isolating code and data. This protection, however, is selective. Many common Keywords mechanisms—dynamic code loading, run-time code Open process architecture, sealed process architecture, sealed generation, shared memory, and intrusive system APIs— kernel, software isolated process (SIP). make the barrier between processes very permeable. This paper argues that this traditional open process architecture 1. INTRODUCTION exacerbates the dependability and security weaknesses of Processes debuted, circa 1965, as a recognized operating modern systems. system abstraction in Multics [48]. Multics pioneered As a remedy, this paper proposes a sealed process many attributes of modern processes: OS-supported architecture, which prohibits dynamic code loading, self- dynamic code loading, run-time code generation, cross- modifying code, shared memory, and limits the scope of process shared memory, and an intrusive kernel API that the process API. This paper describes the implementation permitted one process to modify directly the state of of the sealed process architecture in the Singularity another process. operating system,
    [Show full text]
  • Designing a Concurrent File Server
    Communicating Process Architectures 2012 1 P.H. Welch et al. (Eds.) Open Channel Publishing Ltd., 2012 c 2012 The authors and Open Channel Publishing Ltd. All rights reserved. Designing a Concurrent File Server James WHITEHEAD II Department of Computer Science, University of Oxford, Wolfson Building, Parks Road, Oxford, OX1 3QD, United Kingdom; [email protected] Abstract. In this paper we present a design and architecture for a concurrent file sys- tem server. This architecture is a compromise between the fully concurrent V6 UNIX implementation, and the simple sequential implementation in the MINIX operating system. The design of the server is made easier through the use of a disciplined model of concurrency, based on the CSP process algebra. By viewing the problem through this restricted lens, without traditional explicit locking mechanisms, we can construct the system as a process network of components with explicit connections and depen- dencies. This provides us with insight into the problem domain, and allows us to anal- yse the issues present in concurrent file system implementation. Keywords. file system, Go, CSP, UNIX, MINIX. Introduction Modern operating systems allow multiple users and programs to share the computing re- sources on a single machine. They also serve as an intermediary between programs and the physical computing hardware, such as persistent storage devices. In the UNIX family of op- erating systems, disk access is accomplished by interacting with files and directories through a hierarchical file system, using system calls. Managing access to the file system in a concurrent environment is a challenging problem. An implementation must ensure that a program cannot corrupt the state of the file system, or the data stored on disk.
    [Show full text]
  • Study on Operating Systems for Small Devices for Mobile Payments Application 17 Th July, 2009
    Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009 Project Report On Study on Operating Systems for Small Devices for Mobile Payments Application Submitted by: V V Aishwarya B.E IV/IV (01-07-862) Department of Computer Science and Engineering (CSE) University College of Engineering (Autonomous) Osmania University , Hyderabad- 500004 To Summer Internship Project under the Guidance of Dr. V N Sastry Associate Professor Institute for Development and Research in Banking Technology (IDRBT) (Established by Reserve Bank of India) Road No. 1, Castle Hills, Masab Tank, Hyderabad – 500 057. July 2009 CSE,UCE,OU 1 IDRBT Study on Operating Systems for Small Devices for Mobile Payments Application 17 th July, 2009 CERTIFICATE This is to certify that this project on “ Study on Operating Systems for Small Devices for Mobile Payments Application ” submitted by Ms. V V Aishwarya , 01-07-862 of B.E. IV/IV, CSE, University College of Engineering, Osmania University, is a record of Bonafide work done by her under my guidance during the Summer Internship Programme from 21 st May, 2009 to 17 th July, 2009. Ms. V V Aishwarya has completed the work assigned to her within the limited period of learning and execution. She has successfully completed the project to my satisfaction and it has been observed that the goals set upon at the outset of this endeavor have been worked upon to the best of the student’s abilities and resources. During this period I have observed her to be very sincere, hardworking and coping up with new challenges.
    [Show full text]