0628731-Wetzels Msc Thesis Final

Total Page:16

File Type:pdf, Size:1020Kb

0628731-Wetzels Msc Thesis Final Eindhoven University of Technology MASTER Kintsugi identifying & addressing challenges in embedded binary security Wetzels, A.L.G.M. Award date: 2017 Link to publication Disclaimer This document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Student theses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the document as presented in the repository. The required complexity or quality of research of student theses may vary by program, and the required minimum study period may vary in duration. General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain KINTSUGI Identifying & addressing challenges in embedded binary security jos wetzels Supervisors: Prof. dr. Sandro Etalle Ali Abbasi, MSc. Department of Mathematics and Computer Science Eindhoven University of Technology (TU/e) June 2017 Jos Wetzels: Kintsugi, Identifying & addressing challenges in embed- ded binary security, © June 2017 To my family Kintsugi ("golden joinery"), is the Japanese art of repairing broken pottery with lacquer dusted or mixed with powdered gold, silver, or platinum. As a philosophy, it treats breakage and repair as part of the history of an object, rather than something to disguise. —[254] ABSTRACT Embedded systems are found everywhere from consumer electron- ics to critical infrastructure. And with the growth of the Internet of Things (IoT), these systems are increasingly interconnected. As a re- sult, embedded security is an area of growing concern. Yet a stream of offensive security research, as well as real-world incidents, contin- ues to demonstrate how vulnerable embedded systems actually are. This thesis focuses on binary security, the exploitation and miti- gation of memory corruption vulnerabilities. We look at the state of embedded binary security by means of quantitative and qualitative analysis and identify several gap areas and show embedded binary security to lag behind the general purpose world significantly. We then describe the challenges and limitations faced by embedded exploit mitigations and identify a clear open problem area that war- rants attention: deeply embedded systems. Next, we outline the cri- teria for a deeply embedded exploit mitigation baseline. Finally, as a first step to addressing this problem area, we designed, implemented and evaluated µArmor : an exploit mitigation baseline for deeply em- bedded systems. v When you want to know how things really work, study them when they’re coming apart. — William Gibson ACKNOWLEDGEMENTS First of all, I would like to thank my supervisors, Prof. dr. Sandro Etalle and Ali Abbasi, MSc., for their assistance and support through- out the process of researching and writing this thesis. Sandro’s guid- ance helped me structure the rather voluminous body of research produced by this thesis while Ali’s continuous feedback and brain- storming helped this work achieve its current depth. Secondly, I am grateful to my family, without whom none of this would have been possible, for their unconditional love and support. Finally, I am thankful to my friends for their moral support and to the many people from the information security field and the outer reaches of the internet who, over the years, have continued to inspire me. Jos Wetzels Eindhoven University of Technology (TU/e) June 2017 vii CONTENTS i embedded binary security1 1 introduction3 1.1 Problem Statement . 3 1.2 Research Goal & Questions . 4 1.3 Contributions . 4 1.4 Outline . 5 2 background7 2.1 Basic Embedded Concepts . 7 2.2 Embedded Security Threat Landscape . 11 2.3 Embedded Patching Issues . 14 2.4 Memory Corruption Vulnerabilities . 17 2.4.1 Language Safety . 18 2.4.2 ’Weird Machines’ & Exploitation . 19 2.5 Exploit Mitigations . 20 3 embedded exploit mitigation baseline 25 3.1 Establishing a Minimum Baseline . 25 3.2 Baseline Mitigations In-Depth . 26 3.2.1 Executable Space Protection (ESP) . 26 3.2.2 Address Space Layout Randomization (ASLR) . 30 3.2.3 Stack Canaries . 34 3.3 Exploit Mitigation Dependencies . 36 3.3.1 ESP Dependencies . 36 3.3.2 ASLR Dependencies . 38 3.3.3 Stack Canary Dependencies . 39 ii analysis of embedded exploit mitigations 41 4 quantitative analysis 43 4.1 Embedded OS mitigation & dependency support . 43 4.2 Embedded hardware feature support . 44 4.3 Conclusions . 48 5 qualitative analysis 53 5.1 QNX ............................. 53 5.1.1 Security History . 55 5.1.2 QNX ESP . 55 5.1.3 QNX ASLR . 56 5.1.4 QNX Stack Canaries . 64 5.1.5 QNX OS CSPRNG . 67 5.2 RedactedOS . 73 5.2.1 RedactedOS OS CSPRNG . 74 5.3 Zephyr . 75 5.3.1 Zephyr Stack Canaries . 77 5.4 Conclusions . 80 ix x contents 6 embedded challenges 83 6.1 Development Practices & Cost Sensitivity . 83 6.2 Resource Constraints . 84 6.3 Safety, Reliability & Real-Time Requirements . 85 6.4 Hardware & OS Limitations . 87 6.4.1 MPUs, MMUs & Hardware ESP . 87 6.4.2 Virtual Memory . 88 6.4.3 Advanced Processor Features . 88 6.4.4 OS CSPRNGs . 89 6.5 Open Problems . 91 6.5.1 Deeply Embedded Exploit Mitigation Criteria . 92 6.5.2 OS CSPRNG Design for Deeply Embedded Sys- tems . 93 iii µarmor design, implementation & evaluation 95 7 µarmor design 97 7.1 Representative Platform . 97 7.2 Attacker Model . 98 7.3 High-Level Design . 98 7.4 µESP Design . 99 7.5 µScramble Design . 101 7.6 µSSP Design . 105 7.7 µRNG Design . 107 8 µarmor implementation 113 8.1 µESP Implementation . 113 8.2 µScramble Implementation . 116 8.3 µSSP Implementation . 118 8.4 µRNG Implementation . 119 9 µarmor evaluation & limitations 121 9.1 Real-Time Compatibility & Safety Issues . 121 9.2 Overhead Evaluation . 121 9.3 Security Evaluation . 129 9.3.1 µESP Security . 129 9.3.2 µScramble Security . 129 9.3.3 µSSP Security . 133 9.3.4 µRNG Security . 134 9.4 Limitations . 136 iv conclusion 137 10 related work 139 10.1 Embedded Mitigation Support & Quality . 139 10.2 Embedded Mitigation Design . 139 11 discussion, conclusions & future work 145 11.1 Discussion . 145 11.2 Conclusions . 147 11.3 Future Work . 148 contents xi v appendix 151 a supplementary data 153 bibliography 165 LISTOFFIGURES Figure 1 Library-Based Operating System Example . 11 Figure 2 Memory corruption exploitation flowchart demon- strating mitigations at different stages based on [390]...................... 23 Figure 3 x86 Page Table Entry (PTE) with NX bit . 29 Figure 4 Address Space Layout Randomization (ASLR) [22] 31 Figure 5 Stack Canary Example . 34 Figure 6 ESP Dependencies . 37 Figure 7 ASLR Dependencies . 38 Figure 8 Stack Canary Dependencies . 39 Figure 9 Embedded OS Exploit Mitigation Support . 44 Figure 10 Embedded OS exploit mitigation dependency support . 47 Figure 11 Core Family dependency support . 48 Figure 12 QNX Architecture [233]............. 54 Figure 13 QNX Private Virtual Memory [220]....... 54 Figure 14 QNX Memory Layout (x86)........... 57 Figure 15 QNX ASLR Memory Object Graph . 60 Figure 16 Simplified QNX Yarrow 6.6 Design . 67 Figure 17 QNX Yarrow Boottime Entropy Collection . 70 Figure 18 QNX Yarrow Restart Boottime Entropy Visual- ization [43]..................... 71 Figure 19 QNX Yarrow Runtime Entropy Collection . 73 Figure 20 RedactedOS PRNG Known Seed Attack . 76 Figure 21 Zephyr Architecture [186]............ 77 Figure 22 µArmor High-Level Design as a subgraph of Figure 2 ....................... 99 Figure 23 µESP Design . 100 Figure 24 µArmor Firmware Distribution Process . 101 Figure 25 µScramble Firmware Diversification . 102 Figure 26 µSSP Design . 105 Figure 27 µRNG Design . 108 Figure 28 µRNG Reseed Control . 108 Figure 29 µScramble LLVM Implementation . 117 xii LISTOFTABLES Table 1 Embedded OS exploit mitigation adoption . 45 Table 2 Embedded OS exploit mitigation dependency support . 46 Table 3 Core Family dependency support . 49 Table 4 Core Family dependency support . 50 Table 5 Core Family dependency support . 51 Table 6 QNX Hardware ESP Support . 56 Table 7 QNX Address Boundaries . 57 Table 8 QNX Default Libc Load Addresses . 58 Table 9 QNX ASLR Memory Object Randomization Sup- port . 59 Table 10 QNX ClockCycles Implementations . 61 Table 11 QNX ASLR Userspace Memory Object Min En- tropy . 62 Table 12 QNX Stack Canary Min Entropy . 66 Table 13 Qualitative Exploit Mitigation Analysis Overview 82 Table 14 µESP Memory Permission Policies . 114 Table 15 TI LM3S6965 MPU µESP Settings, execute-from- flash ......................... 115 Table 16 TI LM3S6965 MPU µESP Settings, execute-from- RAM ........................ 115 Table 17 µESP Overhead Evaluation . 123 Table 18 µSSP Overhead Evaluation . 124 Table 19 µRNG Overhead Evaluation . 124 Table 20 µScramble Overhead wrt. Application . 125 Table 21 µScramble Overhead wrt. Application . 126 Table 22 µScramble Overhead wrt. Resources . 127 Table 23 µScramble Overhead wrt. Resources . 128 Table 24 µRNG Resource Consumption Comparison . 129 Table 25 µScramble Coverage Analysis . 131 Table 26 µScramble Coverage Analysis . 132 Table 27 TRNG support among Zephyr 1.8 supported boards . 154 Table 28 Popular Embedded Development Board Resources155 Table 29 Benchmarks & Applications selected from TACLeBench Suite [357]..................... 156 Table 30 Benchmarks & Applications selected from TACLeBench Suite [357]..................... 157 xiii LISTINGS Listing 1 µESP MPU Setup Pseudo-Code . 114 Listing 2 QNX vmm_mmap Routine . 158 Listing 3 QNX map_create Routine . 158 Listing 4 QNX map_find_va Routine . 159 Listing 5 QNX stack_randomize Routine . 160 Listing 6 QNX Stack Canary Failure Handler (User-Space)160 Listing 7 QNX Stack Canary Generation Handler .
Recommended publications
  • Porting Darwin to the MV88F6281 Arming the Snowleopard
    Porting Darwin to the MV88F6281 ARMing the SnowLeopard. Tristan Schaap 1269011 Apple Inc. Platform Technologies Group Delft University of Technology Dept. of Computer Science Committee: Ir. B.R. Sodoyer Dr. K. van der Meer Preface! 3 Introduction! 4 Summary! 5 Building a new platform! 6 Booting iBoot! 7 Building the kernelcache! 8 Booting the kernel! 10 THUMBs down! 16 Conclusion! 18 Future Work! 19 Glossary! 20 References! 21 Appendix A! 22 Appendix B! 23 Skills! 23 Process! 26 Reflection! 27 Appendix C! 28 Plan of Approach! 28 2 Preface Due to innovative nature of this project, I have had to limit myself in the detail in which I describe my work. This means that this report will be lacking in such things as product specific- and classified information. I would like to thank a few people who made it possible for me to successfully complete my internship at the Platform Technologies Group at Apple. First off, the people who made this internship possible, John Kelley, Ben Byer and my manager John Wright. Mike Smith, Tom Duffy and Anthony Yvanovich for helping me through the rough patches of this project. And the entirety of Core OS for making my stay an unforgettable experience. 3 Introduction About the Platform Technologies Group As it was described by a manager: “We do the plumbing, if we do our jobs right, you never see it.”. The Platform Technologies Group, a subdivision of the Core OS department, works on the embedded platforms that Apple maintains. Here, platforms are brought up and the embedded kernel and lower level support for the platforms is maintained.
    [Show full text]
  • M Morpho of Sm Ologica Mall-Sp S Al, Phy Pore a Solana Siolog
    Vol. 8(37), pp. 3422-3434, 10 September, 2014 DOI: 10.5897/AJMR2014.6802 Article Number: B5A96EE47927 ISSN 1996-0808 African Journal of Microbiology Research Copyright © 2014 Author(s) retain the copyrighht of this article http://www.academicjournals.org/AJMR Full Length Research Paper Morphological, physiological and pathogenic variability of small-spore Alternaria sp. causinng leaf blight of Solanaceous plants in Allgeria BESSADAT Nabahat1*, SIMONEAU Philippe2, BENICHOU Soumaya1, SETTI Benali3, Kihal Mabrouk1 and HENNI Djamel Eddine1 1Laboratoire de Microbiologie Appliquée, Université d’Oran Es-Senia, BP15224 El M’naouer 31000 Oran, Algeria. 2SFR QUASAV 4207, UMR 1345 IRHS, Université d’Angers, 2 boulevard Lavoisier, France. 3Institut des Sciences Agronomiques, Université de Chlef, Algeria. Received 25 February, 2014; Acceppted 9 June, 2014 Due to premature defoliation, early blight epidemics can cause major yield losses. Large-spore Alternaria species such as A. solani and A. tomatophila have long been recognized as important pathogens responsible for such blight disease in the famiily Solanaceeae and thus represent a serious risk for crop production. Small-spore Alternaria species have also been frequently isolated from plant samples with typical blight symptoms but their incidence as primary pathogens is often controversial. In order to study the diversity of small-spore Alternaria species, 32 isolates were selected from a larger collection of 130 isolates from infected leaves, fruits and sttems of tomato from various growing regions of North-West Algeria. Morphological characterization under standard conditions annd polymerase chain reaction (PCR) analyses using specific primers to amplify a part of the ITS regions and the 5.8S gene were conducted to confirm their identification as members of the altternata section.
    [Show full text]
  • Deciding Memory Safety for Single-Pass Heap-Manipulating Programs
    Deciding Memory Safety for Single-Pass Heap-Manipulating Programs UMANG MATHUR, University of Illinois, Urbana-Champaign, USA ADITHYA MURALI, University of Illinois, Urbana-Champaign, USA PAUL KROGMEIER, University of Illinois, Urbana-Champaign, USA P. MADHUSUDAN, University of Illinois, Urbana-Champaign, USA MAHESH VISWANATHAN, University of Illinois, Urbana-Champaign, USA We investigate the decidability of automatic program verification for programs that manipulate heaps, andin particular, decision procedures for proving memory safety for them. We extend recent work that identified a decidable subclass of uninterpreted programs to a class of alias-aware programs that can update maps. We 35 apply this theory to develop verification algorithms for memory safetyÐ determining if a heap-manipulating program that allocates and frees memory locations and manipulates heap pointers does not dereference an unallocated memory location. We show that this problem is decidable when the initial allocated heap forms a forest data-structure and when programs are streaming-coherent, which intuitively restricts programs to make a single pass over a data-structure. Our experimental evaluation on a set of library routines that manipulate forest data-structures shows that common single-pass algorithms on data-structures often fall in the decidable class, and that our decision procedure is efficient in verifying them. CCS Concepts: • Theory of computation → Logic and verification; Automated reasoning. Additional Key Words and Phrases: Memory Safety, Program Verification, Aliasing, Decidability, Uninterpreted Programs, Streaming-Coherence, Forest Data-Structures ACM Reference Format: Umang Mathur, Adithya Murali, Paul Krogmeier, P. Madhusudan, and Mahesh Viswanathan. 2020. Deciding Memory Safety for Single-Pass Heap-Manipulating Programs. Proc. ACM Program.
    [Show full text]
  • SOLUTIONS Products &
    Top Brands • Quality Equipment • Total Solutions Products & Splicing Equipment SOLUTIONS Test Equipment Consumables & Tools Cable Connectivity Cable Assemblies Outside Plant Cable Management Active Components Premise Security 2016–2017 Product Catalog Part of the Group Company Profile ince its formation in 1995, FiberOptic.com has become the number one on-line provider of fiber optic products, Straining and rental solutions. The Fiber Optic Marketplace, LLC began as an on-line business–to–business portal for the fiber optic community, and has expanded its business both domestically and internationally. The company’s customers include Fortune 500 companies, telecommunications providers, the military, installers, contractors and educational institutions from across the globe. In addition to efficient product distribution, FiberOptic.com offers classroom, on– site and on-line training courses for individuals interested in fiber optic theory and installation. Experienced fiber optics instructors conduct training classes throughout the year at our location in Breinigsville, Pennsylvania. On-site training programs are also available for groups of six students or more. The company also offers equipment rentals including fusion splicers and OTDRs. The Fiber Optic Marketplace, LLC is committed to maintaining excellent customer service and client relations. As we continue into the future, the company will continue to offer expertise in the field of fiber optics by providing customized solutions for our customers’ project requirements. We will continue to uphold our status as the number one on-line provider of fiber optic products, training and rental solutions. SHIPPING OPTIONS • Same day shipping for in-stock products ordered before 3PM EST. • You choose your shipping method: UPS, FedEx, DHL or U.S.
    [Show full text]
  • Linux on the Road
    Linux on the Road Linux with Laptops, Notebooks, PDAs, Mobile Phones and Other Portable Devices Werner Heuser <wehe[AT]tuxmobil.org> Linux Mobile Edition Edition Version 3.22 TuxMobil Berlin Copyright © 2000-2011 Werner Heuser 2011-12-12 Revision History Revision 3.22 2011-12-12 Revised by: wh The address of the opensuse-mobile mailing list has been added, a section power management for graphics cards has been added, a short description of Intel's LinuxPowerTop project has been added, all references to Suspend2 have been changed to TuxOnIce, links to OpenSync and Funambol syncronization packages have been added, some notes about SSDs have been added, many URLs have been checked and some minor improvements have been made. Revision 3.21 2005-11-14 Revised by: wh Some more typos have been fixed. Revision 3.20 2005-11-14 Revised by: wh Some typos have been fixed. Revision 3.19 2005-11-14 Revised by: wh A link to keytouch has been added, minor changes have been made. Revision 3.18 2005-10-10 Revised by: wh Some URLs have been updated, spelling has been corrected, minor changes have been made. Revision 3.17.1 2005-09-28 Revised by: sh A technical and a language review have been performed by Sebastian Henschel. Numerous bugs have been fixed and many URLs have been updated. Revision 3.17 2005-08-28 Revised by: wh Some more tools added to external monitor/projector section, link to Zaurus Development with Damn Small Linux added to cross-compile section, some additions about acoustic management for hard disks added, references to X.org added to X11 sections, link to laptop-mode-tools added, some URLs updated, spelling cleaned, minor changes.
    [Show full text]
  • UG1046 Ultrafast Embedded Design Methodology Guide
    UltraFast Embedded Design Methodology Guide UG1046 (v2.3) April 20, 2018 Revision History The following table shows the revision history for this document. Date Version Revision 04/20/2018 2.3 • Added a note in the Overview section of Chapter 5. • Replaced BFM terminology with VIP across the user guide. 07/27/2017 2.2 • Vivado IDE updates and minor editorial changes. 04/22/2015 2.1 • Added Embedded Design Methodology Checklist. • Added Accessing Documentation and Training. 03/26/2015 2.0 • Added SDSoC Environment. • Added Related Design Hubs. 10/20/2014 1.1 • Removed outdated information. •In System Level Considerations, added information to the following sections: ° Performance ° Clocking and Reset 10/08/2014 1.0 Initial Release of document. UltraFast Embedded Design Methodology Guide Send Feedback 2 UG1046 (v2.3) April 20, 2018 www.xilinx.com Table of Contents Chapter 1: Introduction Embedded Design Methodology Checklist. 9 Accessing Documentation and Training . 10 Chapter 2: System Level Considerations Performance. 13 Power Consumption . 18 Clocking and Reset. 36 Interrupts . 41 Embedded Device Security . 45 Profiling and Partitioning . 51 Chapter 3: Hardware Design Considerations Configuration and Boot Devices . 63 Memory Interfaces . 69 Peripherals . 76 Designing IP Blocks . 94 Hardware Performance Considerations . 102 Dataflow . 108 PL Clocking Methodology . 112 ACP and Cache Coherency. 116 PL High-Performance Port Access. 120 System Management Hardware Assistance. 124 Managing Hardware Reconfiguration . 127 GPs and Direct PL Access from APU . 133 Chapter 4: Software Design Considerations Processor Configuration . 137 OS and RTOS Choices . 142 Libraries and Middleware . 152 Boot Loaders . 156 Software Development Tools . 162 UltraFast Embedded Design Methodology GuideSend Feedback 3 UG1046 (v2.3) April 20, 2018 www.xilinx.com Chapter 5: Hardware Design Flow Overview .
    [Show full text]
  • EMEA Arrow EMEA Design Partner Network Catalogue
    EMEA Arrow EMEA Design Partner Network Catalogue [email protected] Engineering Solutions Center Expertise | Enablement | Support The mission of Arrow’s Engineering Solutions Center is to support the field team in their design activities ranging from NPI proposals, consultancy in complex areas like software, IoT, FPGAs, high-end to complete system concepts and Arrow’s ready-to-use solutions. Through the TestDrive board loan program, the ESC provides many supplier development boards and Arrow developed solutions to enable quick design starts. Design, customization, prototyping and certification services are available from Arrow’s comprehensive 3rd Party Network. 2 Editorial Dear Arrow Colleagues, A warm welcome to what I hope you will find to be a useful and informative first edition of the Arrow EMEA Design Partner Catalogue. To stay competitive, our customers must continuously leverage leading edge technologies while shortening design cycles. Further, the majority of today’s innovations are happening at the level of software, applications, sensing capabilities, connectivity and security. These dynamics require new skills and capabilities that our customers may lack. This is where the Arrow EMEA Design Partner Network can help. Our partners provide immediate access to pre-screened, Minimize design time qualified, and certified third-party design services companies. Arrow’s network of some of the best and speed time-to-market engineering design services companies can save your customers time and money and allow them to bring by enabling the Arrow products to market faster. Partners can support them EMEA Partner Network all the way from specification development to turnkey board design or be an extension to their engineering to get involved early in team.
    [Show full text]
  • Create Low-Power Applications with MQX™ and MQX™ Lite RTOS FTF-SDS-F0040
    Hands-On Workshop: Create Low-Power Applications with MQX™ and MQX™ Lite RTOS FTF-SDS-F0040 Maclain Lobdell | Freescale Software Product Manager Vincent Leynaert | Freescale FAE APR.2014 TM External Use Hands-On Workshop: Create Low-Power Applications with MQX™ and MQX™ Lite RTOS FTF-SDS-F0040 4 Hour Class Learn how to take advantage of the power management capabilities of MQX and MQX Lite RTOS. See how to create feature-rich applications without killing battery life. Attendees will get hands-on experience with system power mode transitions, driver state transitions and slowing or stopping the system tick timer for power savings. TM External Use 1 Session Introduction • Power efficiency is an increasingly important part of embedded product design. Power consumption budgets are tightening even though performance expectations are ever increasing. • You can create power efficient applications while using an RTOS for sophisticated designs. TM External Use 2 Session Objectives • After completing this session you will be able to: − Understand how power management capabilities can be used in RTOS- based applications − Understand how to perform system power mode transitions, frequency scaling, driver state transitions, and slow or stop the RTOS system tick timer for power savings TM External Use 3 Agenda • Quick Review of MQX Software Solutions • Tools for Analyzing MCU Power • Kinetis MCU Low Power Features • MQX RTOS Power Management Features − Hands On • Optimizing Applications for Low Power − Optimizing/Disabling the System Tick Timer − Architecting
    [Show full text]
  • Intra-Unikernel Isolation with Intel Memory Protection Keys
    Intra-Unikernel Isolation with Intel Memory Protection Keys Mincheol Sung Pierre Olivier∗ Virginia Tech, USA The University of Manchester, United Kingdom [email protected] [email protected] Stefan Lankes Binoy Ravindran RWTH Aachen University, Germany Virginia Tech, USA [email protected] [email protected] Abstract ACM Reference Format: Mincheol Sung, Pierre Olivier, Stefan Lankes, and Binoy Ravin- Unikernels are minimal, single-purpose virtual machines. dran. 2020. Intra-Unikernel Isolation with Intel Memory Protec- This new operating system model promises numerous bene- tion Keys. In 16th ACM SIGPLAN/SIGOPS International Conference fits within many application domains in terms of lightweight- on Virtual Execution Environments (VEE ’20), March 17, 2020, Lau- ness, performance, and security. Although the isolation be- sanne, Switzerland. ACM, New York, NY, USA, 14 pages. https: tween unikernels is generally recognized as strong, there //doi.org/10.1145/3381052.3381326 is no isolation within a unikernel itself. This is due to the use of a single, unprotected address space, a basic principle 1 Introduction of unikernels that provide their lightweightness and perfor- Unikernels have gained attention in the academic research mance benefits. In this paper, we propose a new design that community, offering multiple benefits in terms of improved brings memory isolation inside a unikernel instance while performance, increased security, reduced costs, etc. As a keeping a single address space. We leverage Intel’s Memory result,
    [Show full text]
  • Overrun Handling for Mixed-Criticality Support in RTEMS Kuan-Hsun Chen, Georg Von Der Brüggen, Jian-Jia Chen
    Overrun Handling for Mixed-Criticality Support in RTEMS Kuan-Hsun Chen, Georg von der Brüggen, Jian-Jia Chen To cite this version: Kuan-Hsun Chen, Georg von der Brüggen, Jian-Jia Chen. Overrun Handling for Mixed-Criticality Support in RTEMS. WMC 2016, Nov 2016, Porto, Portugal. hal-01438843 HAL Id: hal-01438843 https://hal.archives-ouvertes.fr/hal-01438843 Submitted on 25 Jan 2017 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. Overrun Handling for Mixed-Criticality Support in RTEMS Kuan-Hsun Chen, Georg von der Bruggen,¨ and Jian-Jia Chen Department of Informatics, TU Dortmund University, Germany Email: fkuan-hsun.chen, georg.von-der-brueggen, [email protected] Abstract—Real-time operating systems are not only used in of real-time operation systems is sufficient. However, some embedded real-time systems but also useful for the simulation and applications also have tasks with arbitrary deadlines, i.e., for validation of those systems. During the evaluation of our paper some tasks D > T . If the tasks are strictly periodic, this about Systems with Dynamic Real-Time Guarantees that appears i i in RTSS 2016 we discovered certain unexpected system behavior leads to a situation where two or more instances of the same in the open-source real-time operating system RTEMS.
    [Show full text]
  • “Sok: Eternal War in Memory”
    “SoK: Eternal War in Memory” Presented by Mengjia Yan MIT 6.888 Fall 2020 Overview • Discuss the paper “SoK: Eternal War in Memory” with concrete examples • Recent progress on memory safety • With a focus on hardware/architecture 2 Motivation • C/C++ is unsafe • EveryboDy runs C/C++ coDe • They surely have exploitable vulnerabilities 3 Low-level Language Basics (C/C++/Assembly) 0x00..0000 • Programmers have more control + Efficient OS memory - Bugs - Programming productivity TEXT (code) Global/Static • Pointers DATA • Address of variables (uint64): index of memory location where variable is stored Heap • Programmers need to do pointer check, e.g. NULL, out-of-bound, use-after-free Stack 0xFF..FFFF 4 Low-level Language Basics 0x00..0000 TEXT (code) Heap Stack 0xFF..FFFF 5 Low-level Language Basics TEXT (code) stack 6 Attacks Code Injection Attack Example TEXT (code) int func (char *str) { Shell code: char buffer[12]; strncpy(buffer, str, len(str)); PUSH “/bin/sh” CALL system stack return 1; } int main() { …. func (input); … } 8 Code Injection Attack TEXT (code) TEXT (code) stack stack buffer Shell code … … Return addr Return addr 9 Attacks 10 Return-Oriented Programming (ROP) int func (char *str) { TEXT (code) TEXT (code) char buffer[12]; strncpy(buffer, str, len(str)); stack stack return 1; } …. int main() { buffer …. … … func (input); Return addr Return addr … } 11 Attacks 12 HeartBleed Vulnerability • Publicly DiscloseD in April 2014 • Bug in the OpenSSL cryptographic software library heartbeat extension • Missing a bound check 13 Attacks
    [Show full text]
  • SH-1/SH-2/SH-DSP Programming Manual
    Hitachi SuperH™ RISC Engine SH-1/SH-2/SH-DSP Programming Manual ADE-602-063C Rev. 4.0 5/13/99 Hitachi ,Ltd Cautions 1. Hitachi neither warrants nor grants licenses of any rights of Hitachi’s or any third party’s patent, copyright, trademark, or other intellectual property rights for information contained in this document. Hitachi bears no responsibility for problems that may arise with third party’s rights, including intellectual property rights, in connection with use of the information contained in this document. 2. Products and product specifications may be subject to change without notice. Confirm that you have received the latest product standards or specifications before final design, purchase or use. 3. Hitachi makes every attempt to ensure that its products are of high quality and reliability. However, contact Hitachi’s sales office before using the product in an application that demands especially high quality and reliability or where its failure or malfunction may directly threaten human life or cause risk of bodily injury, such as aerospace, aeronautics, nuclear power, combustion control, transportation, traffic, safety equipment or medical equipment for life support. 4. Design your application so that the product is used within the ranges guaranteed by Hitachi particularly for maximum rating, operating supply voltage range, heat radiation characteristics, installation conditions and other characteristics. Hitachi bears no responsibility for failure or damage when used beyond the guaranteed ranges. Even within the guaranteed ranges, consider normally foreseeable failure rates or failure modes in semiconductor devices and employ systemic measures such as fail-safes, so that the equipment incorporating Hitachi product does not cause bodily injury, fire or other consequential damage due to operation of the Hitachi product.
    [Show full text]