DOCSLIB.ORG

Are We Susceptible to Rowhammer? an End-To-End Methodology for Cloud Providers

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Are We Susceptible to Rowhammer? an End-To-End Methodology for Cloud Providers Are We Susceptible to Rowhammer? An End-to-End Methodology for Cloud Providers Lucian Cojocar, Jeremie Kimxy, Minesh Patelx, Lillian Tsaiz, Stefan Saroiu, Alec Wolman, and Onur Mutluxy Microsoft Research, xETH Zurich,¨ yCMU, zMIT Abstract—Cloud providers are concerned that Rowhammer poses vendors claim that their memory is safe against Rowhammer a potentially critical threat to their servers, yet today they lack a attacks; these claims are delivered to cloud providers with each systematic way to test whether the DRAM used in their servers is new DRAM feature: DDR4 [77], ECC-equipped DRAM [33], vulnerable to Rowhammer attacks. This paper presents an end- to-end methodology to determine if cloud servers are susceptible [31], and TRR-equipped DRAM [81], [33]. There is a large to these attacks. With our methodology, a cloud provider can gap between a proof-of-concept exploit carried out in a re- construct worst-case testing conditions for DRAM. search lab and an actual attack in the wild. In fact, no evidence We apply our methodology to three classes of servers from a indicates that Rowhammer attacks have been carried out in major cloud provider. Our findings show that none of the CPU practice. In the absence of attacks in the wild, one could easily instruction sequences used in prior work to mount Rowhammer attacks create worst-case DRAM testing conditions. To address dismiss Rowhammer as a credible threat. this limitation, we develop an instruction sequence that lever- This confusion is further fed by the lack of a system- ages microarchitectural side-effects to “hammer” DRAM at a atic methodology to test for Rowhammer. Previous proof-of- near-optimal rate on modern Intel Skylake and Cascade Lake concept attacks used varied methodologies to mount Rowham- platforms. We also design a DDR4 fault injector that can reverse mer [69], [101], [32], [114], [13], [96], [11], [12], [37], [94], engineer row adjacency for any DDR4 DIMM. When applied to our cloud provider’s DIMMs, we find that DRAM rows do not [97], [110], [77], [59], [2], [35], [36], [105], [25], [106], always follow a linear map. [83], [95], [16], [18], [10], [118], [22] based on heuristics, without rigorously characterizing their effectiveness. While I. INTRODUCTION such approaches can demonstrate an attack’s viability, they are The consequences of a large-scale security compromise of a unsuitable for testing purposes because they cannot distinguish cloud provider cannot be overstated. An increasing number of between Rowhammer-safe memory and a sub-optimal, imper- banks, hospitals, stores, factories, and universities depend upon fect testing methodology. Lacking a comprehensive testing cloud resources for their day-to-day activities. Users store tool, cloud providers find it difficult to ascertain the degree important and private data in the cloud, including tax returns, to which Rowhammer poses a threat to their infrastructure. health records, e-mail, and backups. Home devices and home Building a systematic and scalable testing methodology automation are also becoming reliant on cloud infrastructure. must overcome two serious practical challenges. First, it An attack that steals or deletes data, or performs a large- must devise a sequence of CPU instructions that leads to a scale denial of service (DoS) attack on the cloud, would be maximal rate of row activations in DRAM. This sequence catastrophic to both cloud providers and customers. must overcome the hardware’s attempts to capture locality, Today’s DRAM is vulnerable to memory disturbance errors: such as the CPU’s re-ordering of instructions and the DRAM a high rate of accesses to the same address in DRAM flips bits controller’s re-ordering of memory accesses. For this, we need in data stored in nearby addresses [69]. Rowhammer attacks to measure the row activation rates of the instruction sequences generate adversarial workloads that exploit disturbance errors used by previous work, identify their bottlenecks, and test new to flip the value of security-critical bits, such as an OS’s page candidates that overcome these bottlenecks. Previous work table entries [97], [32], a browser’s isolation sandbox [32], showed that the probability of flipping bits in a Rowhammer arXiv:2003.04498v1 [cs.CR] 10 Mar 2020 a CPU’s isolation mechanism [59], an encryption key [97], attack increases with the rate of row activations [89], [69]. or a CPU instruction opcode [36]. Even worse, mounting The second challenge is determining row adjacency in Rowhammer requires no special privilege: attacks have been a DRAM device. Contiguous virtual addresses do not map demonstrated by running user-level code [32], [97], JavaScript linearly to DRAM rows and are in fact subject to three programs [13], [37], and even by sending RDMA network mapping layers. The OS maintains a virtual-to-physical ad- packets [106], [83]. Because all DRAM is potentially sus- dress map that can change often and at runtime [55], [57]; ceptible, Rowhammer attacks are an easy way to mount a if present, virtualization adds another mapping layer due large-scale catastrophic attack on the cloud. The combination to guest-physical addresses. The memory controller further of easy-to-mount and easy-to-scale makes Rowhammer a maps physical addresses to logical bus addresses specified formidable potential attack vector to the cloud. in terms of ranks, banks, rows, and columns [72], [1]. The Unfortunately, the threat that Rowhammer poses to cloud final mapping is done by the DRAM device itself, where providers remains unclear. Security researchers have been pub- a device can remap adjacent logical bus addresses to non- lishing a stream of proof-of-concept exploits using Rowham- adjacent physical rows [71]. DRAM vendors consider these mer that affect all types of DRAM, including DDR3 [69], [32], maps to be trade secrets and strongly guard their secrecy. DDR4 [110], [77], and ECC-equipped DRAM [18]. DRAM Prior techniques to reverse engineer row adjacency with a commodity memory controller rely on Rowhammer at- flipping bits on today’s DDR4 memory. The location and tacks [100], [94], [105] and work only on DIMMs that density of bit flips lets our methodology reverse engineer the succumb to them. Once bits flip, the flips’ locations reveal physical row adjacency of any DDR4 DRAM device. To our information on row adjacency. This creates a chicken-and-egg knowledge, ours is the first fault injector capable of injecting problem: testing DIMMs’ resiliency to Rowhammer requires faults into DDR4 commands. knowing row adjacency information, and reverse engineering We leverage the fault injector to reverse engineer physical row adjacency requires having DIMMs succumb to Rowham- adjacency in a major cloud provider’s DRAM devices supplied mer. by three different vendors. Our results show that logical rows This paper presents solutions to both challenges and com- do not always map linearly, but instead can follow a half- bines them in an end-to-end methodology that creates worst- row pattern, where two halves of a single row are adjacent to case conditions for testing the presence of disturbance errors different rows. A methodology that uses guess-based heuristics in DRAM. Our methodology lets cloud providers construct (1) to determine row adjacency will be ineffective in testing these an instruction sequence that maximizes the rate of DRAM row half-row patterns. We also find that mounting a Rowhammer activations on a given system, and (2) accurate maps of address attack on a victim row that follows a half-row pattern requires translations used by the system’s hardware. Armed with this hammering more aggressor rows than it does for a victim row knowledge, a cloud provider can develop a quality control that is contiguous within a single physical row. pipeline to test its servers’ DRAM and ultimately characterize We applied our methodology on a major cloud provider’s the risk of a Rowhammer attack to its infrastructure. three most recent classes of servers based on Intel’s Cascade We start by showing how a memory bus analyzer can char- Lake, Skylake, and Broadwell architectures. On the two newest acterize the effectiveness of a sequence of CPU instructions architectures, Cascade Lake and Skylake, our methodology when hammering memory. It can measure the rate of activation achieves a near-optimal rate of activations by using clflushopt commands and compare them to the optimal rate (i.e., the to “hammer” memory, an instruction introduced with the highest rate of activations to memory that the specifications Skylake architecture. Finally, we used the fault injector to allow). Our results show that all instruction sequences used in successfully reverse engineer physical row adjacency on all previous work hammer memory at a sub-optimal rate. Most three classes of servers. previous sequences have a rate that is at most half of optimal, and the most effective previous sequence is 33% from optimal. II. BACKGROUND We tested 42 different instruction sequences, including those Rowhammer bit flips result from circuit-level charge leakage found in previous work [69], [32], [114], [13], [96], [11], mechanisms that are exacerbated by certain memory access [37], [94], [97], [110], [77], [59], [2], [35], [36], [105], and patterns. This section provides a high-level background on developed additional variants. DRAM and the physical mechanisms responsible for the Our characterization sheds light on the factors that prevent Rowhammer phenomenon in order to facilitate the understand- these instruction sequences from having a high rate of ac- ing of our work. More detail on Rowhammer and its system- tivations. One significant factor is out-of-order execution – level implications can be found in [69], [88], [89]. the CPU constantly re-orders memory accesses to increase the likelihood they are served from the cache. Out-of-order A. DRAM Organization execution can act as a de facto rate limiter to Rowhammer DRAM comprises a hierarchy of two-dimensional arrays, attacks.
Load more

