DOCSLIB.ORG

Sel4: Formal Verification of an OS Kernel

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Sel4: Formal Verification of an OS Kernel seL4: Formal Verification of an OS Kernel Gerwin Klein1;2, Kevin Elphinstone1;2, Gernot Heiser1;2;3 June Andronick1;2, David Cock1, Philip Derrin1∗, Dhammika Elkaduwe1;2,z Kai Engelhardt1;2 Rafal Kolanski1;2, Michael Norrish1;4, Thomas Sewell1, Harvey Tuch1;2y, Simon Winwood1;2 1 NICTA, 2 UNSW, 3 Open Kernel Labs, 4 ANU [email protected] Abstract proach is to reduce the amount of privileged code, Complete formal verification is the only known way in order to minimise the exposure to bugs. This is to guarantee that a system is free of programming a primary motivation behind security kernels and errors. separation kernels [38, 54], the MILS approach [4], We present our experience in performing the for- microkernels [1, 12, 35, 45, 57, 71] and isolation ker- mal, machine-checked verification of the seL4 mi- nels [69], the use of small hypervisors as a minimal crokernel from an abstract specification down to its trust base [16,26,56,59], as well as systems that re- C implementation. We assume correctness of com- quire the use of type-safe languages for all code except piler, assembly code, and hardware, and we used a some \dirty" core [7,23]. Similarly, the Common Cri- unique design approach that fuses formal and oper- teria [66] at the strictest evaluation level requires the ating systems techniques. To our knowledge, this is system under evaluation to have a \simple" design. the first formal proof of functional correctness of a With truly small kernels it becomes possible to take complete, general-purpose operating-system kernel. security and robustness further, to the point where Functional correctness means here that the implemen- it is possible to guarantee the absence of bugs [22, tation always strictly follows our high-level abstract 36,56,64]. This can be achieved by formal, machine- specification of kernel behaviour. This encompasses checked verification, providing mathematical proof traditional design and implementation safety proper- that the kernel implementation is consistent with ties such as the kernel will never crash, and it will its specification and free from programmer-induced never perform an unsafe operation. It also proves implementation defects. much more: we can predict precisely how the kernel We present seL4, a member of the L4 [46] microker- will behave in every possible situation. nel family, designed to provide this ultimate degree seL4, a third-generation microkernel of L4 prove- of assurance of functional correctness by machine- nance, comprises 8,700 lines of C code and 600 lines assisted and machine-checked formal proof. We have of assembler. Its performance is comparable to other shown the correctness of a very detailed, low-level high-performance L4 kernels. design of seL4 and we have formally verified its C 1 Introduction implementation. We assume the correctness of the The security and reliability of a computer system compiler, assembly code, boot code, management of can only be as good as that of the underlying oper- caches, and the hardware; we prove everything else. ating system (OS) kernel. The kernel, defined as the Specifically, seL4 achieves the following: part of the system executing in the most privileged • it is suitable for real-life use, and able to achieve mode of the processor, has unlimited hardware access. performance that is comparable with the best- Therefore, any fault in the kernel's implementation performing microkernels; has the potential to undermine the correct operation • its behaviour is precisely formally specified at of the rest of the system. an abstract level; General wisdom has it that bugs in any sizeable • its formal design is used to prove desirable code base are inevitable. As a consequence, when properties, including termination and execution security or reliability is paramount, the usual ap- safety; Philip Derrin is now at Open Kernel Labs. • its implementation is formally proven to satisfy ∗ the specification; and yHarvey Tuch is now at VMware. zDhammika Elkaduwe is now at University of Peradeniya • its access control mechanism is formally proven 1 to provide strong security guarantees. also propagated via IPC to support virtualisation. To our knowledge, seL4 is the first-ever general- IPC uses synchronous and asynchronous endpoints purpose OS kernel that is fully formally verified for (port-like destinations without in-kernel buffering) functional correctness. As such, it is a platform of for inter-thread communication, with RPC facilitated unprecedented trustworthiness, which will allow the via reply capabilities. Capabilities are segregated and construction of highly secure and reliable systems on stored in capability address spaces composed of ca- top. pability container objects called CNodes. The functional-correctness property we prove for As in traditional L4 kernels, seL4 device drivers run seL4 is much stronger and more precise than what as normal user-mode applications that have access automated techniques like model checking, static to device registers and memory either by mapping analysis or kernel implementations in type-safe lan- the device into the virtual address space, or by con- guages can achieve. We not only analyse specific trolled access to device ports on Intel x86 hardware. aspects of the kernel, such as safe execution, but also seL4 provides a mechanism to receive notification of provide a full specification and proof for the kernel's interrupts (via IPC) and acknowledge their receipt. precise behaviour. Memory management in seL4 is explicit: both in- We have created a methodology for rapid kernel de- kernel objects and virtual address spaces are pro- sign and implementation that is a fusion of traditional tected and managed via capabilities. Physical mem- operating systems and formal methods techniques. ory is initially represented by untyped capabilities, We found that our verification focus improved the which can be subdivided or retyped into kernel objects design and was surprisingly often not in conflict with such as page tables, thread control blocks, CNodes, achieving performance. endpoints, and frames (for mapping in virtual ad- In this paper, we present the design of seL4, discuss dress spaces). The model guarantees all memory the methodologies we used, and provide an overview allocation in the kernel is explicit and authorised. of the approach used in the formal verification from Initial development of seL4, and all verification high-level specification to the C implementation. We work, was done for an ARMv6-based platform, with also discuss the lessons we have learnt from the a subsequent port of the kernel (so far without proof) project, and the implications for similar efforts. to x86. The remainder of this paper is structured as fol- 2.2 Kernel design process lows. In Sect. 2, we give an overview of seL4, of the OS developers tend to take a bottom-up approach to design approach, and of the verification approach. In kernel design. High performance is obtained by man- Sect. 3, we describe how to design a kernel for formal aging the hardware efficiently, which leads to designs verification. In Sect. 4, we describe precisely what motivated by low-level details. In contrast, formal we verified, and identify the assumptions we make. methods practitioners tend toward top-down design, In Sect. 5, we describe important lessons we learnt as proof tractability is determined by system com- in this project, and in Sect. 6, we contrast our effort plexity. This leads to designs based on simple models with related work. with a high degree of abstraction from hardware. As a compromise that blends both views, we 2 Overview adopted an approach [19, 22] based around an in- 2.1 seL4 programming model termediate target that is readily accessible by both This paper is primarily about the formal verification OS developers and formal methods practitioners. It of the seL4 kernel, not its API design. We therefore uses the functional programming language Haskell to provide only a brief overview of its main characteris- provide a programming language for OS developers, tics. while at the same time providing an artefact that can seL4 [20], similarly to projects at Johns Hopkins be automatically translated into the theorem proving (Coyotos) and Dresden (Nova), is a third-generation tool and reasoned about. microkernel, and is broadly based on L4 [46] and Fig. 1 shows our approach in more detail. The influenced by EROS [58]. It features abstractions for square boxes are formal artefacts that have a direct virtual address spaces, threads, inter-process commu- role in the proof. The double arrows represent imple- nication (IPC), and, unlike most L4 kernels, capabili- mentation or proof effort, the single arrows represent ties for authorisation. Virtual address spaces have no design/implementation influence of artefacts on other kernel-defined structure; page faults are propagated artefacts. The central artefact is the Haskell proto- via IPC to pager threads, responsible for defining type of the kernel. The prototype requires the design the address space by mapping frames into the virtual and implementation of algorithms that manage the space. Exceptions and non-native system calls are low-level hardware details. To execute the Haskell Design Cycle Isabelle/HOL Design Abstract Specification Hardware Haskell Executable Specification Haskell Prototype Formal Executable Spec Simulator + Prototype Manual Proof Implementation Automatic Translation High-Performance C Implementation Refinement Proof User Programs High-Performance C Implementation Figure 1: The seL4 design process Figure 2: The refinement layers in the verification of seL4 prototype in a near-to-realistic setting, we link it with software (derived from QEMU) that simulates opportunities to micro-optimise the kernel, which is the hardware platform. Normal user-level execution required for adequate microkernel performance. is enabled by the simulator, while traps are passed 2.3 Formal verification to the kernel model which computes the result of The technique we use for formal verification is inter- the trap. The prototype modifies the user-level state active, machine-assisted and machine-checked proof.
Load more

