DOCSLIB.ORG

Strict Memory Protection for Microcontrollers

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Strict Memory Protection for Microcontrollers Master Thesis Spring 2019 Strict Memory Protection for Microcontrollers Erlend Sveen Supervisor: Jingyue Li Co-supervisor: Magnus Själander Sunday 17th February, 2019 Abstract Modern desktop systems protect processes from each other with memory protection. Microcontroller systems, which lack support for memory virtualization, typically only uses memory protection for areas that the programmer deems necessary and does not separate processes completely. As a result the application still appears monolithic and only a handful of errors may be detected. This thesis presents a set of solutions for complete separation of processes, unleash- ing the full potential of the memory protection unit embedded in modern ARM-based microcontrollers. The operating system loads multiple programs from disk into indepen- dently protected portions of memory. These programs may then be started, stopped, modified, crashed etc. without affecting other running programs. When loading pro- grams, a new allocation algorithm is used that automatically aligns the memories for use with the protection hardware. A pager is written to satisfy additional run-time demands of applications, and communication primitives for inter-process communication is made available. Since every running process is unable to get access to other running processes, not only reliability but also security is improved. An application may be split so that unsafe or error-prone code is separated from mission-critical code, allowing it to be independently restarted when an error occurs. With executable and writeable memory access rights being mutually exclusive, code injection is made harder to perform. The solution is all transparent to the programmer. All that is required is to split an application into sub-programs that operates largely independently. An added benefit of this modularity is that code may also be developed and tested as independent programs. The standard POSIX API is used as the programming interface, allowing programmers to use existing knowledge and code when designing applications. For programs that do not depend on specific hardware, development may be done and tested on a regular desktop system entirely before running it on a microcontroller. ii Acknowledgements Thanks to supervisors Jingyue Li and Magnus Själander for helping with all the formal- ities surrounding the thesis, and giving valuable feedback on the thesis work. The work presented in this thesis would not have been possible without supervision. Also thanks to the students at the Orbit satellite program, which have helped by providing an environment for the thesis in the first place. The satellite program was in need of someone to work on the software, which resulted in both the pre-thesis project and the thesis itself. Students working on the satellite software has provided valuable feedback when using the operating system, helping to improve it. iii Contents List of Figures viii List of Tables ix 1. Introduction1 1.1. Research Drivers...............................1 1.2. Solutions...................................2 1.3. Testing and Evaluation...........................3 1.4. Summary...................................3 1.5. Thesis Structure...............................3 2. Background5 2.1. Memory Protection in Desktop Processors.................5 2.1.1. Overview................................5 2.1.2. History.................................6 2.1.3. Memory Architecture As Seen By Software.............7 2.1.4. Challenges...............................8 2.2. Memory Protection in Microcontrollers.................. 10 2.2.1. History................................. 10 2.2.2. Microcontroller Memory Protection................. 10 2.2.3. Table Size and Table Entry Restrictions............... 11 2.2.4. Allocation Example.......................... 11 3. Related Work 13 3.1. State of the Art............................... 13 3.2. Shared vs Non-Shared Memory Architecture............... 15 3.2.1. Microcontroller Shared Memory Problem Example......... 17 3.2.2. MPU Setup............................... 17 3.2.3. Shortcomings.............................. 18 3.2.4. Privilege Escalation.......................... 18 3.2.5. Summary................................ 19 3.3. Research Motivation............................. 20 3.3.1. Previos Project Work......................... 21 4. Project Scope 23 4.1. Problem Summary.............................. 23 4.1.1. Memory Protection Schemes..................... 23 4.1.2. Key Difficulties............................. 23 iv Contents 4.1.3. Benefits................................. 24 4.1.4. Hardware Popularity and Generalization............... 24 4.2. Research Questions.............................. 25 4.2.1. Question 1: How may memory contents be protected during vari- ous failure modes?........................... 25 4.2.2. Question 2: How may the improvements be made without harming performance?.............................. 25 4.2.3. Summary................................ 26 4.3. Solution Roadmap.............................. 26 4.4. Architecture Overview............................ 27 5. Memory Allocation 29 5.1. Allocation Rules............................... 29 5.1.1. Allocation Rule Summary....................... 30 5.2. Metadata Structures and Multibanking.................. 31 5.3. Allocation Algorithm............................ 33 5.3.1. Algorithm Without MPU Support.................. 33 5.3.2. Algorithm With MPU Support.................... 36 6. Program Loading 41 6.1. Program Structure.............................. 41 6.2. The ELF file format............................. 42 6.3. Relocation.................................. 44 6.4. Load API Selection............................. 45 6.5. Load Procedure................................ 46 6.6. Context Switching.............................. 48 7. Adding Paging 50 7.1. Paging without Virtualization........................ 50 7.2. Adding Paging................................ 50 7.2.1. Architectural Considerations..................... 51 7.2.2. Control Structures........................... 52 7.2.3. System Calls.............................. 53 7.2.4. Page Fault Handler........................... 57 7.2.5. Table Walking Algorithm....................... 58 7.2.6. Replacement Policy.......................... 60 7.2.7. Miscellaneous Page Table Functions................. 60 8. Testing and Verification 62 8.1. Memory Allocation.............................. 62 8.1.1. Performance Considerations...................... 62 8.1.2. Functionality Testing.......................... 63 8.1.3. Test Subjects.............................. 64 8.1.4. Methodology.............................. 64 v Contents 8.1.5. Expected Results............................ 65 8.1.6. Test Execution............................. 66 8.1.7. Discussion................................ 66 8.1.8. Conclusion............................... 68 8.2. Program Loading............................... 68 8.2.1. Performance Considerations...................... 68 8.2.2. Test Subjects.............................. 69 8.2.3. Methodology.............................. 69 8.2.4. Expected Results............................ 71 8.2.5. Test Execution............................. 71 8.2.6. Discussion................................ 72 8.2.7. Conclusion............................... 72 8.3. Paging and Memory Protection....................... 73 8.3.1. Performance Considerations...................... 73 8.3.2. Test Subjects.............................. 74 8.3.3. Methodology.............................. 74 8.3.4. Expected Results and Test Execution................ 76 8.3.5. Discussion................................ 78 8.3.6. Conclusion............................... 79 8.4. Small System Use Case Example...................... 79 8.4.1. Methodology.............................. 79 8.4.2. Test Execution............................. 80 8.4.3. Results................................. 81 8.4.4. Discussion and Conclusion....................... 84 8.5. Memory Copy Speed Test.......................... 85 8.5.1. Methodology.............................. 85 8.5.2. Expected Results............................ 85 8.5.3. Test Execution............................. 86 8.5.4. Discussion and Conclusion....................... 86 8.6. Added Context Switching Overhead.................... 86 8.7. System Call Interface Overhead....................... 87 8.7.1. System Calls.............................. 87 8.7.2. Benefits and Limitations........................ 88 8.7.3. Performance Study........................... 88 8.7.4. Summary................................ 92 9. Discussion 94 9.1. Solution Discussion.............................. 94 9.1.1. Memory Allocation........................... 94 9.1.2. Program Loading............................ 94 9.1.3. Paging Mechanism........................... 95 9.2. Research Question Discussion........................ 95 9.2.1. Research Question 1.......................... 95 9.2.2. Research Question 2.......................... 96 vi Contents 10.Conclusion 98 11.Future Work 99 11.1. Memory Allocation Improvements..................... 99 11.2. Paging Improvements............................ 99 11.3. Memory Sharing Schemes.......................... 99 11.4. Improved Standards Compliance...................... 100 11.5. Hardware Error Handling.......................... 100 11.6. Syscall Data Access Checking........................ 100 11.7. Moving Data Back Into Flash........................ 100 11.8. Test Procedures............................... 101 11.9. Build Automation.............................
Load more