Recommended publications
  • ASIC Implementation of DDR SDRAM Memory Controller
    © 2016 IJEDR | Volume 4, Issue 4 | ISSN: 2321-9939 ASIC Implementation of DDR SDRAM Memory Controller Ramagiri Ramya, Naganaik M.Tech Scholar, ASST.PROF, HOD of ECE BRIG-IC, Hyderabad ________________________________________________________________________________________________________ Abstract - A Dedicated Memory Controller is of prime importance in applications that do not contain microprocessors (high-end applications). The Memory Controller provides command signals for memory refresh, read and write operation and initialization of SDRAM. Our work will focus on ASIC Design methodology of Double Data Rate (DDR) SDRAM Controller that is located between the DDR SDRAM and Bus Master. The Controller simplifies the SDRAM command interface to standard system read/write interface and also optimizes the access time of read/write cycle. Keywords - DDR SDRAM Controller, Read/Write Data path, Cadence RTL Compiler. ________________________________________________________________________________________________________ I. INTRODUCTION Memory devices are almost found in all systems and nowadays high speed and high performance memories are in great demand. For better throughput and speed, the controllers are to be designed with clock frequency in the range of megahertz. As the clock speed of the controller is increasing, the design challenges are also becoming complex. Therefore the next generation memory devices require very high speed controllers like double data rate and quad data rate memory controllers. In this paper, the double data rate SDRAM Controller is implemented using ASIC methodology. Synchronous DRAM (SDRAM) is preferred in embedded system memory design because of its speed and pipelining capability. In high-end applications, like microprocessors there will be specific built in peripherals to provide the interface to the SDRAM. But for other applications, the system designer must design a specific memory controller to provide command signals for memory refresh, read and write operation and initialization of SDRAM.
    [Show full text]
  • Microkernel Mechanisms for Improving the Trustworthiness of Commodity Hardware
    Microkernel Mechanisms for Improving the Trustworthiness of Commodity Hardware Yanyan Shen Submitted in fulfilment of the requirements for the degree of Doctor of Philosophy School of Computer Science and Engineering Faculty of Engineering March 2019 Thesis/Dissertation Sheet Surname/Family Name : Shen Given Name/s : Yanyan Abbreviation for degree as give in the University calendar : PhD Faculty : Faculty of Engineering School : School of Computer Science and Engineering Microkernel Mechanisms for Improving the Trustworthiness of Commodity Thesis Title : Hardware Abstract 350 words maximum: (PLEASE TYPE) The thesis presents microkernel-based software-implemented mechanisms for improving the trustworthiness of computer systems based on commercial off-the-shelf (COTS) hardware that can malfunction when the hardware is impacted by transient hardware faults. The hardware anomalies, if undetected, can cause data corruptions, system crashes, and security vulnerabilities, significantly undermining system dependability. Specifically, we adopt the single event upset (SEU) fault model and address transient CPU or memory faults. We take advantage of the functional correctness and isolation guarantee provided by the formally verified seL4 microkernel and hardware redundancy provided by multicore processors, design the redundant co-execution (RCoE) architecture that replicates a whole software system (including the microkernel) onto different CPU cores, and implement two variants, loosely-coupled redundant co-execution (LC-RCoE) and closely-coupled redundant co-execution (CC-RCoE), for the ARM and x86 architectures. RCoE treats each replica of the software system as a state machine and ensures that the replicas start from the same initial state, observe consistent inputs, perform equivalent state transitions, and thus produce consistent outputs during error-free executions.
    [Show full text]
  • SMASH: Synchronized Many-Sided Rowhammer Attacks from Javascript
    SMASH: Synchronized Many-sided Rowhammer Attacks from JavaScript Finn de Ridder Pietro Frigo Emanuele Vannacci Herbert Bos ETH Zurich VU Amsterdam VU Amsterdam VU Amsterdam VU Amsterdam Cristiano Giuffrida Kaveh Razavi VU Amsterdam ETH Zurich Abstract has instead been lagging behind. In particular, rather than Despite their in-DRAM Target Row Refresh (TRR) mitiga- addressing the root cause of the Rowhammer bug, DDR4 in- tions, some of the most recent DDR4 modules are still vul- troduced a mitigation known as Target Row Refresh (TRR). nerable to many-sided Rowhammer bit flips. While these TRR, however, has already been shown to be ineffective bit flips are exploitable from native code, triggering them against many-sided Rowhammer attacks from native code, in the browser from JavaScript faces three nontrivial chal- at least in its current in-DRAM form [12]. However, it is lenges. First, given the lack of cache flushing instructions in unclear whether TRR’s failing also re-exposes end users to JavaScript, existing eviction-based Rowhammer attacks are TRR-aware, JavaScript-based Rowhammer attacks from the already slow for the older single- or double-sided variants browser. In fact, existing many-sided Rowhammer attacks and thus not always effective. With many-sided Rowhammer, require frequent cache flushes, large physically-contiguous mounting effective attacks is even more challenging, as it re- regions, and certain access patterns to bypass in-DRAM TRR, quires the eviction of many different aggressor addresses from all challenging in JavaScript. the CPU caches. Second, the most effective many-sided vari- In this paper, we show that under realistic assumptions, it ants, known as n-sided, require large physically-contiguous is indeed possible to bypass TRR directly from JavaScript, memory regions which are not available in JavaScript.
    [Show full text]
  • A Modern Primer on Processing in Memory
    A Modern Primer on Processing in Memory Onur Mutlua,b, Saugata Ghoseb,c, Juan Gomez-Luna´ a, Rachata Ausavarungnirund SAFARI Research Group aETH Z¨urich bCarnegie Mellon University cUniversity of Illinois at Urbana-Champaign dKing Mongkut’s University of Technology North Bangkok Abstract Modern computing systems are overwhelmingly designed to move data to computation. This design choice goes directly against at least three key trends in computing that cause performance, scalability and energy bottlenecks: (1) data access is a key bottleneck as many important applications are increasingly data-intensive, and memory bandwidth and energy do not scale well, (2) energy consumption is a key limiter in almost all computing platforms, especially server and mobile systems, (3) data movement, especially off-chip to on-chip, is very expensive in terms of bandwidth, energy and latency, much more so than computation. These trends are especially severely-felt in the data-intensive server and energy-constrained mobile systems of today. At the same time, conventional memory technology is facing many technology scaling challenges in terms of reliability, energy, and performance. As a result, memory system architects are open to organizing memory in different ways and making it more intelligent, at the expense of higher cost. The emergence of 3D-stacked memory plus logic, the adoption of error correcting codes inside the latest DRAM chips, proliferation of different main memory standards and chips, specialized for different purposes (e.g., graphics, low-power, high bandwidth, low latency), and the necessity of designing new solutions to serious reliability and security issues, such as the RowHammer phenomenon, are an evidence of this trend.
    [Show full text]
  • Drammer: Deterministic Rowhammer Attacks on Mobile Platforms
    Drammer: Deterministic Rowhammer Attacks on Mobile Platforms Victor van der Veen Yanick Fratantonio Martina Lindorfer Vrije Universiteit Amsterdam UC Santa Barbara UC Santa Barbara [email protected] [email protected] [email protected] Daniel Gruss Clémentine Maurice Giovanni Vigna Graz University of Technology Graz University of Technology UC Santa Barbara [email protected] [email protected] [email protected] Herbert Bos Kaveh Razavi Cristiano Giuffrida Vrije Universiteit Amsterdam Vrije Universiteit Amsterdam Vrije Universiteit Amsterdam [email protected] [email protected] [email protected] ABSTRACT 1. INTRODUCTION Recent work shows that the Rowhammer hardware bug can The Rowhammer hardware bug allows an attacker to mod- be used to craft powerful attacks and completely subvert a ify memory without accessing it, simply by repeatedly ac- system. However, existing efforts either describe probabilis- cessing, i.e., \hammering", a given physical memory loca- tic (and thus unreliable) attacks or rely on special (and often tion until a bit in an adjacent location flips. Rowhammer unavailable) memory management features to place victim has been used to craft powerful attacks that bypass all cur- objects in vulnerable physical memory locations. Moreover, rent defenses and completely subvert a system [16,32,35,47]. prior work only targets x86 and researchers have openly won- Until now, the proposed exploitation techniques are either dered whether Rowhammer attacks on other architectures, probabilistic [16,35] or rely on special memory management such as ARM, are even possible. features such as memory deduplication [32], MMU paravir- We show that deterministic Rowhammer attacks are feasi- tualization [47], or the pagemap interface [35].
    [Show full text]
  • Throwhammer: Rowhammer Attacks Over the Network and Defenses
    Throwhammer: Rowhammer Attacks over the Network and Defenses Andrei Tatar Radhesh Krishnan Konoth Elias Athanasopoulos VU Amsterdam VU Amsterdam University of Cyprus Cristiano Giuffrida Herbert Bos Kaveh Razavi VU Amsterdam VU Amsterdam VU Amsterdam Abstract never progressed beyond local privilege escalations or sandbox escapes. The attacker needs the ability to run Increasingly sophisticated Rowhammer exploits allow an code on the victim machine in order to flip bits in sen- attacker that can execute code on a vulnerable system sitive data. Hence, Rowhammer posed little threat from to escalate privileges and compromise browsers, clouds, attackers without code execution on the victim machines. and mobile systems. In all these attacks, the common In this paper, we show that this is no longer true and at- assumption is that attackers first need to obtain code tackers can flip bits by only sending network packets to execution on the victim machine to be able to exploit a victim machine connected to RDMA-enabled networks Rowhammer either by having (unprivileged) code exe- commonly used in clouds and data centers [1, 20, 45, 62]. cution on the victim machine or by luring the victim to a website that employs a malicious JavaScript applica- Rowhammer exploits today Rowhammer allows at- tion. In this paper, we revisit this assumption and show tackers to flip a bit in one physical memory location that an attacker can trigger and exploit Rowhammer bit by aggressively reading (or writing) other locations (i.e., flips directly from a remote machine by only sending hammering). As bit flips occur at the physical level, they network packets.
    [Show full text]
  • Can Microkernels Mitigate Microarchitectural Attacks?⋆
    Can Microkernels Mitigate Microarchitectural Attacks?? Gunnar Grimsdal1, Patrik Lundgren2, Christian Vestlund3, Felipe Boeira1, and Mikael Asplund1[0000−0003−1916−3398] 1 Department of Computer and Information Science, Link¨oping University, Sweden ffelipe.boeira,[email protected] 2 Westermo Network Technologies [email protected] 3 Sectra AB, Link¨oping,Sweden Abstract. Microarchitectural attacks such as Meltdown and Spectre have attracted much attention recently. In this paper we study how effec- tive these attacks are on the Genode microkernel framework using three different kernels, Okl4, Nova, and Linux. We try to answer the question whether the strict process separation provided by Genode combined with security-oriented kernels such as Okl4 and Nova can mitigate microar- chitectural attacks. We evaluate the attack effectiveness by measuring the throughput of data transfer that violates the security properties of the system. Our results show that the underlying side-channel attack Flush+Reload used in both Meltdown and Spectre, is effective on all in- vestigated platforms. We were also able to achieve high throughput using the Spectre attack, but we were not able to show any effective Meltdown attack on Okl4 or Nova. Keywords: Genode, Meltdown, Spectre, Flush+Reload, Okl4, Nova 1 Introduction It used to be the case that general-purpose operating systems were mostly found in desktop computers and servers. However, as IoT devices are becoming in- creasingly more sophisticated, they tend more and more to require a powerful operating system such as Linux, since otherwise all basic services must be im- plemented and maintained by the device developers. At the same time, security has become a prime concern both in IoT and in the cloud domain.
    [Show full text]
  • Bundling Spatially Correlated Prefetches for Improved Main Memory Row Buffer Locality
    Bundling Spatially Correlated Prefetches for Improved Main Memory Row Buffer Locality by Patrick Judd A thesis submitted in conformity with the requirements for the degree of Master of Applied Science Graduate Department of Electrical and Computer Engineering University of Toronto © Copyright by Patrick Judd 2014 Bundling Spatially Correlated Prefetches for Improved Main Memory Row Buffer Locality Patrick Judd Masters of Applied Science Graduate Department of Electrical and Computer Engineering University of Toronto 2014 Abstract Row buffer locality is a consequence of programs ’ inherent spatial locality that the memory system can easily exploit for significant performance gains and power savings. However, as the number of cores on a chip increases, request streams become interleaved more frequently and row buffer locality is lost. Prefetching can help mitigate this effect, but more spatial locality remains to be recovered. In this thesis we propose Prefetch Bundling, a scheme which tags spatially correlated prefetches with information to allow the memory controller to prevent prefetches from becoming interleaved. We evaluate this scheme with a simple scheduling policy and show that it improves the row hit rate by 11%. Unfortunately, the simplicity of the scheduling policy does not translate these row hits to improved performance or power savings. However, future work may build on this framework and develop more balanced policies that leverage the row locality of Prefetch Bundling. ii Acknowledgments There are many people to thank as I reflect back on my Master’s degree. First and foremost I must thank my supervisor, Andreas Moshovos, for his support, confidence in my abilities, and most of all for his ability to keep me grounded during stressful and trying times.
    [Show full text]
  • Throwhammer: Rowhammer Attacks Over the Network and Defenses
    Throwhammer: Rowhammer Attacks over the Network and Defenses Andrei Tatar and Radhesh Krishnan Konoth, Vrije Universiteit Amsterdam; Elias Athanasopoulos, University of Cyprus; Cristiano Giuffrida, Herbert Bos, and Kaveh Razavi, Vrije Universiteit Amsterdam https://www.usenix.org/conference/atc18/presentation/tatar This paper is included in the Proceedings of the 2018 USENIX Annual Technical Conference (USENIX ATC ’18). July 11–13, 2018 • Boston, MA, USA ISBN 978-1-939133-02-1 Open access to the Proceedings of the 2018 USENIX Annual Technical Conference is sponsored by USENIX. Throwhammer: Rowhammer Attacks over the Network and Defenses Andrei Tatar Radhesh Krishnan Konoth Elias Athanasopoulos VU Amsterdam VU Amsterdam University of Cyprus Cristiano Giuffrida Herbert Bos Kaveh Razavi VU Amsterdam VU Amsterdam VU Amsterdam Abstract never progressed beyond local privilege escalations or sandbox escapes. The attacker needs the ability to run Increasingly sophisticated Rowhammer exploits allow an code on the victim machine in order to flip bits in sen- attacker that can execute code on a vulnerable system sitive data. Hence, Rowhammer posed little threat from to escalate privileges and compromise browsers, clouds, attackers without code execution on the victim machines. and mobile systems. In all these attacks, the common In this paper, we show that this is no longer true and at- assumption is that attackers first need to obtain code tackers can flip bits by only sending network packets to execution on the victim machine to be able to exploit a victim machine connected to RDMA-enabled networks Rowhammer either by having (unprivileged) code exe- commonly used in clouds and data centers [1, 20, 45, 62].
    [Show full text]
  • Row Hammer Exploit in Cloud Environment
    Iowa State University Capstones, Theses and Creative Components Dissertations Fall 2018 Row hammer exploit in cloud environment Adithya Venkataraman Iowa State University Follow this and additional works at: https://lib.dr.iastate.edu/creativecomponents Part of the Computer and Systems Architecture Commons Recommended Citation Venkataraman, Adithya, "Row hammer exploit in cloud environment" (2018). Creative Components. 113. https://lib.dr.iastate.edu/creativecomponents/113 This Creative Component is brought to you for free and open access by the Iowa State University Capstones, Theses and Dissertations at Iowa State University Digital Repository. It has been accepted for inclusion in Creative Components by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. Row hammer exploit in c loud environment by Adithya Venkataraman A report submitted to the graduate faculty in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE Major: Electrical and Computer Engineering Program of Study Committee: Akhilesh Tyagi, Major Professor The student author, whose presentation of the scholarship herein was approved by the program of study committee, is solely responsible for the content of this thesis. The Graduate College will ensure this dissertation is globally accessible and will not permit alterations after a degree is conferred. Iowa State University Ames, Iowa 2018 Copyright © Adithya Venkataraman, 2018. All rights reserved. ii TABLE OF CONTENTS Page
    [Show full text]
  • PC Hardware Contents
    PC Hardware Contents 1 Computer hardware 1 1.1 Von Neumann architecture ...................................... 1 1.2 Sales .................................................. 1 1.3 Different systems ........................................... 2 1.3.1 Personal computer ...................................... 2 1.3.2 Mainframe computer ..................................... 3 1.3.3 Departmental computing ................................... 4 1.3.4 Supercomputer ........................................ 4 1.4 See also ................................................ 4 1.5 References ............................................... 4 1.6 External links ............................................. 4 2 Central processing unit 5 2.1 History ................................................. 5 2.1.1 Transistor and integrated circuit CPUs ............................ 6 2.1.2 Microprocessors ....................................... 7 2.2 Operation ............................................... 8 2.2.1 Fetch ............................................. 8 2.2.2 Decode ............................................ 8 2.2.3 Execute ............................................ 9 2.3 Design and implementation ...................................... 9 2.3.1 Control unit .......................................... 9 2.3.2 Arithmetic logic unit ..................................... 9 2.3.3 Integer range ......................................... 10 2.3.4 Clock rate ........................................... 10 2.3.5 Parallelism .........................................
    [Show full text]
  • Machxo2 LPDDR SDRAM Controller IP Core User's Guide
    MachXO2™ LPDDR SDRAM Controller IP Core User’s Guide February 2014 IPUG92_01.3 Table of Contents Chapter 1. Introduction .......................................................................................................................... 4 Introduction ........................................................................................................................................................... 4 Quick Facts ........................................................................................................................................................... 4 Features ................................................................................................................................................................ 4 Chapter 2. Functional Description ........................................................................................................ 5 Overview ............................................................................................................................................................... 5 Initialization Block......................................................................................................................................... 5 Read Training Block..................................................................................................................................... 6 Data Control Block ....................................................................................................................................... 6 LPDDR I/Os ................................................................................................................................................
    [Show full text]