DOCSLIB.ORG

Building a Reliable Operating System

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Building a Reliable Operating System c 2008 Francis Manoj David BUILDING A RELIABLE OPERATING SYSTEM BY FRANCIS MANOJ DAVID B.Tech., Indian Institute of Technology Madras, 2001 DISSERTATION Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Computer Science in the Graduate College of the University of Illinois at Urbana-Champaign, 2008 Urbana, Illinois Doctoral Committee: Professor Roy H. Campbell, Chair Professor Ravishankar K. Iyer Associate Professor Ralph E. Johnson Assistant Professor Samuel T. King Ray Essick, Motorola Abstract Despite many decades of research, the management of errors in a live operating system remains a challenging problem. This thesis presents CuriOS, an operating system that incorporates several new error management techniques that significantly improve reliabil- ity. Errors detected by both hardware and software are signaled using language exception handling mechanisms. Unhandled exceptions do not crash the operating system and are dispatched to recovery routines. The architecture of CuriOS is influenced by microkernel design principles. Individual operating system services are assigned separate protection domains. This componentiza- tion provided by traditional microkernel designs helps confine errors. However, an error that occurs in a microkernel operating system service can potentially result in state corrup- tion and service failure. A simple restart of the failed service is not always the best solution for reliability. Blindly restarting a service which maintains client-related state such as ses- sion information results in the loss of this state and affects all clients that were using the service. CuriOS adopts a novel design that uses lightweight distribution, isolation and per- sistence of client-related state information maintained by operating system services. This helps mitigate the problem of state loss during a restart. This design also achieves inter- client isolation by curtailing error propagation within services. Fault injection experiments show that it is possible to recover from 87% or more man- ifested errors in operating system services such as the file system, timer, scheduler and network while maintaining low performance overheads. ii To Hina iii Acknowledgments I thank my advisor, Prof. Roy H. Campbell, for his enduring optimism and encouragement during my years at graduate school. It was a wonderful experience learning and working with him. Credit is also due to him for reading and helping revise several other publications in addition to this thesis. The other members of my PhD committee: Prof. Ravishankar Iyer, Prof. Ralph Johnson, Prof. Sam King and Dr. Ray Essick were also extremely helpful with their feedback and guidance. I owe Jeffrey Carlyle and Ellick Chan a lot of gratitude for working with me through the years in an effective research team. We spent many late nights in the Siebel Center fixing our code, running experiments and writing papers. They are awesome people to work with and are very good friends. Thanks are also due to everyone in the Systems Software Research Group for their support, feedback and encouragement during my research. My research team was supported by many partners in industry. I am very grateful to DoCoMo Labs USA, Motorola and Texas Instruments for providing us with equipment and funding for our research. I thank the many staff members in the Department of Computer Science who ensured my smooth progress through the PhD program. Anda Ohlsson and Barb Cicone helped me solve many non-technical issues over the years. Mary Beth Kelly and Lynette Lubben helped sort through all the paperwork required to submit this thesis on time. My numerous friends in Champaign-Urbana made day-to-day life colorful and fun. And finally, I will always be indebted to my family for their continuing support and love. iv Table of Contents ListofTables...................................... vii ListofFigures .....................................viii ListofAbbreviations ................................ ix Chapter1 Introduction ............................... 1 Chapter2 RelatedOperatingSystems . ... 7 2.1 Minix3..................................... 7 2.2 L4/Iguana................................... 9 2.3 Chorus..................................... 10 2.4 EROS ..................................... 10 2.5 Others..................................... 11 2.6 Summary ................................... 12 Chapter3 CuriOSArchitecture . 14 3.1 Organization.................................. 14 3.2 ProtectedObjects ............................... 15 3.3 ThreadModel................................. 18 3.4 ErrorManagement .............................. 19 Chapter4 ErrorSignaling ............................. 21 4.1 Creating C++ Exceptions from Processor Exceptions . ........ 22 4.2 CrossDomainExceptions. 27 4.3 UndispatchableExceptions . .. 28 4.4 SizeandPerformanceImpact. 29 Chapter5 ErrorDetection ............................. 33 5.1 InvalidMemoryAccessErrors . 33 5.2 MemoryCorruptionErrors . 34 5.3 LockupErrors................................. 37 v Chapter 6 Restart-Based Error Recovery . .... 46 6.1 ComponentRestarts.............................. 46 6.2 ServerStateManagement. 48 6.3 OperatingSystemServiceConstruction . ..... 50 6.4 Intra-ComponentErrorPropagation . .... 53 6.5 RecoverableErrors .............................. 55 Chapter7 RestartableComponents . .. 56 7.1 StatelessComponents. 56 7.2 StatefulComponents ............................. 58 Chapter8 Evaluation ................................ 62 8.1 ErrorRecovery ................................ 62 8.2 Performance.................................. 66 8.3 MemoryOverheads.............................. 67 8.4 RefactoringEffort............................... 68 Chapter 9 Fault-Tolerance Patterns . .... 69 9.1 ArchitecturalPatterns. .. 69 9.2 ErrorDetectionPatterns . 70 9.3 ErrorRecoveryPatterns. 71 Chapter 10 Additional Dependability Benefits . ...... 73 10.1Security .................................... 73 10.2 Maintainability ................................ 75 Chapter11 RelatedWork.............................. 76 11.1 Fault-Tolerance ................................ 76 11.2 HardwareProtectedObjects . .. 78 11.3 ProtectionDomains. .. .. .. .. .. .. .. .. 79 Chapter12 FutureWork .............................. 80 12.1 ImprovedErrorDetection. .. 80 12.2 ImprovedErrorRecovery. 81 12.3 ParallelComputing . .. .. .. .. .. .. .. .. 81 12.4 OtherHardwareArchitectures . ... 82 12.5 OtherOperatingSystems . 83 Chapter13 Conclusions ............................... 84 Appendix A The Choices Operating System . ... 85 Appendix B The ARM Processor Architecture . ... 87 References ....................................... 91 Author’sBiography .................................. 100 vi List of Tables 2.1 Recoverability of microkernel operating systems from memory access errors 8 4.1 Comparing SJLJ and table-driven implementations of exceptions . 30 4.2 Section sizes for different exception handling implementations . 31 5.1 Effectivenessoflockupdetectors . ..... 38 8.1 Protectedmethodcallperformance . .... 66 B.1 ARMprocessormodes ............................ 88 B.2 ARMregisters................................. 89 B.3 ARMinterruptvectorsandhandlingmodes . .... 90 vii List of Figures 1.1 Statedistribution ............................... 4 3.1 CuriOSorganization ............................. 15 3.2 Protectedmethodcall. .. .. .. .. .. .. .. .. 16 3.3 Pseudo code for the protected object implementation . ......... 17 3.4 CuriOSthreads ................................ 19 4.1 Terminology.................................. 22 4.2 InterruptmanagementinterfacesinCuriOS . ...... 23 4.3 Codeforthefunctionthatthrowstheexception . ....... 24 4.4 Processorexceptioncontrolflow . ... 25 4.5 Processorexceptionclasses. ... 26 4.6 Handlingofundispatchableexceptions . ...... 29 4.7 Size comparison of CuriOS using different exception handling mechanisms 32 5.1 Creatinganexceptionfromawatchdogbite . ..... 40 5.2 CuriOShardlockuprecoverycomparison . .... 44 6.1 Pseudo code for the protected object restart implementation......... 47 6.2 Requestprocessing .............................. 49 6.3 Pseudo code for the SSR mapping and unmapping implementation . 51 6.4 ErrorpropagationbetweenSSRs . .. 54 8.1 Errorrecoveryafterfaultinjection . ...... 63 viii List of Abbreviations DMA Direct Memory Access ECC Error Correcting Code FIFO First In, First Out HTTP Hyper Text Transfer Protocol I/O Input/Output IP Internet Protocol KB Kilobyte MAC Media Access Control MB Megabyte MMU MemoryManagementUnit NFS Network File System NMI NonMaskableInterrupt OS OperatingSystem QoS QualityofService SSR Server State Region TCP TransmissionControlProtocol TLB Translation Lookaside Buffer UDP User Datagram Protocol ix Chapter 1 Introduction Operating system reliability remains a challenging problem today [1] despite several decades of research [2, 3, 4, 5]. Errors caused by hardware and software faults are a major factor affecting operating system reliability. Hardware faults can arise due to various factors, some of which are aging, temperature, firmware faults, and radiation-induced bit-flips in memory and registers (Single Event Upsets [6]). Software faults (bugs) due to incorrect code are also very common in large and complex operating systems [7]. Errors in a monolithic operating system can easily propagate and corrupt other parts of the system [8, 9], making recovery extremely difficult. Microkernel designs componentize the operating system into servers managed by a minimal kernel. These
Load more

