DOCSLIB.ORG

Build.Sh: Cross-Building Netbsd

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Build.Sh: Cross-Building Netbsd USENIX Association Proceedings of BSDCon ’03 San Mateo, CA, USA September 8–12, 2003 THE ADVANCED COMPUTING SYSTEMS ASSOCIATION © 2003 by The USENIX Association All Rights Reserved For more information about the USENIX Association: Phone: 1 510 528 8649 FAX: 1 510 548 5738 Email: [email protected] WWW: http://www.usenix.org Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein. build.sh: Cross-building NetBSD Luke Mewburn, Matthew Green The NetBSD Foundation [email protected], [email protected] Abstract 2. Background NetBSD has a cross build infrastructure which allows cross-building of an entire NetBSD release including 2.1. NetBSD bootable distribution media. The build process does not Since the NetBSD project was started in 1993 it has had require root privileges or writable source directories. a goal of being portable [3] to many target platforms. The build process works on many POSIX compatible There has been significant effort in designing, imple- operating systems. This paper explains the changes menting, and improving NetBSD to make it easier to made to NetBSD to enable this build process, enumer- “port” to a new target platform [4]. Device drivers are ates benefits of the work, and introduces future work written in a way that permits easy sharing between plat- enabling cross building of any software for NetBSD. forms without unnecessary code replication [5]. 1. Introduction The source code portability of NetBSD did not equate to “ease of use” when building the system on a host other NetBSD [1] is the most portable Unix operating system than the target platform, or indeed, natively. in common use. It is freely available and redistributable, and runs on a broad variety of platforms from modern Prior to build.sh a NetBSD release for a given platform desktop systems and high end servers that can build an was built “natively” on that platform on a version of the entire release in less than an hour, to embedded systems operating system that was “close” to the target release. and older machines that may take several days to build a There were exceptions, but these alternate processes release. were not simple to use nor easily automated, and had a variety of other limitations which build.sh addresses. In late 2001, work began on changes to improve the ability of NetBSD to be cross built, especially an entire build.sh offers a level of flexibility in building NetBSD release. This system is referred to as “build.sh”, because that has not been addressed by other open source operat- that is the name of the script that is the user-visible ing systems. front-end to the infrastructure. NetBSD 1.6 was the first release to be shipped with 2.2. Cross compiling Unix build.sh, and the Release Engineering group of the Net- Unix was cross-compiled from the beginning, but when BSD Project took advantage of it to cross-build binary native hosting was available, that became the main releases for 39 platforms on a near daily basis during the development methodology and has remained so. release cycle for NetBSD 1.6 [2]. Previous releases required access to each of the various platforms by Cross-compilation is the technique of running programs release engineers, or co-ordination with developers with on a “host” system to generate object code for a differ- that hardware. While that method works for a moderate ent “target” system. This has not been an easy task for number of platforms (NetBSD 1.5 released binaries for most system builders and has generally not been inte- 20 platforms), it does not scale, especially as the number grated into operating system build processes as used by of platforms in NetBSD is growing (54 as of June 2003). open source operating systems. Freely available software projects such as GCC [6] have object files. Shared libraries are created by calling supported being cross-compiled for a long time, and gcc with the -shared option, which calls ld with GCC is part of the GNU toolchain which NetBSD uses various options to create a shared library. and is heavily dependent upon for cross-compiling. gcc’s -v flag may be used to see exactly what external 2.2.1. An introduction to cross-compiling programs are called. For example, cross-compiling a simple NetBSD/sparc “hello world” C program on a There are many parts to a full cross compiler environ- NetBSD/macppc box gives: ment. Besides the compiler itself, many others tools and files are required to create functional programs. Every- what-time-is-love~>/tools/bin/sparc--netbsde thing that a normal compiler needs must be present. For lf-gcc-I/dest/usr/include-L/dest/usr/lib-B/ the GNU toolchain, this includes: dest/usr/lib/-v-save-temps-ohello.xhello. c • The compiler - gcc. Readingspecsfrom/tools/lib/gcc-lib/sparc--n etbsdelf/2.95.3/specs gccversion2.95.320010315(release)(NetBSD • The assembler - as. nb4) /tools/lib/gcc-lib/sparc--netbsdelf/2.95.3/cp • The linker - ld. p0-lang-c-v-I/dest/usr/include-isystem/de st/usr/lib/include-D__GNUC__=2-D__GNUC_MINOR • The “binutils”; size, nm, strip, ar, etc. __=95-D__sparc__-D__NetBSD__-D__ELF__-D__s parc__-D__NetBSD__-D__ELF__-Asystem(unix)- Asystem(NetBSD)-D__GCC_NEW_VARARGS__-Acpu(sp • Header files (provided by NetBSD). arc)-Amachine(sparc)-D__sparchello.chello. i • Libraries (provided by NetBSD and the GNU tool- GNUCPPversion2.95.320010315(release)(Net chain). BSDnb4)(sparc-netbsdelf) #include"..."searchstartshere: #include<...>searchstartshere: Following is a quick overview of how it all works. This /dest/usr/include is basically the same for any compiler; in this example /tools/lib/gcc-lib/sparc--netbsdelf/2.95.3/in the details are from the GCC C compiler: clude /tools/lib/gcc-lib/sparc--netbsdelf/2.95.3/.. /../../../sparc--netbsdelf/include 1. The C compiler front-end gcc calls the C pre- Endofsearchlist. processor cpp on an input source file, usually a Thefollowingdefaultdirectorieshavebeenom “.c” file, producing a “.i” file. This is still valid C ittedfromthesearchpath: code but will now be devoid of C pre-processor /tools/lib/gcc-lib/sparc--netbsdelf/2.95.3/.. directives. (Actually in modern GCC, the cpp pass /../../../include/g++-3 /tools/lib/gcc-lib/sparc--netbsdelf/2.95.3/.. is done inside the cc1 pass to speed up the process /../../../sparc--netbsdelf/sys-include and provide better error reporting. This process is Endofomittedlist. largely invisible to the user.) /tools/lib/gcc-lib/sparc--netbsdelf/2.95.3/cc 1hello.i-quiet-dumpbasehello.c-version-o 2. gcc calls the back-end cc1 with the output of cpp hello.s GNUCversion2.95.320010315(release)(NetBS producing a “.s” file. This is a assembler source file Dnb4)(sparc-netbsdelf)compiledbyGNUCver corresponding to the input C file. sion2.95.320010315(release)(NetBSDnb4). /tools/sparc--netbsdelf/bin/as-32-ohello.o 3. gcc calls the assembler as with the output of cc1 hello.s producing a “.o” file. This is an object file /tools/lib/gcc-lib/sparc--netbsdelf/2.95.3/co llect2-melf32_sparc-dy-dc-dp-e__start- corresponding to the input assembler file. dynamic-linker/usr/libexec/ld.elf_so-ohello .x/dest/usr/lib/crt0.o/dest/usr/lib/crti.o/ 4. gcc calls the linker ld with the output of as plus dest/usr/lib/crtbegin.o-L/dest/usr/lib-L/des several other files (sometimes collectively called t/usr/lib-L/tools/lib/gcc-lib/sparc--netbsdel the “crtstuff”), to produce an executable. f/2.95.3-L/tools/sparc--netbsdelf/libhello.o -lgcc-lc-lgcc/dest/usr/lib/crtend.o/dest/ usr/lib/crtn.o In addition to creating executables, archive and shared libraries are built. Archive libraries are usu- ally created with the ar binutils program from The output shows the cpp0, cc1, as and ld programs 3. A “Canadian cross compile” is when “build host”, being called in succession. An object file is created and “host”, and “target” are all different: the sundry “crtstuff” is added to the final ld line. ./configure --build=i386-netbsdelf \ If gcc is passed the -save-temps option the output of --host=i686-pc-cygwin \ each program will be saved rather than deleted after it --target=powerpc-eabi && make has been processed. In the above example, the following This strange beast is called a “Canadian cross com- files were created: piler”, because when a name was needed there were three political parties in Canada. It is most often what-time-is-love~>ls-lhello.? found when dealing with pre-built toolchains. The -rw-rw-r--1mrgmrg57Jun52001hello.c -rw-rw-r--1mrgmrg7820Jul715:01hello.i above example would produce a toolchain that will -rw-r--r--1mrgmrg872Jul715:01hello.o run on a i686-pc-cygwin host (i.e., a Windows sys- -rw-rw-r--1mrgmrg408Jul715:01hello.s tem with Cygwin installed) and will target embed- -rwxr-xr-x1mrgmrg68638Jul715:01hello.x ded PowerPC platforms. The toolchain would be built on a NetBSD/i386 machine. These are the source file and the cpp, cc1, as and ld outputs, respectively. A normal cross-compiler is required to build a Canadian cross-compiler. For a cross compiler the assembler, linker and binutils must also be “cross” tools. For the GNU toolchain these Most people who build software use a native build in all are normally called “$target-$tool”. For example cases. Usually people using cross compilers use the powerpc-eabi-ld is the linker for the “powerpc-eabi” same “build host” and “host”.
Load more