Recommended publications
  • Memory Deduplication: An
    1 Memory Deduplication: An Effective Approach to Improve the Memory System Yuhui Deng1,2, Xinyu Huang1, Liangshan Song1, Yongtao Zhou1, Frank Wang3 1Department of Computer Science, Jinan University, Guangzhou, 510632, P. R. China {[email protected]；[email protected]；[email protected]；[email protected]} 2Key Laboratory of Computer System and Architecture, Chinese Academy of Sciences Beijing, 100190, PR China 3 School of Computing，University of Kent, CT27NF, UK [email protected] Abstract— Programs now have more aggressive demands of memory to hold their data than before. This paper analyzes the characteristics of memory data by using seven real memory traces. It observes that there are a large volume of memory pages with identical contents contained in the traces. Furthermore, the unique memory content accessed are much less than the unique memory address accessed. This is incurred by the traditional address-based cache replacement algorithms that replace memory pages by checking the addresses rather than the contents of those pages, thus resulting in many identical memory contents with different addresses stored in the memory. For example, in the same file system, opening two identical files stored in different directories, or opening two similar files that share a certain amount of contents in the same directory, will result in identical data blocks stored in the cache due to the traditional address-based cache replacement algorithms. Based on the observations, this paper evaluates memory compression and memory deduplication. As expected, memory deduplication greatly outperforms memory compression. For example, the best deduplication ratio is 4.6 times higher than the best compression ratio.
    [Show full text]
  • Memory Protection at Option
    Memory Protection at Option Application-Tailored Memory Safety in Safety-Critical Embedded Systems – Speicherschutz nach Wahl Auf die Anwendung zugeschnittene Speichersicherheit in sicherheitskritischen eingebetteten Systemen Der Technischen Fakultät der Universität Erlangen-Nürnberg zur Erlangung des Grades Doktor-Ingenieur vorgelegt von Michael Stilkerich Erlangen — 2012 Als Dissertation genehmigt von der Technischen Fakultät Universität Erlangen-Nürnberg Tag der Einreichung: 09.07.2012 Tag der Promotion: 30.11.2012 Dekan: Prof. Dr.-Ing. Marion Merklein Berichterstatter: Prof. Dr.-Ing. Wolfgang Schröder-Preikschat Prof. Dr. Michael Philippsen Abstract With the increasing capabilities and resources available on microcontrollers, there is a trend in the embedded industry to integrate multiple software functions on a single system to save cost, size, weight, and power. The integration raises new requirements, thereunder the need for spatial isolation, which is commonly established by using a memory protection unit (MPU) that can constrain access to the physical address space to a fixed set of address regions. MPU-based protection is limited in terms of available hardware, flexibility, granularity and ease of use. Software-based memory protection can provide an alternative or complement MPU-based protection, but has found little attention in the embedded domain. In this thesis, I evaluate qualitative and quantitative advantages and limitations of MPU-based memory protection and software-based protection based on a multi-JVM. I developed a framework composed of the AUTOSAR OS-like operating system CiAO and KESO, a Java implementation for deeply embedded systems. The framework allows choosing from no memory protection, MPU-based protection, software-based protection, and a combination of the two.
    [Show full text]
  • Murciano Soto, Joan; Rexachs Del Rosario, Dolores Isabel, Dir
    This is the published version of the bachelor thesis: Murciano Soto, Joan; Rexachs del Rosario, Dolores Isabel, dir. Anàlisi de presta- cions de sistemes d’emmagatzematge per IA. 2021. (958 Enginyeria Informàtica) This version is available at https://ddd.uab.cat/record/248510 under the terms of the license TFG EN ENGINYERIA INFORMATICA,` ESCOLA D’ENGINYERIA (EE), UNIVERSITAT AUTONOMA` DE BARCELONA (UAB) Analisi` de prestacions de sistemes d’emmagatzematge per IA Joan Murciano Soto Resum– Els programes d’Intel·ligencia` Artificial (IA) son´ programes que fan moltes lectures de fitxers per la seva naturalesa. Aquestes lectures requereixen moltes crides a dispositius d’emmagatzematge, i aquestes poden comportar endarreriments en l’execucio´ del programa. L’ample de banda per transportar dades de disc a memoria` o viceversa pot esdevenir en un bottleneck, incrementant el temps d’execucio.´ De manera que es´ important saber detectar en aquest tipus de programes, si les entrades/sortides (E/S) del nostre sistema se saturen. En aquest treball s’estudien diferents programes amb altes quantitats de lectures a disc. S’utilitzen eines de monitoritzacio,´ les quals ens informen amb metriques` relacionades amb E/S a disc. Tambe´ veiem l’impacte que te´ el swap, el qual tambe´ provoca un increment d’operacions d’E/S. Aquest document preten´ mostrar la metodologia utilitzada per a realitzar l’analisi` descrivint les eines i els resultats obtinguts amb l’objectiu de que serveixi de guia per a entendre el comportament i l’efecte de les E/S i el swap. Paraules clau– E/S, swap, IA, monitoritzacio.´ Abstract– Artificial Intelligence (IA) programs make many file readings by nature.
    [Show full text]
  • Using an MPU to Enforce Spatial Separation
    HighIntegritySystems Using an MPU to Enforce Spatial Separation Issue 1.3 - November 26, 2020 Copyright WITTENSTEIN aerospace & simulation ltd date as document, all rights reserved. WITTENSTEIN high integrity systems v Americas: +1 408 625 4712 ROTW: +44 1275 395 600 Email: [email protected] Web: www.highintegritysystems.com HighIntegritySystems Contents Contents..........................................................................................................................................2 List Of Figures.................................................................................................................................3 List Of Notation...............................................................................................................................3 CHAPTER 1 Introduction.....................................................................................................4 1.1 Introduction..............................................................................................................................4 1.2 Use Case - An Embedded System...........................................................................................5 CHAPTER 2 System Architecture and its Effect on Spatial Separation......................6 2.1 Spatial Separation with a Multi-Processor System....................................................................6 2.2 Spatial Separation with a Multi-Core System............................................................................6 2.3 Spatial Separation
    [Show full text]
  • Hiding Process Memory Via Anti-Forensic Techniques
    DIGITAL FORENSIC RESEARCH CONFERENCE Hiding Process Memory via Anti-Forensic Techniques By: Frank Block (Friedrich-Alexander Universität Erlangen-Nürnberg (FAU) and ERNW Research GmbH) and Ralph Palutke (Friedrich-Alexander Universität Erlangen-Nürnberg) From the proceedings of The Digital Forensic Research Conference DFRWS USA 2020 July 20 - 24, 2020 DFRWS is dedicated to the sharing of knowledge and ideas about digital forensics research. Ever since it organized the first open workshop devoted to digital forensics in 2001, DFRWS continues to bring academics and practitioners together in an informal environment. As a non-profit, volunteer organization, DFRWS sponsors technical working groups, annual conferences and challenges to help drive the direction of research and development. https://dfrws.org Forensic Science International: Digital Investigation 33 (2020) 301012 Contents lists available at ScienceDirect Forensic Science International: Digital Investigation journal homepage: www.elsevier.com/locate/fsidi DFRWS 2020 USA d Proceedings of the Twentieth Annual DFRWS USA Hiding Process Memory Via Anti-Forensic Techniques Ralph Palutke a, **, 1, Frank Block a, b, *, 1, Patrick Reichenberger a, Dominik Stripeika a a Friedrich-Alexander Universitat€ Erlangen-Nürnberg (FAU), Germany b ERNW Research GmbH, Heidelberg, Germany article info abstract Article history: Nowadays, security practitioners typically use memory acquisition or live forensics to detect and analyze sophisticated malware samples. Subsequently, malware authors began to incorporate anti-forensic techniques that subvert the analysis process by hiding malicious memory areas. Those techniques Keywords: typically modify characteristics, such as access permissions, or place malicious data near legitimate one, Memory subversion in order to prevent the memory from being identified by analysis tools while still remaining accessible.
    [Show full text]
  • Memory Protection in Embedded Systems Lanfranco Lopriore Dipartimento Di Ingegneria Dell’Informazione, Università Di Pisa, Via G
    CORE Metadata, citation and similar papers at core.ac.uk Provided by Archivio della Ricerca - Università di Pisa Memory protection in embedded systems Lanfranco Lopriore Dipartimento di Ingegneria dell’Informazione, Università di Pisa, via G. Caruso 16, 56126 Pisa, Italy E-mail: [email protected] Abstract — With reference to an embedded system featuring no support for memory manage- ment, we present a model of a protection system based on passwords and keys. At the hardware level, our model takes advantage of a memory protection unit (MPU) interposed between the processor and the complex of the main memory and the input-output devices. The MPU sup- ports both concepts of a protection context and a protection domain. A protection context is a set of access rights for the memory pages; a protection domain is a set of one or more protection contexts. Passwords are associated with protection domains. A process that holds a key match- ing a given password can take advantage of this key to activate the corresponding domain. A small set of protection primitives makes it possible to modify the composition of the domains in a strictly controlled fashion. The proposed protection model is evaluated from a number of salient viewpoints, which include key distribution, review and revocation, the memory requirements for storage of the information concerning protection, and the time necessary for key validation. Keywords: access right; embedded system; protection; revocation. 1. INTRODUCTION We shall refer to a typical embedded system architecture featuring a microprocessor inter- facing both volatile and non-volatile primary memory devices, as well as a variety of input/out- put devices including sensors and actuators.
    [Show full text]
  • Virtual Memory - Paging
    Virtual memory - Paging Johan Montelius KTH 2020 1 / 32 The process code heap (.text) data stack kernel 0x00000000 0xC0000000 0xffffffff Memory layout for a 32-bit Linux process 2 / 32 Segments - a could be solution Processes in virtual space Address translation by MMU (base and bounds) Physical memory 3 / 32 one problem Physical memory External fragmentation: free areas of free space that is hard to utilize. Solution: allocate larger segments ... internal fragmentation. 4 / 32 another problem virtual space used code We’re reserving physical memory that is not used. physical memory not used? 5 / 32 Let’s try again It’s easier to handle fixed size memory blocks. Can we map a process virtual space to a set of equal size blocks? An address is interpreted as a virtual page number (VPN) and an offset. 6 / 32 Remember the segmented MMU MMU exception no virtual addr. offset yes // < within bounds index + physical address segment table 7 / 32 The paging MMU MMU exception virtual addr. offset // VPN available ? + physical address page table 8 / 32 the MMU exception exception virtual address within bounds page available Segmentation Paging linear address physical address 9 / 32 a note on the x86 architecture The x86-32 architecture supports both segmentation and paging. A virtual address is translated to a linear address using a segmentation table. The linear address is then translated to a physical address by paging. Linux and Windows do not use use segmentation to separate code, data nor stack. The x86-64 (the 64-bit version of the x86 architecture) has dropped many features for segmentation.
    [Show full text]
  • Chapter 4 Memory Management and Virtual Memory Asst.Prof.Dr
    Chapter 4 Memory management and Virtual Memory Asst.Prof.Dr. Supakit Nootyaskool IT-KMITL Object • To discuss the principle of memory management. • To understand the reason that memory partitions are importance for system organization. • To describe the concept of Paging and Segmentation. 4.1 Difference in main memory in the system • The uniprogramming system (example in DOS) allows only a program to be present in memory at a time. All resources are provided to a program at a time. Example in a memory has a program and an OS running 1) Operating system (on Kernel space) 2) A running program (on User space) • The multiprogramming system is difference from the mentioned above by allowing programs to be present in memory at a time. All resource must be organize and sharing to programs. Example by two programs are in the memory . 1) Operating system (on Kernel space) 2) Running programs (on User space + running) 3) Programs are waiting signals to execute in CPU (on User space). The multiprogramming system uses memory management to organize location to the programs 4.2 Memory management terms Frame Page Segment 4.2 Memory management terms Frame Page A fixed-lengthSegment block of main memory. 4.2 Memory management terms Frame Page A fixed-length block of data that resides in secondary memory. A page of data may temporarily beSegment copied into a frame of main memory. A variable-lengthMemory management block of data that residesterms in secondary memory. A segment may temporarily be copied into an available region of main memory or the segment may be divided into pages which can be individuallyFrame copied into mainPage memory.
    [Show full text]
  • Module 4: Memory Management the Von Neumann Principle for the Design and Operation of Computers Requires That a Program Has to Be Primary Memory Resident to Execute
    Operating Systems/Memory management Lecture Notes Module 4: Memory Management The von Neumann principle for the design and operation of computers requires that a program has to be primary memory resident to execute. Also, a user requires to revisit his programs often during its evolution. However, due to the fact that primary memory is volatile, a user needs to store his program in some non-volatile store. All computers provide a non-volatile secondary memory available as an online storage. Programs and files may be disk resident and downloaded whenever their execution is required. Therefore, some form of memory management is needed at both primary and secondary memory levels. Secondary memory may store program scripts, executable process images and data files. It may store applications, as well as, system programs. In fact, a good part of all OS, the system programs which provide services (the utilities for instance) are stored in the secondary memory. These are requisitioned as needed. The main motivation for management of main memory comes from the support for multi- programming. Several executables processes reside in main memory at any given time. In other words, there are several programs using the main memory as their address space. Also, programs move into, and out of, the main memory as they terminate, or get suspended for some IO, or new executables are required to be loaded in main memory. So, the OS has to have some strategy for main memory management. In this chapter we shall discuss the management issues and strategies for both main memory and secondary memory.
    [Show full text]
  • OS Paging and Buffer Management
    OS Paging and Bu↵er Management Using the Virtual-Memory Paging Mechanism to Balance Hot/Cold Data in Memory and HDD Jana Lampe TU Kaiserslautern LGIS Seminar SS 2014 Optimizing Data Management on New Hardware 1 Introduction 1.1 Motivation Traditional database systems follow the design principle that all data is stored on hard disk where records are accessible via indexing structures and loaded into main-memory as soon as they are requested. Since memory prices have dropped significantly during the last three decades, new database systems have been designed that allow faster access to the data by storing all data inside the main-memory, e.g. H-Store [9]. Notwithstanding the above, also durable storage technologies have made con- siderable progress towards larger capacity, more input/output operations per second as well as reduced cost per storage unit at the same time. Solid-state drives (SSDs) have entered the market and, using the non-volatile NAND-flash technology, convince by their reading and writing speed, although they are still about ten times more expensive than common HDDs. Another promising tech- nology is phase-change memory (PCM), but it is still in research state. Now one could ask, why all the data is stored in memory. If there are records that are not accessed that frequently, would it not be cheaper to store them on a secondary storage device such as HDD or SSD? Moreover, energy consump- tion would decrease and more space would be available to temporarily store intermediate results thereby accelerating query processing. To answer this question, Gray and Putzolu proposed in [5] the 5-minute rule, which says, that a record should be kept in memory if it has accessed at least every 5 minutes (the break-even interval).
    [Show full text]
  • Chapter 3 Protected-Mode Memory Management
    CHAPTER 3 PROTECTED-MODE MEMORY MANAGEMENT This chapter describes the Intel 64 and IA-32 architecture’s protected-mode memory management facilities, including the physical memory requirements, segmentation mechanism, and paging mechanism. See also: Chapter 5, “Protection” (for a description of the processor’s protection mechanism) and Chapter 20, “8086 Emulation” (for a description of memory addressing protection in real-address and virtual-8086 modes). 3.1 MEMORY MANAGEMENT OVERVIEW The memory management facilities of the IA-32 architecture are divided into two parts: segmentation and paging. Segmentation provides a mechanism of isolating individual code, data, and stack modules so that multiple programs (or tasks) can run on the same processor without interfering with one another. Paging provides a mech- anism for implementing a conventional demand-paged, virtual-memory system where sections of a program’s execution environment are mapped into physical memory as needed. Paging can also be used to provide isolation between multiple tasks. When operating in protected mode, some form of segmentation must be used. There is no mode bit to disable segmentation. The use of paging, however, is optional. These two mechanisms (segmentation and paging) can be configured to support simple single-program (or single- task) systems, multitasking systems, or multiple-processor systems that used shared memory. As shown in Figure 3-1, segmentation provides a mechanism for dividing the processor’s addressable memory space (called the linear address space) into smaller protected address spaces called segments. Segments can be used to hold the code, data, and stack for a program or to hold system data structures (such as a TSS or LDT).
    [Show full text]
  • Introduction to Uclinux
    Introduction to uClinux V M Introduction to uClinux Michael Opdenacker Free Electrons http://free-electrons.com Created with OpenOffice.org 2.x Thanks to Nicolas Rougier (Copyright 2003, http://webloria.loria.fr/~rougier/) for the Tux image Introduction to uClinux © Copyright 2004-2007, Free Electrons Creative Commons Attribution-ShareAlike 2.5 license http://free-electrons.com Nov 20, 2007 1 Rights to copy Attribution ± ShareAlike 2.5 © Copyright 2004-2007 You are free Free Electrons to copy, distribute, display, and perform the work [email protected] to make derivative works to make commercial use of the work Document sources, updates and translations: Under the following conditions http://free-electrons.com/articles/uclinux Attribution. You must give the original author credit. Corrections, suggestions, contributions and Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license translations are welcome! identical to this one. For any reuse or distribution, you must make clear to others the license terms of this work. Any of these conditions can be waived if you get permission from the copyright holder. Your fair use and other rights are in no way affected by the above. License text: http://creativecommons.org/licenses/by-sa/2.5/legalcode Introduction to uClinux © Copyright 2004-2007, Free Electrons Creative Commons Attribution-ShareAlike 2.5 license http://free-electrons.com Nov 20, 2007 2 Best viewed with... This document is best viewed with a recent PDF reader or with OpenOffice.org itself! Take advantage of internal or external hyperlinks. So, don't hesitate to click on them! Find pages quickly thanks to automatic search.
    [Show full text]