Lltzvisor: a Lightweight Trustzone-Assisted Hypervisor for Low-End ARM Devices
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
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 . -
AMNESIA 33: How TCP/IP Stacks Breed Critical Vulnerabilities in Iot
AMNESIA:33 | RESEARCH REPORT How TCP/IP Stacks Breed Critical Vulnerabilities in IoT, OT and IT Devices Published by Forescout Research Labs Written by Daniel dos Santos, Stanislav Dashevskyi, Jos Wetzels and Amine Amri RESEARCH REPORT | AMNESIA:33 Contents 1. Executive summary 4 2. About Project Memoria 5 3. AMNESIA:33 – a security analysis of open source TCP/IP stacks 7 3.1. Why focus on open source TCP/IP stacks? 7 3.2. Which open source stacks, exactly? 7 3.3. 33 new findings 9 4. A comparison with similar studies 14 4.1. Which components are typically flawed? 16 4.2. What are the most common vulnerability types? 17 4.3. Common anti-patterns 22 4.4. What about exploitability? 29 4.5. What is the actual danger? 32 5. Estimating the reach of AMNESIA:33 34 5.1. Where you can see AMNESIA:33 – the modern supply chain 34 5.2. The challenge – identifying and patching affected devices 36 5.3. Facing the challenge – estimating numbers 37 5.3.1. How many vendors 39 5.3.2. What device types 39 5.3.3. How many device units 40 6. An attack scenario 41 6.1. Other possible attack scenarios 44 7. Effective IoT risk mitigation 45 8. Conclusion 46 FORESCOUT RESEARCH LABS RESEARCH REPORT | AMNESIA:33 A note on vulnerability disclosure We would like to thank the CERT Coordination Center, the ICS-CERT, the German Federal Office for Information Security (BSI) and the JPCERT Coordination Center for their help in coordinating the disclosure of the AMNESIA:33 vulnerabilities. -
Performance Study of Real-Time Operating Systems for Internet Of
IET Software Research Article ISSN 1751-8806 Performance study of real-time operating Received on 11th April 2017 Revised 13th December 2017 systems for internet of things devices Accepted on 13th January 2018 E-First on 16th February 2018 doi: 10.1049/iet-sen.2017.0048 www.ietdl.org Rafael Raymundo Belleza1 , Edison Pignaton de Freitas1 1Institute of Informatics, Federal University of Rio Grande do Sul, Av. Bento Gonçalves, 9500, CP 15064, Porto Alegre CEP: 91501-970, Brazil E-mail: [email protected] Abstract: The development of constrained devices for the internet of things (IoT) presents lots of challenges to software developers who build applications on top of these devices. Many applications in this domain have severe non-functional requirements related to timing properties, which are important concerns that have to be handled. By using real-time operating systems (RTOSs), developers have greater productivity, as they provide native support for real-time properties handling. Some of the key points in the software development for IoT in these constrained devices, like task synchronisation and network communications, are already solved by this provided real-time support. However, different RTOSs offer different degrees of support to the different demanded real-time properties. Observing this aspect, this study presents a set of benchmark tests on the selected open source and proprietary RTOSs focused on the IoT. The benchmark results show that there is no clear winner, as each RTOS performs well at least on some criteria, but general conclusions can be drawn on the suitability of each of them according to their performance evaluation in the obtained results. -
The OKL4 Microvisor: Convergence Point of Microkernels and Hypervisors
The OKL4 Microvisor: Convergence Point of Microkernels and Hypervisors Gernot Heiser, Ben Leslie Open Kernel Labs and NICTA and UNSW Sydney, Australia ok-labs.com ©2010 Open Kernel Labs and NICTA. All rights reserved. Microkernels vs Hypervisors > Hypervisors = “microkernels done right?” [Hand et al, HotOS ‘05] • Talks about “liability inversion”, “IPC irrelevance” … > What’s the difference anyway? ok-labs.com ©2010 Open Kernel Labs and NICTA. All rights reserved. 2 What are Hypervisors? > Hypervisor = “virtual machine monitor” • Designed to multiplex multiple virtual machines on single physical machine VM1 VM2 Apps Apps AppsApps AppsApps OS OS Hypervisor > Invented in ‘60s to time-share with single-user OSes > Re-discovered in ‘00s to work around broken OS resource management ok-labs.com ©2010 Open Kernel Labs and NICTA. All rights reserved. 3 What are Microkernels? > Designed to minimise kernel code • Remove policy, services, retain mechanisms • Run OS services in user-mode • Software-engineering and dependability reasons • L4: ≈ 10 kLOC, Xen ≈ 100 kLOC, Linux: ≈ 10,000 kLOC ServersServers ServersServers Apps Servers Device AppsApps Drivers Microkernel > IPC performance critical (highly optimised) • Achieved by API simplicity, cache-friendly implementation > Invented 1970 [Brinch Hansen], popularised late ‘80s (Mach, Chorus) ok-labs.com ©2010 Open Kernel Labs and NICTA. All rights reserved. 4 What’s the Difference? > Both contain all code executing at highest privilege level • Although hypervisor may contain user-mode code as well > Both need to abstract hardware resources • Hypervisor: abstraction closely models hardware • Microkernel: abstraction designed to support wide range of systems > What must be abstracted? • Memory • CPU • I/O • Communication ok-labs.com ©2010 Open Kernel Labs and NICTA. -
A Tutorial on Performance Evaluation and Validation Methodology for Low-Power and Lossy Networks
A Tutorial on Performance Evaluation and Validation Methodology for Low-Power and Lossy Networks Kosmas Kritsis, Georgios Papadopoulos, Antoine Gallais, Periklis Chatzimisios, Fabrice Theoleyre To cite this version: Kosmas Kritsis, Georgios Papadopoulos, Antoine Gallais, Periklis Chatzimisios, Fabrice Theoleyre. A Tutorial on Performance Evaluation and Validation Methodology for Low-Power and Lossy Networks. Communications Surveys and Tutorials, IEEE Communications Society, Institute of Electrical and Electronics Engineers, 2018, 20 (3), pp.1799 - 1825. 10.1109/COMST.2018.2820810. hal-01886690 HAL Id: hal-01886690 https://hal.archives-ouvertes.fr/hal-01886690 Submitted on 23 Apr 2020 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. 1 A Tutorial on Performance Evaluation and Validation Methodology for Low-Power and Lossy Networks Kosmas Kritsis, Georgios Z. Papadopoulos, Member, IEEE, Antoine Gallais, Periklis Chatzimisios, Senior Member, IEEE, and Fabrice Theoleyre,´ Senior Member, IEEE, Abstract—Envisioned communication densities in Internet of may be used for counting the number of vehicles, such to Things (IoT) applications are increasing continuously. Because control optimally the street traffic lights and to reduce the these wireless devices are often battery powered, we need waiting time [3]. specific energy efficient (low-power) solutions. -
A Comparative Study Between Operating Systems (Os) for the Internet of Things (Iot)
VOLUME 5 NO 4, 2017 A Comparative Study Between Operating Systems (Os) for the Internet of Things (IoT) Aberbach Hicham, Adil Jeghal, Abdelouahed Sabrim, Hamid Tairi LIIAN, Department of Mathematic & Computer Sciences, Sciences School, Sidi Mohammed Ben Abdellah University, [email protected], [email protected], [email protected], [email protected] ABSTRACT Abstract : We describe The Internet of Things (IoT) as a network of physical objects or "things" embedded with electronics, software, sensors, and network connectivity, which enables these objects to collect and exchange data in real time with the outside world. It therefore assumes an operating system (OS) which is considered as an unavoidable point for good communication between all devices “objects”. For this purpose, this paper presents a comparative study between the popular known operating systems for internet of things . In a first step we will define in detail the advantages and disadvantages of each one , then another part of Interpretation is developed, in order to analyze the specific requirements that an OS should satisfy to be used and determine the most appropriate .This work will solve the problem of choice of operating system suitable for the Internet of things in order to incorporate it within our research team. Keywords: Internet of things , network, physical object ,sensors,operating system. 1 Introduction The Internet of Things (IoT) is the vision of interconnecting objects, users and entities “objects”. Much, if not most, of the billions of intelligent devices on the Internet will be embedded systems equipped with an Operating Systems (OS) which is a system programs that manage computer resources whether tangible resources (like memory, storage, network, input/output etc.) or intangible resources (like running other computer programs as processes, providing logical ports for different network connections etc.), So it is the most important program that runs on a computer[1]. -
Sel4: Formal Verification of an Operating-System Kernel
seL4: Formal Verification of an Operating-System Kernel Gerwin Klein1;2, June Andronick1;2, Kevin Elphinstone1;2, Gernot Heiser1;2;3 1 1 1;2 1;2 David Cock , Philip Derrin ∗, Dhammika Elkaduwe ,z Kai Engelhardt 1;2 1;4 1 1;2 1;2 Rafal Kolanski , Michael Norrish , Thomas Sewell , Harvey Tuch y, Simon Winwood 1 NICTA, 2 UNSW, 3 Open Kernel Labs, 4 ANU [email protected] ABSTRACT We report on the formal, machine-checked verification of the seL4 microkernel from an abstract specification down to its C implementation. We assume correctness of compiler, assembly code, hardware, and boot code. seL4 is a third-generation microkernel of L4 provenance, comprising 8,700 lines of C and 600 lines of assembler. Its performance is comparable to other high-performance L4 kernels. We prove that the implementation always strictly follows our high-level abstract specification of kernel behaviour. This encompasses traditional design and implementation safety properties such as that the kernel will never crash, and it will never perform an unsafe operation. It also implies much more: we can predict precisely how the kernel will behave in every possible situation. 1. INTRODUCTION Almost every paper on formal verification starts with the observation that software complexity is increasing, that this Figure 1: Call graph of the seL4 microkernel. Ver- leads to errors, and that this is a problem for mission and tices represent functions, and edges invocations. safety critical software. We agree, as do most. Here, we report on the full formal verification of a critical system from a high-level model down to very low-level C kernel, and every single bug can potentially cause arbitrary code. -
Contiki – a Lightweight and Flexible Operating System for Tiny Networked Sensors
Contiki – a Lightweight and Flexible Operating System for Tiny Networked Sensors Adam Dunkels, Björn Grönvall, Thiemo Voigt Swedish Institute of Computer Science IEEE EmNetS-I, 16 November 2004 Sensor OS trade-offs: static vs dynamic event-driven vs multi-threaded What we have done ● Contiki – an OS for sensor network nodes ● Ported Contiki to a number of platforms ● MSP430, AVR, HC12, Z80, 6502, x86, ... ● Simulation environment for BSD/Linux/Windows ● Built a few applications for experimental network deployments Contributions ● Dynamic loading of programs ● Selective reprogramming ● Static vs dynamic linking ● Concurrency management mechanisms ● Events vs threads ● Trade-offs: preemption, size Contiki design target ● “Mote”-class device ● 10-100 kilobytes of code ROM ● 1-10 kilobytes of RAM ● Communication (radio) ● ESB from FU Berlin ● MSP430, 2k RAM, 60k ROM Contiki size (bytes) Module Code MSP430 Code AVR RAM Kernel 810 1044 10 + e + p Program loader 658 - 8 Multi-threading library 582 678 8 + s Timer library 60 90 0 Memory manager 170 226 0 Event log replicator 1656 1934 200 µIP TCP/IP stack 4146 5218 18 + b Run-time reprogramming and loadable programs Reprogramming sensor nodes ● Software development for sensor nets ● Need to reprogram many nodes quite often ● Utilize radio for reprogramming ● Radio inherently broadcast ● Reprogram many nodes at once ● Much faster than firmware download via cable or programming adapter ● Reprogram deployed networks Traditional systems: entire system a monolithic binary ● Most systems statically -
Operating System Support for Run-Time Security with a Trusted Execution Environment
Operating System Support for Run-Time Security with a Trusted Execution Environment - Usage Control and Trusted Storage for Linux-based Systems - by Javier Gonz´alez Ph.D Thesis IT University of Copenhagen Advisor: Philippe Bonnet Submitted: January 31, 2015 Last Revision: May 30, 2015 ITU DS-nummer: D-2015-107 ISSN: 1602-3536 ISBN: 978-87-7949-302-5 1 Contents Preface8 1 Introduction 10 1.1 Context....................................... 10 1.2 Problem....................................... 12 1.3 Approach...................................... 14 1.4 Contribution.................................... 15 1.5 Thesis Structure.................................. 16 I State of the Art 18 2 Trusted Execution Environments 20 2.1 Smart Cards.................................... 21 2.1.1 Secure Element............................... 23 2.2 Trusted Platform Module (TPM)......................... 23 2.3 Intel Security Extensions.............................. 26 2.3.1 Intel TXT.................................. 26 2.3.2 Intel SGX.................................. 27 2.4 ARM TrustZone.................................. 29 2.5 Other Techniques.................................. 32 2.5.1 Hardware Replication........................... 32 2.5.2 Hardware Virtualization.......................... 33 2.5.3 Only Software............................... 33 2.6 Discussion...................................... 33 3 Run-Time Security 36 3.1 Access and Usage Control............................. 36 3.2 Data Protection................................... 39 3.3 Reference -
Embedded Operating Systems
7 Embedded Operating Systems Claudio Scordino1, Errico Guidieri1, Bruno Morelli1, Andrea Marongiu2,3, Giuseppe Tagliavini3 and Paolo Gai1 1Evidence SRL, Italy 2Swiss Federal Institute of Technology in Zurich (ETHZ), Switzerland 3University of Bologna, Italy In this chapter, we will provide a description of existing open-source operating systems (OSs) which have been analyzed with the objective of providing a porting for the reference architecture described in Chapter 2. Among the various possibilities, the ERIKA Enterprise RTOS (Real-Time Operating System) and Linux with preemption patches have been selected. A description of the porting effort on the reference architecture has also been provided. 7.1 Introduction In the past, OSs for high-performance computing (HPC) were based on custom-tailored solutions to fully exploit all performance opportunities of supercomputers. Nowadays, instead, HPC systems are being moved away from in-house OSs to more generic OS solutions like Linux. Such a trend can be observed in the TOP500 list [1] that includes the 500 most powerful supercomputers in the world, in which Linux dominates the competition. In fact, in around 20 years, Linux has been capable of conquering all the TOP500 list from scratch (for the first time in November 2017). Each manufacturer, however, still implements specific changes to the Linux OS to better exploit specific computer hardware features. This is especially true in the case of computing nodes in which lightweight kernels are used to speed up the computation. 173 174 Embedded Operating Systems Figure 7.1 Number of Linux-based supercomputers in the TOP500 list. Linux is a full-featured OS, originally designed to be used in server or desktop environments. -
RIOT, the Friendly Operating System for The
The friendly operating system for the IoT by Thomas Eichinger (on behalf of the RIOT community) OpenIoT Summit NA 2017 Why? How? What is RIOT? Why? How? What is RIOT? Why a software platform for the IoT? ● Linux, Arduino, … bare metal? ● But as IoT software evolves … ○ More complex pieces e.g. an IP network stack ○ Evolution of application logic ● … non-portable IoT software slows innovation ○ 90% of IoT software should be hardware-independent → this is achievable with a good software platform (but not if you develop bare metal) Why a software platform for the IoT? ✓ faster innovation by spreading IoT software dev. costs ✓ long-term IoT software robustness & security ✓ trust, transparency & protection of IoT users’ privacy ✓ less garbage with less IoT device lock-down Why? How? What is RIOT? How to achieve our goals? Experience (e.g. with Linux) points towards ● Open source Indirect business models ● Free core Geopolitical neutrality ● Driven by a grassroot community Main Challenges of an OS in IoT Low-end IoT device resource constraints ● Kernel performance ● System-level interoperability ● Network-level interoperability ● Trust SW platform on low-end IoT devices ● The good news: ○ No need for advanced GUI (a simple shell is sufficient) ○ No need for high throughput performance (kbit/s) ○ No need to support dozens of concurrent applications ● The bad news: ○ kBytes of memory! ○ Typically no MMU! ○ Extreme energy efficency must be built in! SW platform on low-end IoT devices ● Contiki ● mbedOS (ARM) ● ● Zephyr (Intel) ● TinyOS ● LiteOS (Huawei) ● myNewt ● … ● FreeRTOS ● and closed source alternatives Reference: O. Hahm et al. "Operating Systems for Low-End Devices in the Internet of Things: A survey," IEEE Internet of Things Journal, 2016. -
Partitioned System with Xtratum on Powerpc
Tesina de M´asteren Autom´aticae Inform´aticaIndustrial Partitioned System with XtratuM on PowerPC Author: Rui Zhou Advisor: Prof. Alfons Crespo i Lorente December 2009 Contents 1. Introduction1 1.1. MILS......................................2 1.2. ARINC 653..................................3 1.3. PikeOS.....................................6 1.4. ADEOS....................................7 2. Overview of XtratuM 11 2.1. Virtualization and Hypervisor........................ 11 2.2. XtratuM.................................... 12 3. Overview of PowerPC 16 3.1. POWER.................................... 16 3.2. PowerPC.................................... 17 3.3. PowerPC in Safety-critical.......................... 19 4. Main PowerPC Drivers to Virtualize 20 4.1. Processors................................... 20 4.2. Timer..................................... 21 4.3. Interrupt.................................... 23 4.4. Memory.................................... 24 5. Porting Implementation 25 5.1. Hypercall................................... 26 5.2. Timer..................................... 27 5.3. Interrupt.................................... 28 5.4. Memory.................................... 31 5.5. Partition.................................... 32 6. Benchmark 34 7. Conclusions and Future Work 38 Abstract Nowadays, the diversity of embedded applications has been developed into a new stage with the availability of various new high-performance processors and low cost on-chip memory. As the result of these new advances in hardware, there is a