DOCSLIB.ORG

Secure Compilation for Memory Protection Alexandre Dang

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Secure compilation for memory protection Alexandre Dang To cite this version: Alexandre Dang. Secure compilation for memory protection. Cryptography and Security [cs.CR]. Université Rennes 1, 2019. English. NNT : 2019REN1S111. tel-02972693 HAL Id: tel-02972693 https://tel.archives-ouvertes.fr/tel-02972693 Submitted on 20 Oct 2020 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. THÈSE DE DOCTORAT DE L’UNIVERSITÉ DE RENNES 1 COMUE UNIVERSITÉ BRETAGNE LOIRE ÉCOLE DOCTORALE N° 601 Mathématiques et Sciences et Technologies de l’Information et de la Communication Spécialité : (voir liste des spécialités) Par Alexandre DANG Compilation Sécurisée pour la Protection de la Mémoire Thèse présentée et soutenue à Rennes, le 10 Décembre 2020 Unité de recherche : Celtique Thèse N° : Rapporteurs avant soutenance : Tamara Rezk Inria Sofia Antipolis Alejandro Russo Chalmers University of Technology Composition du Jury : Attention, en cas d’absence d’un des membres du Jury le jour de la soutenance, la composition du Jury ne comprend que les membres présents Président : Prénom Nom Fonction et établissement d’exercice (à préciser après la soutenance) Examinateurs : Frédéric Besson Inria Rennes Tamara Rezk Inria Sofia Antipolis Alejandro Russo Chalmers University of Technology Heydemann Karine Université Pierre et Marie Curie Viet Triem Tong Valérie CentraleSupélec Dir. de thèse : Thomas JENSEN Inria Rennes COMPILATION POUR LA PROTECTION DE LA MÉMOIRE Nos vies sont de plus en plus dépendantes des systèmes informatiques et cette tendance devrait s’accentuer dans les années à venir. Que ce soit dans la santé, les transports ou l’économie, ces différents domaines ne sont plus capables de fonctionner correctement sans l’utilisation de ces systèmes. De ce fait, l’intérêt porté sur la sécu- rité informatique a également pris de l’importance, en conséquence des retombées désastreuses que peuvent provoquer les cyber attaques. Cette thèse a pour but d’améliorer la sécurité des systèmes informatiques en s’intéressant à la compilation sécurisée des programmes. La compilation est le processus de tra- duction d’un programme source écrit par des humains vers du code machine lisible par nos processeurs. Il existe deux manière de faire de la compilation sécurisée: par application ou par préservation d’une politique de sécurité. Appliquer une politique de sécurité à un programme durant la compilation consiste à prendre n’importe quel programme en entrée et de toujours produire un programme sécurisé en sortie. Un tel exemple est le compilateur gcc patché avec StackGuard [29] qui produit des exé- cutables résistants aux attaques de type buffer overflow [70]. Dans ce cas précis, la politique de sécurité appliquée est choisie par le compilateur ce qui peut poser prob- lème lorsqu’elle diffère du choix de l’utilisateur. Un compilateur préservant la sécurité des programmes suit un objectif différent, celui-ci s’assure que le programme compilé soit au moins aussi sécurisé que le programme source. Par exemple, Jasmin [3] est un compilateur dédié aux implémentations cryptographiques et garantit qu’un programme compilé respecte les mêmes propriétés de sécurité que sa version source. Le choix de compilateur sécurisé dépend du degré de confiance accordé au programme source qui va être compilé. Dans le cas où le programme source est d’origine inconnue ou malveillante, on utilisera l’application de sécurité pour être sûr d’obtenir un programme sécurisé en sortie. Au contraire, lorsque la politique de sécurité est mise en place par les développeurs dans le code source d’un programme, on utilisera plutôt à un com- pilateur qui s’assurera que la sécurité du programme source soit préservée jusqu’au 3 programme exécutable. Les deux types de compilation sécurisée présentés seront abordés dans cette thèse. Tout d’abord nous avons développé le compilateur COMPCERTSFI qui applique les techniques de Software Fault Isolation (SFI) sur les programmes transformés. La deuxième partie de la thèse se concentre sur la préservation de propriétés de sécurité durant la compilation. Nous avons défini une propriété appelée Information Flow Pre- serving qui garantit qu’une transformation produise des programmes aussi sécurisés que que leurs version source. COMPCERTSFI Software Fault Isolation (SFI) est une technique d’isolation qui essaye de maximiser les temps d’exécution. Les principes fondamentaux de SFI ont été établis par Wahbe et al. [114] et les travaux qui suivent tels que NaCl [117] ou Pittsfield [73] sont tous basés sur ces principes. Nous commençons par présenter les fondamentaux de SFI pour ensuite nous pencher sur notre compilateur COMPCERTSFI. Software Fault Isolation (SFI) Différentes méthode d’isolation existent comme les machines virtuelles ou la mémoire virtuelle entre processus. SFI est la technique qui réduit au maximum les interactions entre un programme hôte et différents modules qui peuvent être malveillants. Pour cela, dans SFI, le programme hôte accueille dans sa propre mémoire, les différents modules avec lesquels il veut interagir. Pour éviter que ces modules corrompent la mémoire du programme hôte, ils sont placés dans des zones mémoires attitrées, appelées sandbox. La politique de sécurité de SFI décrite par Wahbe et al. est la suivante: — Sûreté de la mémoire: un module ne peut ni lire, ni écrire ni sauter hors de sa sandbox. — Communication sécurisée: toute communication entre l’hôte et ses modules passent à travers une interface qui vérifie leur légitimité. — Vérification du code: tout code exécuté par un module a été au préalable con- trôlé de manière à ce qu’il satisfasse les deux règles précédentes SFI est composée de deux éléments majeurs: un générateur et un vérifieur. Le généra- teur est intégré durant la compilation et transforme le code d’un module de manière à 4 ce qu’il satisfasse les règles de sûreté de la mémoire et de communication sécurisée. Ensuite, avant de charger le code d’un module en mémoire, il sera contrôlé par le vérifieur qui s’assure que le code respecte la politique de sécurité de SFI. De nombreux travaux ont été effectué sur SFI tels que MiSFIt [107], Pittsfield [73] ou NaCl [117, 98, 6] qui a été utilisé dans le navigateur Google Chrome. Le principal but de ces travaux a été de diminuer au maximum, les ralentissements introduits par les transformations de programme de SFI. COMPCERTSFI COMPCERTSFI est un compilateur basé sur COMPCERT [66] qui pro- duit des programmes respectant la politique de sécurité de SFI. COMPCERT est un compilateur certifié, pour le langage C, prouvé avec l’assistant de preuve Coq [112], de respecter un théorème de préservation des programmes compilés. Grâce à ce théorème de préservation, COMPCERTSFI peut retirer le vérifieur SFI des outils de SFI. En effet, COMPCERTSFI possède seulement un générateur de code pour SFI mais pas de vérifieur. Cette approche a d’abord été théorisé par PSFI [60] et COMPCERTSFI en est une implémentation compétitive et complète. L’idée est d’utiliser un générateur SFI assez tôt dans la chaîne de compilation, puis de profiter du théorème de préser- vation de COMPCERT pour préserver la sécurité de SFI dans le binaire produit. Les théorèmes prouvés sur le générateur SFI de COMPCERTSFI sont les suivants: — Sécurité: le code produit par le générateur ne peut accéder à de la mémoire situées en dehors de sa sandbox et toute interaction hôte-module est identifiée et contrôlée par une bibliothèque de confiance. — Sûreté: le code produit ne contient pas de comportements indéfinis Le théorème de sécurité correspond aux règles de sûreté de la mémoire et de com- munication sécurisée des principes de SFI et garantissent l’isolation des modules. Le théorème de sûreté est nécessaire pour pouvoir appliquer le théorème de préservation de COMPCERT qui cite: si un programme p ne contient pas de comportements indéfinis alors le programme compilé p′ a le même comportement que p. Grâce à ce théorème de préservation, nous avons la garantie que les transformations faites auparavant par le générateur SFI sont conservées durant la compilation et que le programme compilé est bien isolé dans sa sandbox. Ne pas posséder de vérifieur donne plusieurs avantages. Tout d’abord, puisque les transformations SFI se font à haut niveau, COMPCERTSFI supporte naturellement 5 toutes les architectures supportés par COMPCERT. Avec l’approche traditionnelle de SFI, nous sommes obligés de développer un générateur et un vérifieur pour chaque architecture. Un autre avantage est que les transformations SFI se font à haut niveau ce qui permet aux constructions SFI d’être optimisés par le compilateur. En effet, dans l’approche classique le vérifieur doit être capable de contrôler que du code respecte les principes de SFI et doit être donc facilement vérifiable. De ce fait, les transformations SFI ne sont pas optimisés afin d’être visible par le vérifieur SFI. Nous avons effectué des mesures des performances de COMPCERTSFI et les avons comparés avec NaCl. En moyenne, notre compilateur a des performances similaires à NaCl et nous avons observé que les différences résident principalement dans les performances du compilateur COMPCERT pour les temps d’exécution. En effet, COMP- CERT est plus lent que gcc ou Clang, utilisés par NaCl, et nos expériences montrent que l’impact de nos transformations SFI est modeste. Plusieurs pistes sont possi- bles pour améliorer COMPCERTSFI. La première est de tout simplement améliorer les performance de COMPCERT en utilisant des variantes plus rapides telle que COM- PCERTSSA [10] qui possède des optimisations supplémentaires. Une autre idée est de créer des optimisations spécifiques à SFI pour diminuer encore plus le ralentisse- ment provoqué par les constructions SFI rajoutées dans le code.
Recommended publications
  • Openvms Record Management Services Reference Manual

    Openvms Record Management Services Reference Manual

    OpenVMS Record Management Services Reference Manual Order Number: AA-PV6RD-TK April 2001 This reference manual contains general information intended for use in any OpenVMS programming language, as well as specific information on writing programs that use OpenVMS Record Management Services (OpenVMS RMS). Revision/Update Information: This manual supersedes the OpenVMS Record Management Services Reference Manual, OpenVMS Alpha Version 7.2 and OpenVMS VAX Version 7.2 Software Version: OpenVMS Alpha Version 7.3 OpenVMS VAX Version 7.3 Compaq Computer Corporation Houston, Texas © 2001 Compaq Computer Corporation Compaq, AlphaServer, VAX, VMS, the Compaq logo Registered in U.S. Patent and Trademark Office. Alpha, PATHWORKS, DECnet, DEC, and OpenVMS are trademarks of Compaq Information Technologies Group, L.P. in the United States and other countries. UNIX and X/Open are trademarks of The Open Group in the United States and other countries. All other product names mentioned herein may be the trademarks of their respective companies. Confidential computer software. Valid license from Compaq required for possession, use, or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor’s standard commercial license. Compaq shall not be liable for technical or editorial errors or omissions contained herein. The information in this document is provided "as is" without warranty of any kind and is subject to change without notice. The warranties for Compaq products are set forth in the express limited warranty statements accompanying such products. Nothing herein should be construed as constituting an additional warranty.
  • Attacking Client-Side JIT Compilers.Key

    Attacking Client-Side JIT Compilers.Key

    Attacking Client-Side JIT Compilers Samuel Groß (@5aelo) !1 A JavaScript Engine Parser JIT Compiler Interpreter Runtime Garbage Collector !2 A JavaScript Engine • Parser: entrypoint for script execution, usually emits custom Parser bytecode JIT Compiler • Bytecode then consumed by interpreter or JIT compiler • Executing code interacts with the Interpreter runtime which defines the Runtime representation of various data structures, provides builtin functions and objects, etc. Garbage • Garbage collector required to Collector deallocate memory !3 A JavaScript Engine • Parser: entrypoint for script execution, usually emits custom Parser bytecode JIT Compiler • Bytecode then consumed by interpreter or JIT compiler • Executing code interacts with the Interpreter runtime which defines the Runtime representation of various data structures, provides builtin functions and objects, etc. Garbage • Garbage collector required to Collector deallocate memory !4 A JavaScript Engine • Parser: entrypoint for script execution, usually emits custom Parser bytecode JIT Compiler • Bytecode then consumed by interpreter or JIT compiler • Executing code interacts with the Interpreter runtime which defines the Runtime representation of various data structures, provides builtin functions and objects, etc. Garbage • Garbage collector required to Collector deallocate memory !5 A JavaScript Engine • Parser: entrypoint for script execution, usually emits custom Parser bytecode JIT Compiler • Bytecode then consumed by interpreter or JIT compiler • Executing code interacts with the Interpreter runtime which defines the Runtime representation of various data structures, provides builtin functions and objects, etc. Garbage • Garbage collector required to Collector deallocate memory !6 Agenda 1. Background: Runtime Parser • Object representation and Builtins JIT Compiler 2. JIT Compiler Internals • Problem: missing type information • Solution: "speculative" JIT Interpreter 3.
  • Chapter 1. Origins of Mac OS X

    Chapter 1. Origins of Mac OS X

    1 Chapter 1. Origins of Mac OS X "Most ideas come from previous ideas." Alan Curtis Kay The Mac OS X operating system represents a rather successful coming together of paradigms, ideologies, and technologies that have often resisted each other in the past. A good example is the cordial relationship that exists between the command-line and graphical interfaces in Mac OS X. The system is a result of the trials and tribulations of Apple and NeXT, as well as their user and developer communities. Mac OS X exemplifies how a capable system can result from the direct or indirect efforts of corporations, academic and research communities, the Open Source and Free Software movements, and, of course, individuals. Apple has been around since 1976, and many accounts of its history have been told. If the story of Apple as a company is fascinating, so is the technical history of Apple's operating systems. In this chapter,[1] we will trace the history of Mac OS X, discussing several technologies whose confluence eventually led to the modern-day Apple operating system. [1] This book's accompanying web site (www.osxbook.com) provides a more detailed technical history of all of Apple's operating systems. 1 2 2 1 1.1. Apple's Quest for the[2] Operating System [2] Whereas the word "the" is used here to designate prominence and desirability, it is an interesting coincidence that "THE" was the name of a multiprogramming system described by Edsger W. Dijkstra in a 1968 paper. It was March 1988. The Macintosh had been around for four years.
  • Improving System Security Through TCB Reduction

    Improving System Security Through TCB Reduction

    Improving System Security Through TCB Reduction Bernhard Kauer March 31, 2015 Dissertation vorgelegt an der Technischen Universität Dresden Fakultät Informatik zur Erlangung des akademischen Grades Doktoringenieur (Dr.-Ing.) Erstgutachter Prof. Dr. rer. nat. Hermann Härtig Technische Universität Dresden Zweitgutachter Prof. Dr. Paulo Esteves Veríssimo University of Luxembourg Verteidigung 15.12.2014 Abstract The OS (operating system) is the primary target of todays attacks. A single exploitable defect can be sufficient to break the security of the system and give fully control over all the software on the machine. Because current operating systems are too large to be defect free, the best approach to improve the system security is to reduce their code to more manageable levels. This work shows how the security-critical part of theOS, the so called TCB (Trusted Computing Base), can be reduced from millions to less than hundred thousand lines of code to achieve these security goals. Shrinking the software stack by more than an order of magnitude is an open challenge since no single technique can currently achieve this. We therefore followed a holistic approach and improved the design as well as implementation of several system layers starting with a newOS called NOVA. NOVA provides a small TCB for both newly written applications but also for legacy code running inside virtual machines. Virtualization is thereby the key technique to ensure that compatibility requirements will not increase the minimal TCB of our system. The main contribution of this work is to show how the virtual machine monitor for NOVA was implemented with significantly less lines of code without affecting the per- formance of its guest OS.
  • 1 More Register Allocation Interference Graph Allocators

    1 More Register Allocation Interference Graph Allocators

    More Register Allocation Last time – Register allocation – Global allocation via graph coloring Today – More register allocation – Clarifications from last time – Finish improvements on basic graph coloring concept – Procedure calls – Interprocedural CS553 Lecture Register Allocation II 2 Interference Graph Allocators Chaitin Briggs CS553 Lecture Register Allocation II 3 1 Coalescing Move instructions – Code generation can produce unnecessary move instructions mov t1, t2 – If we can assign t1 and t2 to the same register, we can eliminate the move Idea – If t1 and t2 are not connected in the interference graph, coalesce them into a single variable Problem – Coalescing can increase the number of edges and make a graph uncolorable – Limit coalescing coalesce to avoid uncolorable t1 t2 t12 graphs CS553 Lecture Register Allocation II 4 Coalescing Logistics Rule – If the virtual registers s1 and s2 do not interfere and there is a copy statement s1 = s2 then s1 and s2 can be coalesced – Steps – SSA – Find webs – Virtual registers – Interference graph – Coalesce CS553 Lecture Register Allocation II 5 2 Example (Apply Chaitin algorithm) Attempt to 3-color this graph ( , , ) Stack: Weighted order: a1 b d e c a1 b a e c 2 a2 b a1 c e d a2 d The example indicates that nodes are visited in increasing weight order. Chaitin and Briggs visit nodes in an arbitrary order. CS553 Lecture Register Allocation II 6 Example (Apply Briggs Algorithm) Attempt to 2-color this graph ( , ) Stack: Weighted order: a1 b d e c a1 b* a e c 2 a2* b a1* c e* d a2 d * blocked node CS553 Lecture Register Allocation II 7 3 Spilling (Original CFG and Interference Graph) a1 := ..
  • Feasibility of Optimizations Requiring Bounded Treewidth in a Data Flow Centric Intermediate Representation

    Feasibility of Optimizations Requiring Bounded Treewidth in a Data Flow Centric Intermediate Representation

    Feasibility of Optimizations Requiring Bounded Treewidth in a Data Flow Centric Intermediate Representation Sigve Sjømæling Nordgaard and Jan Christian Meyer Department of Computer Science, NTNU Trondheim, Norway Abstract Data flow analyses are instrumental to effective compiler optimizations, and are typically implemented by extracting implicit data flow information from traversals of a control flow graph intermediate representation. The Regionalized Value State Dependence Graph is an alternative intermediate representation, which represents a program in terms of its data flow dependencies, leaving control flow implicit. Several analyses that enable compiler optimizations reduce to NP-Complete graph problems in general, but admit linear time solutions if the graph’s treewidth is limited. In this paper, we investigate the treewidth of application benchmarks and synthetic programs, in order to identify program features which cause the treewidth of its data flow graph to increase, and assess how they may appear in practical software. We find that increasing numbers of live variables cause unbounded growth in data flow graph treewidth, but this can ordinarily be remedied by modular program design, and monolithic programs that exceed a given bound can be efficiently detected using an approximate treewidth heuristic. 1 Introduction Effective program optimizations depend on an intermediate representation that permits a compiler to analyze the data and control flow semantics of the source program, so as to enable transformations without altering the result. The information from analyses such as live variables, available expressions, and reaching definitions pertains to data flow. The classical method to obtain it is to iteratively traverse a control flow graph, where program execution paths are explicitly encoded and data movement is implicit.
  • Iterative-Free Program Analysis

    Iterative-Free Program Analysis

    Iterative-Free Program Analysis Mizuhito Ogawa†∗ Zhenjiang Hu‡∗ Isao Sasano† [email protected] [email protected] [email protected] †Japan Advanced Institute of Science and Technology, ‡The University of Tokyo, and ∗Japan Science and Technology Corporation, PRESTO Abstract 1 Introduction Program analysis is the heart of modern compilers. Most control Program analysis is the heart of modern compilers. Most control flow analyses are reduced to the problem of finding a fixed point flow analyses are reduced to the problem of finding a fixed point in a in a certain transition system, and such fixed point is commonly certain transition system. Ordinary method to compute a fixed point computed through an iterative procedure that repeats tracing until is an iterative procedure that repeats tracing until convergence. convergence. Our starting observation is that most programs (without spaghetti This paper proposes a new method to analyze programs through re- GOTO) have quite well-structured control flow graphs. This fact cursive graph traversals instead of iterative procedures, based on is formally characterized in terms of tree width of a graph [25]. the fact that most programs (without spaghetti GOTO) have well- Thorup showed that control flow graphs of GOTO-free C programs structured control flow graphs, graphs with bounded tree width. have tree width at most 6 [33], and recent empirical study shows Our main techniques are; an algebraic construction of a control that control flow graphs of most Java programs have tree width at flow graph, called SP Term, which enables control flow analysis most 3 (though in general it can be arbitrary large) [16].
  • The Evolution of the Unix Time-Sharing System*

    The Evolution of the Unix Time-Sharing System*

    The Evolution of the Unix Time-sharing System* Dennis M. Ritchie Bell Laboratories, Murray Hill, NJ, 07974 ABSTRACT This paper presents a brief history of the early development of the Unix operating system. It concentrates on the evolution of the file system, the process-control mechanism, and the idea of pipelined commands. Some attention is paid to social conditions during the development of the system. NOTE: *This paper was first presented at the Language Design and Programming Methodology conference at Sydney, Australia, September 1979. The conference proceedings were published as Lecture Notes in Computer Science #79: Language Design and Programming Methodology, Springer-Verlag, 1980. This rendition is based on a reprinted version appearing in AT&T Bell Laboratories Technical Journal 63 No. 6 Part 2, October 1984, pp. 1577-93. Introduction During the past few years, the Unix operating system has come into wide use, so wide that its very name has become a trademark of Bell Laboratories. Its important characteristics have become known to many people. It has suffered much rewriting and tinkering since the first publication describing it in 1974 [1], but few fundamental changes. However, Unix was born in 1969 not 1974, and the account of its development makes a little-known and perhaps instructive story. This paper presents a technical and social history of the evolution of the system. Origins For computer science at Bell Laboratories, the period 1968-1969 was somewhat unsettled. The main reason for this was the slow, though clearly inevitable, withdrawal of the Labs from the Multics project. To the Labs computing community as a whole, the problem was the increasing obviousness of the failure of Multics to deliver promptly any sort of usable system, let alone the panacea envisioned earlier.
  • Vx32: Lightweight User-Level Sandboxing on the X86

    Vx32: Lightweight User-Level Sandboxing on the X86

    Vx32: Lightweight User-level Sandboxing on the x86 Bryan Ford and Russ Cox Massachusetts Institute of Technology {baford,rsc}@pdos.csail.mit.edu Abstract 1 Introduction Code sandboxing is useful for many purposes, but most A sandbox is a mechanism by which a host software sandboxing techniques require kernel modifications, do system may execute arbitrary guest code in a confined not completely isolate guest code, or incur substantial environment, so that the guest code cannot compromise performance costs. Vx32 is a multipurpose user-level or affect the host other than according to a well-defined sandbox that enables any application to load and safely policy. Sandboxing is useful for many purposes, such execute one or more guest plug-ins, confining each guest as running untrusted Web applets within a browser [6], to a system call API controlled by the host application safely extending operating system kernels [5, 32], and and to a restricted memory region within the host’s ad- limiting potential damage caused by compromised ap- dress space. Vx32 runs guest code efficiently on several plications [19, 22]. Most sandboxing mechanisms, how- widespread operating systems without kernel extensions ever, either require guest code to be (re-)written in a type- or special privileges; it protects the host program from safe language [5,6], depend on special OS-specific facil- both reads and writes by its guests; and it allows the host ities [8, 15, 18, 19], allow guest code unrestricted read to restrict the instruction set available to guests. The key access to the host’s state [29, 42], or entail a substantial to vx32’s combination of portability, flexibility, and effi- performance cost [33,34,37].
  • X86-64 Calling Conventions

    X86-64 Calling Conventions

    CSE 351: The Hardware/Software Interface Section 4 Procedure calls Procedure calls In x86 assembly, values are passed to function calls on the stack Perks: Concise, easy to remember Drawbacks: Always requires memory accesses In x86-64 assembly, values are passed to function calls in registers Perks: Less wasted space, faster Drawbacks: Potentially requires a lot of register manipulation 2/23/2014 2 x86 calling conventions Simply push arguments onto the stack in order, then “call” the function! Suppose we define the following function: int sum(int a, int b) { return a + b; } (See also sum.c from the provided code) 2/23/2014 3 x86 calling conventions int sum(int a, int b) { return a + b; } In assembly, we have something like this: sum: pushl %ebp # Save base pointer movl %esp, %ebp # Save stack pointer movl 12(%ebp), %eax # Load b movl 8(%ebp), %edx # Load a addl %edx, %eax # Compute a + b popl %ebp # Restore base pointer ret # Return 2/23/2014 4 x86 calling conventions What is happening with %ebp and %esp? pushl %ebp The base pointer %ebp is the address of the caller, which is the location to which “ret” returns. The function pushes it into the stack so that it won’t be overwritten movl %esp, %ebp Functions often shift the stack pointer to allocate temporary stack space, so this instruction makes a backup of the original location. In the body of the function, %ebp is now the original start of the stack ret When sum() returns, execution picks up at the stored base pointer address.
  • Sample Applications User Guides Release 20.05.0

    Sample Applications User Guides Release 20.05.0

    Sample Applications User Guides Release 20.05.0 May 26, 2020 CONTENTS 1 Introduction to the DPDK Sample Applications1 1.1 Running Sample Applications...............................1 1.2 The DPDK Sample Applications..............................1 2 Compiling the Sample Applications3 2.1 To compile all the sample applications...........................3 2.2 To compile a single application..............................3 2.3 To cross compile the sample application(s)........................4 3 Command Line Sample Application5 3.1 Overview..........................................5 3.2 Compiling the Application.................................5 3.3 Running the Application..................................6 3.4 Explanation.........................................6 4 Ethtool Sample Application8 4.1 Compiling the Application.................................8 4.2 Running the Application..................................8 4.3 Using the application....................................8 4.4 Explanation.........................................9 4.5 Ethtool interface......................................9 5 Hello World Sample Application 11 5.1 Compiling the Application................................. 11 5.2 Running the Application.................................. 11 5.3 Explanation......................................... 11 6 Basic Forwarding Sample Application 13 6.1 Compiling the Application................................. 13 6.2 Running the Application.................................. 13 6.3 Explanation........................................
  • Register Allocation by Puzzle Solving

    Register Allocation by Puzzle Solving

    University of California Los Angeles Register Allocation by Puzzle Solving A dissertation submitted in partial satisfaction of the requirements for the degree Doctor of Philosophy in Computer Science by Fernando Magno Quint˜aoPereira 2008 c Copyright by Fernando Magno Quint˜aoPereira 2008 The dissertation of Fernando Magno Quint˜ao Pereira is approved. Vivek Sarkar Todd Millstein Sheila Greibach Bruce Rothschild Jens Palsberg, Committee Chair University of California, Los Angeles 2008 ii to the Brazilian People iii Table of Contents 1 Introduction ................................ 1 2 Background ................................ 5 2.1 Introduction . 5 2.1.1 Irregular Architectures . 8 2.1.2 Pre-coloring . 8 2.1.3 Aliasing . 9 2.1.4 Some Register Allocation Jargon . 10 2.2 Different Register Allocation Approaches . 12 2.2.1 Register Allocation via Graph Coloring . 12 2.2.2 Linear Scan Register Allocation . 18 2.2.3 Register allocation via Integer Linear Programming . 21 2.2.4 Register allocation via Partitioned Quadratic Programming 22 2.2.5 Register allocation via Multi-Flow of Commodities . 24 2.3 SSA based register allocation . 25 2.3.1 The Advantages of SSA-Based Register Allocation . 29 2.4 NP-Completeness Results . 33 3 Puzzle Solving .............................. 37 3.1 Introduction . 37 3.2 Puzzles . 39 3.2.1 From Register File to Puzzle Board . 40 iv 3.2.2 From Program Variables to Puzzle Pieces . 42 3.2.3 Register Allocation and Puzzle Solving are Equivalent . 45 3.3 Solving Type-1 Puzzles . 46 3.3.1 A Visual Language of Puzzle Solving Programs . 46 3.3.2 Our Puzzle Solving Program .