DOCSLIB.ORG

Formal Verification of a Modern Boot Loader

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Formal Verification of a Modern Boot Loader View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Syracuse University Research Facility and Collaborative Environment Syracuse University SURFACE Electrical Engineering and Computer Science - Technical Reports College of Engineering and Computer Science 8-2018 Formal Verification of a Modern Boot Loader Scott D. Constable Syracuse University, [email protected] Rob Sutton RJMetrics Arash Sahebolamri Syracuse University, [email protected] Steve Chapin Syracuse University, [email protected] Follow this and additional works at: https://surface.syr.edu/eecs_techreports Part of the Information Security Commons, and the Software Engineering Commons Recommended Citation Constable, Scott D.; Sutton, Rob; Sahebolamri, Arash; and Chapin, Steve, "Formal Verification of a Modern Boot Loader" (2018). Electrical Engineering and Computer Science - Technical Reports. 183. https://surface.syr.edu/eecs_techreports/183 This Report is brought to you for free and open access by the College of Engineering and Computer Science at SURFACE. It has been accepted for inclusion in Electrical Engineering and Computer Science - Technical Reports by an authorized administrator of SURFACE. For more information, please contact [email protected]. Syracuse University SURFACE Electrical Engineering and Computer Science College of Engineering and Computer Science Technical Reports 8-2018 Formal Verification of a Modern Boot Loader Scott .D Constable Rob Sutton Arash Sahebolamri Steve Chapin Follow this and additional works at: https://surface.syr.edu/eecs_techreports Part of the Information Security Commons, and the Software Engineering Commons Formal Verification of a Modern Boot loader ∗ Scott Constable Rob Sutton Arash Sahebolamri Steve Chapin Department of Electrical Engineering and Computer Science Syracuse University Syracuse, New York, 13244-1200 Abstract loader code, operating system, and web server soft- ware. Such TCBs could easily comprise millions of We introduce the Syracuse Assured Boot Loader Ex- lines of code. ecutive (SABLE), a trustworthy secure loader. A The surface area of the problem may be reduced trusted boot loader performs a cryptographic mea- in two ways. The first and most obvious solution is surement (hash) of program code and executes it un- to shrink the TCB, either by reducing the amount of conditionally, allowing later-stage software to verify code required to perform the desired tasks, or reduc- the integrity of the system through local or remote ing the amount of code which needs to be trusted. attestation. A secure loader differs from a trusted The latter can be accomplished by utilizing hard- loader in that it executes subsequent code only if ware protections such as AMD SVM [5] and Intel measurements of that code match known-good val- TXT [20], which effectively remove pre-operating sys- ues. We have applied a rigorous formal verifica- tem software and firmware from the TCB. ARM tion technique recently demonstrated in practice by TrustZone [3] partitions system code into \normal NICTA in their verification of the seL4 microkernel. world" and \secure world" code, ideally to exclude We summarize our design philosophy from a high the normal world code from the TCB. More recently, level and present our formal verification strategy. Intel SGX technology [2] introduced a hardware- protected execution environment to shield arbitrary 1 Introduction code (e.g. system or application code) from the rest of the system. The United States Department of Defense Orange The second solution is to increase the trustworthi- Book defines the Trusted Computing Base (TCB) ness of code which must be a member of the TCB. of a computer system as the part of the computer For instance, a program written in a memory-safe system \which contains all of the elements of the language may be more trustworthy than a similar system responsible for supporting the security pol- program written in C. Stronger guarantees about the icy and supporting the isolation of objects (code and trustworthiness of a program or system can be made data) on which the protection is based" [15]. Hence, using formal methods. Substantial progress on pro- on a typical x86 server the TCB or \trust bound- ducing partially or fully verified operating systems, ary" would encompass the hardware, firmware, boot microkernels, and hypervisors has been made in the past decade [17, 23, 27]. ∗This research was supported in part by a subcontract from Critical Technologies Inc., under United States Air SABLE is a trustworthy secure loader which ap- Force Research Laboratory (USAFRL) Information Direc- plies both of these solutions to shrink the platform torate prime contract #FA8750 13 C 0152, based upon US TCB and improve the trustworthiness of platform Department of Defense (DoD) Small Business Innovation Re- search (SBIR) topic #AF121-051, \Remote Attestation and software. A trusted boot loader performs a crypto- Distributed Trust in Networks (RADTiN)" graphic measurement of program code and then ex- 1 ecutes it unconditionally. Later-stage software may be done to fully formally verify SABLE, respectively. opt to verify the integrity of the system through lo- Section 7 discusses our reflection on the design and cal or remote attestation. A secure loader differs from verification process. a trusted loader in that it executes subsequent code only if measurements of that code match known-good values. 2 Background Hence a secure loader must, by definition, prevent the execution of untrusted code [30]. SABLE is able 2.1 Trusted Computing to make this guarantee by utilizing the Trusted Plat- According to the Trusted Computing Group (TCG), form Module (TPM) [36] chip together with AMD SVM on AMD platforms and Intel TXT on Intel Trust is the expectation that a device will platforms. Via cryptographic hashing, the TPM can behave in a particular manner for a specific \measure" code prior to its execution. Addition- purpose. A trusted platform should provide ally the TPM may \seal" data to a particular sys- at least three basic features: protected capa- tem state, characterized by hash chain digests aggre- bilities, integrity measurement and integrity gated in secure storage [30]. By joining these two reporting. [37] paradigms, SABLE satisfies the definition of a secure loader. SABLE serves as the software foundation for integrity Moreover we employ formal verification techniques measurement and utilizes the protected capabilities demonstrated in practice during the seL4 verifica- of the trusted platform. The following subsections tion effort [24]. In particular, we have implemented introduce these concepts. Integrity reporting may SABLE in a manner which allows it to be trans- be performed by the operating system or application lated into a monadic language that can be parsed software which is outside the scope of this paper. De- by a proof assistant. In this proof assistant, we con- tails about integrity reporting with the TPM can be struct an abstract specification of SABLE's imple- found elsewhere [11, 31, 37, 44]. mentation, and prove that the implementation ex- hibits a subset of the behavior allowed by the ab- 2.1.1 Integrity Measurement stract specification. This rigorous verification effort The TCG uses the term measurement to describe thus increases the trustworthiness of SABLE when a cryptographic hash operation [37]. Measurements compared against other trusted software which has can, among other purposes, be used to verify the in- only been penetration tested. tegrity of code/data or to attest to the integrity of a We have implemented SABLE to run on both the particular system configuration. TPM chips contain AMD SVM and Intel TXT architectures. From the several Platform Configuration Registers (PCRs) user's perspective, the behavior of SABLE on either which store measurements in a digest. Measure- architecture is identical. Though the implementation ments, however, are not written directly into a PCR. details do differ somewhat, for brevity we focus our Rather, they are extended into a PCR in the following discussion in this paper on SABLE's implementation manner: for AMD SVM. The rest of this paper is organized as follows. Sec- PCRi;n+1 H(PCRi;n jj H(data)) tion 2 introduces the relevant background in trusted computing and formal verification. Section 3 out- where H is a cryptographic hash function, jj is the lines the design of SABLE and its bilateral attesta- concatenation operator, and PCRi;n is the value tion protocol. Section 4 describes the implementa- of the ith PCR after n extend operations on that tion of SABLE. Section 5 details the formal methods PCR [37]. Thus in each extend operation the cur- used to verify SABLE's implementation. Sections 6 rent value in the PCR is replaced by the hash of the and 8 discuss related work and the work remaining to old value of the PCR concatenated with the hash of 2 is sufficiently trustworthy (i.e. known non-malicious). Then the client would use the SML to compute the hash digest(s) in the same manner and sequence as the server software and the TPM, and compare the result(s) against the server's quoted PCR value(s). Assuming that the PCR values can be transmitted to the client with verifiable integrity1, these PCR val- ues accurately characterize of the state of the server. Thus the remote client is able to determine whether or not the SML is an honest log of the server's run- ning software and firmware. A Linux platform which uses this logging and reporting scheme was described in [33]. Figure 1: Trusted boot execution [37] In the TCG terminology, the boot protocol given in Figure 1 uses a static RTM (SRTM) [37]. A SRTM begins performing measurements as early in the boot the new data. Because the PCRs are shielded by the process as possible. For instance, on PC clients the TPM and a narrow command interface, they form a BIOS and firmware serve as the SRTM. The BIOS root of trust for measurement (RTM) for the system.
Load more

