DOCSLIB.ORG

Enhacing the Development Life Cycle to Produce Secure Software

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

REPORT DOCUMENTATION PAGE Form Approved OMB No. 0704-0188 Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing this collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden to Department of Defense, Washington Headquarters Services, Directorate for Information Operations and Reports (0704-0188), 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to any penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number. PLEASE DO NOT RETURN YOUR FORM TO THE ABOVE ADDRESS. 1. REPORT DATE (DD-MM-YYYY) 2008-10-01 2. REPORT TYPE Technical Report 3. DATES COVERED (From - To) 2008-10-01 - 2008-10-01 4. TITLE AND SUBTITLE 5a. CONTRACT NUMBER ENHANCING THE DEVELOPMENT LIFE CYCLE TO PRODUCE SECURE SOFTWARE 5b. GRANT NUMBER 5c. PROGRAM ELEMENT NUMBER 6. AUTHOR(S) 5d. PROJECT NUMBER Goertzel, Karen Mercedes (editor, principal co-author) Winograd, Theodore (co-author) 5e. TASK NUMBER Numerous Other Reviewers 5f. WORK UNIT NUMBER 7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORG REPORT # DACS Data & Analysis Center for Software, ITT AES, 775 Daedalian Dr., Rome, NY 13441 DAN 358844 US 9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR'S ACRONYM(S) Defense Technical Information Center (DTIC)/AI, 8725 John J. Kingman Rd., STE0944, DTIC Ft.Belvoir, VA 22060 US 11. SPONSOR/MONITOR'S REPORT NUMBER(S) 12. DISTRIBUTION / AVAILABILITY STATEMENT - DISTRIBUTION STATEMENT A. Approved for public release; 13. SUPPLEMENTARY NOTES . 14. ABSTRACT: The most risk-averse system with a security architecture including layers upon layers of defenses-in-depth can still be vulnerable to violations and compromises if the software that implements those layered defenses is not dependable, trustworthy, and survivable. The reality is this: software has long been, and remains, the weakest link in any information system. The adversaries who attack those systems know this. And they have the expertise, tools, and resources to exploit that knowledge. Enhancing the Development Life Cycle to Produce Secure Software answers the questions of why software security is important, why so much software is not secure, and the risks posed to systems that contain non-secure software. Enhancing the Development Life Cycle introduces a set of principles to govern risk-aware software engineering, and provides extensive guidance for software practitioners that can help them adapt and enhance their current software life cycle practices to increase the likelihood that the software they produce will be more dependable, trustworthy, and survivable...in other words, more secure. Benefiting from collaborative contributions and critiques by participants in the Software Assurance Forum, Enhancing the Development Life Cycle provides information intended to prepare its readers to evaluate and choose from among the growing number of secure software development methodologies, practices, and technologies best suited for adoption by their own development organizations to help reshape their life cycle processes and practices.. 15. SUBJECT TERMS 16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF 18. NUMBER OF 19a. NAME OF RESPONSIBLE PERSON ABSTRACT PAGES: 331 Thomas McGibbon UU a. REPORT b. ABSTRACT c. THIS PAGE 19b. TELEPHONE NUMBER (include area code) U U U 315-838-7094 1 Enhancing the Development Life Cycle to Produce Secure Software Version 2.0 - October 2008 FOREWORD Dependence on information technology makes software assurance a key element of business continuity, national security, and homeland security. Software vulnerabilities jeopardize intellectual property, consumer trust, business operations and services, and a broad spectrum of critical applications and infrastructure, including everything from Supervisory Control and Data Acquisition systems to commercial-off-the-shelf applications. The integrity of key assets depends upon the reliability and security of the software that enables and controls those assets. However, informed consumers have growing concerns about the scarcity of practitioners with requisite competencies to build secure software. They have concerns with suppliers’ capabilities to build and deliver secure software with requisite levels of integrity and to exercise a minimum level of responsible practice. Because software development offers opportunities to insert malicious code and to unintentionally design and build software with exploitable weaknesses, security-enhanced processes and practices—and the skilled people to perform them—are required to build software that can be trusted not to increase risk exposure. In an era riddled with asymmetric cyber attacks, claims about system reliability, integrity and safety must also include provisions for built-in security of the enabling software. In their Report to the President entitled Cyber Security: A Crisis of Prioritization (February 2005), the President’s Information Technology Advisory Committee (PITAC) summed up the problem of non-secure software: Network connectivity provides “door-to-door” transportation for attackers, but vulnerabilities in the software residing in computers substantially compound the cyber security problem. As the PITAC noted in a 1999 report, the software development methods that have been the norm fail to provide the high quality, reliable, and secure software that the Information Technology infrastructure requires. Software development is not yet a science or a rigorous discipline, and the development process by and large is not controlled to minimize the vulnerabilities that attackers exploit. Today, as with cancer, vulnerable software can be invaded and modified to cause damage to previously healthy software, and infected software can replicate itself and be carried across networks to cause damage in other systems. Like cancer, these damaging processes may be invisible to the lay person even though experts recognize that their threat is growing. And as in cancer, both preventive actions and research are critical, the former to minimize damage today and the latter to establish a foundation of knowledge and capabilities that will assist the cyber security professionals of tomorrow reduce risk and minimize damage for the long term. Vulnerabilities in software that are introduced by mistake or poor practices are a serious problem today. In the future, the Nation may face an even more challenging problem as adversaries—both foreign and domestic—become increasingly sophisticated in their ability to insert malicious code into critical software. Software Assurance has emerged in response to the dramatic increases in business and mission risks that are now known to be attributable to exploitable software, including: i Enhancing the Development Life Cycle to Produce Secure Software Version 2.0 - October 2008 • Dependence on software components of systems despite their being the weakest link in those systems; • Size and complexity of software that obscures its intent and precludes exhaustive testing; • Outsourcing of software development and reliance on unvetted software supply chains; • Attack sophistication that eases exploitation of software weaknesses and vulnerabilities; • Reuse and interfacing of legacy software with newer applications in increasingly complex, disparate networked environments resulting in unintended consequences and the increase of vulnerable software targets. The growing extent of the resulting risk exposure is not yet well understood. The number of threats specifically targeting software is increasing, as the majority of today’s network- and system-level attacks exploit vulnerabilities in application-level software. These factors combine to the increase of risks to software-enabled capabilities and the vulnerability of software- intensive systems to asymmetric cyber threats. Only by establishing the basis for justifiable confidence in the software that enables their core business operations can the organizations that depend on software-intensive systems trust those systems to continue performing in a dependable, trustworthy manner, even in the face of attack. Enhancing the Development Life Cycle to Produce Secure Software joins a growing body of software assurance information resources and tools provided through the Department of Homeland Security (DHS) BuildSecurityIn Web portal (https://buildsecurityin.us-cert.gov) that are intended to assist software developers, architects, acquirers, and educators in the improvement and verification of the quality, reliability, and security of the software they produce or procure—and in establishing the justification to use that software with confidence. Enhancing the Development Life Cycle to Produce Secure Software1 is intended to complement Software Security Assurance: A State-of-the-Art Report,2 which provides an broad overview of the current methodologies, practices, technologies, and activities engaged in by government, industry, and academia for producing secure software and verifying software’s security. Enhancing the Development Life Cycle complements Software Security Assurance by describing in greater
Recommended publications
  • Software Assurance

    Software Assurance

    Information Assurance State-of-the-Art Report Technology Analysis Center (IATAC) SOAR (SOAR) July 31, 2007 Data and Analysis Center for Software (DACS) Joint endeavor by IATAC with DACS Software Security Assurance Distribution Statement A E X C E E C L I L V E R N E Approved for public release; C S E I N N I IO DoD Data & Analysis Center for Software NF OR MAT distribution is unlimited. Information Assurance Technology Analysis Center (IATAC) Data and Analysis Center for Software (DACS) Joint endeavor by IATAC with DACS Software Security Assurance State-of-the-Art Report (SOAR) July 31, 2007 IATAC Authors: Karen Mercedes Goertzel Theodore Winograd Holly Lynne McKinley Lyndon Oh Michael Colon DACS Authors: Thomas McGibbon Elaine Fedchak Robert Vienneau Coordinating Editor: Karen Mercedes Goertzel Copy Editors: Margo Goldman Linda Billard Carolyn Quinn Creative Directors: Christina P. McNemar K. Ahnie Jenkins Art Director, Cover, and Book Design: Don Rowe Production: Brad Whitford Illustrations: Dustin Hurt Brad Whitford About the Authors Karen Mercedes Goertzel Information Assurance Technology Analysis Center (IATAC) Karen Mercedes Goertzel is a subject matter expert in software security assurance and information assurance, particularly multilevel secure systems and cross-domain information sharing. She supports the Department of Homeland Security Software Assurance Program and the National Security Agency’s Center for Assured Software, and was lead technologist for 3 years on the Defense Information Systems Agency (DISA) Application Security Program. Ms. Goertzel is currently lead author of a report on the state-of-the-art in software security assurance, and has also led in the creation of state-of-the-art reports for the Department of Defense (DoD) on information assurance and computer network defense technologies and research.
  • Design and Implementation of Generics for the .NET Common Language Runtime

    Design and Implementation of Generics for the .NET Common Language Runtime

    Design and Implementation of Generics for the .NET Common Language Runtime Andrew Kennedy Don Syme Microsoft Research, Cambridge, U.K. fakeÒÒ¸d×ÝÑeg@ÑicÖÓ×ÓfغcÓÑ Abstract cally through an interface definition language, or IDL) that is nec- essary for language interoperation. The Microsoft .NET Common Language Runtime provides a This paper describes the design and implementation of support shared type system, intermediate language and dynamic execution for parametric polymorphism in the CLR. In its initial release, the environment for the implementation and inter-operation of multiple CLR has no support for polymorphism, an omission shared by the source languages. In this paper we extend it with direct support for JVM. Of course, it is always possible to “compile away” polymor- parametric polymorphism (also known as generics), describing the phism by translation, as has been demonstrated in a number of ex- design through examples written in an extended version of the C# tensions to Java [14, 4, 6, 13, 2, 16] that require no change to the programming language, and explaining aspects of implementation JVM, and in compilers for polymorphic languages that target the by reference to a prototype extension to the runtime. JVM or CLR (MLj [3], Haskell, Eiffel, Mercury). However, such Our design is very expressive, supporting parameterized types, systems inevitably suffer drawbacks of some kind, whether through polymorphic static, instance and virtual methods, “F-bounded” source language restrictions (disallowing primitive type instanti- type parameters, instantiation at pointer and value types, polymor- ations to enable a simple erasure-based translation, as in GJ and phic recursion, and exact run-time types.
  • 0.1 Problems

    0.1 Problems

    0.1. PROBLEMS 1 0.1 Problems 1. Among the fundamental challenges in information security are confi- dentiality, integrity, and availability, or CIA. a. Define each of these terms: confidentiality, integrity, availability. b. Give a concrete example where confidentiality is more important than integrity. c. Give a concrete example where integrity is more important than confidentiality. d. Give a concrete example where availability is the overriding con- cern. 2. From a bank's perspective, which is usually more important, the in- tegrity of its customer's data or the confidentiality of the data? From the perspective of the bank's customers, which is more important? 3. Instead of an online bank, suppose that Alice provides an online chess playing service known as Alice's Online Chess (AOC). Players, who pay a monthly fee, log into AOC where they are matched with another player of comparable ability. a. Where (and why) is confidentiality important for AOC and its customers? b. Why is integrity necessary? c. Why is availability an important concern? 4. Instead of an online bank, suppose that Alice provides an online chess playing service known as Alice's Online Chess (AOC). Players, who pay a monthly fee, log into AOC where they are matched with another player of comparable ability. a. Where should cryptography be used in AOC? b. Where should access control used? c. Where would security protocols be used? d. Is software security a concern for AOC? Why or why not? 5. Some authors distinguish between secrecy, privacy, and confidential- ity. In this usage, secrecy is equivalent to our use of the term con- fidentiality, whereas privacy is secrecy applied to personal data, and 2 confidentiality (in this misguided sense) refers to an obligation not to divulge certain information.
  • Tricore Architecture Manual for a Detailed Discussion of Instruction Set Encoding and Semantics

    Tricore Architecture Manual for a Detailed Discussion of Instruction Set Encoding and Semantics

    User’s Manual, v2.3, Feb. 2007 TriCore 32-bit Unified Processor Core Embedded Applications Binary Interface (EABI) Microcontrollers Edition 2007-02 Published by Infineon Technologies AG 81726 München, Germany © Infineon Technologies AG 2007. All Rights Reserved. Legal Disclaimer The information given in this document shall in no event be regarded as a guarantee of conditions or characteristics (“Beschaffenheitsgarantie”). With respect to any examples or hints given herein, any typical values stated herein and/or any information regarding the application of the device, Infineon Technologies hereby disclaims any and all warranties and liabilities of any kind, including without limitation warranties of non- infringement of intellectual property rights of any third party. Information For further information on technology, delivery terms and conditions and prices please contact your nearest Infineon Technologies Office (www.infineon.com). Warnings Due to technical requirements components may contain dangerous substances. For information on the types in question please contact your nearest Infineon Technologies Office. Infineon Technologies Components may only be used in life-support devices or systems with the express written approval of Infineon Technologies, if a failure of such components can reasonably be expected to cause the failure of that life-support device or system, or to affect the safety or effectiveness of that device or system. Life support devices or systems are intended to be implanted in the human body, or to support and/or maintain and sustain and/or protect human life. If they fail, it is reasonable to assume that the health of the user or other persons may be endangered. User’s Manual, v2.3, Feb.
  • Financial Fraud and Internet Banking: Threats and Countermeasures

    Financial Fraud and Internet Banking: Threats and Countermeasures

    Report Financial Fraud and Internet Banking: Threats and Countermeasures By François Paget, McAfee® Avert® Labs Report Financial Fraud and Internet Banking: Threats and Countermeasures Table of Contents Some Figures 3 U.S. Federal Trade Commission Statistics 3 CyberSource 4 Internet Crime Complaint Center 4 In Europe 5 The Many Faces of Fraud 6 Small- and large-scale identity theft 7 Carding and skimming 8 Phishing and pharming 8 Crimeware 9 Money laundering 10 Mules 10 Virtual casinos 11 Pump and dump 12 Nigerian advance fee fraud (419 fraud) 12 Auctions 14 Online shopping 16 Anonymous payment methods 17 Protective Measures 18 Scoring 18 Europay, MasterCard, and Visa (EMV) standard 18 PCI-DSS 19 Secure Sockets Layer (SSL) and Transport Secured Layer (TLS) protocols 19 SSL extended validation 20 3-D Secure technology 21 Strong authentication and one-time password devices 22 Knowledge-based authentication 23 Email authentication 23 Conclusion 24 About McAfee, Inc. 26 Report Financial Fraud and Internet Banking: Threats and Countermeasures Financial fraud has many faces. Whether it involves swindling, debit or credit card fraud, real estate fraud, drug trafficking, identity theft, deceptive telemarketing, or money laundering, the goal of cybercriminals is to make as much money as possible within a short time and to do so inconspicuously. This paper will introduce you to an array of threats facing banks and their customers. It includes some statistics and descriptions of solutions that should give readers—whether they are responsible for security in a financial organization or a customer—an overview of the current situation. Some Figures U.S.
  • Tribits Lifecycle Model Version

    Tribits Lifecycle Model Version

    SANDIA REPORT SAND2012-0561 Unlimited Release Printed February 2012 TriBITS Lifecycle Model Version 1.0 A Lean/Agile Software Lifecycle Model for Research-based Computational Science and Engineering and Applied Mathematical Software Roscoe A. Bartlett Michael A. Heroux James M. Willenbring Prepared by Sandia National Laboratories Albuquerque, New Mexico 87185 and Livermore, California 94550 Sandia National Laboratories is a multi-program laboratory managed and operated by Sandia Corporation, a wholly owned subsidiary of Lockheed Martin Corporation, for the U.S. Department of Energys National Nuclear Security Administration under Contract DE-AC04-94AL85000. Approved for public release; further dissemination unlimited. Issued by Sandia National Laboratories, operated for the United States Department of Energy by Sandia Corporation. NOTICE: This report was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government, nor any agency thereof, nor any of their employees, nor any of their contractors, subcontractors, or their employees, make any warranty, express or implied, or assume any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or rep- resent that its use would not infringe privately owned rights. Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government, any agency thereof, or any of their contractors or subcontractors. The views and opinions expressed herein do not necessarily state or reflect those of the United States Government, any agency thereof, or any of their contractors.
  • Lecture 2 — Software Correctness

    Lecture 2 — Software Correctness

    Lecture 2 — Software Correctness David J. Pearce School of Engineering and Computer Science Victoria University of Wellington Software Correctness RECOMMENDATIONS To Builders and Users of Software Make the most of effective software development technologies and formal methods. A variety of modern technologies — in particular, safe programming languages, static analysis, and formal methods — are likely to reduce the cost and difficulty of producing dependable software. Elementary best practices, such as source code control and systematic defect tracking, should be universally adopted, . –Software for Dependable Systems Patriot Missle 1991, Dhahran - Iraqi Scud missile hits barracks killing 28 soldiers - Patriot system was activated, but missed target by over 600m - Floating point representation of 0.1 was cause (rounding error over time, required 100 hours of continuous operation) See: “Engineering Disasters” https://www.youtube.com/watch?v=EMVBLg2MrLs (Image by Darkone - Own work, CC BY-SA 2.5) Unintended Acceleration? (Overview) Braking Problems (Toyota Prius) Drivers reported “sudden acceleration” when braking By 2010, over seven million cars recalled NASA experts called into investigate Specialists in static analysis Their report had significant redactions though Bookout vs Toyota, 2013 Victim’s awarded $1.5million each Barr provided expert testimony See “Unintended Acceleration and Other Embedded Software bugs”, Michael Barr, 2011 See “An Update on Toyota and Unintended acceleration” Unintended Acceleration? (NASA Analysis) Throttle
  • Configuration Description (And the Resulting ECU Ex- Tract of the System Configuration for the Individual Ecus)

    Configuration Description (And the Resulting ECU Ex- Tract of the System Configuration for the Individual Ecus)

    Specification of ECU Configuration V2.5.0 R3.2 Rev 3 Specification of ECU Document Title Configuration Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification No 087 Document Classification Standard Document Version 2.5.0 Document Status Final Part of Release 3.2 Revision 3 Document Change History Date Version Changed by Description • Improved description about HandleIds AUTOSAR • improved CDD module 28.02.2014 2.5.0 Release configuration and made it Management PostBuild configurable • Miscellaneous fixes and improvements in the document • Support unidirectional CDD communication AUTOSAR 15.05.2013 2.4.1 • Improved description about Administration HandleIds • Added post build support for CDD • Reworked CDD configuration to reflect the direction of the communication AUTOSAR 25.05.2012 2.4.0 • Introduced apiServicePrefix Administration attribute to store the CDD module abbreviation (changed ecuc_sws_6037) 1 of 156 Document ID 087: AUTOSAR_ECU_Configuration — AUTOSAR CONFIDENTIAL — Specification of ECU Configuration V2.5.0 R3.2 Rev 3 • Added section on Complex Device Driver (section 4.4) • Clarification of PostBuildSelectable, PostBuildLoadable in VSMD AUTOSAR 31.03.2011 2.3.0 (added ecuc_sws_6046, Administration ecuc_sws_6047, ecuc_sws_6048, ecuc_sws_6049) • set configuration class affection support to deprecated AUTOSAR Updated definition how symbolic 14.10.2009 2.2.0 Administration names are generated from the EcuC. AUTOSAR Fixed foreign reference to 15.09.2008 2.1.0 Administration PduToFrameMapping AUTOSAR 01.07.2008 2.0.2 Legal
  • CS5233 Components – Models and Engineering - Komponententechnologien - Master of Science (Informatik)

    CS5233 Components – Models and Engineering - Komponententechnologien - Master of Science (Informatik)

    Prof. Dr. Th. Letschert CS5233 Components – Models and Engineering - Komponententechnologien - Master of Science (Informatik) Components in the Software Life-cycle Seite 1 © Th Letschert Software Lifecycle : Development 1. Development coding type checking, byte code generation 2. Linking / Loading 3. Execution Which language features support separate development in Java? Which units of (mutual dependent) code may be written, type-checked and compiled concurrently? Seite 2 Th Letschert Software Lifecycle : Development 1. Development component in Java: Compilation Unit The notion of “program” is obsolete by now Source code : system of interdependent compilation units Compilation unit: Source code fragment, unit of work for the compiler Separate compilation: Type-checking and generation of binary code for code fragments Result Binary code Type information for compiling other fragments Compilation units in Java: Goal symbol (“top” production) of the grammar (see Java language specification) CompilationUnit ::= [PackageDeclaration] [ImportDeclations] TypeDeclarations Types declared in different CUs can depend on each other, even circularly CUs have to be stored in files with a name that conforms to the one and only public type definition files have to placed in directories according to the package structure Seite 3 Th Letschert Software Lifecycle : Development Separate Compilation in Java Compile class C depending on C₁, C₂, ··· Cn . C₁, C₂, ··· must be present in source or binary form . if some Ci is not present in binary form:
  • Linkers and Loaders Do?

    Linkers and Loaders Do?

    Linkers & Loaders by John R. Levine Table of Contents 1 Table of Contents Chapter 0: Front Matter ........................................................ 1 Dedication .............................................................................................. 1 Introduction ............................................................................................ 1 Who is this book for? ......................................................................... 2 Chapter summaries ............................................................................. 3 The project ......................................................................................... 4 Acknowledgements ............................................................................ 5 Contact us ........................................................................................... 6 Chapter 1: Linking and Loading ........................................... 7 What do linkers and loaders do? ............................................................ 7 Address binding: a historical perspective .............................................. 7 Linking vs. loading .............................................................................. 10 Tw o-pass linking .............................................................................. 12 Object code libraries ........................................................................ 15 Relocation and code modification .................................................... 17 Compiler Drivers .................................................................................
  • Low-Cost Deterministic C++ Exceptions for Embedded Systems

    Low-Cost Deterministic C++ Exceptions for Embedded Systems

    Edinburgh Research Explorer Low-Cost Deterministic C++ Exceptions for Embedded Systems Citation for published version: Renwick, J, Spink, T & Franke, B 2019, Low-Cost Deterministic C++ Exceptions for Embedded Systems. in Proceedings of the 28th International Conference on Compiler Construction. ACM, Washington, DC, USA, pp. 76-86, 28th International Conference on Compiler Construction, Washington D.C., United States, 16/02/19. https://doi.org/10.1145/3302516.3307346 Digital Object Identifier (DOI): 10.1145/3302516.3307346 Link: Link to publication record in Edinburgh Research Explorer Document Version: Peer reviewed version Published In: Proceedings of the 28th International Conference on Compiler Construction General rights Copyright for the publications made accessible via the Edinburgh Research Explorer is retained by the author(s) and / or other copyright owners and it is a condition of accessing these publications that users recognise and abide by the legal requirements associated with these rights. Take down policy The University of Edinburgh has made every reasonable effort to ensure that Edinburgh Research Explorer content complies with UK legislation. If you believe that the public display of this file breaches copyright please contact [email protected] providing details, and we will remove access to the work immediately and investigate your claim. Download date: 25. Sep. 2021 Low-Cost Deterministic C++ Exceptions for Embedded Systems James Renwick Tom Spink Björn Franke University of Edinburgh University of Edinburgh University of Edinburgh Edinburgh, UK Edinburgh, UK Edinburgh, UK [email protected] [email protected] [email protected] ABSTRACT which their use is often associated. However, C++’s wide usage has The C++ programming language offers a strong exception mech- not been without issues.
  • A Link-Time Optimizer for the Compaq Alpha

    A Link-Time Optimizer for the Compaq Alpha

    £ aÐØÓ : A Link-Time Optimizer for the Compaq Alpha Robert Muth Saumya Debray Scott Watterson Department of Computer Science University of Arizona Tucson, AZ 85721, USA fÑÙظ Öݸ ×Ûg Koen De Bosschere Vakgroep Elektronica en Informatiesystemen Universiteit Gent B-9000 Gent, Belgium Keywords : compilers, code optimization, executable editing November 2, 1999 Abstract Traditional optimizing compilers are limited in the scope of their optimizations by the fact that only a single function, or possibly a single module, is available for analysis and optimization. In particular, this means that library routines cannot be optimized to specific calling contexts. Other optimization opportunities, exploiting information not available before linktime such as addresses of variables and the final code layout, are often ignored because linkers are traditionally unsophisticated. A possible solution is to carry out whole-program optimization at link time. This paper describes aÐØÓ, a link-time optimizer for the Compaq Alpha architecture. It is able to realize significant performance improvements even for programs compiled with a good optimizing compiler with a high level of optimization. The resulting code is considerably faster that that obtained using the OM link-time optimizer, even when the latter is used in conjunction with profile-guided and inter-file compile- time optimizations. £ The work of Robert Muth, Saumya Debray and Scott Watterson was supported in part by the National Science Foundation under grant numbers CCR-9502826, CCR-9711166, and CDA-9500991. Koen De Bosschere is a research associate with the Fund for Scientific Research – Flanders. 1 Introduction Optimizing compilers for traditional imperative languages often limit their program analyses and optimizations to individual procedures [1].