DOCSLIB.ORG

Certifying Low-Level Programs with Hardware Interrupts and Preemptive Threads

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Certifying Low-Level Programs with Hardware Interrupts and Preemptive Threads Certifying Low-Level Programs with Hardware Interrupts and Preemptive Threads Xinyu Feng†‡ Zhong Shao† Yuan Dong†§ Yu Guo ∗ †Yale University, New Haven, CT 06520-8285, U.S.A. ‡Toyota Technological Institute at Chicago, Chicago, IL 60637, U.S.A. §Tsinghua University, Beijing 100084, China ∗University of Science and Technology of China, Hefei, Anhui 230026, China [email protected] [email protected] [email protected] [email protected] Abstract Hardware interrupts are widely used in the world’s critical soft- . ware systems to support preemptive threads, device drivers, operat- ing system kernels, and hypervisors. Handling interrupts properly High-Level Concurrent Programs is an essential component of low-level system programming. Un- Low-Level Code with Interrupts & Concurrency 1 irq0 1 irq1 fortunately, interrupts are also extremely hard to reason about: they 0 irq2 locks I/O primitives dramatically alter the program control flow and complicate the in- cond var. cli/ 1 irq3 . sti . 1 irq4 variants in low-level concurrent code (e.g., implementation of syn- scheduler device drivers 0 irq5 chronization primitives). Existing formal verification techniques— ctxt switching interrupt handlers 1 irq6 including Hoare logic, typed assembly language, concurrent sepa- 0 irq7 ration logic, and the assume-guarantee method—have consistently ignored the issues of interrupts; this severely limits the applicability Figure 1. “High-Level” vs. “Low-Level” System Programs and power of today’s program verification systems. In this paper we present a novel Hoare-logic-like framework 1. Introduction for certifying low-level system programs involving both hard- Low-level system programs (e.g., thread implementations, device ware interrupts and preemptive threads. We show that enabling drivers, OS kernels, and hypervisors) form the backbone of almost and disabling interrupts can be formalized precisely using simple every safety-critical software system in the world. It is thus highly ownership-transfer semantics, and the same technique also extends desirable to formally certify the correctness of these programs. to the concurrent setting. By carefully reasoning about the inter- Indeed, there have been several new projects launched recently— action among interrupt handlers, context switching, and synchro- including Verisoft/XT (Gargano et al. 2005; Paul et al. 2007), nization libraries, we are able to—for the first time—successfully L4.verified (Tuch et al. 2005), and Singularity (Hunt and Larus certify a preemptive thread implementation and a large number of 2004)—all aiming to build certified OS kernels and/or hypervisors. common synchronization primitives. Our work provides a foun- With formal specifications and provably safe components, certified dation for reasoning about interrupt-based kernel programs and system software can provide a trustworthy computing platform makes an important advance toward building fully certified operat- and enable anticipatory statements about system configurations and ing system kernels and hypervisors. behaviors (Hunt and Larus 2004). Categories and Subject Descriptors F.3.1 [Logics and Meanings Unfortunately, system programs—especially those involving of Programs]: Specifying and Verifying and Reasoning about Pro- both interrupts and concurrency—are extremely hard to reason grams; D.2.4 [Software Engineering]: Software/Program Verifi- about. In Fig. 1, we divide programs in a typical preemptible cation — Correctness proofs, formal methods, reliability; D.3.1 uniprocessor OS kernel into two layers. At the “higher” abstrac- [Programming Languages]: Formal Definitions and Theory — Se- tion level, we have threads that follow the standard concurrent mantics; D.4.5 [Operating Systems]: Reliability — Verification programming model (Hoare 1972): interrupts are invisible, but the execution of a thread can be preempted by other threads; synchro- General Terms Languages, Reliability, Security, Verification nization operations are treated as primitives. Below this layer (see the shaded box), we have more sub- Keywords Hardware Interrupts, Preemptive Threads, Certified tle “lower-level” code involving both interrupts and concurrency. System Software, Concurrency, Separation Logic The implementation of many synchronization primitives and in- put/output operations requires explicit manipulation of interrupts; they behave concurrently in a preemptive way (if interrupt is en- abled) or a non-preemptive way (if interrupt is disabled). When execution of a thread is interrupted, control is transferred to an in- Permission to make digital or hard copies of all or part of this work for personal or terrupt handler, which may call the thread scheduler and switch the classroom use is granted without fee provided that copies are not made or distributed control to another thread. Some of the code in the shaded box (e.g., for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute the scheduler and context switching routine) may behave sequen- to lists, requires prior specific permission and/or a fee. tially since they are always executed with interrupt disabled. PLDI’08, June 7–13, 2008, Tucson, Arizona, USA. Existing program verification techniques (including Hoare Copyright c 2008 ACM 978-1-59593-860-2/08/06. $5.00 logic (Hoare 1969), typed assembly language (Morrisett et al. Locks Condition Variables yield void acq_m(Lock *l); void wait_m(Lock *l, CV *cv); void signal_m(CV *cv); timer_handler void rel_m(Lock *l); void yield() cli/ void acq_h(Lock *l); Sec. 5.1 void wait_h(Lock *l, CV *cv); Sec. 5.2 sti Sec. 6 & [TR] void rel_h(Lock *l); & [TR] void signal_h(Lock *l, CV *cv); & [TR] void acq_spin(Lock *l); void wait_bh(Lock *l, CV *cv); Sec. 3.2 & [TR] Level C void rel_spin(Lock *l); void signal_bh(Lock *l, CV *cv); switch block unblock void scheduler() void blk(queue * q) int unblk(queue * q) Level S [TR] node* deQueue(queue * q) void enQueue(queue * q, node *n) ctxt switching code Figure 3. Structure of Our Certified Preemptive Thread Implementation Thread AHandler 0 Thread B interrupt handlers, context switching, and synchronization libraries. 0 q . ) . Handler 1 Our paper makes the following new contributions: r (1 . i . sti q1 • . ir As far as we know, our work presents the first program logic switch . (see Sec. 4) that can successfully certify the correctness of low- . cli . (4 . ) level programs involving both interrupts and concurrency. Our iret ( cli ( switch 3) 2) iret . idea of using ownership-transfer semantics to model interrupts . ( sti 5) switch is both novel and general (since it also works in the concurrent . sti setting). Our logic supports modular verification: threads and . handlers can be certified in the same way as we certify sequen- tial code without worrying about possible interleaving. Sound- Figure 2. Interaction between Threads and Interrupts ness of our logic is formally proved in the Coq proof assistant. • Following separation logic’s local-reasoning idea, our program 1998), concurrent separation logic (O’Hearn 2004; Brookes 2004), logic also enforces partitions of resources between different and its assume-guarantee variant (Feng et al. 2007a; Vafeiadis and threads and between threads and interrupt handlers. These log- Parkinson 2007)) can probably handle those high-level concurrent ical partitions at different program points essentially give an programs, but they have consistently ignored the issues of inter- abstract formalization of the semantics of interrupts and the in- rupts thus cannot be used to certify concurrent code in the shaded teraction between handlers and threads. box. Having both explicit interrupts and threads creates the follow- • Our AIM machine (see Sec. 3) unifies both the preemptive and ing new challenges: non-preemptive threading models, and to our best knowledge, • Asymmetric preemption relations. Non-handler code may be is the first to successfully formalize concurrency with explicit preempted by an interrupt handler (and low-priority handlers interrupt handlers. In AIM, operations that manipulate thread can be preempted by higher-priority ones), but not vice versa. queues are treated as primitives; These operations, together Interrupt handlers cannot be simply treated as threads (Regehr with the scheduler and context-switching code (the low half of and Cooprider 2007). Fig. 3), are strictly sequential thus can be certified in a simpler • Subtle intertwining between interrupts and threads. In Fig. 2, logic. Certified code at different levels is linked together using thread A is interrupted by the interrupt request irq0. In the an OCAP-style framework (Feng et al. 2007b). handler, the control is switched to thread B. From thread A’s • Synchronization operations can be implemented as subroutines point of view, the behavior of the handler 0 is complex: should in AIM. To demonstrate the power of our framework, we have the handler be responsible for the behavior of thread B? certified, for the first time, various implementations of locks • Asymmetric synchronizations. Synchronization between han- and condition variables (see Sec. 5). Our specifications pinpoint dler and non-handler code is achieved simply by enabling and precisely the differences between different implementations. disabling interrupts (via sti and cli instructions in x86). Unlike locks, interrupts can be disabled by one thread and enabled by 2. Informal Development another. In Fig. 2, thread A disables interrupts and then
Load more

