The World Beyond X86
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Microcode Revision Guidance August 31, 2019 MCU Recommendations
microcode revision guidance August 31, 2019 MCU Recommendations Section 1 – Planned microcode updates • Provides details on Intel microcode updates currently planned or available and corresponding to Intel-SA-00233 published June 18, 2019. • Changes from prior revision(s) will be highlighted in yellow. Section 2 – No planned microcode updates • Products for which Intel does not plan to release microcode updates. This includes products previously identified as such. LEGEND: Production Status: • Planned – Intel is planning on releasing a MCU at a future date. • Beta – Intel has released this production signed MCU under NDA for all customers to validate. • Production – Intel has completed all validation and is authorizing customers to use this MCU in a production environment. -
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. -
Analysis of Firmware Security in Embedded ARM Environments
Analysis of Firmware Security in Embedded ARM Environments Dane A. Brown Dissertation submitted to the Faculty of the Virginia Polytechnic Institute and State University in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Computer Engineering T. Charles Clancy, Chair Ryan Gerdes Yaling Yang Jonathan Black Patrick Schaumont August 13, 2019 Arlington, Virginia Keywords: Security, Firmware, Embedded Devices, ARM Copyright 2019, Dane A. Brown Analysis of Firmware Security in Embedded ARM Environments Dane A. Brown (ABSTRACT) Modern enterprise-grade systems with virtually unlimited resources have many options when it comes to implementing state of the art intrusion prevention and detection solutions. These solutions are costly in terms of energy, execution time, circuit board area, and capital. Sus- tainable Internet of Things devices and power-constrained embedded systems are thus forced to make suboptimal security trade-offs. One such trade-off is the design of architectures which prevent execution of injected shell code, yet have allowed Return Oriented Program- ming (ROP) to emerge as a more reliable way to execute malicious code following attacks. ROP is a method used to take over the execution of a program by causing the return address of a function to be modified through an exploit vector, then returning to small segments of otherwise innocuous code located in executable memory one after the other to carry out the attacker’s aims. We show that the Tiva TM4C123GH6PM microcontroller, which utilizes an ARM Cortex-M4F processor, can be fully controlled with this technique. Firmware code is pre-loaded into a ROM on Tiva microcontrollers which can be subverted to erase and rewrite the flash memory where the program resides. -
18-447 Computer Architecture Lecture 6: Multi-Cycle and Microprogrammed Microarchitectures
18-447 Computer Architecture Lecture 6: Multi-Cycle and Microprogrammed Microarchitectures Prof. Onur Mutlu Carnegie Mellon University Spring 2015, 1/28/2015 Agenda for Today & Next Few Lectures n Single-cycle Microarchitectures n Multi-cycle and Microprogrammed Microarchitectures n Pipelining n Issues in Pipelining: Control & Data Dependence Handling, State Maintenance and Recovery, … n Out-of-Order Execution n Issues in OoO Execution: Load-Store Handling, … 2 Reminder on Assignments n Lab 2 due next Friday (Feb 6) q Start early! n HW 1 due today n HW 2 out n Remember that all is for your benefit q Homeworks, especially so q All assignments can take time, but the goal is for you to learn very well 3 Lab 1 Grades 25 20 15 10 5 Number of Students 0 30 40 50 60 70 80 90 100 n Mean: 88.0 n Median: 96.0 n Standard Deviation: 16.9 4 Extra Credit for Lab Assignment 2 n Complete your normal (single-cycle) implementation first, and get it checked off in lab. n Then, implement the MIPS core using a microcoded approach similar to what we will discuss in class. n We are not specifying any particular details of the microcode format or the microarchitecture; you can be creative. n For the extra credit, the microcoded implementation should execute the same programs that your ordinary implementation does, and you should demo it by the normal lab deadline. n You will get maximum 4% of course grade n Document what you have done and demonstrate well 5 Readings for Today n P&P, Revised Appendix C q Microarchitecture of the LC-3b q Appendix A (LC-3b ISA) will be useful in following this n P&H, Appendix D q Mapping Control to Hardware n Optional q Maurice Wilkes, “The Best Way to Design an Automatic Calculating Machine,” Manchester Univ. -
System Design for a Computational-RAM Logic-In-Memory Parailel-Processing Machine
System Design for a Computational-RAM Logic-In-Memory ParaIlel-Processing Machine Peter M. Nyasulu, B .Sc., M.Eng. A thesis submitted to the Faculty of Graduate Studies and Research in partial fulfillment of the requirements for the degree of Doctor of Philosophy Ottaw a-Carleton Ins titute for Eleceical and Computer Engineering, Department of Electronics, Faculty of Engineering, Carleton University, Ottawa, Ontario, Canada May, 1999 O Peter M. Nyasulu, 1999 National Library Biôiiothkque nationale du Canada Acquisitions and Acquisitions et Bibliographie Services services bibliographiques 39S Weiiington Street 395. nie WeUingtm OnawaON KlAW Ottawa ON K1A ON4 Canada Canada The author has granted a non- L'auteur a accordé une licence non exclusive licence allowing the exclusive permettant à la National Library of Canada to Bibliothèque nationale du Canada de reproduce, ban, distribute or seU reproduire, prêter, distribuer ou copies of this thesis in microform, vendre des copies de cette thèse sous paper or electronic formats. la forme de microficbe/nlm, de reproduction sur papier ou sur format électronique. The author retains ownership of the L'auteur conserve la propriété du copyright in this thesis. Neither the droit d'auteur qui protège cette thèse. thesis nor substantial extracts fkom it Ni la thèse ni des extraits substantiels may be printed or otherwise de celle-ci ne doivent être imprimés reproduced without the author's ou autrement reproduits sans son permission. autorisation. Abstract Integrating several 1-bit processing elements at the sense amplifiers of a standard RAM improves the performance of massively-paralle1 applications because of the inherent parallelism and high data bandwidth inside the memory chip. -
Endian: from the Ground up a Coordinated Approach
WHITEPAPER Endian: From the Ground Up A Coordinated Approach By Kevin Johnston Senior Staff Engineer, Verilab July 2008 © 2008 Verilab, Inc. 7320 N MOPAC Expressway | Suite 203 | Austin, TX 78731-2309 | 512.372.8367 | www.verilab.com WHITEPAPER INTRODUCTION WHat DOES ENDIAN MEAN? Data in Imagine XYZ Corp finally receives first silicon for the main Endian relates the significance order of symbols to the computers chip for its new camera phone. All initial testing proceeds position order of symbols in any representation of any flawlessly until they try an image capture. The display is kind of data, if significance is position-dependent in that regularly completely garbled. representation. undergoes Of course there are many possible causes, and the debug Let’s take a specific type of data, and a specific form of dozens if not team analyzes code traces, packet traces, memory dumps. representation that possesses position-dependent signifi- There is no problem with the code. There is no problem cance: A digit sequence representing a numeric value, like hundreds of with data transport. The problem is eventually tracked “5896”. Each digit position has significance relative to all down to the data format. other digit positions. transformations The development team ran many, many pre-silicon simula- I’m using the word “digit” in the generalized sense of an between tions of the system to check datapath integrity, bandwidth, arbitrary radix, not necessarily decimal. Decimal and a few producer and error correction. The verification effort checked that all other specific radixes happen to be particularly useful for the data submitted at the camera port eventually emerged illustration simply due to their familiarity, but all of the consumer. -
Micro-Circuits for High Energy Physics*
MICRO-CIRCUITS FOR HIGH ENERGY PHYSICS* Paul F. Kunz Stanford Linear Accelerator Center Stanford University, Stanford, California, U.S.A. ABSTRACT Microprogramming is an inherently elegant method for implementing many digital systems. It is a mixture of hardware and software techniques with the logic subsystems controlled by "instructions" stored Figure 1: Basic TTL Gate in a memory. In the past, designing microprogrammed systems was difficult, tedious, and expensive because the available components were capable of only limited number of functions. Today, however, large blocks of microprogrammed systems have been incorporated into a A input B input C output single I.e., thus microprogramming has become a simple, practical method. false false true false true true true false true true true false 1. INTRODUCTION 1.1 BRIEF HISTORY OF MICROCIRCUITS Figure 2: Truth Table for NAND Gate. The first question which arises when one talks about microcircuits is: What is a microcircuit? The answer is simple: a complete circuit within a single integrated-circuit (I.e.) package or chip. The next question one might ask is: What circuits are available? The answer to this question is also simple: it depends. It depends on the economics of the circuit for the semiconductor manufacturer, which depends on the technology he uses, which in turn changes as a function of time. Thus to understand Figure 3: Logical NOT Circuit. what microcircuits are available today and what makes them different from those of yesterday it is interesting to look into the economics of producing microcircuits. The basic element in a logic circuit is a gate, which is a circuit with a number of inputs and one output and it performs a basic logical function such as AND, OR, or NOT. -
Coreboot - the Free firmware
coreboot - the free firmware Linux Club of Peking University April 9th, 2016 . Linux Club of Peking University coreboot - the free firmware April 9th, 2016 1 / 30 1 History 2 Why use coreboot 3 How coreboot works 4 Building and using coreboot 5 Flashing 6 Utilities and Debugging 7 Contribute to coreboot 8 Proprietary Components 9 References . Linux Club of Peking University coreboot - the free firmware April 9th, 2016 2 / 30 History: from LinuxBIOS to coreboot coreboot has a very long history, stretching back more than 15 years to when it was known as LinuxBIOS. While the project has gone through lots of changes over the years, many of the earliest developers still contribute today. Linux Club of Peking University coreboot - the free firmware April 9th, 2016 3 / 30 LinuxBIOS v1: 1999-2000 The coreboot project originally started as LinuxBIOS in 1999 at Los Alamos National Labs (LANL) by Ron Minnich. Ron needed to boot a cluster made up of many x86 mainboards without the hassles that are part of the PC BIOS. The goal was to do minimal hardware initilization in order to boot Linux as fast as possible. Linux already had the drivers and support to initialize the majority of devices. Ron and a number of other key contributors from LANL, Linux NetworkX, and other open source firmware projects successfully booted Linux from flash. From there they were able to discover other nodes in the cluster, load a full kernel and user space, and start the clustering software. Linux Club of Peking University coreboot - the free firmware April 9th, 2016 4 / 30 LinuxBIOS v2: 2000-2005 After the initial success of v1, the design was expanded to support more CPU architectures (x86, Alpha, PPC) and to support developers with increasingly diverse needs. -
Linux Kernel. LTS? LTSI?
ARM Reference Kernel of Tizen 3 MyungJoo Ham, Ph.D. MyungJoo Ham Tizen “System Domain” & System SW Lab “Base Domain” Architect SW Platform Team SWC Samsung Electronics ARM Reference Kernel of Tizen 3 1. What is it? 2. Idea & Principle 3. Design & Updates 4. Discussion What is “Tizen Reference Kernel” • Kernel (& BSP) for Tizen Reference Devices BSP Validated & Tested for the Reference Devices Image from seoz.com 3 What is “Tizen Reference Kernel” • Kernel (& BSP) for Tizen Reference Devices BSP Validated & Tested for the Reference Devices Yet Another BSP? Image from seoz.com 4 Need for “Tizen Reference Kernel” • Distribute reference devices • Tizen-common kernel features & interface • Basis for next-gen Tizen development 1 KDBUS, User PM-QoS, PASS, DMABUF Sync FW, … 2 CMA, DRM-Exynos, Devfreq, Extcon, Charger-manager, LAB/Turboboost … • Support Tizen Vendors! • Well-known and well-written example. • Code basis for vendors. 5 Previous Tizen ARM Reference Kernel (~2.2.1) • Linux 3.0.15 • Obsolete LTS. (Current: 3.4 & 3.10) • Support RD-PQ (Tizen 2) & RD-210 (Tizen 1 & 2) • RD-PQ: Exynos4412 • RD-210: Exynos4210 (Linux 2.6.36 for Tizen 1) • Not Good as Reference • Too many backported features. • Too OLD! No LTS/LTSI support • Many kernel hacks & dirty patches • git history removed. 1. Forked from production kernel. 2. Hard to read 6 Status of Tizen 3 Reference Kernels • Two Reference Kernels: ARM / Intel • ARM (armv7, aarch64) • Linux 3.10.y • 3.10.33 @ 2014/05 • Full git history. • armv6 support (Raspberry Pi) coming soon. (Thanks to Univ. of Warsaw) • Test & validation phase (integration test with userspace) • Intel (x86, x86_64) • Linux 3.14.1 • Recent ATOM SoC support merged @ 3.14 • Test & validation phase (integration test with userspace) 7 ARM Reference Kernel of Tizen 3 1. -
P4080 Development System User's Guide
Freescale Semiconductor Document Number: P4080DSUG User Guide Rev. 0, 07/2010 P4080 Development System User’s Guide by Networking and Multimedia Group Freescale Semiconductor, Inc. Austin, TX Contents 1Overview 1. Overview . 1 2. Features Summary . 2 The P4080 development system (DS) is a high-performance 3. Block Diagram and Placement . 4 computing, evaluation, and development platform 4. Evaluation Support . 6 supporting the P4080 Power Architecture® processor. The 5. Architecture . 8 P4080 development system’s official designation is 6. Configuration . 40 7. Programming Model . 45 P4080DS, and may be ordered using this part number. 8. Revision History . 58 The P4080DS is designed to the ATX form-factor standard, A. References . 58 allowing it to be used in 2U rack-mount chassis, as well as in a standard ATX chassis. The system is lead-free and RoHS-compliant. © 2011 Freescale Semiconductor, Inc. All rights reserved. Features Summary 2 Features Summary The features of the P4080DS development board are as follows: • Support for the P4080 processor — Core processors – Eight e500mc cores – 45 nm SOI process technology — High-speed serial port (SerDes) – Eighteen lanes, dividable into many combinations – Five controllers support five add-in card slots. – Supports PCI Express, SGMII, Nexus/Aurora debug, XAUI, and Serial RapidIO®. — Dual DDR memory controllers – Designed for DDR3 support – One-per-channel 240-pin sockets that support standard JEDEC DIMMs — Triple-speed Ethernet/ USB controller – One 10/100/1G port uses on-board VSC8244 PHY -
Introductory Lecture & FLOSS
Introductory Lecture & FLOSS Lecture 1 TU Wien, 193.067 Free and Open Technologies (WS 2019/2020) Christoph Derndorfer and Lukas F. Lang This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Introduction Organization ● Lectures: ○ Weekly lecture to cover course materials (until Christmas) ○ Lectures take place on Tuesdays, 17:00–19:00, Argentinierstraße 8, Seminarraum/Bibliothek 194-05 ○ Attendance is mandatory ● Group project: ○ In groups of 4 students ○ 3 meetings with lecturers during the semester (week 44/2019, week 48/2019, week 2/2020) ○ Final presentations at the end of January (week 4/2020) ● Final paper: ○ In groups of 2 students ○ Final presentations at the end of January (week 5/2020) ○ Deadline: Sunday, February 9, 2020, 23:59 CET (no exceptions!) Organization ● Grading: ○ 50% group project ○ 35% seminar paper ○ 15% participation during lectures ○ All course components need to be passed in order to pass the overall course! ● Course materials: ○ Will be provided at https://free-and-open-technologies.github.io ● For further questions: ○ Email [email protected] and [email protected] Lecture outline 1. FLOSS (Free/Libre and Open Source Software) 2. Open Hardware 3. Open Data 4. Open Content/Open Educational Resources 5. Open Science/Research 6. Open Access 7. Open Spaces/Open Practices: Metalab Vienna 8. Guest Lecture: Stefanie Wuschitz (Mz* Baltazar’s Lab) Group project ● Goal: ○ Extend, contribute to, or create a new open project within scope of lecture topics ● Choose topic from a list (see course website) or (even better) suggest your own: ○ Groups of 4 students ○ Send a 1-page proposal until Friday, October 25, via email to both lecturers ■ Define the idea, goal, (potential) impact, requirements, and estimated effort ■ State deliverables (should be broken down into three milestones to discuss in meetings) ● Requirements: ○ Open and accessible (Git repository, openly licensed) → others can access/use/study/extend ○ Use time sheet to track and compare estimated vs. -
The Central Processor Unit
Systems Architecture The Central Processing Unit The Central Processing Unit – p. 1/11 The Computer System Application High-level Language Operating System Assembly Language Machine level Microprogram Digital logic Hardware / Software Interface The Central Processing Unit – p. 2/11 CPU Structure External Memory MAR: Memory MBR: Memory Address Register Buffer Register Address Incrementer R15 / PC R11 R7 R3 R14 / LR R10 R6 R2 R13 / SP R9 R5 R1 R12 R8 R4 R0 User Registers Booth’s Multiplier Barrel IR Shifter Control Unit CPSR 32-Bit ALU The Central Processing Unit – p. 3/11 CPU Registers Internal Registers Condition Flags PC Program Counter C Carry IR Instruction Register Z Zero MAR Memory Address Register N Negative MBR Memory Buffer Register V Overflow CPSR Current Processor Status Register Internal Devices User Registers ALU Arithmetic Logic Unit Rn Register n CU Control Unit n = 0 . 15 M Memory Store SP Stack Pointer MMU Mem Management Unit LR Link Register Note that each CPU has a different set of User Registers The Central Processing Unit – p. 4/11 Current Process Status Register • Holds a number of status flags: N True if result of last operation is Negative Z True if result of last operation was Zero or equal C True if an unsigned borrow (Carry over) occurred Value of last bit shifted V True if a signed borrow (oVerflow) occurred • Current execution mode: User Normal “user” program execution mode System Privileged operating system tasks Some operations can only be preformed in a System mode The Central Processing Unit – p. 5/11 Register Transfer Language NAME Value of register or unit ← Transfer of data MAR ← PC x: Guard, only if x true hcci: MAR ← PC (field) Specific field of unit ALU(C) ← 1 (name), bit (n) or range (n:m) R0 ← MBR(0:7) Rn User Register n R0 ← MBR num Decimal number R0 ← 128 2_num Binary number R1 ← 2_0100 0001 0xnum Hexadecimal number R2 ← 0x40 M(addr) Memory Access (addr) MBR ← M(MAR) IR(field) Specified field of IR CU ← IR(op-code) ALU(field) Specified field of the ALU(C) ← 1 Arithmetic and Logic Unit The Central Processing Unit – p.