Recommended publications
  • 2020 Spring Product Guide Final-Min
    2020 SPRING INTEGRATOR PRODUCT GUIDE COME SWIM WITH THE BIG FISH November 9 – 11, 2020 | Cleveland, OH | Huntington Convention Center Take control of your business success. Gain insights from the integration industry elite this November at Total Tech Summit. This uniquely powerful by invitation-only event drives extraordinary progress in the integration industry. Total Tech Summit is where the industry elite gather. Total Tech Summit helps to grow and improve your company through: › Educational, deep-dive sessions from the industry elite › 1-on-1 and boardroom meetings with new vendors that can take your offerings from better to best › Networking at every turn. Connect with both integrators in your industry and beyond to help give you fresh ideas and business strategies › Complimentary flights, hotel, “Gathering of professionals that registration, and meals to help you are non-competition to collaborate focus on what matters most on ideas to grow business in profits, procurement, strategies, staffing and general business practices is a wealth of knowledge at the cost of a couple days’ time and to also have the added benefit of meeting one on one with manufacturers that you may not have reached out to.” — John Rudolph, Vice President, PCD To learn more and to apply to join the best in the industry, please visit www.totaltechsummit.com Table of Contents Page 6 Audio ▶ Page 23 Control/Networking/Energy Management ▶ Page 36 Home Enhancements (central vacuum, wire and cable, tools, testers, furniture) ▶ Page 48 Security ▶ Page 53 Video ▶ Page
    [Show full text]
  • Greg Kroah-Hartman [email protected] Github.Com/Gregkh/Presentation-Kdbus
    kdbus IPC for the modern world Greg Kroah-Hartman [email protected] github.com/gregkh/presentation-kdbus Interprocess Communication ● signal ● synchronization ● communication standard signals realtime The Linux Programming Interface, Michael Kerrisk, page 878 POSIX semaphore futex synchronization named eventfd unnamed semaphore System V semaphore “record” lock file lock file lock mutex threads condition variables barrier read/write lock The Linux Programming Interface, Michael Kerrisk, page 878 data transfer pipe communication FIFO stream socket pseudoterminal POSIX message queue message System V message queue memory mapping System V shared memory POSIX shared memory shared memory memory mapping Anonymous mapping mapped file The Linux Programming Interface, Michael Kerrisk, page 878 Android ● ashmem ● pmem ● binder ashmem ● POSIX shared memory for the lazy ● Uses virtual memory ● Can discard segments under pressure ● Unknown future pmem ● shares memory between kernel and user ● uses physically contigous memory ● GPUs ● Unknown future binder ● IPC bus for Android system ● Like D-Bus, but “different” ● Came from system without SysV types ● Works on object / message level ● Needs large userspace library ● NEVER use outside an Android system binder ● File descriptor passing ● Used for Intents and application separation ● Good for small messages ● Not for streams of data ● NEVER use outside an Android system QNX message passing ● Tight coupling to microkernel ● Send message and control, to another process ● Used to build complex messages
    [Show full text]
  • Performance Tuning Guide
    Red Hat Enterprise Linux 7 Performance Tuning Guide Optimizing subsystem throughput in Red Hat Enterprise Linux 7 Red Hat Subject Matter ExpertsLaura Bailey Charlie Boyle Red Hat Enterprise Linux 7 Performance Tuning Guide Optimizing subsystem throughput in Red Hat Enterprise Linux 7 Laura Bailey Red Hat Customer Content Services Charlie Boyle Red Hat Customer Content Services Red Hat Subject Matter Experts Edited by Milan Navrátil Red Hat Customer Content Services [email protected] Legal Notice Copyright © 2016 Red Hat, Inc. and others. This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates. XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
    [Show full text]
  • Understanding and Improving Security of the Android Operating System
    Syracuse University SURFACE Dissertations - ALL SURFACE December 2016 Understanding and Improving Security of the Android Operating System Edward Paul Ratazzi Syracuse University Follow this and additional works at: https://surface.syr.edu/etd Part of the Engineering Commons Recommended Citation Ratazzi, Edward Paul, "Understanding and Improving Security of the Android Operating System" (2016). Dissertations - ALL. 592. https://surface.syr.edu/etd/592 This Dissertation is brought to you for free and open access by the SURFACE at SURFACE. It has been accepted for inclusion in Dissertations - ALL by an authorized administrator of SURFACE. For more information, please contact [email protected]. ABSTRACT Successful realization of practical computer security improvements requires an understanding and insight into the system’s security architecture, combined with a consideration of end-users’ needs as well as the system’s design tenets. In the case of Android, a system with an open, modular architecture that emphasizes usability and performance, acquiring this knowledge and insight can be particularly challenging for several reasons. In spite of Android’s open source philosophy, the system is extremely large and complex, documentation and reference materials are scarce, and the code base is rapidly evolving with new features and fixes. To make matters worse, the vast majority of Android devices in use do not run the open source code, but rather proprietary versions that have been heavily customized by vendors for product dierentiation. Proposing security improvements or making customizations without suicient insight into the system typically leads to less-practical, less-eicient, or even vulnerable results. Point solutions to specific problems risk leaving other similar problems in the distributed security architecture unsolved.
    [Show full text]
  • Pagedout 002 Beta2.Pdf
    It seems PO!#1 was received well. OK, that was an understatement - the download count (over 135k at the moment of writing these words) and the positive feedback we've received blew my predictions out of the water! It seems Paged Out! Institute our readers appreciated the old-school zine feel, liked the https://pagedout.institute/ experimental one-page format, and enjoyed the topic choice. Project Lead At the same time I realize we still have a long way to go on multiple fronts. To give you a glimpse of what's on my mind, here Gynvael Coldwind are three most urgent matters. Executive Assistant First of all, the print files proved to be more tricky than Arashi Coldwind expected. Thankfully the first version is being battle-tested at a printing house as we speak, so it shouldn't be long now. Once we have these, we'll claim we've reached beta2. DTP Programmer foxtrot_charlie Secondly, and even more importantly, we have even more delays with optimizing the PDFs towards screen readers (text-to- DTP Advisor speech engines and the like). This requires more work both on the process side and technical side, but we'll get there. And tusiak_charlie once we do, we'll call it the final version. Lead Reviewers And last, I'm thinking of re-working the article review process for Mateusz "j00ru" Jurczyk PO!#3 to distribute the review work more evenly both in terms of time and between reviewers, and to automate certain things we KrzaQ usually check for. So, if you've written an article for PO!#1 or PO! #2, note that there will be changes ("the only constant thing is Reviewers change" and all that).
    [Show full text]
  • Crestron 3-Series Control Systems Reference Guide
    Crestron 3-Series Control Systems Reference Guide A portion of the code in this product is covered by the Microsoft® Public License (Ms-PL), which can be found at www.microsoft.com/opensource/licenses.mspx. This device includes an aggregation of separate independent works that are each generally copyrighted by Crestron Electronics, Inc., with all rights reserved. One of those independent works, Linux Bridge Project, is copyrighted under the GNU GENERAL PUBLIC LICENSE, Version2, reproduced in “GNU General Public License” on page 78, where the corresponding source code is available at: ftp://ftp.crestron.com/gpl. The specific patents that cover Crestron products are listed at patents.crestron.com/. Crestron, the Crestron logo, 3-Series, 3-Series Control System, Core 3, Core 3 OS, Core 3 UI, Cresnet, Crestron Mobile Pro, Crestron Toolbox, e-Control, Fusion RV, VisionTools, and VT Pro-e are either trademarks or registered trademarks of Crestron Electronics, Inc. in the United States and/or other countries. BACnet is either a trademark or registered trademark of American Society of Heating, Refrigerating and Air-Conditioning Engineers, Inc. in the United States and/or other countries. iPad and iPhone are either trademarks or registered trademarks of Apple, Inc. in the United States and/or other countries. Blu-ray Disc is a trademark or registered trademark of the Blu-ray Disc Association (BDA) in the United States and/or other countries. Android is either a trademark or registered trademark of Google, Inc. in the United States and/or other countries. Microsoft and Windows are either trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries.
    [Show full text]
  • Open Source Used in Cisco Findit Network Probe, Version 1.1.0
    Open Source Used In Cisco FindIT Network Probe 1.1.0.x Cisco Systems, Inc. www.cisco.com Cisco has more than 200 offices worldwide. Addresses, phone numbers, and fax numbers are listed on the Cisco website at www.cisco.com/go/offices. Text Part Number: 78EE117C99-157639917 Open Source Used In Cisco FindIT Network Probe 1.1.0.x 1 This document contains licenses and notices for open source software used in this product. With respect to the free/open source software listed in this document, if you have any questions or wish to receive a copy of any source code to which you may be entitled under the applicable free/open source license(s) (such as the GNU Lesser/General Public License), please contact us at [email protected]. In your requests please include the following reference number 78EE117C99-157639917 En ce qui a trait au logiciel gratuit ou à exploitation libre figurant dans ce document, si vous avez des questions ou souhaitez recevoir une copie du code source, auquel vous avez droit en vertu des licences gratuites ou d'exploitation libre applicables (telles que licences GNU Lesser/General Public), veuillez communiquer avec nous à l'adresse external- [email protected]. Dans vos demandes, veuillez inclure le numéro de référence 78EE117C99-157639917 Contents 1.1 Angular Bootstrap 0.12.0 1.1.1 Available under license 1.2 Angular UI Sortable 1.1.1 1.2.1 Available under license 1.3 angular-chart.js 0.7.2 1.3.1 Available under license 1.4 Angular-dashboard-frmework 0.8.0 1.4.1 Available under license 1.5
    [Show full text]
  • The LPIC-2 Exam Prep I
    The LPIC-2 Exam Prep i The LPIC-2 Exam Prep Copyright 2013 Snow B.V. The LPIC-2 Exam Prep ii Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013 Snow B.V. Copyright 2013 Snow B.V. The LPIC-2 Exam Prep iii COLLABORATORS TITLE : The LPIC-2 Exam Prep ACTION NAME DATE SIGNATURE WRITTEN BY Heinrich W. 2010 Klöpping, Beno T.J. Mesman, Piet W. Plomp, Willem A. Schreuder, Ricky Latupeirissa, Patryck Winkelmolen, Many, many Snow B.V. colleagues for peer reviewing and authoring updates., Jos Jansen, and Joost Helberg REVISION HISTORY NUMBER DATE DESCRIPTION NAME Copyright 2013 Snow B.V. The LPIC-2 Exam Prep iv Contents 0 Capacity Planning (200) 1 0.1 Measure and Troubleshoot Resource Usage (200.1) . .1 0.1.1 iostat .....................................................2 0.1.2 vmstat ....................................................2 0.1.3 netstat ....................................................3 0.1.4 ps .......................................................4 0.1.5 pstree .....................................................5 0.1.6 w .......................................................5 0.1.7 lsof ......................................................5 0.1.8 free ......................................................6 0.1.9 top . .6 0.1.10 uptime ....................................................7 0.1.11 sar ......................................................7 0.1.12 Match / correlate system symptoms with likely problems . .8 0.1.13 Estimate throughput and identify bottlenecks in a system including networking . .8 0.2 Predict Future Resource Needs (200.2) . .8 0.2.1 ........................................................9 0.2.2 Predict future growth . .9 0.2.3 Resource Exhaustion . .9 0.3 Questions and answers . 10 1 Linux Kernel (201) 11 1.1 Kernel Components (201.1) . 11 1.1.1 Different types of kernel images .
    [Show full text]
  • Stable and Should Be Used Instead
    SIMP Documentation THE SIMP TEAM Dec 09, 2020 Contents 1 Level of Knowledge 3 1.1 Quick Start................................................4 1.2 Changelogs................................................4 1.3 SIMP Getting Started Guide....................................... 103 1.4 SIMP User Guide............................................ 119 1.5 SIMP HOWTO Guides.......................................... 208 1.6 Frequently Asked Questions....................................... 281 1.7 Contributing to SIMP.......................................... 290 1.8 SIMP Security Concepts......................................... 326 1.9 SIMP Security Control Mapping..................................... 344 1.10 Vulnerability Supplement........................................ 705 1.11 Help................................................... 707 1.12 License.................................................. 708 1.13 Contact.................................................. 709 1.14 Glossary of Terms............................................ 709 Index 725 i ii SIMP Documentation This is the documentation for the 6.5.0-1 release of SIMP, which is compatible with CentOS and Red Hat Enterprise Linux (RHEL). This guide will walk a user through the process of installing and managing a SIMP system. It also provides a mapping of security features to security requirements, which can be used to document a system’s security conformance. Warning: Be EXTREMELY CAREFUL when performing copy/paste operations from this document! Different web browsers and operating
    [Show full text]
  • An Overview of the Verification of the Sel4 Microkernel
    An Overview of the Verification of the seL4 Microkernel Lukas Stevens Seminar | Formal Proof in Mathematics and Computer Science 21st June 2018 Contents 1 What is the seL4 Microkernel? 1 1.1 A Brief History of Microkernels . .1 1.2 seL4: Putting the Security in L4 . .2 1.3 Operating System Verification: An Overview . .2 2 Engineering the seL4 Kernel 3 2.1 Design Process for Verification . .3 2.2 Formal Methods of the Correctness Proof . .5 3 Layers of the Functional Correctness Proof 6 3.1 Abstract Specification . .6 3.2 Executable Specification . .7 3.3 Low-level Implementation in C . .8 3.4 Refinement by Forward Simulation . .9 3.5 The Costs and Benefits of Verification . 11 4 Summary and Outlook 13 1 What is the seL4 Microkernel? 1.1 A Brief History of Microkernels Our interactions with computers are shaped by operating systems (OS) such as Linux, Windows and Android. Therefore, understanding the inner workings of operating systems is not only interesting, but also important. At the core of every OS resides the kernel [Lin]. The kernel is responsible for providing the necessary abstractions that are needed to run the rest of the OS and user facing applications. These abstractions include memory management, i.e. mapping of virtual addresses into physical memory, and scheduling of threads. In order to provide these services, the kernel is the first part of the OS loaded into memory at startup, and it retains complete control over the whole system after that. Owing to its critical nature, the kernel is usually loaded into a protected memory region, which can not be accessed by the rest of the OS or user applications.
    [Show full text]
  • Resource Management Guide
    Red Hat Enterprise Linux 7 Resource Management Guide Managing system resources on Red Hat Enterprise Linux 7 Milan Navrátil Eva Majoršinová Peter Ondrejka Douglas Silas Martin Prpič Rüdiger Landmann Red Hat Enterprise Linux 7 Resource Management Guide Managing system resources on Red Hat Enterprise Linux 7 Milan Navrátil Red Hat Customer Content Services [email protected] Eva Majoršinová Red Hat Customer Content Services Peter Ondrejka Red Hat Customer Content Services Douglas Silas Red Hat Customer Content Services Martin Prpič Red Hat Product Security Rüdiger Landmann Red Hat Customer Content Services Legal Notice Copyright © 2016 Red Hat, Inc. This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates. XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
    [Show full text]
  • Étude Formelle Des Distributions De Logiciel Libre
    Université Paris Diderot — Paris 7 École doctorale de Sciences Mathématiques de Paris Centre THÈSE pour obtenir le grade de DOCTEUR DE L’UNIVERSITÉ PARIS DIDEROT Spécialité : Informatique présentée par Jacob Pieter BOENDER Directeur : Roberto DI COSMO Étude formelle des distributions de logiciel libre A formal study of Free Software Distributions soutenue le 24 mars 2011 devant le jury composé de : M. Roberto DI COSMO directeur M. Jesús M. GONZÁLEZ-BARAHONA examinateur M. Carsten SINZ rapporteur M. Diomidis SPINELLIS examinateur M. Jean-Bernard STEFANI examinateur M. Ralf TREINEN examinateur M. Peter VAN ROY rapporteur 2 Contents C Résumé5 La théorie des paquets.............................6 Algorithmes et outils..............................8 Formalisation..................................9 Validation et analyse..............................9 Conclusions et perspectives.......................... 10 1 Introduction 11 1.1 F/OSS Software Distributions...................... 11 1.2 Contributions............................... 12 1.3 Structure.................................. 14 2 Definitions 17 2.1 Existing package formats......................... 17 2.2 Definitions................................. 28 2.3 Installability................................ 30 2.4 Dependencies............................... 32 3 Strong dependencies and conflicts 37 3.1 Strong dependencies........................... 37 3.2 Dominators................................ 39 3.3 Dominators in strong dependency graphs and control flow graphs 41 3.4 Strong conflicts.............................
    [Show full text]