Recommended publications
  • Object Management System Concepts: Supporting Integrated Office Workstation Applications
    Object Management System Concepts: Supporting Integrated Office Workstation Applications by Stanley Benjamin Zdonik, Jr. S.B., Massachusetts Institute of Technology (1970) S.M., Massachusetts Institute of Technology (1980) E.E., Massachusetts Institute of Technology (1980) Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy at the Massachusetts Institute of Technology May 1983 © Massachusetts Institute of Technology 1983 Signature of Author............... .. ..... .... Department of Electric~l Eng~neering and Computer Science May 13, 1983 Certified by . .* .* .. Michael Hammer Thesis Supervisor Accepted . ...... .-.----4 p . Arthur C. Smith Chairman, Departmental Committee on Graduate Students Object Management System Concepts: Supporting Integrated Office Workstation Applications by Stanley B. Zdonik, Jr. Submitted to the Department of Electrical Engineering and Computer Science on May 13, 1983, in partial fulfillment of the requirements for the Degree of Doctor of Philosophy Abstract The capabilities of a system for storing and retrieving office style objects are described in this work. Traditional file systems provide facilities for the storage and retrieval of objects that are created in user programs, but the semantics of these objects are not available to the file system. Database management systems provide a means of describing the semantics of objects using a single basic paradigm, the record. This model is inadequate for describing the richer semantics of office objects. An object management system combines the advantages of both a file system and a database management system in that it can store arbitrarily defined programming language objects and at the same time maintain a high-level description of their meaning. This work presents a high-level model of data that can be used to describe office objects more effectively than data processing oriented models.
    [Show full text]
  • Building a SAN-Less Private Cloud with IBM Powervm and IBM Powervc
    Front cover Building a SAN-less Private Cloud with IBM PowerVM and IBM PowerVC Javier Bazan Lazcano Stephen Lutz Redpaper International Technical Support Organization Building a SAN-less Private Cloud with IBM PowerVM and IBM PowerVC July 2018 REDP-5455-02 Note: Before using this information and the product it supports, read the information in “Notices” on page v. Third Edition (July 2018) This edition applies to Version 1, Release 4, Modification 1 of IBM Cloud PowerVC Manager for Software-Defined Infrastructure V1.1 (product number 5765-VCD). © Copyright International Business Machines Corporation 2017, 2018. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices . .v Trademarks . vi Preface . vii Authors. vii Now you can become a published author, too! . viii Comments welcome. viii Stay connected to IBM Redbooks . viii Chapter 1. Architecture of a software-defined infrastructure solution with IBM Power Systems servers and IBM PowerVC . 1 1.1 Software-defined infrastructure . 2 1.2 The motivation behind software-defined infrastructure . 2 1.3 Use cases . 4 1.3.1 Use case 1: Building a storage area network-less cloud . 4 1.3.2 Use case 2: Building an iSCSI-backed cloud . 5 1.3.3 More use cases. 5 1.4 Rack topologies and components . 6 1.4.1 Starter cloud . 7 1.4.2 Mini cloud . 8 1.4.3 Rack scale . 9 1.4.4 Storage/management switches. 10 1.4.5 Data switches . 10 1.4.6 Network nodes .
    [Show full text]
  • A VLSI Architecture for Enhancing Software Reliability Kanad Ghose Iowa State University
    Iowa State University Capstones, Theses and Retrospective Theses and Dissertations Dissertations 1988 A VLSI architecture for enhancing software reliability Kanad Ghose Iowa State University Follow this and additional works at: https://lib.dr.iastate.edu/rtd Part of the Computer Sciences Commons Recommended Citation Ghose, Kanad, "A VLSI architecture for enhancing software reliability " (1988). Retrospective Theses and Dissertations. 9345. https://lib.dr.iastate.edu/rtd/9345 This Dissertation is brought to you for free and open access by the Iowa State University Capstones, Theses and Dissertations at Iowa State University Digital Repository. It has been accepted for inclusion in Retrospective Theses and Dissertations by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. INFORMATION TO USERS The most advanced technology has been used to photo­ graph and reproduce this manuscript from the microfilm master. UMI films the original text directly from the copy submitted. Thus, some dissertation copies are in typewriter face, while others may be from a computer printer. In the unlikely event that the author did not send UMI a complete manuscript and there are missing pages, these will be noted. Also, if unauthorized copyrighted material had to be removed, a note will indicate the deletion. Oversize materials (e.g., maps, drawings, charts) are re­ produced by sectioning the original, beginning at the upper left-hand comer and continuing from left to right in equal sections with small overlaps. Each oversize page is available as one exposure on a standard 35 mm slide or as a 17" x 23" black and white photographic print for an additional charge.
    [Show full text]
  • Access Control and Operating System
    Outline (may not finish in one lecture) Access Control and Operating Access Control Concepts Secure OS System Security • Matrix, ACL, Capabilities • Methods for resisting • Multi-level security (MLS) stronger attacks OS Mechanisms Assurance • Multics • Orange Book, TCSEC John Mitchell – Ring structure • Common Criteria • Amoeba • Windows 2000 – Distributed, capabilities certification • Unix Some Limitations – File system, Setuid • Information flow • Windows • Covert channels – File system, Tokens, EFS • SE Linux – Role-based, Domain type enforcement Access control Access control matrix [Lampson] Common Assumption Objects • System knows who the user is File 1 File 2 File 3 … File n – User has entered a name and password, or other info • Access requests pass through gatekeeper User 1 read write - - read – OS must be designed monitor cannot be bypassed User 2 write write write - - Reference Subjects monitor User 3 - - - read read User process ? Resource … User m read write read write read Decide whether user can apply operation to resource Two implementation concepts Capabilities Access control list (ACL) File 1 File 2 … Operating system concept • “… of the future and always will be …” • Store column of matrix User 1 read write - Examples with the resource User 2 write write - • Dennis and van Horn, MIT PDP-1 Timesharing Capability User 3 - - read • Hydra, StarOS, Intel iAPX 432, Eros, … • User holds a “ticket” for … • Amoeba: distributed, unforgeable tickets each resource User m read write write • Two variations References – store
    [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]
  • A Compiler Target Model for Line Associative Registers
    University of Kentucky UKnowledge Theses and Dissertations--Electrical and Computer Engineering Electrical and Computer Engineering 2019 A Compiler Target Model for Line Associative Registers Paul S. Eberhart University of Kentucky, [email protected] Digital Object Identifier: https://doi.org/10.13023/etd.2019.141 Right click to open a feedback form in a new tab to let us know how this document benefits ou.y Recommended Citation Eberhart, Paul S., "A Compiler Target Model for Line Associative Registers" (2019). Theses and Dissertations--Electrical and Computer Engineering. 138. https://uknowledge.uky.edu/ece_etds/138 This Master's Thesis is brought to you for free and open access by the Electrical and Computer Engineering at UKnowledge. It has been accepted for inclusion in Theses and Dissertations--Electrical and Computer Engineering by an authorized administrator of UKnowledge. For more information, please contact [email protected]. STUDENT AGREEMENT: I represent that my thesis or dissertation and abstract are my original work. Proper attribution has been given to all outside sources. I understand that I am solely responsible for obtaining any needed copyright permissions. I have obtained needed written permission statement(s) from the owner(s) of each third-party copyrighted matter to be included in my work, allowing electronic distribution (if such use is not permitted by the fair use doctrine) which will be submitted to UKnowledge as Additional File. I hereby grant to The University of Kentucky and its agents the irrevocable, non-exclusive, and royalty-free license to archive and make accessible my work in whole or in part in all forms of media, now or hereafter known.
    [Show full text]
  • Programmable Digital Microcircuits - a Survey with Examples of Use
    - 237 - PROGRAMMABLE DIGITAL MICROCIRCUITS - A SURVEY WITH EXAMPLES OF USE C. Verkerk CERN, Geneva, Switzerland 1. Introduction For most readers the title of these lecture notes will evoke microprocessors. The fixed instruction set microprocessors are however not the only programmable digital mi• crocircuits and, although a number of pages will be dedicated to them, the aim of these notes is also to draw attention to other useful microcircuits. A complete survey of programmable circuits would fill several books and a selection had therefore to be made. The choice has rather been to treat a variety of devices than to give an in- depth treatment of a particular circuit. The selected devices have all found useful ap• plications in high-energy physics, or hold promise for future use. The microprocessor is very young : just over eleven years. An advertisement, an• nouncing a new era of integrated electronics, and which appeared in the November 15, 1971 issue of Electronics News, is generally considered its birth-certificate. The adver• tisement was for the Intel 4004 and its three support chips. The history leading to this announcement merits to be recalled. Intel, then a very young company, was working on the design of a chip-set for a high-performance calculator, for and in collaboration with a Japanese firm, Busicom. One of the Intel engineers found the Busicom design of 9 different chips too complicated and tried to find a more general and programmable solu• tion. His design, the 4004 microprocessor, was finally adapted by Busicom, and after further négociation, Intel acquired marketing rights for its new invention.
    [Show full text]
  • Mixed-Criticality Scheduling and Resource Sharing for High-Assurance Operating Systems
    Mixed-Criticality Scheduling and Resource Sharing for High-Assurance Operating Systems Anna Lyons Submitted in fulfilment of the requirements for the degree of Doctor of Philosophy School of Computer Science and Engineering University of New South Wales Sydney, Australia September 2018 Abstract Criticality of a software system refers to the severity of the impact of a failure. In a high-criticality system, failure risks significant loss of life or damage to the environ- ment. In a low-criticality system, failure may risk a downgrade in user-experience. As criticality of a software system increases, so too does the cost and time to develop that software: raising the criticality also raises the assurance level, with the highest levels requiring extensive, expensive, independent certification. For modern cyber-physical systems, including autonomous aircraft and other vehicles, the traditional approach of isolating systems of different criticality by using completely separate physical hardware, is no longer practical, being both restrictive and inefficient. The result is mixed-criticality systems, where software applications with different criticalities execute on the same hardware. Sufficient mechanisms are required to ascertain that software in mixed-criticality systems is sufficiently isolated, otherwise, all software on that hardware is promoted to the highest criticality level, driving up costs to impractical levels. For mixed-criticality systems to be viable, both spatial and temporal isolation are required. Current aviation standards allow for mixed-criticality systems where temporal and spatial resources are strictly and statically partitioned in time and space, allowing some improvement over fully isolated hardware. However, further improvements are not only possible, but required for future innovation in cyber-physical systems.
    [Show full text]
  • IBM Worklight V5.0.6 Technology Overview
    IBM Software Technical White Paper WebSphere IBM Worklight V5.0.6 Technology overview IBM Worklight—Overview Contents IBM® Worklight® software helps enable organizational leaders to extend their business to mobile devices. This software provides an open, 1 IBM Worklight—Overview comprehensive and advanced mobile application platform for smart- phones and tablets, helping organizations of all sizes to efficiently 2 IBM Worklight—Components develop, connect, run and manage mobile and omni-channel applications. 3 Development tools Leveraging standards-based technologies and tools, the IBM team has created Worklight software that provides a single integrated platform. 8 Runtime server environment This platform includes a comprehensive development environment, 9 The IBM Worklight Console mobile-optimized runtime middleware, a private enterprise application store and an integrated management and analytics console—all supported 9 IBM Worklight Device by a variety of security mechanisms. Runtime components 10 Security and authentication Develop. The IBM Worklight Studio and the IBM Worklight software mechanisms development kit (SDK) simplify the development of mobile and omni- channel applications (apps) throughout multiple mobile platforms, includ- ing iOS, Android, BlackBerry, Windows 8, Windows Phone and Java ME. The IBM Worklight optimization framework fosters code reuse while delivering rich user experiences that match the styling requirements of each target environment. With such code reuse, IBM Worklight reduces costs of development, reduces time-to-market and provides strong support for your ongoing management efforts. Connect. The IBM Worklight Server architecture and adapter technol- ogy simplifies the integration of mobile apps with back-end enterprise systems and cloud-based services. The IBM Worklight Server is designed IBM Software Technical White Paper WebSphere to fit quickly into your organization’s IT infrastructure and is Console.
    [Show full text]
  • AIX Dec 2004.P65
    110 December 2004 In this issue 3 Finding the biggest file in directories on the same filesystem 4 Creating a physical partition map of an hdisk by logical volume 9 AIX console mirroring 11 Using ClamAV 14 Happy 18th birthday AIX 16 Deploying multiple compiler versions on AIX 27 Mirroring tips and techniques in AIX 36 Generating a logo 41 Default user password settings in AIX 47 AIX news © Xephon Inc 2004 AIX Update Published by Disclaimer Xephon Inc Readers are cautioned that, although the PO Box 550547 information in this journal is presented in good Dallas, Texas 75355 faith, neither Xephon nor the organizations or USA individuals that supplied information in this Phone: 214-340-5690 journal give any warranty or make any Fax: 214-341-7081 representations as to the accuracy of the material it contains. Neither Xephon nor the contributing Editor organizations or individuals accept any liability of Trevor Eddolls any kind howsoever arising out of the use of such E-mail: [email protected] material. Readers should satisfy themselves as to the correctness and relevance to their Publisher circumstances of all advice, information, code, Bob Thomas JCL, scripts, and other contents of this journal E-mail: [email protected] before making any use of it. Subscriptions and back-issues Contributions A year’s subscription to AIX Update, When Xephon is given copyright, articles comprising twelve monthly issues, costs published in AIX Update are paid for at the rate $275.00 in the USA and Canada; £180.00 in of $160 (£100 outside North America) per the UK; £186.00 in Europe; £192.00 in 1000 words and $80 (£50) per 100 lines of code Australasia and Japan; and £190.50 elsewhere.
    [Show full text]
  • H&P Chapter 1 Supplement: but First, What Is Security? Assets
    H&P Chapter 1 Supplement: Introduction to Security for Computer Architecture Students https://doi.org/10.7916/d8-7r78-2635 Adam Hastings Mohammed Tarek Simha Sethumadhavan October 1, 2019 For decades, the role of the computer architect has been to design systems that meet requirements, defined primarily by speed, area, and energy efficiency. However, as humans become more and more reliant on computers, it becomes increasingly obvious that our specifications have failed us on one key design requirement – Security, – as evidenced by nearly weeklynews of high-profile security breaches. In the face of such damaging consequences, it becomes clear that the security of our technology must no longer be relegated as an afterthought, but must be a first-order design requirement, from the very beginning—security must be “built-in” rather than “bolted on”, so to speak. In particular, it becomes important, even necessary, for security to be built into the lowest levels of the computing stack. It is for this reason that security must become a fundamental part of computer architecture, and must be included in any serious study of the subject. But First, What is Security? In its broadest sense, security is about protecting assets. An asset is anything of value that is worth protecting, e.g. anything from the valuables in a bank vault to a secret message shared between friends to classified government information to objects of personal sentimental value. As long as an asset is valued, its owners should work to secure it. For an asset to be secure, security professionals generally think of the asset as maintaining three essential properties: • Confidentiality—Is the asset only accessible to those authorized to access it? In computer systems, maintaining confidentiality means controlling who can read some piece of information.
    [Show full text]
  • (J. Bayko) Date: 12 Jun 92 18:49:18 GMT Newsgroups: Alt.Folklore.Computers,Comp.Arch Subject: Great Microprocessors of the Past and Present
    From: [email protected] (J. Bayko) Date: 12 Jun 92 18:49:18 GMT Newsgroups: alt.folklore.computers,comp.arch Subject: Great Microprocessors of the Past and Present I had planned to submit an updated version of the Great Microprocessor list after I’d completed adding new processors, checked out little bits, and so on... That was going to take a while... But then I got to thinking of all the people stuck with the origional error-riddled version. All these poor people who’d kept it, or perhaps placed in in an FTP site, or even - using it for reference??! In good conscience, I decided I can’t leave that erratic old version lying out there, where people might think it’s accurate. So here is an interim release. There will be more to it later - the 320xx will be included eventually, for example. But at least this has been debugged greatly. Enjoy... John Bayko. — Great Microprocessors of the Past and Present (V 3.2.1) Section One: Before the Great Dark Cloud. ————————— Part I: The Intel 4004 (1972) The first single chip CPU was the Intel 4004, a 4-bit processor meant for a calculator. It processed data in 4 bits, but its instructions were 8 bits long. Internally, it featured four 12 bit(?) registers which acted as an internal evaluation stack. The Stack Pointer pointed to one of these registers, not a memory location (only CALL and RET instructions operated on the Stack Pointer). There were also sixteen 4-bit (or eight 8-bit) general purpose registers The 4004 had 46 instructions.
    [Show full text]