Recommended publications
  • The Programming Language Concurrent Pascal
    IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-I, No.2, JUNE 1975 199 The Programming Language Concurrent Pascal PER BRINCH HANSEN Abstract-The paper describes a new programming language Disk buffer for structured programming of computer operating systems. It e.lt­ tends the sequential programming language Pascal with concurx:~t programming tools called processes and monitors. Section I eltplains these concepts informally by means of pictures illustrating a hier­ archical design of a simple spooling system. Section II uses the same enmple to introduce the language notation. The main contribu~on of Concurrent Pascal is to extend the monitor concept with an .ex­ Producer process Consumer process plicit hierarchy Of access' rights to shared data structures that can Fig. 1. Process communication. be stated in the program text and checked by a compiler. Index Terms-Abstract data types, access rights, classes, con­ current processes, concurrent programming languages, hierarchical operating systems, monitors, scheduling, structured multiprogram­ ming. Access rights Private data Sequential 1. THE PURPOSE OF CONCURRENT PASCAL program A. Background Fig. 2. Process. INCE 1972 I have been working on a new programming .. language for structured programming of computer S The next picture shows a process component in more operating systems. This language is called Concurrent detail (Fig. 2). Pascal. It extends the sequential programming language A process consists of a private data structure and a Pascal with concurrent programming tools called processes sequential program that can operate on the data. One and monitors [1J-[3]' process cannot operate on the private data of another This is an informal description of Concurrent Pascal.
    [Show full text]
  • The Programmer As a Young Dog
    The Programmer as a Young Dog (1976) This autobiographical sketch describes the beginning of the author’s career at the Danish computer company Regnecentralen from 1963 to 1970. (The title is inspired by James Joyce’s “A Portrait of the Artist as a Young Man” and Dylan Thomas’s “Portrait of the Artist as a Young Dog.”) After three years in Regnecentralen’s compiler group, the author got the chance to design the architecture of the RC 4000 computer. In 1967, he became Head of the Software Development group that designed the RC 4000 multiprogramming system. The article was written in memory of Niels Ivar Bech, the dynamic director of Regnecentralen, who inspired a generation of young Danes to make unique contributions to computing. I came to Regnecentralen in 1963 to work with Peter Naur and Jrn Jensen. The two of them worked so closely together that they hardly needed to say anything to solve a problem. I remember a discussion where Peter was writing something on the blackboard, when Jrn suddenly said “but Peter ...” and immediately was interrupted with the reply “yes, of course, Jrn.” I swear that nothing else was said. It made quite an impression on me, especially since I didn’t even know what the discussion was about in the rst place. After a two-year apprenticeship as a systems programmer, I wanted to travel abroad and work for IBM in Winchester in Southern England. At that time Henning Isaksson was planning to build a process control computer for Haldor Topse, Ltd. Henning had asked Niels Ivar Bech for a systems programmer for quite some time.
    [Show full text]
  • Part Iii Harnessing Parallelism
    PART III HARNESSING PARALLELISM The primary impetus behind the study of parallel programming, or concurrent programming as some would call it, was the necessity to write operating systems. While the first computers were simple enough to be considered sequential in nature, the advent of faster central processing units and the accompanying discrepancy in speed between the central processor and periph­ eral devices forced the consideration of possible concurrent activity of these mechanisms. The operating system was asked to control concurrent activity, and to control it in such a way that concurrent activity was maximized This desire for concurrent activity resulted in machine features such as the channel and the interrupt-the mechanism by which termination of an I/O activity is signaled The main problem with the interrupt, as far as the operating system designer was concerned, was its inherent unpredictability. Not knowing exactly when an interrupt could occur, the operating system had to be designed to expect an interrupt at any time. With the advent of multiprogramming and interactive, on-line processing, it became clear that the original motivation for parallelism-the control and exploitation of concurrent I/O-was only a special case, and some fundamen­ tal concepts began to emerge for study and use in more general parallel programming situations. Thus emerged the general idea of a set of processes executing concurrently, with the need for synchronization and mutual exclu­ sion (with respect to time) of some of their activities. The past 10-15 years have seen an enormous amount of activity in studying the general problem, a very small part of which is presented here.
    [Show full text]
  • A Programmer's Story. the Life of a Computer Pioneer
    A PROGRAMMER’S STORY The Life of a Computer Pioneer PER BRINCH HANSEN FOR CHARLES HAYDEN Copyright c 2004 by Per Brinch Hansen. All rights reserved. Per Brinch Hansen 5070 Pine Valley Drive, Fayetteville, NY 13066, USA CONTENTS Acknowledgments v 1 Learning to Read and Write 1938–57 1 Nobody ever writes two books – My parents – Hitler occupies Denmark – Talking in kindergarten – A visionary teacher – The class newspaper – “The topic” – An elite high school – Variety of teachers – Chemical experiments – Playing tennis with a champion – Listening to jazz – “Ulysses” and other novels. 2 Choosing a Career 1957–63 17 Advice from a professor – Technical University of Denmark – rsted’s inuence – Distant professors – Easter brew – Fired for being late – International exchange student – Masers and lasers – Radio talk — Graduation trip to Yugoslavia – An attractive tourist guide – Master of Science – Professional goals. 3 Learning from the Masters 1963–66 35 Regnecentralen – Algol 60 – Peter Naur and Jrn Jensen – Dask and Gier Algol – The mysterious Cobol 61 report – I join the compiler group – Playing roulette at Marienlyst resort – Jump- starting Siemens Cobol at Mogenstrup Inn – Negotiating salary – Compiler testing in Munich – Naur and Dijkstra smile in Stock- holm – The Cobol compiler is nished – Milena and I are married in Slovenia. 4 Young Man in a Hurr 1966–70 59 Naur’s vision of datalogy – Architect of the RC 4000 computer – Programming a real-time system – Working with Henning Isaks- son, Peter Kraft, and Charles Simonyi – Edsger Dijkstra’s inu- ence – Head of software development – Risking my future at Hotel Marina – The RC 4000 multiprogramming system – I meet Edsger Dijkstra, Niklaus Wirth, and Tony Hoare – The genius of Niels Ivar Bech.
    [Show full text]
  • Virtual Organization Clusters: Self-Provisioned Clouds on the Grid Michael Murphy Clemson University, [email protected]
    Clemson University TigerPrints All Dissertations Dissertations 5-2010 Virtual Organization Clusters: Self-Provisioned Clouds on the Grid Michael Murphy Clemson University, [email protected] Follow this and additional works at: https://tigerprints.clemson.edu/all_dissertations Part of the Computer Sciences Commons Recommended Citation Murphy, Michael, "Virtual Organization Clusters: Self-Provisioned Clouds on the Grid" (2010). All Dissertations. 511. https://tigerprints.clemson.edu/all_dissertations/511 This Dissertation is brought to you for free and open access by the Dissertations at TigerPrints. It has been accepted for inclusion in All Dissertations by an authorized administrator of TigerPrints. For more information, please contact [email protected]. Virtual Organization Clusters: Self-Provisioned Clouds on the Grid A Dissertation Presented to the Graduate School of Clemson University In Partial Fulfillment of the Requirements for the Degree Doctor of Philosophy Computer Science by Michael A. Murphy May 2010 Accepted by: Dr. Sebastien Goasguen, Committee Chair Dr. Jim Martin Dr. Walt Ligon Dr. Robert Geist Abstract Virtual Organization Clusters (VOCs) provide a novel architecture for overlaying dedicated cluster systems on existing grid infrastructures. VOCs provide customized, homogeneous execution environments on a per-Virtual Organization basis, without the cost of physical cluster construction or the overhead of per-job containers. Administrative access and overlay network capabilities are granted to Virtual Organizations (VOs) that choose to implement VOC technology, while the system remains completely transparent to end users and non-participating VOs. Unlike alternative systems that require explicit leases, VOCs are autonomically self-provisioned according to configurable usage policies. As a grid computing architecture, VOCs are designed to be technology agnostic and are implementable by any combination of software and services that follows the Virtual Organization Cluster Model.
    [Show full text]
  • Downloading from Naur's Website: 19
    1 2017.04.16 Accepted for publication in Nuncius Hamburgensis, Band 20. Preprint of invited paper for Gudrun Wolfschmidt's book: Vom Abakus zum Computer - Begleitbuch zur Ausstellung "Geschichte der Rechentechnik", 2015-2019 GIER: A Danish computer from 1961 with a role in the modern revolution of astronomy By Erik Høg, lektor emeritus, Niels Bohr Institute, Copenhagen Abstract: A Danish computer, GIER, from 1961 played a vital role in the development of a new method for astrometric measurement. This method, photon counting astrometry, ultimately led to two satellites with a significant role in the modern revolution of astronomy. A GIER was installed at the Hamburg Observatory in 1964 where it was used to implement the entirely new method for the meas- urement of stellar positions by means of a meridian circle, then the fundamental instrument of as- trometry. An expedition to Perth in Western Australia with the instrument and the computer was a suc- cess. This method was also implemented in space in the first ever astrometric satellite Hipparcos launched by ESA in 1989. The Hipparcos results published in 1997 revolutionized astrometry with an impact in all branches of astronomy from the solar system and stellar structure to cosmic distances and the dynamics of the Milky Way. In turn, the results paved the way for a successor, the one million times more powerful Gaia astrometry satellite launched by ESA in 2013. Preparations for a Gaia suc- cessor in twenty years are making progress. Zusammenfassung: Eine elektronische Rechenmaschine, GIER, von 1961 aus Dänischer Herkunft spielte eine vitale Rolle bei der Entwiklung einer neuen astrometrischen Messmethode.
    [Show full text]
  • A Secure Computing Platform for Building Automation Using Microkernel-Based Operating Systems Xiaolong Wang University of South Florida, [email protected]
    University of South Florida Scholar Commons Graduate Theses and Dissertations Graduate School November 2018 A Secure Computing Platform for Building Automation Using Microkernel-based Operating Systems Xiaolong Wang University of South Florida, [email protected] Follow this and additional works at: https://scholarcommons.usf.edu/etd Part of the Computer Sciences Commons Scholar Commons Citation Wang, Xiaolong, "A Secure Computing Platform for Building Automation Using Microkernel-based Operating Systems" (2018). Graduate Theses and Dissertations. https://scholarcommons.usf.edu/etd/7589 This Dissertation is brought to you for free and open access by the Graduate School at Scholar Commons. It has been accepted for inclusion in Graduate Theses and Dissertations by an authorized administrator of Scholar Commons. For more information, please contact [email protected]. A Secure Computing Platform for Building Automation Using Microkernel-based Operating Systems by Xiaolong Wang A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Computer Science and Engineering Department of Computer Science and Engineering College of Engineering University of South Florida Major Professor: Xinming Ou, Ph.D. Jarred Ligatti, Ph.D. Srinivas Katkoori, Ph.D. Nasir Ghani, Ph.D. Siva Raj Rajagopalan, Ph.D. Date of Approval: October 26, 2018 Keywords: System Security, Embedded System, Internet of Things, Cyber-Physical Systems Copyright © 2018, Xiaolong Wang DEDICATION In loving memory of my father, to my beloved, Blanka, and my family. Thank you for your love and support. ACKNOWLEDGMENTS First and foremost, I would like to thank my advisor, Dr. Xinming Ou for his guidance, encouragement, and unreserved support throughout my PhD journey.
    [Show full text]
  • Kernel Operating System
    International Journal of Advanced Technology in Engineering and Science www.ijates.com Volume No.02, Special Issue No. 01, September 2014 ISSN (online): 2348 – 7550 KERNEL OPERATING SYSTEM Manjeet Saini1, Abhishek Jain2, Ashish Chauhan3 Department Of Computer Science And Engineering, Dronacharya College Of Engineering Khentawas, Farrukh Nagar, Gurgaon, Haryana, (India) ABSTRACT The central module of an operating system (OS) is the Kernel. It is the part of the operating system that loads first, and it remains in main memory. It is necessary for the kernel to be very small while still providing all the essential services needed by other parts of the OS because it stays in the memory. To prevent kernel code from being overwritten by programs or other parts of the operating system it is loaded into a protected area of memory. The presence of an operating system kernel is not a necessity to run a computer. Directly loading and executing the programs on the "bare metal" machine is possible, provided that the program authors are willing to do without any OS support or hardware abstraction. Many video game consoles and embedded systems still constitute the “bare metal” approach. But in general, newer systems use kernels and operating systems. Keywords: Scalability, Multicore Processors, Message Passing I. INTRODUCTION In computing, the kernel is a computer program that manages input/output requests from software, and translates them into data processing instructions for the central processing unit and other electronic components of a computer. When a computer program (in this context called a process) makes requests of the kernel, the request is called a system call.
    [Show full text]
  • Teaching Computer Languages and Elementary Theory for Mixed Audiences at University Level
    Teaching computer languages and elementary theory for mixed audiences at university level Henning Christiansen Roskilde University, Computer Science Dept. P.O.Box 260, DK-4000 Roskilde, Denmark E-mail: [email protected] Abstract. Theoretical issues of computer science are traditionally taught in a way that presupposes a solid mathematical background and are usu- ally considered more or less unaccessible for students without this. An effective methodology is described which has been developed for a target group of university students with different backgrounds such as natural science or humanities. It has been developed for a course that integrates theoretical material on computer languages and abstract machines with practical programming techniques. Prolog used as meta-language for de- scribing language issues is the central instrument in the approach: Formal descriptions become running prototypes that are easy and appealing to test and modify, and can be extended into analyzers, interpreters, and tools such as tracers and debuggers. Experience shows a high learning curve, especially when the principles are extended into a learning-by- doing approach having the students to develop such descriptions them- selves from an informal introduction. 1 Introduction The advanced studies in Computer Science at Roskilde University are offered for students with a variety of different backgrounds such as natural science, hu- manities, and social science basic studies. A distinct characteristic at Roskilde is that 50% of the students’ work consists of project work which means that the nominal time for lectures in the advanced studies is rather small compared with most other universities and there is an obvious danger that the education may concentrate on practical and application oriented aspects without the penetra- tion of theoretical insight and understanding that is expected from a university degree.
    [Show full text]
  • The Solo Operating System the Solo Operating System
    PER BRINCH HANSEN Information Science California Institute of Technology July 1975 THE SOLO OPERATING SYSTEM THE SOLO OPERATING SYSTEM Per Brinch Hansen Information Sciencs California Institute of Technology Pasadena, California 91125 July 1975 This is a description of the Solo operating system written in the programming language Concurrent Pascal for the PDP 11/45 computer. It contains four papers entitled 1. The Solo operating system: A Concurrent Pascal program 2. The Solo operating system. Job interface 3. The Solo operating system: Processes, monitors, and classes 4, Disk scheduling at compile time The development of Concurrent Pascal and Solo has been supported by the National Science Foundation under grant number DCR74-17331 Copyright @ 1975 Par Brinch Hansen THE SOLO OPERATING SYSTEIYI. A CONCURRENT PASCAL PROGRAM Per Brinch Hansen Information Science California Institute of Technology Pasadena, California 91125 June 1975 Summary This is a description of the single-user operating system Solo written in the programming language Concurrent Pascal. It supports the development of sequential and concurrent Pascal programs for the PDP 11/45 computer. Input/output are handled by concurrent processes, Pascal programs can call one another recursively and pass arbitrary parameters among themselves. This makes it possible to use Pascal as a job control language. Solo is the first major example of a hierarchical concurrent program implemented in terms of abstract data types (classes, monitors, and processes) with compile-time control of most access rights. It is described here from the user's point of view as an introduction to anothsr paper describing its internal structure. Key Words and Phrases: Solo operating system, Concurrent Pascal, Job control, Input/output buffering, File system, Disk allocation, Operator communication, Size and performance.
    [Show full text]
  • Microkernel-Based and Capability-Based Operating Systems
    Microkernel-based and Capability-based Operating System Martin Děcký [email protected] March 2021 About the Speaker Charles University Research scientist at D3S (2008 – 2017) Graduated (Ph.D.) in 2015 Co-author of the HelenOS (http://www.helenos.org/) microkernel multiserver operating system Huawei Technologies Senior Research Engineer, Munich Research Center (2017 – 2018) Principal Research Engineer, Dresden Research Center (2019 – present) Martin Děcký, March 25th 2021 Microkernel-based and Capability-based Operating Systems 2 Sweden RC Finland RC UK RC Ireland RC Belgium RC Vancouver Edmonton Toronto Poland RC Ukraine RC Montreal France RC Ottawa Germany, Austria, Switzerland RC Israel RC Beijing Waterloo Italy RC Xi’an Nanjing Japan RC Chengdu Shanghai Wuhan Suzhou Songshanhu Hangzhou HQ Shenzhen India RC Edinburgh Tampere Stockholm Helsinki Cambridge Singapore RC Ipswich Goteburg London Lund Warsaw Leuven Dublin Dresden Nuremburg Kyiv Paris Zurich Munich City R&D Center Lagrange Vienna Grenoble Milan Related Country Research Center Nice Pisa City Research Center Tel Aviv Martin Děcký, March 25th 2021 Microkernel-based and Capability-based Operating Systems 3 Huawei Dresden Research Center (DRC) Since 2019, ~20 employees (plus a virtualization team in Munich) Martin Děcký, March 25th 2021 Microkernel-based and Capability-based Operating Systems 4 Huawei Dresden Research Center (DRC) (2) Focuses on R&D in the domain of operating systems Microkernels, hypervisors Collaboration with the OS Kernel Lab in Huawei HQ Collaboration with
    [Show full text]
  • Concurrent Pascal Machine Concurrent Pascal Machine
    PER BRINCH HANSEN Information Science California Institute of Technology October 1975 CONCURRENT PASCAL MACHINE CONCURRENT PASCAL MACHINE. STORE ALLOCATION Per Brinch Hansen Information Science California Institute of Technology Pasadena, California 91125 October 1975 Summary This describes the allocation of core store among the classes, monitors, and processes of a Concurrent Pascal program running on a PDP 11/45 computer. Key Words and Phrasesl Concurrent Pascal implementation, Virtual machine, Store allocation, PDP 11/45 computer. CR Categories I 4.2, 6.2 The development of Concurrent Pascal has been supported by the National Science Foundation under grant number DCR74-17331. Copyright ~ 1975 Per Brlnch Hansen CONCURRENT PASCAL MACHINE Per Brinch Hansen InforMation Science California Institute of Technology Pasadena. California 91125 October 1975 This is a description of the virtual machine that executes Concurrent Pascal programs on the PDP 11/45 computer. It contains four papers entitled. 1. Concurrent Pascal machine. store allocation 2. Concurrent Pascal machinel Code interpretation 3. Concurrent Pascal machine: Kernel 4. The Concurrent Pascal compiler The development of Concurrent Pascal has been supported by the National Science foundation under grant number DCR74-17331. Copyright ~ 1975 Per Brinch Hansen CONTENTS 1 • INTRODUCTION 1 2. CORE STORE 1 3. VIRTUAL STORE 3 4. DATA SEGMENTS 5 5. PERMANENT VARIABLES 6 6, TEMPORARY VARIABLES 7 7. COMPRomISES 8 REfERENCES 10 1. INTRODUCTION Concurrent Pascal is a programming language for structured programming of computer operating systems [1, 2]. The Concurrent Pascal compiler generates code for a virtual machine that can be simulated by microprogram or machine code on different computers [3] . This paper describes the allocation of core store among the processes of a Concurrent Pascal program running on a PDP 11/45 computer.
    [Show full text]