Recommended publications
  • Automatic Sandboxing of Unsafe Software Components in High Level Languages
    Master Thesis Automatic Sandboxing of Unsafe Software Components in High Level Languages Benjamin Lamowski Technische Universität Dresden Fakultät Informatik Institut für Systemarchitektur Professur Betriebssysteme Betreuender Hochschullehrer: Prof. Dr. rer. nat. Hermann Härtig Betreuender Mitarbeiter: Dr. Carsten Weinhold 3. Mai 2017 Aufgabenstellung Neue “sichere“ Programmiersprachen wie Go, Swift oder Rust wurden nicht nur für die normale Anwendungsentwicklung entworfen, sondern sie zielen auch auf eine hochper- formante Ausführung und Programmierung vergleichsweise systemnaher Funktionalität ab. Eine attraktive Eigenschaft beispielsweise von Rust ist das gegenüber C und C++ deutlich strengere Speicherverwaltungsmodell, bei dem bereits zur Kompilierzeit der Lebenszyklus und die Erreichbarkeit von Objekten sowie die Zuständigkeit für deren Allokation und Deallokation wohldefiniert sind. Ganze Klassen von Programmfehlern wie etwa Buffer Overflows oder Dereferenzierung ungültige Zeiger werden dadurch eliminiert und die Programme mithin sicherer und robuster. Aus diversen Gründen müssen Programme, die in sicheren Sprachen geschriebenen wurden, aber oftmals auf “unsicheren“ Legacy-Code zurückgreifen. So bietet etwa Rust über das “unsafe“-Sprachelement die Möglichkeit, Funktionen innerhalb von Bibliotheken aufzurufen, die in fehleranfälligem C geschrieben sind. Leider werden die vom Com- piler durchgesetzten Garantien der sicheren Sprache hinfällig, sobald im Code einer C-Bibliothek ein Speicherfehler auftritt. Ein Schreibzugriff etwa durch
    [Show full text]
  • Demystifying the Real-Time Linux Scheduling Latency
    Demystifying the Real-Time Linux Scheduling Latency Daniel Bristot de Oliveira Red Hat, Italy [email protected] Daniel Casini Scuola Superiore Sant’Anna, Italy [email protected] Rômulo Silva de Oliveira Universidade Federal de Santa Catarina, Brazil [email protected] Tommaso Cucinotta Scuola Superiore Sant’Anna, Italy [email protected] Abstract Linux has become a viable operating system for many real-time workloads. However, the black-box approach adopted by cyclictest, the tool used to evaluate the main real-time metric of the kernel, the scheduling latency, along with the absence of a theoretically-sound description of the in-kernel behavior, sheds some doubts about Linux meriting the real-time adjective. Aiming at clarifying the PREEMPT_RT Linux scheduling latency, this paper leverages the Thread Synchronization Model of Linux to derive a set of properties and rules defining the Linux kernel behavior from a scheduling perspective. These rules are then leveraged to derive a sound bound to the scheduling latency, considering all the sources of delays occurring in all possible sequences of synchronization events in the kernel. This paper also presents a tracing method, efficient in time and memory overheads, to observe the kernel events needed to define the variables used in the analysis. This results in an easy-to-use tool for deriving reliable scheduling latency bounds that can be used in practice. Finally, an experimental analysis compares the cyclictest and the proposed tool, showing that the proposed method can find sound bounds faster with acceptable overheads. 2012 ACM Subject Classification Computer systems organization → Real-time operating systems Keywords and phrases Real-time operating systems, Linux kernel, PREEMPT_RT, Scheduling latency Digital Object Identifier 10.4230/LIPIcs.ECRTS.2020.9 Supplementary Material ECRTS 2020 Artifact Evaluation approved artifact available at https://doi.org/10.4230/DARTS.6.1.3.
    [Show full text]
  • A Microkernel API for Fine-Grained Decomposition
    A Microkernel API for Fine-Grained Decomposition Sebastian Reichelt Jan Stoess Frank Bellosa System Architecture Group, University of Karlsruhe, Germany freichelt,stoess,[email protected] ABSTRACT from the microkernel APIs in existence. The need, for in- Microkernel-based operating systems typically require spe- stance, to explicitly pass messages between servers, or the cial attention to issues that otherwise arise only in dis- need to set up threads and address spaces in every server for tributed systems. The resulting extra code degrades per- parallelism or protection require OS developers to adopt the formance and increases development effort, severely limiting mindset of a distributed-system programmer rather than to decomposition granularity. take advantage of their knowledge on traditional OS design. We present a new microkernel design that enables OS devel- Distributed-system paradigms, though well-understood and opers to decompose systems into very fine-grained servers. suited for physically (and, thus, coarsely) partitioned sys- We avoid the typical obstacles by defining servers as light- tems, present obstacles to the fine-grained decomposition weight, passive objects. We replace complex IPC mecha- required to exploit the benefits of microkernels: First, a nisms by a simple function-call approach, and our passive, lot of development effort must be spent into matching the module-like server model obviates the need to create threads OS structure to the architecture of the selected microkernel, in every server. Server code is compiled into small self- which also hinders porting existing code from monolithic sys- contained files, which can be loaded into the same address tems. Second, the more servers exist | a desired property space (for speed) or different address spaces (for safety).
    [Show full text]
  • A Practical UNIX Capability System
    A Practical UNIX Capability System Adam Langley <[email protected]> 22nd June 2005 ii Abstract This report seeks to document the development of a capability security system based on a Linux kernel and to follow through the implications of such a system. After defining terms, several other capability systems are discussed and found to be excellent, but to have too high a barrier to entry. This motivates the development of the above system. The capability system decomposes traditionally monolithic applications into a number of communicating actors, each of which is a separate process. Actors may only communicate using the capabilities given to them and so the impact of a vulnerability in a given actor can be reasoned about. This design pattern is demonstrated to be advantageous in terms of security, comprehensibility and mod- ularity and with an acceptable performance penality. From this, following through a few of the further avenues which present themselves is the two hours traffic of our stage. Acknowledgments I would like to thank my supervisor, Dr Kelly, for all the time he has put into cajoling and persuading me that the rest of the world might have a trick or two worth learning. Also, I’d like to thank Bryce Wilcox-O’Hearn for introducing me to capabilities many years ago. Contents 1 Introduction 1 2 Terms 3 2.1 POSIX ‘Capabilities’ . 3 2.2 Password Capabilities . 4 3 Motivations 7 3.1 Ambient Authority . 7 3.2 Confused Deputy . 8 3.3 Pervasive Testing . 8 3.4 Clear Auditing of Vulnerabilities . 9 3.5 Easy Configurability .
    [Show full text]
  • Interrupt Handling in Linux
    Department Informatik Technical Reports / ISSN 2191-5008 Valentin Rothberg Interrupt Handling in Linux Technical Report CS-2015-07 November 2015 Please cite as: Valentin Rothberg, “Interrupt Handling in Linux,” Friedrich-Alexander-Universitat¨ Erlangen-Nurnberg,¨ Dept. of Computer Science, Technical Reports, CS-2015-07, November 2015. Friedrich-Alexander-Universitat¨ Erlangen-Nurnberg¨ Department Informatik Martensstr. 3 · 91058 Erlangen · Germany www.cs.fau.de Interrupt Handling in Linux Valentin Rothberg Distributed Systems and Operating Systems Dept. of Computer Science, University of Erlangen, Germany [email protected] November 8, 2015 An interrupt is an event that alters the sequence of instructions executed by a processor and requires immediate attention. When the processor receives an interrupt signal, it may temporarily switch control to an inter- rupt service routine (ISR) and the suspended process (i.e., the previously running program) will be resumed as soon as the interrupt is being served. The generic term interrupt is oftentimes used synonymously for two terms, interrupts and exceptions [2]. An exception is a synchronous event that occurs when the processor detects an error condition while executing an instruction. Such an error condition may be a devision by zero, a page fault, a protection violation, etc. An interrupt, on the other hand, is an asynchronous event that occurs at random times during execution of a pro- gram in response to a signal from hardware. A proper and timely handling of interrupts is critical to the performance, but also to the security of a computer system. In general, interrupts can be emitted by hardware as well as by software. Software interrupts (e.g., via the INT n instruction of the x86 instruction set architecture (ISA) [5]) are means to change the execution context of a program to a more privileged interrupt context in order to enter the kernel and, in contrast to hardware interrupts, occur synchronously to the currently running program.
    [Show full text]
  • On the Construction of Reliable Device Drivers Leonid Ryzhyk
    On the Construction of Reliable Device Drivers Leonid Ryzhyk Ph.D. 2009 ii iii ‘I hereby declare that this submission is my own work and to the best of my knowledge it contains no materials previously pub- lished or written by another person, or substantial proportions of material which have been accepted for the award of any other degree or diploma at UNSW or any other educational institution, except where due acknowledgement is made in the thesis. Any contribution made to the research by others, with whom I have worked at UNSW or elsewhere, is explicitly acknowledged in the thesis. I also declare that the intellectual content of this the- sis is the product of my own work, except to the extent that as- sistance from others in the project’s design and conception or in style, presentation, and linguistic expression is acknowledged.’ Signed .................................. Date .................................. iv Abstract This dissertation is dedicated to the problem of device driver reliability. Software defects in device drivers constitute the biggest source of failure in operating systems, causing sig- nificant damage through downtime and data loss. Previous research on driver reliability has concentrated on detecting and mitigating defects in existing drivers using static analysis or runtime isolation. In contrast, this dissertation presents an approach to reducing the number of defects through an improved device driver architecture and development process. In analysing factors that contribute to driver complexity and induce errors, I show that a large proportion of errors are due to two key shortcomings in the device-driver architecture enforced by current operating systems: poorly-defined communication protocols between drivers and the operating system, which confuse developers and lead to protocol violations, and a multithreaded model of computation, which leads to numerous race conditions and deadlocks.
    [Show full text]
  • UG1046 Ultrafast Embedded Design Methodology Guide
    UltraFast Embedded Design Methodology Guide UG1046 (v2.3) April 20, 2018 Revision History The following table shows the revision history for this document. Date Version Revision 04/20/2018 2.3 • Added a note in the Overview section of Chapter 5. • Replaced BFM terminology with VIP across the user guide. 07/27/2017 2.2 • Vivado IDE updates and minor editorial changes. 04/22/2015 2.1 • Added Embedded Design Methodology Checklist. • Added Accessing Documentation and Training. 03/26/2015 2.0 • Added SDSoC Environment. • Added Related Design Hubs. 10/20/2014 1.1 • Removed outdated information. •In System Level Considerations, added information to the following sections: ° Performance ° Clocking and Reset 10/08/2014 1.0 Initial Release of document. UltraFast Embedded Design Methodology Guide Send Feedback 2 UG1046 (v2.3) April 20, 2018 www.xilinx.com Table of Contents Chapter 1: Introduction Embedded Design Methodology Checklist. 9 Accessing Documentation and Training . 10 Chapter 2: System Level Considerations Performance. 13 Power Consumption . 18 Clocking and Reset. 36 Interrupts . 41 Embedded Device Security . 45 Profiling and Partitioning . 51 Chapter 3: Hardware Design Considerations Configuration and Boot Devices . 63 Memory Interfaces . 69 Peripherals . 76 Designing IP Blocks . 94 Hardware Performance Considerations . 102 Dataflow . 108 PL Clocking Methodology . 112 ACP and Cache Coherency. 116 PL High-Performance Port Access. 120 System Management Hardware Assistance. 124 Managing Hardware Reconfiguration . 127 GPs and Direct PL Access from APU . 133 Chapter 4: Software Design Considerations Processor Configuration . 137 OS and RTOS Choices . 142 Libraries and Middleware . 152 Boot Loaders . 156 Software Development Tools . 162 UltraFast Embedded Design Methodology GuideSend Feedback 3 UG1046 (v2.3) April 20, 2018 www.xilinx.com Chapter 5: Hardware Design Flow Overview .
    [Show full text]
  • Microkernel Mechanisms for Improving the Trustworthiness of Commodity Hardware
    Microkernel Mechanisms for Improving the Trustworthiness of Commodity Hardware Yanyan Shen Submitted in fulfilment of the requirements for the degree of Doctor of Philosophy School of Computer Science and Engineering Faculty of Engineering March 2019 Thesis/Dissertation Sheet Surname/Family Name : Shen Given Name/s : Yanyan Abbreviation for degree as give in the University calendar : PhD Faculty : Faculty of Engineering School : School of Computer Science and Engineering Microkernel Mechanisms for Improving the Trustworthiness of Commodity Thesis Title : Hardware Abstract 350 words maximum: (PLEASE TYPE) The thesis presents microkernel-based software-implemented mechanisms for improving the trustworthiness of computer systems based on commercial off-the-shelf (COTS) hardware that can malfunction when the hardware is impacted by transient hardware faults. The hardware anomalies, if undetected, can cause data corruptions, system crashes, and security vulnerabilities, significantly undermining system dependability. Specifically, we adopt the single event upset (SEU) fault model and address transient CPU or memory faults. We take advantage of the functional correctness and isolation guarantee provided by the formally verified seL4 microkernel and hardware redundancy provided by multicore processors, design the redundant co-execution (RCoE) architecture that replicates a whole software system (including the microkernel) onto different CPU cores, and implement two variants, loosely-coupled redundant co-execution (LC-RCoE) and closely-coupled redundant co-execution (CC-RCoE), for the ARM and x86 architectures. RCoE treats each replica of the software system as a state machine and ensures that the replicas start from the same initial state, observe consistent inputs, perform equivalent state transitions, and thus produce consistent outputs during error-free executions.
    [Show full text]
  • Microsoft and Wind River Are Currently in a "Dead Heat" For
    Microsoft and Wind River are currently in a "dead heat" for the top position in sales of embedded operating system software and toolkits, according to Stephen Balacco, embedded software analyst at Venture Development Corp. (VDC). In terms of the sale of real-time operating systems, on the other hand, Balacco said Wind River still maintains a "commanding market leadership position," but noted that Wind River has been "as challenged as any supplier in this market space over the last two years in the face of a slumping telecommunications industry, where they have been highly leveraged for sales, as well as [from] increased competition from royalty-free and Linux OS vendors making inroads." While not disclosing specific market share numbers publicly, VDC provided the following list indicating the market share position in terms of sales revenue, for the leading vendors in the embedded operating system market . 1. Microsoft 2. Wind River 3. Symbian 4. Palm 5. QNX 6. Enea Data 7. Green Hills Software 8. LynuxWorks 9. MontaVista Software 10. Accelerated Technology (Mentor Graphics) Included among key factors identified by VDC as impacting this market were . • Increased focus and emphasis on bundling integrated development solutions that minimize unnecessary and repetitive development and allow OEMs to focus on their core competencies in differentiating their product through the application; • Ability of OS vendors to adapt business models that are flexible in their pricing and terms and conditions in response to a changing set of market requirements spurred on by competitive market forces; and • A telecommunications market that continues to struggle has affected investments in new projects.
    [Show full text]
  • The OKL4 Microvisor: Convergence Point of Microkernels and Hypervisors
    The OKL4 Microvisor: Convergence Point of Microkernels and Hypervisors Gernot Heiser, Ben Leslie Open Kernel Labs and NICTA and UNSW Sydney, Australia ok-labs.com ©2010 Open Kernel Labs and NICTA. All rights reserved. Microkernels vs Hypervisors > Hypervisors = “microkernels done right?” [Hand et al, HotOS ‘05] • Talks about “liability inversion”, “IPC irrelevance” … > What’s the difference anyway? ok-labs.com ©2010 Open Kernel Labs and NICTA. All rights reserved. 2 What are Hypervisors? > Hypervisor = “virtual machine monitor” • Designed to multiplex multiple virtual machines on single physical machine VM1 VM2 Apps Apps AppsApps AppsApps OS OS Hypervisor > Invented in ‘60s to time-share with single-user OSes > Re-discovered in ‘00s to work around broken OS resource management ok-labs.com ©2010 Open Kernel Labs and NICTA. All rights reserved. 3 What are Microkernels? > Designed to minimise kernel code • Remove policy, services, retain mechanisms • Run OS services in user-mode • Software-engineering and dependability reasons • L4: ≈ 10 kLOC, Xen ≈ 100 kLOC, Linux: ≈ 10,000 kLOC ServersServers ServersServers Apps Servers Device AppsApps Drivers Microkernel > IPC performance critical (highly optimised) • Achieved by API simplicity, cache-friendly implementation > Invented 1970 [Brinch Hansen], popularised late ‘80s (Mach, Chorus) ok-labs.com ©2010 Open Kernel Labs and NICTA. All rights reserved. 4 What’s the Difference? > Both contain all code executing at highest privilege level • Although hypervisor may contain user-mode code as well > Both need to abstract hardware resources • Hypervisor: abstraction closely models hardware • Microkernel: abstraction designed to support wide range of systems > What must be abstracted? • Memory • CPU • I/O • Communication ok-labs.com ©2010 Open Kernel Labs and NICTA.
    [Show full text]
  • Formal Modelling of Separation Kernels
    The University of York Department of Computer Science Submitted in part fulfilment for the degree of MSc in Software Engineering. Formal Modelling of Separation Kernels Andrius Velykis 18th September 20091 Supervised by Dr Leo Freitas Number of words = 45327, as counted by detex <report.tex> j wc -w. This report consists of 98 pages in total. This includes the body of the report (without blank pages) and Appendix A, but not Appendices B, C, D, E and F. 1Updated transactional operation proofs, 21st September 2009. Abstract A separation kernel is an architecture for secure applications, which benefits from inherent security of distributed systems. Due to its small size and usage in high-integrity environments, it makes a good target for formal modelling and verification. This project presents results from mechanisation and modelling of separation kernel components: a process table, a process queue and a scheduler. The results have been developed as a part of the pilot project within the international Grand Challenge in Verified Software. This thesis covers full development life-cycle from project initiation through design and evaluation to successful completion. Important findings about kernel properties, formal modelling and design decisions are discussed. The developed formal specification is fully verified and contributes to the pilot project aim of creating a formal kernel model and refining it down to implementation code. Other reusable artefacts, such as general lemmas and a new technique of ensuring transactional properties of operations are defined. The results will be curated within the Verified Software Repository. i Robertai. Aˇci¯u. Acknowledgements I would like to thank Dr Leo Freitas for his supervision, encouragement and getting me hooked on formal methods.
    [Show full text]
  • ADSP-BF537 EZ-KIT Lite® Evaluation System Manual
    ADSP-BF537 EZ-KIT Lite® Evaluation System Manual Revision 2.4, April 2008 Part Number 82-000865-01 Analog Devices, Inc. One Technology Way Norwood, Mass. 02062-9106 a Copyright Information ©2008 Analog Devices, Inc., ALL RIGHTS RESERVED. This document may not be reproduced in any form without prior, express written consent from Analog Devices, Inc. Printed in the USA. Limited Warranty The EZ-KIT Lite evaluation system is warranted against defects in materi- als and workmanship for a period of one year from the date of purchase from Analog Devices or from an authorized dealer. Disclaimer Analog Devices, Inc. reserves the right to change this product without prior notice. Information furnished by Analog Devices is believed to be accurate and reliable. However, no responsibility is assumed by Analog Devices for its use; nor for any infringement of patents or other rights of third parties which may result from its use. No license is granted by impli- cation or otherwise under the patent rights of Analog Devices, Inc. Trademark and Service Mark Notice The Analog Devices icon bar and logo, VisualDSP++, the VisualDSP++ logo, Blackfin, the Blackfin logo, the CROSSCORE logo, EZ-KIT Lite, and EZ-Extender are registered trademarks of Analog Devices, Inc. All other brand and product names are trademarks or service marks of their respective owners. Regulatory Compliance The ADSP-BF537 EZ-KIT Lite is designed to be used solely in a labora- tory environment. The board is not intended for use as a consumer end product or as a portion of a consumer end product. The board is an open system design which does not include a shielded enclosure and therefore may cause interference to other electrical devices in close proximity.
    [Show full text]