Safe and Efficient Execution of LLVM-Based Languages

Total Page:16

File Type:pdf, Size:1020Kb

Safe and Efficient Execution of LLVM-Based Languages Submitted by Dipl.-Ing. Manuel Rigger, M.Phil. Submitted at Institute for System Software Supervisor and First Examiner o.Univ.-Prof. Dipl.-Ing. Dr. Dr.h.c. Safe and Efficient Hanspeter M¨ossenb¨ock Second Examiner Reader Execution of Dr. Cristian Cadar LLVM-based Languages October 2018 Doctoral Thesis to obtain the academic degree of Doktor der technischen Wissenschaften in the Doctoral Program Technische Wissenschaften JOHANNES KEPLER UNIVERSITY LINZ Altenbergerstraße 69 4040 Linz, Osterreich¨ www.jku.at DVR 0093696 ii Statutory Declaration I hereby declare that the thesis submitted is my own unaided work, that I have not used other than the sources indicated, and that all direct and indirect sources are acknowledged as references. This printed thesis is identical with the electronic version submitted. Linz, October 29, 2018 iii iv STATUTORY DECLARATION Abstract In unsafe languages like C/C++, errors such as buffer overflows cause Un- defined Behavior. Typically, compilers handle undefined behavior in some arbitrary way, for example, they disregard it when optimizing and omit in- serting checks that could detect it. Consequently, undefined behavior often results in hard-to-find bugs and security vulnerabilities, for example, when a buffer overflow corrupts memory. Existing bug-finding tools that instrument code to detect undefined be- havior often suffer from compilers that possibly optimize code so that errors are no longer detected. Alternatively, unsafe code could be rewritten in a safe language like Java, which is well defined and where such errors are de- tected. However, this would incur an infeasible-high cost for many projects. To tackle undefined behavior, we came up with an approach to exe- cute unsafe languages on the Java Virtual Machine. We implemented this approach as Safe Sulong, a system that includes an interpreter for unsafe languages, which is written in Java. By relying on Java’s well-definedness and its automatic run-time checks, the interpreter can detect buffer over- flows and other errors during its execution and can terminate the program in such cases. Safe Sulong tracks metadata such as types and object bounds, which we provide to programmers over an introspection interface, so that they can use this data to mitigate errors and to implement additional checks. The interpreter also supports unstandardized elements in C code such as the most common inline assembly and GCC builtins. To implement them, we first studied their usage in a large number of open-source projects. Sulong is used in GraalVM, a commercially-used multi-lingual virtual machine. Since Sulong allows the implementation of efficient native function interfaces, our safe execution mechanism could also make the execution of native extensions of other languages such as Ruby, Python, and R safer. v vi ABSTRACT Kurzfassung In unsicheren Sprachen wie C/C++ f¨uhrenFehler wie Puffer¨uberl¨aufezu undefiniertem Verhalten, das von Compilern in der Regel auf undefinierte Weise behandelt wird. Sie ignorieren es zum Beispiel bei Optimierungen und f¨uhren keine Uberpr¨ufungen¨ durch, die es erkennen k¨onnten. Das f¨uhrt oft zu schwer lokalisierbaren Fehlern und Sicherheitsl¨ucken, beispielsweise wenn ein Puffer¨uberlauf Daten im Speicher zerst¨ort. Vorhandene Fehlererkennungswerkzeuge, die das Programm zum Erken- nen von undefiniertem Verhalten instrumentieren, benutzen oft Compiler, die den Code so optimieren, dass Fehler nicht mehr erkannt werden. Al- ternativ k¨onnten unsichere Programme in einer sicheren Sprache wie Java neu geschrieben werden, die vollst¨andigdefiniert und sicher ist. Dies w¨urde jedoch f¨urviele Projekte zu untragbar hohen Kosten f¨uhren. Um undefiniertes Verhalten in den Griff zu bekommen, haben wir einen Ansatz entwickelt, bei dem unsichere Sprachen auf der Java Virtual Ma- chine ausgef¨uhrtwerden. Der Ansatz wurde unter dem Namen Safe Su- long implementiert, einem System, das auf einem in Java geschriebenen Interpreter f¨urunsichere Sprachen basiert. Indem der Interpreter auf die Wohldefiniertheit und die automatischen Laufzeitpr¨ufungen von Java ver- traut, kann er Puffer¨uberl¨aufeund andere Fehler zur Laufzeit erkennen und das Programm in solchen F¨allenabbrechen. Safe Sulong merkt sich Meta- daten wie Typen und Objektgrenzen, die Programmierern ¨uber eine Intro- spektionsschnittstelle zur Verf¨ugunggestellt werden, mit denen sie Fehler abfangen und zus¨atzliche Pr¨ufungenimplementieren k¨onnen. Der Inter- preter unterst¨utztauch unstandardisierte Elemente in C-Code wie g¨angige Inline-Assembly-Codest¨ucke und GCC-Builtins. Zu diesem Zweck haben wir zun¨achst die Verwendung solcher Elemente in einer großen Anzahl von Open-Source-Projekten untersucht. vii viii KURZFASSUNG Sulong wird in der GraalVM verwendet, einer kommerziellen, mehrsprachi- gen virtuellen Maschine. Sulong erlaubt die Definition von Schnittstellen zu nativem Code, wodurch unsere Sicherheitsmechanismen auch verwendet werden k¨onnten um die Ausf¨uhrungnativer Erweiterungen anderer Sprachen wie Ruby, Python und R sicherer zu machen. Acknowledgments This thesis would not have been possible without the help of many people. First and foremost, I want to thank my advisor Hanspeter M¨ossenb¨ock, for being an excellent mentor, for his constant feedback and support, for allowing me to freely follow my research interests, and for maintaining a successful and mutually-beneficial collaboration with Oracle Labs. I am thankful to Cristian Cadar for the time and effort he put into evaluating this work and providing feedback. I also want to thank the other members of the dissertation jury for their time, namely Armin Biere and Paul Gr¨unbacher. I sincerely thank Stefan Marr for teaching me much about academia and for his mentoring, which helped me to develop myself during the second half of my PhD. I want to thank Matthias Grimmer who mentored me and taught me the essential academic skills during thefirst year of my PhD. I am thankful to Ren´eMayrhofer for his feedback from the viewpoint of a security researcher. I am grateful to Stephen Kell for his insightful feedback on my work, and Bram Adams for his help with improving the study on the use of GCC builtins. I want to thank Ingrid Abfalter for correcting my papers and improving my writing. I would like to express my gratitude to Thomas W¨urthinger for funding my research, and his trust for letting me develop an important puzzle piece of the Graal project. I am thankful to all of the Oracle Labs employees who worked together with me, shared their knowledge, helped me debug issues, gave feedback on my work, and developed the Sulong research prototype into a product. I especially want to thank Roland Schatz, Matthias Grimmer, Lukas Stadler, Chris Seaton, and Christian Wimmer. I want to thank my fellow PhD students, Josef Eisl, David Leopoldseder, and Benoit Daloze for their feedback and help. I want to thank the students that worked on Sulong-related topics, all of which were excellent: Jacob ix x ACKNOWLEDGMENTS Kreindl, Daniel Pekarek, Thomas Pointhuber, and Raphael Mosaner. I am grateful for my family and friends. I want to thank Jin Ting for her love, and for her patience even when I worked on evenings and weekends. I want to thank my parents, sister, and grandparents for all their support. Contents Statutory Declaration iii Abstract v Kurzfassung vii Acknowledgments ix Contents x I Introduction and Overview 1 1 Introduction 3 1.1 Problem . ............. 3 1.2 State of the Art . .......... 4 1.3 Remaining Challenges . 8 1.4 Suggested Approach . 9 1.5 Contributions . 10 1.6 Limitations . 14 1.7 Project Context . 15 1.8 Research Context . 18 1.9 Outline . 20 2 Overview 21 2.1 Sulong . 21 2.2 Introspection . 29 2.3 Empirical Studies . 30 xi xii CONTENTS 3 Publications 35 3.1 Journal Papers . 35 3.2 Conference Papers . 35 3.3 Full Workshop Papers . 37 3.4 Other Publications . 37 3.5 Under Review . 38 Bibliography 38 II Publications 61 4 Native Sulong 63 5 Safe Sulong 75 6 Lenient C 91 7 Introspection 105 8 Context-aware Failure-oblivious Computing 137 9 A Study on the Use of Inline Assembly 153 10 A Study on the Use of GCC Builtins 171 III Future Work and Conclusion 185 11 Future Work 187 11.1 Safe Sulong . 187 11.2 Introspection . 191 11.3 Empirical Studies . 192 12 Conclusion 195 Part I Introduction and Overview 1 Chapter 1 Introduction 1.1 Problem In unsafe languages like C, the semantics of operations are only specified for valid input. For example, while dereferencing a valid pointer is well specified, the effect of dereferencing an out-of-bounds pointer, which is known as a buffer overflow, is not specified by the C standard.1 Such an error is said to cause Undefined Behavior. Compilers are not required to produce code that detects undefined behavior while the program executes, so they do not, for example, insert bounds checks to detect buffer overflows. In fact, state-of- the-art compilers such as Clang or GCC even optimize the program based on the assumption that undefined behavior never occurs [139]. Executing programs with undefined behavior that have been compiled by Clang or GCC can yield various unintended or even disastrous results. For example, out-of-bounds reads can result in sensitive data of adjacent objects being read, even when those objects were not explicitly referenced [125]. Ex- amples for disastrous out-of-bounds reads were Heartbleed in the OpenSSL SSL library [35] and Cloudbleed in the online service Cloudfare [46], which both allowed attackers to leak sensitive information on web servers, and af- fected millions of users. Attackers might not only exploit buffer overflows to read private data; out-of-bounds writes can be exploited to overwrite control- flow data, allowing attackers to divert the controlflow of the program and even to take control over the process [114, 18, 9, 132]. Furthermore, a pro- 1If not further specified, we refer to the ISO/IEC 9899:2018 standard, which is infor- mally known as C17 or C18.
Recommended publications
  • Effective Virtual CPU Configuration with QEMU and Libvirt
    Effective Virtual CPU Configuration with QEMU and libvirt Kashyap Chamarthy <[email protected]> Open Source Summit Edinburgh, 2018 1 / 38 Timeline of recent CPU flaws, 2018 (a) Jan 03 • Spectre v1: Bounds Check Bypass Jan 03 • Spectre v2: Branch Target Injection Jan 03 • Meltdown: Rogue Data Cache Load May 21 • Spectre-NG: Speculative Store Bypass Jun 21 • TLBleed: Side-channel attack over shared TLBs 2 / 38 Timeline of recent CPU flaws, 2018 (b) Jun 29 • NetSpectre: Side-channel attack over local network Jul 10 • Spectre-NG: Bounds Check Bypass Store Aug 14 • L1TF: "L1 Terminal Fault" ... • ? 3 / 38 Related talks in the ‘References’ section Out of scope: Internals of various side-channel attacks How to exploit Meltdown & Spectre variants Details of performance implications What this talk is not about 4 / 38 Related talks in the ‘References’ section What this talk is not about Out of scope: Internals of various side-channel attacks How to exploit Meltdown & Spectre variants Details of performance implications 4 / 38 What this talk is not about Out of scope: Internals of various side-channel attacks How to exploit Meltdown & Spectre variants Details of performance implications Related talks in the ‘References’ section 4 / 38 OpenStack, et al. libguestfs Virt Driver (guestfish) libvirtd QMP QMP QEMU QEMU VM1 VM2 Custom Disk1 Disk2 Appliance ioctl() KVM-based virtualization components Linux with KVM 5 / 38 OpenStack, et al. libguestfs Virt Driver (guestfish) libvirtd QMP QMP Custom Appliance KVM-based virtualization components QEMU QEMU VM1 VM2 Disk1 Disk2 ioctl() Linux with KVM 5 / 38 OpenStack, et al. libguestfs Virt Driver (guestfish) Custom Appliance KVM-based virtualization components libvirtd QMP QMP QEMU QEMU VM1 VM2 Disk1 Disk2 ioctl() Linux with KVM 5 / 38 libguestfs (guestfish) Custom Appliance KVM-based virtualization components OpenStack, et al.
    [Show full text]
  • Meeting Agenda 4:30 – 6:00 PM, Wednesday, Nov 2Nd, 2016 Lyons Town Hall
    Meeting Agenda 4:30 – 6:00 PM, Wednesday, Nov 2nd, 2016 Lyons Town Hall I. Roll Call, Agenda, Minutes • Amendments to Agenda • Approve Minutes from Oct 19th • UEB Officers and Member Lead Areas • Upcoming Meetings - Nov 12, 2016 9 AM or 1 PM - Lyons Boards and Commissions Training - Lyons ​ ​ ​ Nov 9. 8 AM - Northern Water Fall Water Users Meeting - Longmont, Best Western 1850 Industrial Cir. Dec 2nd - CAMU Fall Meeting - Fairfield & Woods in Denver, CO II. Audience Business III. Liaison Updates • Board of Trustees Update - MEAN meeting Report • Staff, Engineering Update - Honeywell Savings Gaurantee IV. Continued Business ● Town Utility Account tracking V. New Business ● Water/Wastewater Rate and CIP Study Presentation RG & Assoc. VI. Parking Lot • 2017 Utility FUnd Budget, Pipe Water rates for 2017 Budget, • Reserve/Rate Stabilization Funds • Wastewater Pretreatment Policy • LRAP INF 2.2.1 • Municipal Code Corrections UEB Meeting Minutes, 19 Oct 2016 Meeting Time and Location: Began at 4:30 at Town Hall. ​ Attendance:, Aaron Caplan, Lee Hall, Coco Gordon, John Cowdry, Chuck Keim, Dan Reitz, Jay Stott ​ Staff: Kyle Miller Liaisons: Guests: ​ ​ Amendments to Agenda: Welcomed Jay Stott as the newest member of the UEB. ​ Previous Minutes: . Reviewed and modified Oct 5th Minutes under Water Wastewater CIP to add “Areas ​ where there is no looping of the water mains need looping. It was emphasized to try and coordinate getting water, and wastewater done first in areas that need paving.” Aaron had not followed up with Parks and ​ Rec to find out if they were budgeting for water usage. He would do so. Then approved minutes.
    [Show full text]
  • Undocumented CPU Behavior: Analyzing Undocumented Opcodes on Intel X86-64 Catherine Easdon Why Investigate Undocumented Behavior? the “Golden Screwdriver” Approach
    Undocumented CPU Behavior: Analyzing Undocumented Opcodes on Intel x86-64 Catherine Easdon Why investigate undocumented behavior? The “golden screwdriver” approach ● Intel have confirmed they add undocumented features to general-release chips for key customers "As far as the etching goes, we have done different things for different customers, and we have put different things into the silicon, such as adding instructions or pins or signals for logic for them. The difference is that it goes into all of the silicon for that product. And so the way that you do it is somebody gives you a feature, and they say, 'Hey, can you get this into the product?' You can't do something that takes up a huge amount of die, but you can do an instruction, you can do a signal, you can do a number of things that are logic-related." ~ Jason Waxman, Intel Cloud Infrastructure Group (Source: http://www.theregister.co.uk/2013/05/20/intel_chip_customization/ ) Poor documentation ● Intel has a long history of withholding information from their manuals (Source: http://datasheets.chipdb.org/Intel/x86/Pentium/24143004.PDF) Poor documentation ● Intel has a long history of withholding information from their manuals (Source: https://stackoverflow.com/questions/14413839/what-are-the-exhaustion-characteristics-of-rdrand-on-ivy-bridge) Poor documentation ● Even when the manuals don’t withhold information, they are often misleading or inconsistent Section 22.15, Intel Developer Manual Vol. 3: Section 6.15 (#UD exception): Poor documentation leads to vulnerabilities ● In operating systems ○ POP SS/MOV SS (May 2018) ■ Developer confusion over #DB handling ■ Load + execute unsigned kernel code on Windows ■ Also affected: Linux, MacOS, FreeBSD..
    [Show full text]
  • Intel® 64 and IA-32 Architectures Software Developer's Manual, Volume 3C: System Programming Guide, Part 3
    Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3C: System Programming Guide, Part 3 NOTE: The Intel® 64 and IA-32 Architectures Software Developer's Manual consists of seven volumes: Basic Architecture, Order Number 253665; Instruction Set Reference A-M, Order Number 253666; Instruction Set Reference N-Z, Order Number 253667; Instruction Set Reference, Order Number 326018; System Programming Guide, Part 1, Order Number 253668; System Programming Guide, Part 2, Order Number 253669; System Programming Guide, Part 3, Order Number 326019. Refer to all seven volumes when evaluating your design needs. Order Number: 326019-049US February 2014 INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDI- TIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRAN- TY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. A "Mission Critical Application" is any application in which failure of the Intel Product could result, directly or indirectly, in personal injury or death. SHOULD YOU PURCHASE OR USE INTEL'S PRODUCTS FOR ANY SUCH MISSION CRITICAL APPLICATION, YOU SHALL INDEMNIFY AND HOLD INTEL AND ITS SUBSIDIARIES, SUBCONTRACTORS AND AFFILIATES, AND THE DIRECTORS, OFFICERS, AND EMPLOYEES OF EACH, HARMLESS AGAINST ALL CLAIMS COSTS, DAMAGES, AND EXPENSES AND REASONABLE ATTORNEYS' FEES ARISING OUT OF, DIRECTLY OR INDIRECTLY, ANY CLAIM OF PRODUCT LIABILITY, PERSONAL INJURY, OR DEATH ARISING IN ANY WAY OUT OF SUCH MISSION CRITICAL APPLICATION, WHETHER OR NOT INTEL OR ITS SUBCONTRACTOR WAS NEGLIGENT IN THE DESIGN, MANUFACTURE, OR WARNING OF THE INTEL PRODUCT OR ANY OF ITS PARTS.
    [Show full text]
  • Embedded Linux Systems with the Yocto Project™
    OPEN SOURCE SOFTWARE DEVELOPMENT SERIES Embedded Linux Systems with the Yocto Project" FREE SAMPLE CHAPTER SHARE WITH OTHERS �f, � � � � Embedded Linux Systems with the Yocto ProjectTM This page intentionally left blank Embedded Linux Systems with the Yocto ProjectTM Rudolf J. Streif Boston • Columbus • Indianapolis • New York • San Francisco • Amsterdam • Cape Town Dubai • London • Madrid • Milan • Munich • Paris • Montreal • Toronto • Delhi • Mexico City São Paulo • Sidney • Hong Kong • Seoul • Singapore • Taipei • Tokyo Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. For information about buying this title in bulk quantities, or for special sales opportunities (which may include electronic versions; custom cover designs; and content particular to your business, training goals, marketing focus, or branding interests), please contact our corporate sales depart- ment at [email protected] or (800) 382-3419. For government sales inquiries, please contact [email protected]. For questions about sales outside the U.S., please contact [email protected]. Visit us on the Web: informit.com Cataloging-in-Publication Data is on file with the Library of Congress.
    [Show full text]
  • Cp 99, Other Filing/Pleading, 11/12/2014
    BINGHAM Catherine Wang Brett P. Ferenchak catherine. wang@ bingham. com [email protected] November 11, 2014 Via Overnight Courier and E-Mail Oregon Public Utility Commission Attn: Filing Center 550 Capitol Street, N.E. Suite 215 Salem, OR 97301-2551 [email protected] Re: Business Telecom, LLC d/b/a EarthLink Business I Notification of Conversion and Associated Name Change Dear Sir or Madam: Business Telecom, LLC d/b/a EarthLink Business I (formerly known as Business Telecom, Inc. d/b/a EarthLink Business III) (the "Company") hereby notifies the Commission (1) that the Company converted from a North Carolina corporation to a North Carolina limited liability company' and (2) of the associated name change to "Business Telecom, LLC d/b/a EarthLink Business 1." The Company requests that the Commission update its records, including the Company's Certificate,2 to reflect the conversion and associate name change and, to the extent necessary, approve these changes. Attached hereto are the Company's conversion documents and updated authorization to transact business in Oregon and trade name registration. Beijing Boston Frankfurt Hartford Hong Kong London los Angeles New York Orange County San Francisco Santa Monica Silicon Valley Tokyo Washington The conversion of the Company to a limited liability company was merely a change in its corporate form -the conversion was accomplished through the filing of Articles of Bingham McCutchen LLP Conversion in North Carolina and did not entail any merger or other transactions interrupting 2020 K Street NW Washington, DC the existence of the Company. 20006-1806 2 The Company is authorized to provide interexchange telecommunications services pursuant to Order No.
    [Show full text]
  • Smashing the Stack Protector for Fun and Profit
    Smashing the Stack Protector for Fun and Profit Bruno Bierbaumer1 ( ), Julian Kirsch1, Thomas Kittel1, Aurélien Francillon2, and Apostolis Zarras3 1 Technical University of Munich, Munich, Germany [email protected] 2 EURECOM, Sophia Antipolis, France 3 Maastricht University, Maastricht, Netherlands Abstract. Software exploitation has been proven to be a lucrative busi- ness for cybercriminals. Unfortunately, protecting software against attacks is a long-lasting endeavor that is still under active research. However, certain software-hardening schemes are already incorporated into current compilers and are actively used to make software exploitation a compli- cated procedure for the adversaries. Stack canaries are such a protection mechanism. Stack canaries aim to prevent control flow hijack by detecting corruption of a specific value on the program’s stack. Careful design and implementation of this conceptually straightforward mechanism is crucial to defeat stack-based control flow detours. In this paper, we examine 17 different stack canary implementations across multiple versions of the most popular Operating Systems running on various architectures. We systematically compare critical implementation details and introduce one new generic attack vector which allows bypassing stack canaries on current Linux systems running up-to-date multi-threaded software altogether. We release an open-source framework (CookieCrumbler) that identifies the characteristics of stack canaries on any platform it is compiled on and we propose mitigation techniques against stack-based attacks. Although stack canaries may appear obsolete, we show that when they are used correctly, they can prevent intrusions which even the more sophisticated solutions may potentially fail to block. 1 Introduction Buffer overflow vulnerabilities are as old as the Internet itself.
    [Show full text]
  • FRVT General Evaluation Specifications
    Face Recognition Vendor Test Ongoing General Evaluation Specifications VERSION 1.1 Patrick Grother Mei Ngan Kayee Hanaoka Information Access Division Information Technology Laboratory Contact via [email protected] September 9, 2020 1 FRVT Ongoing 2 Revision History 3 4 Date Version Description April 1, 2019 1.0 Initial document September 9, 2020 1.1 Update operating system to CentOS 8.2 and compiler to g++ 8.3.1 Adjust the legal similarity score range to [0, 1000000] 5 NIST General Evaluation Specifications Page 1 of 9 FRVT Ongoing 6 Table of Contents 7 1. Audience ............................................................................................................................................................................ 3 8 2. Rules for Participation........................................................................................................................................................ 3 9 2.1. Participation Agreement .......................................................................................................................................... 3 10 2.2. Validation ................................................................................................................................................................. 3 11 2.3. Number and Schedule of Submissions ..................................................................................................................... 3 12 3. Reporting...........................................................................................................................................................................
    [Show full text]
  • User's Manual
    rBOX610 Linux Software User’s Manual Disclaimers This manual has been carefully checked and believed to contain accurate information. Axiomtek Co., Ltd. assumes no responsibility for any infringements of patents or any third party’s rights, and any liability arising from such use. Axiomtek does not warrant or assume any legal liability or responsibility for the accuracy, completeness or usefulness of any information in this document. Axiomtek does not make any commitment to update the information in this manual. Axiomtek reserves the right to change or revise this document and/or product at any time without notice. No part of this document may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of Axiomtek Co., Ltd. Trademarks Acknowledgments Axiomtek is a trademark of Axiomtek Co., Ltd. ® Windows is a trademark of Microsoft Corporation. Other brand names and trademarks are the properties and registered brands of their respective owners. Copyright 2014 Axiomtek Co., Ltd. All Rights Reserved February 2014, Version A2 Printed in Taiwan ii Table of Contents Disclaimers ..................................................................................................... ii Chapter 1 Introduction ............................................. 1 1.1 Specifications ...................................................................................... 2 Chapter 2 Getting Started ......................................
    [Show full text]
  • LTIB Quick Start: Targeting the Coldfire Mcf54418tower Board By: Soledad Godinez and Jaime Hueso Guadalajara Mexico
    Freescale Semiconductor Document Number: AN4426 Application Note Rev. 0, December 2011 LTIB Quick Start: Targeting the ColdFire MCF54418Tower Board by: Soledad Godinez and Jaime Hueso Guadalajara Mexico Contents 1 Introduction 1 Introduction................................................................1 The purpose of this document is to indicate step-by-step how 2 LTIB..........................................................................1 to accomplish these tasks: • Install the BSP on a host development system. 2.1 Introduction....................................................1 • Run Linux Target Image Builder (LTIB) to build target 2.2 Installing the BSP...........................................2 images. • Boot Linux on the ColdFire MCF54418 Tower board. 2.3 Running LTIB................................................7 3 Target deployment .................................................13 This document is a guide for people who want to properly set up the Freescale Linux Target Image Builder (LTIB) for the 3.1 The Tower kit ..............................................13 ColdFire MCF54418 Tower Board Support Package (BSP). 3.2 Constructing the Tower kit...........................15 3.3 Programming U-boot, kernel, and root file system.............................................16 2 LTIB 3.4 Configuring U-boot......................................24 3.5 Running.......................................................25 4 Conclusions.............................................................26 2.1 Introduction Freescale GNU/Linux
    [Show full text]
  • CS 0449: Introduction to Systems Software
    CS 0449: Introduction to Systems Software Jonathan Misurda Computer Science Department University of Pittsburgh [email protected] http://www.cs.pitt.edu/∼jmisurda Version 3, revision 1 Last modified: July 27, 2017 at 1:33 P.M. Copyright © 2017 by Jonathan Misurda This text is meant to accompany the course CS 0449 at the University of Pittsburgh. Any other use, commercial or otherwise, is prohibited without permission of the author. All rights reserved. Java is a registered trademark of Oracle Corporation. This reference is dedicated to the students of CS 0449, Fall 2007 (2081). Their patience in dealing with a changing course and feedback on the first version of this text was greatly appreciated. Contents Contents i List of Figures v List of Code Listings vii Preface ix 1 Pointers 1 1.1 Basic Pointers . 2 1.1.1 Fundamental Operations . 2 1.2 Passing Pointers to Functions . 4 1.3 Pointers, Arrays, and Strings . 5 1.3.1 Pointer Arithmetic . 6 1.4 Terms and Definitions . 7 2 Variables: Scope & Lifetime 8 2.1 Scope and Lifetime in C . 9 2.1.1 Global Variables . 11 2.1.2 Automatic Variables . 12 2.1.3 Register variables . 13 2.1.4 Static Variables . 13 2.1.5 Volatile Variables . 16 2.2 Summary Table . 17 2.3 Terms and Definitions . 17 ii Contents 3 Compiling & Linking: From Code to Executable 19 3.1 The Stages of Compilation . 19 3.1.1 The Preprocessor . 20 3.1.2 The Compiler . 21 3.1.3 The Linker . 22 3.2 Executable File Formats .
    [Show full text]
  • A Type-Checking Preprocessor for Cilk 2, a Multithreaded C Language
    A Typechecking Prepro cessor for Cilk a Multithreaded C Language by Rob ert C Miller Submitted to the Department of Electrical Engineering and Computer Science in partial fulllment of the requirements for the degrees of Bachelor of Science in Computer Science and Engineering and Master of Engineering in Electrical Engineering and Computer Science at the Massachusetts Institute of Technology May Copyright Massachusetts Institute of Technology All rights reserved Author ::::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::: Department of Electrical Engineering and Computer Science May Certied by ::::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::::::::::::: Charles E Leiserson Thesis Sup ervisor Accepted by ::::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::::::::::::: F R Morgenthaler Chairman Department Committee on Graduate Theses A Typechecking Prepro cessor for Cilk a Multithreaded C Language by Rob ert C Miller Submitted to the Department of Electrical Engineering and Computer Science on May in partial fulllment of the requirements for the degrees of Bachelor of Science in Computer Science and Engineering and Master of Engineering in Electrical Engineering and Computer Science Abstract This thesis describ es the typechecking optimizing translator that translates Cilk a C ex tension language for multithreaded parallel programming into C The CilktoC translator is based on CtoC a to ol I developed that parses type checks analyzes and regenerates a C program With a translator based on CtoC
    [Show full text]