Recommended publications
  • Managing Projects with GNU Make, Third Edition by Robert Mecklenburg
    ManagingProjects with GNU Make Other resources from O’Reilly Related titles Unix in a Nutshell sed and awk Unix Power Tools lex and yacc Essential CVS Learning the bash Shell Version Control with Subversion oreilly.com oreilly.com is more than a complete catalog of O’Reilly books. You’ll also find links to news, events, articles, weblogs, sample chapters, and code examples. oreillynet.com is the essential portal for developers interested in open and emerging technologies, including new platforms, pro- gramming languages, and operating systems. Conferences O’Reilly brings diverse innovators together to nurture the ideas that spark revolutionary industries. We specialize in document- ing the latest tools and systems, translating the innovator’s knowledge into useful skills for those in the trenches. Visit con- ferences.oreilly.com for our upcoming events. Safari Bookshelf (safari.oreilly.com) is the premier online refer- ence library for programmers and IT professionals. Conduct searches across more than 1,000 books. Subscribers can zero in on answers to time-critical questions in a matter of seconds. Read the books on your Bookshelf from cover to cover or sim- ply flip to the page you need. Try it today with a free trial. THIRD EDITION ManagingProjects with GNU Make Robert Mecklenburg Beijing • Cambridge • Farnham • Köln • Sebastopol • Tokyo Managing Projects with GNU Make, Third Edition by Robert Mecklenburg Copyright © 2005, 1991, 1986 O’Reilly Media, Inc. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use.
    [Show full text]
  • Red Hat Enterprise Linux 6 Developer Guide
    Red Hat Enterprise Linux 6 Developer Guide An introduction to application development tools in Red Hat Enterprise Linux 6 Dave Brolley William Cohen Roland Grunberg Aldy Hernandez Karsten Hopp Jakub Jelinek Developer Guide Jeff Johnston Benjamin Kosnik Aleksander Kurtakov Chris Moller Phil Muldoon Andrew Overholt Charley Wang Kent Sebastian Red Hat Enterprise Linux 6 Developer Guide An introduction to application development tools in Red Hat Enterprise Linux 6 Edition 0 Author Dave Brolley [email protected] Author William Cohen [email protected] Author Roland Grunberg [email protected] Author Aldy Hernandez [email protected] Author Karsten Hopp [email protected] Author Jakub Jelinek [email protected] Author Jeff Johnston [email protected] Author Benjamin Kosnik [email protected] Author Aleksander Kurtakov [email protected] Author Chris Moller [email protected] Author Phil Muldoon [email protected] Author Andrew Overholt [email protected] Author Charley Wang [email protected] Author Kent Sebastian [email protected] Editor Don Domingo [email protected] Editor Jacquelynn East [email protected] Copyright © 2010 Red Hat, Inc. and others. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
    [Show full text]
  • Examining the Viability of MINIX 3 As a Consumer Operating
    Examining the Viability of MINIX 3 as a Consumer Operating System Joshua C. Loew March 17, 2016 Abstract The developers of the MINIX 3 operating system (OS) believe that a computer should work like a television set. You should be able to purchase one, turn it on, and have it work flawlessly for the next ten years [6]. MINIX 3 is a free and open-source microkernel-based operating system. MINIX 3 is still in development, but it is capable of running on x86 and ARM processor architectures. Such processors can be found in computers such as embedded systems, mobile phones, and laptop computers. As a light and simple operating system, MINIX 3 could take the place of the software that many people use every day. As of now, MINIX 3 is not particularly useful to a non-computer scientist. Most interactions with MINIX 3 are done through a command-line interface or an obsolete window manager. Moreover, its tools require some low-level experience with UNIX-like systems to use. This project will examine the viability of MINIX 3 from a performance standpoint to determine whether or not it is relevant to a non-computer scientist. Furthermore, this project attempts to measure how a microkernel-based operating system performs against a traditional monolithic kernel-based OS. 1 Contents 1 Introduction 5 2 Background and Related Work 6 3 Part I: The Frame Buffer Driver 7 3.1 Outline of Approach . 8 3.2 Hardware and Drivers . 8 3.3 Challenges and Strategy . 9 3.4 Evaluation . 10 4 Progress 10 4.1 Compilation and Installation .
    [Show full text]
  • GNU Emacs Manual
    GNU Emacs Manual GNU Emacs Manual Sixteenth Edition, Updated for Emacs Version 22.1. Richard Stallman This is the Sixteenth edition of the GNU Emacs Manual, updated for Emacs version 22.1. Copyright c 1985, 1986, 1987, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with the Invariant Sections being \The GNU Manifesto," \Distribution" and \GNU GENERAL PUBLIC LICENSE," with the Front-Cover texts being \A GNU Manual," and with the Back-Cover Texts as in (a) below. A copy of the license is included in the section entitled \GNU Free Documentation License." (a) The FSF's Back-Cover Text is: \You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development." Published by the Free Software Foundation 51 Franklin Street, Fifth Floor Boston, MA 02110-1301 USA ISBN 1-882114-86-8 Cover art by Etienne Suvasa. i Short Contents Preface ::::::::::::::::::::::::::::::::::::::::::::::::: 1 Distribution ::::::::::::::::::::::::::::::::::::::::::::: 2 Introduction ::::::::::::::::::::::::::::::::::::::::::::: 5 1 The Organization of the Screen :::::::::::::::::::::::::: 6 2 Characters, Keys and Commands ::::::::::::::::::::::: 11 3 Entering and Exiting Emacs ::::::::::::::::::::::::::: 15 4 Basic Editing
    [Show full text]
  • Downloads." the Open Information Security Foundation
    Performance Testing Suricata The Effect of Configuration Variables On Offline Suricata Performance A Project Completed for CS 6266 Under Jonathon T. Giffin, Assistant Professor, Georgia Institute of Technology by Winston H Messer Project Advisor: Matt Jonkman, President, Open Information Security Foundation December 2011 Messer ii Abstract The Suricata IDS/IPS engine, a viable alternative to Snort, has a multitude of potential configurations. A simplified automated testing system was devised for the purpose of performance testing Suricata in an offline environment. Of the available configuration variables, seventeen were analyzed independently by testing in fifty-six configurations. Of these, three variables were found to have a statistically significant effect on performance: Detect Engine Profile, Multi Pattern Algorithm, and CPU affinity. Acknowledgements In writing the final report on this endeavor, I would like to start by thanking four people who made this project possible: Matt Jonkman, President, Open Information Security Foundation: For allowing me the opportunity to carry out this project under his supervision. Victor Julien, Lead Programmer, Open Information Security Foundation and Anne-Fleur Koolstra, Documentation Specialist, Open Information Security Foundation: For their willingness to share their wisdom and experience of Suricata via email for the past four months. John M. Weathersby, Jr., Executive Director, Open Source Software Institute: For allowing me the use of Institute equipment for the creation of a suitable testing
    [Show full text]
  • Architectural Support for Dynamic Linking Varun Agrawal, Abhiroop Dabral, Tapti Palit, Yongming Shen, Michael Ferdman COMPAS Stony Brook University
    Architectural Support for Dynamic Linking Varun Agrawal, Abhiroop Dabral, Tapti Palit, Yongming Shen, Michael Ferdman COMPAS Stony Brook University Abstract 1 Introduction All software in use today relies on libraries, including All computer programs in use today rely on software standard libraries (e.g., C, C++) and application-specific libraries. Libraries can be linked dynamically, deferring libraries (e.g., libxml, libpng). Most libraries are loaded in much of the linking process to the launch of the program. memory and dynamically linked when programs are Dynamically linked libraries offer numerous benefits over launched, resolving symbol addresses across the applica- static linking: they allow code reuse between applications, tions and libraries. Dynamic linking has many benefits: It conserve memory (because only one copy of a library is kept allows code to be reused between applications, conserves in memory for all applications that share it), allow libraries memory (because only one copy of a library is kept in mem- to be patched and updated without modifying programs, ory for all the applications that share it), and allows enable effective address space layout randomization for libraries to be patched and updated without modifying pro- security [21], and many others. As a result, dynamic linking grams, among numerous other benefits. However, these is the predominant choice in all systems today [7]. benefits come at the cost of performance. For every call To facilitate dynamic linking of libraries, compiled pro- made to a function in a dynamically linked library, a trampo- grams include function call trampolines in their binaries. line is used to read the function address from a lookup table When a program is launched, the dynamic linker maps the and branch to the function, incurring memory load and libraries into the process address space and resolves external branch operations.
    [Show full text]
  • The Dragonflybsd Operating System
    1 The DragonFlyBSD Operating System Jeffrey M. Hsu, Member, FreeBSD and DragonFlyBSD directories with slightly over 8 million lines of code, 2 million Abstract— The DragonFlyBSD operating system is a fork of of which are in the kernel. the highly successful FreeBSD operating system. Its goals are to The project has a number of resources available to the maintain the high quality and performance of the FreeBSD 4 public, including an on-line CVS repository with mirror sites, branch, while exploiting new concepts to further improve accessible through the web as well as the cvsup service, performance and stability. In this paper, we discuss the motivation for a new BSD operating system, new concepts being mailing list forums, and a bug submission system. explored in the BSD context, the software infrastructure put in place to explore these concepts, and their application to the III. MOTIVATION network subsystem in particular. A. Technical Goals Index Terms— Message passing, Multiprocessing, Network The DragonFlyBSD operating system has several long- operating systems, Protocols, System software. range technical goals that it hopes to accomplish within the next few years. The first goal is to add lightweight threads to the BSD kernel. These threads are lightweight in the sense I. INTRODUCTION that, while user processes have an associated thread and a HE DragonFlyBSD operating system is a fork of the process context, kernel processes are pure threads with no T highly successful FreeBSD operating system. Its goals are process context. The threading model makes several to maintain the high quality and performance of the FreeBSD guarantees with respect to scheduling to ensure high 4 branch, while exploring new concepts to further improve performance and simplify reasoning about concurrency.
    [Show full text]
  • CS429: Computer Organization and Architecture Linking I & II
    CS429: Computer Organization and Architecture Linking I & II Dr. Bill Young Department of Computer Sciences University of Texas at Austin Last updated: April 5, 2018 at 09:23 CS429 Slideset 23: 1 Linking I A Simplistic Translation Scheme m.c ASCII source file Problems: Efficiency: small change Compiler requires complete re-compilation. m.s Modularity: hard to share common functions (e.g., printf). Assembler Solution: Static linker (or Binary executable object file linker). p (memory image on disk) CS429 Slideset 23: 2 Linking I Better Scheme Using a Linker Linking is the process of m.c a.c ASCII source files combining various pieces of code and data into a Compiler Compiler single file that can be loaded (copied) into m.s a.s memory and executed. Linking could happen at: Assembler Assembler compile time; Separately compiled m.o a.o load time; relocatable object files run time. Linker (ld) Must somehow tell a Executable object file module about symbols p (code and data for all functions defined in m.c and a.c) from other modules. CS429 Slideset 23: 3 Linking I Linking A linker takes representations of separate program modules and combines them into a single executable. This involves two primary steps: 1 Symbol resolution: associate each symbol reference throughout the set of modules with a single symbol definition. 2 Relocation: associate a memory location with each symbol definition, and modify each reference to point to that location. CS429 Slideset 23: 4 Linking I Translating the Example Program A compiler driver coordinates all steps in the translation and linking process.
    [Show full text]
  • Toolchains Instructor: Prabal Dutta Date: October 2, 2012
    EECS 373: Design of Microprocessor-Based Systems Fall 2012 Lecture 3: Toolchains Instructor: Prabal Dutta Date: October 2, 2012 Note: Unless otherwise specified, these notes assume: (i) an ARM Cortex-M3 processor operating in little endian mode; (ii) the ARM EABI application binary interface; and (iii) the GNU GCC toolchain. Toolchains A complete software toolchain includes programs to convert source code into binary machine code, link together separately assembled/compiled code modules, disassemble the binaries, and convert their formats. Binary program file (.bin) Assembly Object Executable files (.s) files (.o) image file objcopy ld (linker) as objdump (assembler) Memory layout Disassembled Linker code (.lst) script (.ld) Figure 0.1: Assembler Toolchain. A typical GNU (GNU's Not Unix) assembler toolchain includes several programs that interact as shown in Figure 0.1 and perform the following functions: • as is the assembler and it converts human-readable assembly language programs into binary machine language code. It typically takes as input .s assembly files and outputs .o object files. • ld is the linker and it is used to combine multiple object files by resolving their external symbol references and relocating their data sections, and outputting a single executable file. It typically takes as input .o object files and .ld linker scripts and outputs .out executable files. • objcopy is a translation utility that copies and converts the contents of an object file from one format (e.g. .out) another (e.g. .bin). • objdump is a disassembler but it can also display various other information about object files. It is often used to disassemble binary files (e.g.
    [Show full text]
  • Linux from Scratch Version 6.2
    Linux From Scratch Version 6.2 Gerard Beekmans Linux From Scratch: Version 6.2 by Gerard Beekmans Copyright © 1999–2006 Gerard Beekmans Copyright (c) 1999–2006, Gerard Beekmans All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: • Redistributions in any form must retain the above copyright notice, this list of conditions and the following disclaimer • Neither the name of “Linux From Scratch” nor the names of its contributors may be used to endorse or promote products derived from this material without specific prior written permission • Any material derived from Linux From Scratch must contain a reference to the “Linux From Scratch” project THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Linux From Scratch - Version 6.2 Table of Contents Preface
    [Show full text]
  • Protecting Against Unexpected System Calls
    Protecting Against Unexpected System Calls C. M. Linn, M. Rajagopalan, S. Baker, C. Collberg, S. K. Debray, J. H. Hartman Department of Computer Science University of Arizona Tucson, AZ 85721 {linnc,mohan,bakers,collberg,debray,jhh}@cs.arizona.edu Abstract writing the return address on the stack with the address of the attack code). This then causes the various actions This paper proposes a comprehensive set of techniques relating to the attack to be carried out. which limit the scope of remote code injection attacks. These techniques prevent any injected code from mak- In order to do any real damage, e.g., create a root ing system calls and thus restrict the capabilities of an shell, change permissions on a file, or access proscribed attacker. In defending against the traditional ways of data, the attack code needs to execute one or more sys- harming a system these techniques significantly raise the tem calls. Because of this, and the well-defined system bar for compromising the host system forcing the attack call interface between application code and the underly- code to take extraordinary steps that may be impractical ing operating system kernel, many researchers have fo- in the context of a remote code injection attack. There cused on the system call interface as a convenient point are two main aspects to our approach. The first is to for detecting and disrupting such attacks (see, for exam- embed semantic information into executables identify- ple, [5, 13, 17, 19, 29, 32, 35, 38]; Section 7 gives a more ing the locations of legitimate system call instructions; extensive discussion).
    [Show full text]
  • Coldfire Cross Development with GNU Toolchain and Eclipse
    ColdFire cross development with GNU Toolchain and Eclipse Version 1.0 embedded development tools Acknowledgements Ronetix GmbH Waidhausenstrasse 13/5 1140 Vienna Austria Tel: +43-720-500315 +43-1962-720 500315 Fax: +43-1- 8174 955 3464 Internet: www.ronetix.at E-Mail [email protected] Acknowledgments: ColdFire is trademark of Freescale Ltd. Windows, Win32, Windows CE are trademarks of Microsoft Corporation. Ethernet is a trademark of XEROX. All other trademarks are trademarks of their respective companies. © 2005-2008 RONETIX All rights reserved. ColdFire cross development 2 www.ronetix.at Acknowledgements Change log April 2007 - First release ColdFire cross development 3 www.ronetix.at Contents 1 INTRODUCTION ...........................................................................................................................5 2 PEEDI COLDFIRE EMULATOR INSTALLATION........................................................................6 3 TOOLSET INSTALLATION ON LINUX ........................................................................................7 4 TOOLSET INSTALLATION ON WINDOWS...............................................................................10 5 WORKING WITH ECLIPSE.........................................................................................................11 5.1 Adding a project ....................................................................................................................11 5.2 Configuring and working with the Eclipse built-in debugger ...........................................16
    [Show full text]