DOCSLIB.ORG

Keystone: an Open Framework for Architecting Trusted Execution

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Keystone: an Open Framework for Architecting Trusted Execution Keystone: An Open Framework for Architecting Trusted Execution Environments Dayeol Lee David Kohlbrenner Shweta Shinde [email protected] [email protected] [email protected] UC Berkeley UC Berkeley UC Berkeley Krste Asanović Dawn Song [email protected] [email protected] UC Berkeley UC Berkeley Abstract 1 Introduction Trusted execution environments (TEEs) see rising use in The last decade has seen the proliferation of trusted exe- devices from embedded sensors to cloud servers and en- cution environments (TEEs) to protect sensitive code and compass a range of cost, power constraints, and security data. All major CPU vendors have rolled out their TEEs threat model choices. On the other hand, each of the current (e.g., ARM TrustZone, Intel SGX, and AMD SEV) to provide vendor-specific TEEs makes a fixed set of trade-offs with a secure execution environment, commonly referred to as little room for customization. We present Keystone—the first an enclave [1, 51, 64]. TEEs have use-cases in diverse de- open-source framework for building customized TEEs. Key- ployment environments ranging from cloud servers, mobile stone uses simple abstractions provided by the hardware phones, ISPs, IoT devices, sensors, and hardware tokens. such as memory isolation and a programmable layer under- Unfortunately, each vendor TEE enables only a small por- neath untrusted components (e.g., OS). We build reusable tion of the possible design space across threat models, hard- TEE core primitives from these abstractions while allowing ware requirements, resource management, porting effort, platform-specific modifications and flexible feature choices. and feature compatibility. When a cloud provider or soft- We showcase how Keystone-based TEEs run on unmodified ware developer chooses a target hardware platform they are RISC-V hardware and demonstrate the strengths of our de- locked into the respective TEE design limitations regardless sign in terms of security, TCB size, execution of a range of of their actual application needs. Constraints breed creativity, benchmarks, applications, kernels, and deployment models. giving rise to significant research effort in working around these limits. For example, Intel SGXv1 [64] requires statically CCS Concepts: • Security and privacy ! Trusted com- sized enclaves, lacks secure I/O and syscall support, and is puting; Hardware security implementation; Software and ap- vulnerable to significant side-channels35 [ ]. Thus, to exe- plication security. cute arbitrary applications, the systems built on SGXv1 have Keywords: Trusted Execution Environment, Hardware En- inflated the Trusted Computing Base (TCB) and are forced clave, Secure Enclave, RISC-V, Memory Isolation, Side-Channel to implement complex workarounds [18, 22, 31]. As only Attack, Hardware Root of Trust, Open Source Intel can make changes to the inherent design trade-offs in SGX, users had to wait for changes like dynamic resizing of ACM Reference Format: enclave virtual memory in SGXv2 [63]. Unsurprisingly, these Dayeol Lee, David Kohlbrenner, Shweta Shinde, Krste Asanović, and other similar restriction have led to a proliferation of new and Dawn Song. 2020. Keystone: An Open Framework for Archi- TEEs on other ISAs (e.g., OpenSPARC [30], RISC-V [36, 80]). tecting Trusted Execution Environments. In Fifteenth European However, each such redesign requires considerable effort Conference on Computer Systems (EuroSys ’20), April 27–30, 2020, and only provides another fixed design point. Heraklion, Greece. ACM, New York, NY, USA, 16 pages. https://doi. We advocate that the hardware should provide security org/10.1145/3342195.3387532 primitives instead of point-wise solutions and in this paper leverage RISC-V’s primitives to construct highly customiz- Permission to make digital or hard copies of part or all of this work for able TEEs. We can draw an analogy with the move from tradi- personal or classroom use is granted without fee provided that copies are tional networking solutions to Software Defined Networking not made or distributed for profit or commercial advantage and that copies (SDN), where exposing the packet forwarding primitives to bear this notice and the full citation on the first page. Copyrights for third- party components of this work must be honored. For all other uses, contact the software has led to far more novel designs and research. the owner/author(s). Such a paradigm shift in TEEs will pave the way for low-cost EuroSys ’20, April 27–30, 2020, Heraklion, Greece use-case customization. It will allow the features and the © 2020 Copyright held by the owner/author(s). security model to be tuned for each hardware platform and ACM ISBN 978-1-4503-6882-7/20/04. https://doi.org/10.1145/3342195.3387532 EuroSys ’20, April 27–30, 2020, Heraklion, Greece D. Lee et al. use-case from a set of common software components, draw- self-paging, and more inside the enclave. For strengthening ing on ideas from modular kernel concepts [40, 60, 78]. This the security, our SM leverages any available configurable motivates the need for Customizable TEEs—an abstraction hardware to compose additional security mechanisms. We that allows entities that create the hardware, operate it, and demonstrate the potential of this with a highly configurable develop applications to configure and deploy various TEE cache controller to, in concert with PMP, transparently de- designs from the same base. Customizable TEEs promise in- fend against physical adversaries and cache side-channels. dependent exploration of gaps/trade-offs in existing designs, We built Keystone, the SM, two RTs (our native RT—Eyrie— quick prototyping of new feature requirements, a shorter and an off-the-shelf microkernel seL455 [ ]), and several mod- turn-around time for fixes, adaptation to threat models, and ules which together allow enclave-bound user applications usage-specific deployment. to selectively configure and use the above features (Figure 1). For realizing this vision, our first observation is the need We extensively benchmark Keystone on 4 suites with varying for a highly programmable trusted layer below the untrusted workloads: RV8, IOZone, CoreMark, and Beebs. We show- OS. Second, we must decouple our isolation mechanisms case use-case studies where Keystone can be used for secure from decisions of resource management, virtualization, and machine learning (Torch and FANN frameworks) and crypto- trust boundaries. We note that a hypervisor solution results graphic tasks (libsodium) on embedded devices and cloud in a trusted layer with a mix of security and virtualization re- servers. Lastly, we test Keystone on different RISC-V sys- sponsibilities, thus complicating the most critical component. tems: the HiFive Freedom Unleashed, 3 in-order cores and Similarly, firmware and micro-code are not programmable to 1 out-of-order core via FPGA, and a QEMU emulation—all a degree that satisfies our requirements. These two require- without modification. Keystone is fully open-source. ments ensure we avoid the mistake of using hardware with Contributions. We make the following contributions: a separation mechanism encumbered with a static bound- • Customizable TEEs. We define a new paradigm wherein ary between what is trusted and untrusted. Lastly, we draw the hardware manufacturer, hardware operator, and inspiration from proliferation of commercial (c.f. Intel SGX, the enclave programmer can tailor the TEE design. TrustZone) and non-commercial TEEs (c.f. Sanctum [36], • Keystone Framework. We present the first framework to Komodo [41]) which demonstrate the need for a common, configure, build, and instantiate customized TEEs. Our portable software base adaptable to ever-changing hardware principled way of ensuring modularity in Keystone capabilities and use-case demands. allows us to customize the design dimensions of TEE To this end, we propose Keystone—the first open-source instances as per the requirements. framework for building customized TEEs. We built Keystone • Open-source Implementation. We demonstrate advan- on unmodified RISC-V using its standard specifications17 [ ] tages of different Keystone TEE configurations that for physical memory protection (PMP)—a primitive which are tailored for minimizing the TCB, adapting to threat allows the programmable machine mode underneath the OS models, using hardware features, handling workloads, in RISC-V to specify arbitrary protections on physical mem- or providing rich functionality without any micro- ory regions. We use this machine mode to execute a trusted architectural changes. A typical Keystone instantiated security monitor (SM) to provide security boundaries without TEE design adds a total TCB of 12-15 K lines of code needing to perform any resource management. Critically, (LoC) to an enclave-bound application, of which the each enclave operates in its own isolated physical memory SM consists of only 1:6 KLoC added by Keystone. region and has its own supervisor-mode runtime (RT) compo- • Benchmarking & Real-world Applications. We evaluate nent to manage the virtual memory of the enclave and more. Keystone on 4 benchmarks: CoreMark, Beebs, and RV8 With this novel design, any enclave-specific functionality (< 1% overhead), and IOZone (40%). We demonstrate can be implemented cleanly by its RT while the SM manages real-world machine learning workloads with Torch in hardware-enforced guarantees. An enclave’s RT implements Eyrie (7:35%), FANN (0:36%) with seL4, and a Keystone- only the required functionality, communicates with the SM,
Load more

Recommended publications
  • Bull SAS: Novascale B260 (Intel Xeon Processor 5110,1.60Ghz)
    SPEC CINT2006 Result spec Copyright 2006-2014 Standard Performance Evaluation Corporation Bull SAS SPECint2006 = 10.2 NovaScale B260 (Intel Xeon processor 5110,1.60GHz) SPECint_base2006 = 9.84 CPU2006 license: 20 Test date: Dec-2006 Test sponsor: Bull SAS Hardware Availability: Dec-2006 Tested by: Bull SAS Software Availability: Dec-2006 0 1.00 2.00 3.00 4.00 5.00 6.00 7.00 8.00 9.00 10.0 11.0 12.0 13.0 14.0 15.0 16.0 17.0 18.0 12.7 400.perlbench 11.6 8.64 401.bzip2 8.41 6.59 403.gcc 6.38 11.9 429.mcf 12.7 12.0 445.gobmk 10.6 6.90 456.hmmer 6.72 10.8 458.sjeng 9.90 11.0 462.libquantum 10.8 17.1 464.h264ref 16.8 9.22 471.omnetpp 8.38 7.84 473.astar 7.83 12.5 483.xalancbmk 12.4 SPECint_base2006 = 9.84 SPECint2006 = 10.2 Hardware Software CPU Name: Intel Xeon 5110 Operating System: Windows Server 2003 Enterprise Edition (32 bits) CPU Characteristics: 1.60 GHz, 4MB L2, 1066MHz bus Service Pack1 CPU MHz: 1600 Compiler: Intel C++ Compiler for IA32 version 9.1 Package ID W_CC_C_9.1.033 Build no 20061103Z FPU: Integrated Microsoft Visual Studio .NET 2003 (lib & linker) CPU(s) enabled: 1 core, 1 chip, 2 cores/chip MicroQuill SmartHeap Library 8.0 (shlW32M.lib) CPU(s) orderable: 1 to 2 chips Auto Parallel: No Primary Cache: 32 KB I + 32 KB D on chip per core File System: NTFS Secondary Cache: 4 MB I+D on chip per chip System State: Default L3 Cache: None Base Pointers: 32-bit Other Cache: None Peak Pointers: 32-bit Memory: 8 GB (2GB DIMMx4, FB-DIMM PC2-5300F ECC CL5) Other Software: None Disk Subsystem: 73 GB SAS, 10000RPM Other Hardware: None
    [Show full text]
  • Comparing Filesystem Performance: Red Hat Enterprise Linux 6 Vs
    COMPARING FILE SYSTEM I/O PERFORMANCE: RED HAT ENTERPRISE LINUX 6 VS. MICROSOFT WINDOWS SERVER 2012 When choosing an operating system platform for your servers, you should know what I/O performance to expect from the operating system and file systems you select. In the Principled Technologies labs, using the IOzone file system benchmark, we compared the I/O performance of two operating systems and file system pairs, Red Hat Enterprise Linux 6 with ext4 and XFS file systems, and Microsoft Windows Server 2012 with NTFS and ReFS file systems. Our testing compared out-of-the-box configurations for each operating system, as well as tuned configurations optimized for better performance, to demonstrate how a few simple adjustments can elevate I/O performance of a file system. We found that file systems available with Red Hat Enterprise Linux 6 delivered better I/O performance than those shipped with Windows Server 2012, in both out-of- the-box and optimized configurations. With I/O performance playing such a critical role in most business applications, selecting the right file system and operating system combination is critical to help you achieve your hardware’s maximum potential. APRIL 2013 A PRINCIPLED TECHNOLOGIES TEST REPORT Commissioned by Red Hat, Inc. About file system and platform configurations While you can use IOzone to gauge disk performance, we concentrated on the file system performance of two operating systems (OSs): Red Hat Enterprise Linux 6, where we examined the ext4 and XFS file systems, and Microsoft Windows Server 2012 Datacenter Edition, where we examined NTFS and ReFS file systems.
    [Show full text]
  • Hypervisors Vs. Lightweight Virtualization: a Performance Comparison
    2015 IEEE International Conference on Cloud Engineering Hypervisors vs. Lightweight Virtualization: a Performance Comparison Roberto Morabito, Jimmy Kjällman, and Miika Komu Ericsson Research, NomadicLab Jorvas, Finland [email protected], [email protected], [email protected] Abstract — Virtualization of operating systems provides a container and alternative solutions. The idea is to quantify the common way to run different services in the cloud. Recently, the level of overhead introduced by these platforms and the lightweight virtualization technologies claim to offer superior existing gap compared to a non-virtualized environment. performance. In this paper, we present a detailed performance The remainder of this paper is structured as follows: in comparison of traditional hypervisor based virtualization and Section II, literature review and a brief description of all the new lightweight solutions. In our measurements, we use several technologies and platforms evaluated is provided. The benchmarks tools in order to understand the strengths, methodology used to realize our performance comparison is weaknesses, and anomalies introduced by these different platforms in terms of processing, storage, memory and network. introduced in Section III. The benchmark results are presented Our results show that containers achieve generally better in Section IV. Finally, some concluding remarks and future performance when compared with traditional virtual machines work are provided in Section V. and other recent solutions. Albeit containers offer clearly more dense deployment of virtual machines, the performance II. BACKGROUND AND RELATED WORK difference with other technologies is in many cases relatively small. In this section, we provide an overview of the different technologies included in the performance comparison.
    [Show full text]
  • Towards Better Performance Per Watt in Virtual Environments on Asymmetric Single-ISA Multi-Core Systems
    Towards Better Performance Per Watt in Virtual Environments on Asymmetric Single-ISA Multi-core Systems Viren Kumar Alexandra Fedorova Simon Fraser University Simon Fraser University 8888 University Dr 8888 University Dr Vancouver, Canada Vancouver, Canada [email protected] [email protected] ABSTRACT performance per watt than homogeneous multicore proces- Single-ISA heterogeneous multicore architectures promise to sors. As power consumption in data centers becomes a grow- deliver plenty of cores with varying complexity, speed and ing concern [3], deploying ASISA multicore systems is an performance in the near future. Virtualization enables mul- increasingly attractive opportunity. These systems perform tiple operating systems to run concurrently as distinct, in- at their best if application workloads are assigned to het- dependent guest domains, thereby reducing core idle time erogeneous cores in consideration of their runtime proper- and maximizing throughput. This paper seeks to identify a ties [4][13][12][18][24][21]. Therefore, understanding how to heuristic that can aid in intelligently scheduling these vir- schedule data-center workloads on ASISA systems is an im- tualized workloads to maximize performance while reducing portant problem. This paper takes the first step towards power consumption. understanding the properties of data center workloads that determine how they should be scheduled on ASISA multi- We propose that the controlling domain in a Virtual Ma- core processors. Since virtual machine technology is a de chine Monitor or hypervisor is relatively insensitive to changes facto standard for data centers, we study virtual machine in core frequency, and thus scheduling it on a slower core (VM) workloads. saves power while only slightly affecting guest domain per- formance.
    [Show full text]
  • I.MX 8Quadxplus Power and Performance
    NXP Semiconductors Document Number: AN12338 Application Note Rev. 4 , 04/2020 i.MX 8QuadXPlus Power and Performance 1. Introduction Contents This application note helps you to design power 1. Introduction ........................................................................ 1 management systems. It illustrates the current drain 2. Overview of i.MX 8QuadXPlus voltage supplies .............. 1 3. Power measurement of the i.MX 8QuadXPlus processor ... 2 measurements of the i.MX 8QuadXPlus Applications 3.1. VCC_SCU_1V8 power ........................................... 4 Processors taken on NXP Multisensory Evaluation Kit 3.2. VCC_DDRIO power ............................................... 4 (MEK) Platform through several use cases. 3.3. VCC_CPU/VCC_GPU/VCC_MAIN power ........... 5 3.4. Temperature measurements .................................... 5 This document provides details on the performance and 3.5. Hardware and software used ................................... 6 3.6. Measuring points on the MEK platform .................. 6 power consumption of the i.MX 8QuadXPlus 4. Use cases and measurement results .................................... 6 processors under a variety of low- and high-power 4.1. Low-power mode power consumption (Key States modes. or ‘KS’)…… ......................................................................... 7 4.2. Complex use case power consumption (Arm Core, The data presented in this application note is based on GPU active) ......................................................................... 11 5. SOC
    [Show full text]
  • Software Performance Engineering Using Virtual Time Program Execution
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Spiral - Imperial College Digital Repository IMPERIAL COLLEGE LONDON DEPARTMENT OF COMPUTING Software Performance Engineering using Virtual Time Program Execution Nikolaos Baltas Submitted in part fullment of the requirements for the degree of Doctor of Philosophy in Computing of Imperial College London and the Diploma of Imperial College London To my mother Dimitra for her endless support The copyright of this thesis rests with the author and is made available under a Creative Commons Attribution Non-Commercial No Derivatives licence. Re- searchers are free to copy, distribute or transmit the thesis on the condition that they attribute it, that they do not use it for commercial purposes and that they do not alter, transform or build upon it. For any reuse or redistribution, researchers must make clear to others the licence terms of this work. 4 Abstract In this thesis we introduce a novel approach to software performance engineering that is based on the execution of code in virtual time. Virtual time execution models the timing-behaviour of unmodified applications by scaling observed method times or replacing them with results acquired from performance model simulation. This facilitates the investigation of \what-if" performance predictions of applications comprising an arbitrary combination of real code and performance models. The ability to analyse code and models in a single framework enables performance testing throughout the software lifecycle, without the need to to extract perfor- mance models from code. This is accomplished by forcing thread scheduling decisions to take into account the hypothetical time-scaling or model-based performance specifications of each method.
    [Show full text]
  • Part 1 of 4 : Introduction to RISC-V ISA
    PULP PLATFORM Open Source Hardware, the way it should be! Working with RISC-V Part 1 of 4 : Introduction to RISC-V ISA Frank K. Gürkaynak <[email protected]> Luca Benini <[email protected]> http://pulp-platform.org @pulp_platform https://www.youtube.com/pulp_platform Working with RISC-V Summary ▪ Part 1 – Introduction to RISC-V ISA ▪ What is RISC-V about ▪ Description of ISA, and basic principles ▪ Simple 32b implementation (Ibex by LowRISC) ▪ How to extend the ISA (CV32E40P by OpenHW group) ▪ Part 2 – Advanced RISC-V Architectures ▪ Part 3 – PULP concepts ▪ Part 4 – PULP based chips | ACACES 2020 - July 2020 Working with RISC-V Few words about myself Frank K. Gürkaynak (just call me Frank) Senior scientist at ETH Zurich (means I am old) working with Luca Studied / Worked at Universities: in Turkey, United States and Switzerland (ETHZ and EPFL) Involved in Digital Design, Low Power Circuits, Open Source Hardware Part of PULP project from the beginning in 2013 | ACACES 2020 - July 2020 Working with RISC-V RISC-V Instruction Set Architecture ▪ Started by UC-Berkeley in 2010 SW ▪ Contract between SW and HW Applications ▪ Partitioned into user and privileged spec ▪ External Debug OS ▪ Standard governed by RISC-V foundation ▪ ETHZ is a founding member of the foundation ISA ▪ Necessary for the continuity User Privileged ▪ Defines 32, 64 and 128 bit ISA Debug ▪ No implementation, just the ISA ▪ Different implementations (both open and close source) HW ▪ At ETH Zurich we specialize in efficient implementations of RISC-V cores | ACACES 2020 - July 2020 Working with RISC-V RISC-V maintains basically a PDF document | ACACES 2020 - July 2020 Working with RISC-V ISA defines the instructions that processor uses C++ program translated to RISC-V instructions defined by ISA.
    [Show full text]
  • Connectcore® 8X Performance and Power Benchmarking Report
    ConnectCore® 8X Performance and Power Benchmarking Report Application Note Revision history—90002448 Revision Date Description A March 2021 Initial release. Trademarks and copyright Digi, Digi International, and the Digi logo are trademarks or registered trademarks in the United States and other countries worldwide. All other trademarks mentioned in this document are the property of their respective owners. © 2021 Digi International Inc. All rights reserved. Disclaimers Information in this document is subject to change without notice and does not represent a commitment on the part of Digi International. Digi provides this document “as is,” without warranty of any kind, expressed or implied, including, but not limited to, the implied warranties of fitness or merchantability for a particular purpose. Digi may make improvements and/or changes in this manual or in the product(s) and/or the program(s) described in this manual at any time. Feedback To provide feedback on this document, email your comments to [email protected] Include the document title and part number (ConnectCore® 8X Performance and Power, 90002448 A) in the subject line of your email. ConnectCore® 8X Performance and Power 2 Contents Introduction Power architecture Measurement conditions Hardware used 7 Software used 7 Digi Embedded Yocto 7 MCA firmware 7 Benchmark packages 8 Host requirements 8 General conditions 8 Location and environment 8 Instrumentation 9 SOM power measurements 9 How to calculate SOM power 9 Resistor swap 9 Console cable 9 Measure points 10 Formula 10
    [Show full text]
  • PIC Licensing Information User Manual
    Oracle® Communications Performance Intelligence Center Licensing Information User Manual Release 10.1 E56971 Revision 3 April 2015 Oracle Communications Performance Intelligence Center Licensing Information User Manual, Release 10.1 Copyright © 2003, 2015 Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notices are applicable: U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.
    [Show full text]
  • Fair Benchmarking for Cloud Computing Systems
    Fair Benchmarking for Cloud Computing Systems Authors: Lee Gillam Bin Li John O’Loughlin Anuz Pranap Singh Tomar March 2012 Contents 1 Introduction .............................................................................................................................................................. 3 2 Background .............................................................................................................................................................. 4 3 Previous work ........................................................................................................................................................... 5 3.1 Literature ........................................................................................................................................................... 5 3.2 Related Resources ............................................................................................................................................. 6 4 Preparation ............................................................................................................................................................... 9 4.1 Cloud Providers................................................................................................................................................. 9 4.2 Cloud APIs ...................................................................................................................................................... 10 4.3 Benchmark selection ......................................................................................................................................
    [Show full text]
  • Mqsim: a Framework for Enabling Realistic Studies of Modern Multi-Queue SSD Devices
    MQSim: A Framework for Enabling Realistic Studies of Modern Multi-Queue SSD Devices Arash Tavakkol, Juan Gómez-Luna, and Mohammad Sadrosadati, ETH Zürich; Saugata Ghose, Carnegie Mellon University; Onur Mutlu, ETH Zürich and Carnegie Mellon University https://www.usenix.org/conference/fast18/presentation/tavakkol This paper is included in the Proceedings of the 16th USENIX Conference on File and Storage Technologies. February 12–15, 2018 • Oakland, CA, USA ISBN 978-1-931971-42-3 Open access to the Proceedings of the 16th USENIX Conference on File and Storage Technologies is sponsored by USENIX. MQSim: A Framework for Enabling Realistic Studies of Modern Multi-Queue SSD Devices Arash Tavakkol†, Juan Gomez-Luna´ †, Mohammad Sadrosadati†, Saugata Ghose‡, Onur Mutlu†‡ †ETH Zurich¨ ‡Carnegie Mellon University Abstract sponse time, and decreasing cost, SSDs have replaced traditional magnetic hard disk drives (HDDs) in many Solid-state drives (SSDs) are used in a wide array of datacenters and enterprise servers, as well as in consumer computer systems today, including in datacenters and en- devices. As the I/O demand of both enterprise and con- terprise servers. As the I/O demands of these systems sumer applications continues to grow, SSD architectures continue to increase, manufacturers are evolving SSD ar- are rapidly evolving to deliver improved performance. chitectures to keep up with this demand. For example, manufacturers have introduced new high-bandwidth in- For example, a major innovation has been the intro- terfaces to replace the conventional SATA host–interface duction of new host interfaces to the SSD. In the past, protocol. These new interfaces, such as the NVMe proto- many SSDs made use of the Serial Advanced Technology col, are designed specifically to enable the high amounts Attachment (SATA) protocol [67], which was originally of concurrent I/O bandwidth that SSDs are capable of designed for HDDs.
    [Show full text]
  • BOOM): an Industry- Competitive, Synthesizable, Parameterized RISC-V Processor
    The Berkeley Out-of-Order Machine (BOOM): An Industry- Competitive, Synthesizable, Parameterized RISC-V Processor Christopher Celio David A. Patterson Krste Asanović Electrical Engineering and Computer Sciences University of California at Berkeley Technical Report No. UCB/EECS-2015-167 http://www.eecs.berkeley.edu/Pubs/TechRpts/2015/EECS-2015-167.html June 13, 2015 Copyright © 2015, by the author(s). All rights reserved. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission. The Berkeley Out-of-Order Machine (BOOM): An Industry-Competitive, Synthesizable, Parameterized RISC-V Processor Christopher Celio, David Patterson, and Krste Asanovic´ University of California, Berkeley, California 94720–1770 [email protected] BOOM is a work-in-progress. Results shown are prelimi- nary and subject to change as of 2015 June. I$ L1 D$ (32k) L2 data 1. The Berkeley Out-of-Order Machine BOOM is a synthesizable, parameterized, superscalar out- exe of-order RISC-V core designed to serve as the prototypical baseline processor for future micro-architectural studies of uncore regfile out-of-order processors. Our goal is to provide a readable, issue open-source implementation for use in education, research, exe and industry. uncore BOOM is written in roughly 9,000 lines of the hardware L2 data (256k) construction language Chisel.
    [Show full text]