DOCSLIB.ORG

SPECS: a Lightweight Runtime Mechanism for Protecting Software from Security-Critical Processor Bugs

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
SPECS: a Lightweight Runtime Mechanism for Protecting Software from Security-Critical Processor Bugs SPECS: A Lightweight Runtime Mechanism for Protecting Software from Security-Critical Processor Bugs Matthew Hicks Cynthia Sturton Samuel T. King Jonathan M. Smith University of Michigan University of North Twitter, Inc. University of Pennsylvania [email protected] Carolina at Chapel Hill [email protected] [email protected] [email protected] Abstract Catch All Catch Security- Low Processor implementation errata remain a problem, and Bugs? Critical Bugs? Overhead? worse, a subset of these bugs are security-critical. We classi- SW-only 7 7 3 fied 7 years of errata from recent commercial processors to HW-only 3 3 7 understand the magnitude and severity of this problem, and SPECS 7 3 3 found that of 301 errata analyzed, 28 are security-critical. SPECS+SW 3 3 3 We propose the SECURITY-CRITICAL PROCESSOR ER- RATA CATCHING SYSTEM (SPECS) as a low-overhead so- Table 1: The design space for catching processor bugs: existing software- lution to this problem. SPECS employs a dynamic verifi- only approaches are limited, but practical; existing hardware-only ap- proaches are powerful, but impractical; and SPECS, combined with ex- cation strategy that is made lightweight by limiting protec- isting software approaches, is both powerful and practical. tion to only security-critical processor state. As a proof-of- concept, we implement a hardware prototype of SPECS in an open source processor. Using this prototype, we evalu- ate SPECS against a set of 14 bugs inspired by the types hardware typically ships with bugs. For example, the errata of security-critical errata we discovered in the classification document for Intel’s Core 2 Duo processor family [20] lists phase. The evaluation shows that SPECS is 86% effective as 129 known bugs. a defense when deployed using only ISA-level state; incurs Some processor bugs have the potential to weaken the se- less than 5% area and power overhead; and has no software curity of software by allowing unprivileged code to modify run-time overhead. or control privileged processor state. We deem these bugs se- curity critical (we do not claim that this set is unique). While Categories and Subject Descriptors C.0 [General]: Hard- some effects of bugs are detectable by software through pe- ware/software interfaces; C.0 [General]: System architec- riodic checks [8, 27] or special encodings [6, 40], other tures; K.6.5 [Security and Protection]: Invasive software processor bugs affect software in a manner that software (e.g., viruses, worms, Trojan horses) cannot detect practically. Such bugs are security-critical be- Keywords Processor errata; hardware security exploits; cause they affect a critical subset of processor functionality security-critical processor errata trusted by the software tasked with detecting and recovering from imperfections. One example of a security-critical bug 1. Introduction is a design flaw in the MIPS R4000 processor that allows user-mode code to control the location of an exception vec- Modern processors are imperfect. Processors are built from tor [26]. The effect of this bug is user-mode code that runs at millions of lines of code [42], yielding chips with billions the supervisor level—privilege escalation. of transistors [22]. Verifying the functional correctness of These types of flaws compromise otherwise correct hardware at such scales remains intractable. The resulting software—especially software that implements security gaps in functional verification mean that today’s production policies. There are many documented examples [4,5, 29– 32] of the impact security-critical bugs have on software. Software-only patching approaches have been explored Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed (e.g., microcode [16, 43], re-compilation [28], and binary for profit or commercial advantage and that copies bear this notice and the full citation translation [35]), but are not able to address all processor on the first page. Copyrights for third-party components of this work must be honored. For all other uses, contact the owner/author(s). bugs [33]. Further, many of the existing patching mecha- ASPLOS ’15, March 14–18, 2015, Istanbul, Turkey. nisms incur large performance penalties [38, 39], mainly Copyright is held by the owner/author(s). ACM 978-1-4503-2835-7/15/03. due to the coarse granularity and heavyweight nature of their http://dx.doi.org/10.1145/2694344.2694366 consistency checks. Recovery AMD Sub Software Synopsis Class Repair ID# class 418 Incorrect translation tables used A6Icretpage walks MA561Incorrect ISA state 731 Using large pages causes incorrect IO address trans- lations ISA state 77 Using unaligned descriptor table allows software to XR ISA ISA state state Assertions jump past the end of the table without causing an exception Assertions Exception 170 May use instructions from old page tables pointed to (a) (b) (c) (d) by old CR3 EI design time run time 578 Branch prediction causes invalid control flow 639 CALL instruction treated as a NOP 776 Branch prediction causes invalid control flow Figure 1: Processor design flow with SPECS: (a) Hardware description 144 Shadow RAM not invalidated language implementation of the instruction set (b) At some point during de- IR 784 Control register data leaked through load operation sign, a bug is introduced. (c) Assertions that implement SPECS invariants are added to the processor, with taps directly on the outputs of ISA state 165 Guest can clear data in VMCB storage elements. (d) To squash in-flight state, SPECS adds write gating to 503 Writes to APIC task priority register use the wrong the inputs of ISA state storing elements and attaches the result of dynamic register IU IL verification to the exception logic, which triggers existing recovery/repair 573 Instruction pointer updated incorrectly software in the event of an invariant violation. 734 Incorrect data stored to and past VMCB 770 Privilege escalation 171 Execute breakpoint handler with mixed guest and host state Alternatively, hardware-based bug defenses can address 248 TLB pages not invalidated all processor bugs using checks on every cycle, but this com- 342 Interrupts disabled for guest prehensiveness comes at a prohibitive cost in terms of hard- 385 Incorrect error address reported ware area and power. One example illustrating the tradeoffs 401 Hypervisor doesn’t get correct IP 440 CR3 not saved correctly IU IX of hardware patching mechanisms is Diva [1]. Diva relies on 563 Flags not stored correctly in VMCB modular redundancy; a second formally-verified but lower- 564 Auto halt flag not set in SMM save state performance processor core checks the calculations of the 659 VMCB flag bit not cleared buggy, high-performance core. Diva can protect against all 691 Cache not invalidated correctly 704 Incorrect IP stored processor bugs, but is complex (potentially creating new pro- 738 Incorrect SP stored in VMCB cessor bugs) and has a high hardware cost. A second ex- 744 A CC6 transition may not restore trap registers ample is Phoenix [37], which detects potentially inconsis- tent processor state by comparing the hardware-level state of Table 2: Security-critical errata mined from AMD processors manufactured between 2006 and 2013. The security-critical errata fit into five classes: MA the processor to known buggy state values; Phoenix requires (arbitrary memory access), XR (exception related), EI (execute incorrect more hardware than Diva and cannot respond to unknown instruction), IR (incorrect results), and IU (invalid register update). Further, bugs. there are two types of IU: IL (illegal) and IX (incorrect). Rather than incur the costs of protecting software from all processor bugs, we propose a hybrid approach, shown in We make three contributions in this paper: Table1: SPECS adds a small amount of additional hard- • We identify and classify security-critical errata from re- ware to the processor that dynamically verifies a subset cent commercial processors and discover that these bugs of processor functionality. The goal is to protect software involve invalid updates to privileged ISA-level state, from security-critical processor bugs, especially those that which is updated in a few simple ways (Section2). it cannot protect itself from efficiently. SPECS works by enforcing instruction-set-specification-derived invariants on • We introduce a lightweight dynamic-verification strategy security-critical processor state dynamically. The invariants against security-critical processor bugs, providing an in- are enforced by a series of simple assertions in hardware trospection point whenever security-critical state is up- (Figure1(c)). The assertions analyze ISA-level state and dated outside the specification (Section3). events to validate in-flight (i.e., not yet visible at the soft- • We implement (Section4) and evaluate (Section5) ware level) ISA-level state updates. If in-flight state vio- SPECS, showing that it is possible to protect software lates a SPECS invariant, a combination of assertions fire from a range of realistic security-critical processor bugs. that then triggers an exception that squashes the inconsistent The evaluation shows that SPECS: (1) is able to detect in-flight state (Figure1(d)). From here, existing software re- 86% of the implemented processor bugs using only ISA- covery/repair mechanisms take over—while SPECS contin- level state; (2) requires less than 5% additional hardware; ues to work in the background. Essentially, SPECS acts as and (3) has no software run-time overhead. 1 an interposition layer for a range of existing processor repair and recovery approaches that allows software to execute past 1 We make the errata used for our analysis and our hardware and software security-critical bugs safely. source code available publicly [19]. 2. Security-Critical Errata 100 % XR - Exception Related 90 % IR - Incorrect Results Existing work on processor bugs as security vulnerabilities MA - Memory Access EI - Incorrect Instruction takes the approach of finding a single processor bug and 80 % IU - Register Related realizing a usable software-level attack with that bug as a 70 % foothold [3, 11, 12, 23].
Load more

Recommended publications
  • A Superscalar Out-Of-Order X86 Soft Processor for FPGA
    A Superscalar Out-of-Order x86 Soft Processor for FPGA Henry Wong University of Toronto, Intel [email protected] June 5, 2019 Stanford University EE380 1 Hi! ● CPU architect, Intel Hillsboro ● Ph.D., University of Toronto ● Today: x86 OoO processor for FPGA (Ph.D. work) – Motivation – High-level design and results – Microarchitecture details and some circuits 2 FPGA: Field-Programmable Gate Array ● Is a digital circuit (logic gates and wires) ● Is field-programmable (at power-on, not in the fab) ● Pre-fab everything you’ll ever need – 20x area, 20x delay cost – Circuit building blocks are somewhat bigger than logic gates 6-LUT6-LUT 6-LUT6-LUT 3 6-LUT 6-LUT FPGA: Field-Programmable Gate Array ● Is a digital circuit (logic gates and wires) ● Is field-programmable (at power-on, not in the fab) ● Pre-fab everything you’ll ever need – 20x area, 20x delay cost – Circuit building blocks are somewhat bigger than logic gates 6-LUT 6-LUT 6-LUT 6-LUT 4 6-LUT 6-LUT FPGA Soft Processors ● FPGA systems often have software components – Often running on a soft processor ● Need more performance? – Parallel code and hardware accelerators need effort – Less effort if soft processors got faster 5 FPGA Soft Processors ● FPGA systems often have software components – Often running on a soft processor ● Need more performance? – Parallel code and hardware accelerators need effort – Less effort if soft processors got faster 6 FPGA Soft Processors ● FPGA systems often have software components – Often running on a soft processor ● Need more performance? – Parallel
    [Show full text]
  • Implementation, Verification and Validation of an Openrisc-1200
    (IJACSA) International Journal of Advanced Computer Science and Applications, Vol. 10, No. 1, 2019 Implementation, Verification and Validation of an OpenRISC-1200 Soft-core Processor on FPGA Abdul Rafay Khatri Department of Electronic Engineering, QUEST, NawabShah, Pakistan Abstract—An embedded system is a dedicated computer system in which hardware and software are combined to per- form some specific tasks. Recent advancements in the Field Programmable Gate Array (FPGA) technology make it possible to implement the complete embedded system on a single FPGA chip. The fundamental component of an embedded system is a microprocessor. Soft-core processors are written in hardware description languages and functionally equivalent to an ordinary microprocessor. These soft-core processors are synthesized and implemented on the FPGA devices. In this paper, the OpenRISC 1200 processor is used, which is a 32-bit soft-core processor and Fig. 1. General block diagram of embedded systems. written in the Verilog HDL. Xilinx ISE tools perform synthesis, design implementation and configure/program the FPGA. For verification and debugging purpose, a software toolchain from (RISC) processor. This processor consists of all necessary GNU is configured and installed. The software is written in C components which are available in any other microproces- and Assembly languages. The communication between the host computer and FPGA board is carried out through the serial RS- sor. These components are connected through a bus called 232 port. Wishbone bus. In this work, the OR1200 processor is used to implement the system on a chip technology on a Virtex-5 Keywords—FPGA Design; HDLs; Hw-Sw Co-design; Open- FPGA board from Xilinx.
    [Show full text]
  • Softcores for FPGA: the Free and Open Source Alternatives
    Softcores for FPGA: The Free and Open Source Alternatives Jeremy Bennett and Simon Cook, Embecosm Abstract Open source soft cores have reached a degree of maturity. You can find them in products as diverse as a Samsung set-top box, NXP's ZigBee chips and NASA's TechEdSat. In this article we'll look at some of the more widely used: the OpenRISC 1000 from OpenCores, Gaisler's LEON family, Lattice Semiconductor's LM32 and Oracle's OpenSPARC, as well as more bleeding edge research designs such as BERI and CHERI from Cambridge University Computer Laboratory. We'll consider the technology, the business case, the engineering risks, and the licensing challenges of using such designs. What do we mean by “free” “Free” is an overloaded term in English. It can mean something you don't pay for, as in “this beer is free”. But it can also mean freedom, as in “you are free to share this article”. It is this latter sense that is central when we talk about free software or hardware designs. Of course such software or hardware designs may also be free, in the sense that you don't have to pay for them, but that is secondary. “Free” software in this sense has been around for a very long time. Explicitly since 1993 and Richard Stallman's GNU Manifesto, but implicitly since the first software was written and shared with colleagues and friends. That freedom is achieved by making the source code available, so others can modify the program, hence the more recent alternative name “open source”, but it is freedom that remains the key concept.
    [Show full text]
  • Openpiton: an Open Source Manycore Research Framework
    OpenPiton: An Open Source Manycore Research Framework Jonathan Balkind Michael McKeown Yaosheng Fu Tri Nguyen Yanqi Zhou Alexey Lavrov Mohammad Shahrad Adi Fuchs Samuel Payne ∗ Xiaohua Liang Matthew Matl David Wentzlaff Princeton University fjbalkind,mmckeown,yfu,trin,yanqiz,alavrov,mshahrad,[email protected], [email protected], fxiaohua,mmatl,[email protected] Abstract chipset Industry is building larger, more complex, manycore proces- sors on the back of strong institutional knowledge, but aca- demic projects face difficulties in replicating that scale. To Tile alleviate these difficulties and to develop and share knowl- edge, the community needs open architecture frameworks for simulation, synthesis, and software exploration which Chip support extensibility, scalability, and configurability, along- side an established base of verification tools and supported software. In this paper we present OpenPiton, an open source framework for building scalable architecture research proto- types from 1 core to 500 million cores. OpenPiton is the world’s first open source, general-purpose, multithreaded manycore processor and framework. OpenPiton leverages the industry hardened OpenSPARC T1 core with modifica- Figure 1: OpenPiton Architecture. Multiple manycore chips tions and builds upon it with a scratch-built, scalable uncore are connected together with chipset logic and networks to creating a flexible, modern manycore design. In addition, build large scalable manycore systems. OpenPiton’s cache OpenPiton provides synthesis and backend scripts for ASIC coherence protocol extends off chip. and FPGA to enable other researchers to bring their designs to implementation. OpenPiton provides a complete verifica- tion infrastructure of over 8000 tests, is supported by mature software tools, runs full-stack multiuser Debian Linux, and has been widespread across the industry with manycore pro- is written in industry standard Verilog.
    [Show full text]
  • Small Soft Core up Inventory ©2019 James Brakefield Opencore and Other Soft Core Processors Reverse-U16 A.T
    tool pip _uP_all_soft opencores or style / data inst repor com LUTs blk F tool MIPS clks/ KIPS ven src #src fltg max max byte adr # start last secondary web status author FPGA top file chai e note worthy comments doc SOC date LUT? # inst # folder prmary link clone size size ter ents ALUT mults ram max ver /inst inst /LUT dor code files pt Hav'd dat inst adrs mod reg year revis link n len Small soft core uP Inventory ©2019 James Brakefield Opencore and other soft core processors reverse-u16 https://github.com/programmerby/ReVerSE-U16stable A.T. Z80 8 8 cylcone-4 James Brakefield11224 4 60 ## 14.7 0.33 4.0 X Y vhdl 29 zxpoly Y yes N N 64K 64K Y 2015 SOC project using T80, HDMI generatorretro Z80 based on T80 by Daniel Wallner copyblaze https://opencores.org/project,copyblazestable Abdallah ElIbrahimi picoBlaze 8 18 kintex-7-3 James Brakefieldmissing block622 ROM6 217 ## 14.7 0.33 2.0 57.5 IX vhdl 16 cp_copyblazeY asm N 256 2K Y 2011 2016 wishbone extras sap https://opencores.org/project,sapstable Ahmed Shahein accum 8 8 kintex-7-3 James Brakefieldno LUT RAM48 or block6 RAM 200 ## 14.7 0.10 4.0 104.2 X vhdl 15 mp_struct N 16 16 Y 5 2012 2017 https://shirishkoirala.blogspot.com/2017/01/sap-1simple-as-possible-1-computer.htmlSimple as Possible Computer from Malvinohttps://www.youtube.com/watch?v=prpyEFxZCMw & Brown "Digital computer electronics" blue https://opencores.org/project,bluestable Al Williams accum 16 16 spartan-3-5 James Brakefieldremoved clock1025 constraint4 63 ## 14.7 0.67 1.0 41.1 X verilog 16 topbox web N 4K 4K N 16 2 2009
    [Show full text]
  • Design of the RISC-V Instruction Set Architecture
    Design of the RISC-V Instruction Set Architecture Andrew Waterman Electrical Engineering and Computer Sciences University of California at Berkeley Technical Report No. UCB/EECS-2016-1 http://www.eecs.berkeley.edu/Pubs/TechRpts/2016/EECS-2016-1.html January 3, 2016 Copyright © 2016, 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. Design of the RISC-V Instruction Set Architecture by Andrew Shell Waterman A dissertation submitted in partial satisfaction of the requirements for the degree of Doctor of Philosophy in Computer Science in the Graduate Division of the University of California, Berkeley Committee in charge: Professor David Patterson, Chair Professor Krste Asanovi´c Associate Professor Per-Olof Persson Spring 2016 Design of the RISC-V Instruction Set Architecture Copyright 2016 by Andrew Shell Waterman 1 Abstract Design of the RISC-V Instruction Set Architecture by Andrew Shell Waterman Doctor of Philosophy in Computer Science University of California, Berkeley Professor David Patterson, Chair The hardware-software interface, embodied in the instruction set architecture (ISA), is arguably the most important interface in a computer system. Yet, in contrast to nearly all other interfaces in a modern computer system, all commercially popular ISAs are proprietary.
    [Show full text]
  • Evaluation of Synthesizable CPU Cores
    Evaluation of synthesizable CPU cores DANIEL MATTSSON MARCUS CHRISTENSSON Maste r ' s Thesis Com p u t e r Science an d Eng i n ee r i n g Pro g r a m CHALMERS UNIVERSITY OF TECHNOLOGY Depart men t of Computer Engineering Gothe n bu r g 20 0 4 All rights reserved. This publication is protected by law in accordance with “Lagen om Upphovsrätt, 1960:729”. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the authors. Daniel Mattsson and Marcus Christensson, Gothenburg 2004. Evaluation of synthesizable CPU cores Abstract The three synthesizable processors: LEON2 from Gaisler Research, MicroBlaze from Xilinx, and OpenRISC 1200 from OpenCores are evaluated and discussed. Performance in terms of benchmark results and area resource usage is measured. Different aspects like usability and configurability are also reviewed. Three configurations for each of the processors are defined and evaluated: the comparable configuration, the performance optimized configuration and the area optimized configuration. For each of the configurations three benchmarks are executed: the Dhrystone 2.1 benchmark, the Stanford benchmark suite and a typical control application run as a benchmark. A detailed analysis of the three processors and their development tools is presented. The three benchmarks are described and motivated. Conclusions and results in terms of benchmark results, performance per clock cycle and performance per area unit are discussed and presented. Sammanfattning De tre syntetiserbara processorerna: LEON2 från Gaisler Research, MicroBlaze från Xilinx och OpenRISC 1200 från OpenCores utvärderas och diskuteras.
    [Show full text]
  • Small Soft Core up Inventory ©2014 James Brakefield Opencore and Other Soft Core Processors Only Cores in the "Usable" Category Included
    Small soft core uP Inventory ©2014 James Brakefield Opencore and other soft core processors Only cores in the "usable" category included Most Prolific Authors ©2014 James Brakefield John Kent micro8a, micro16b, system05, system09, system11, system68 6 Daniel Wallner ax8, ppx16, t65, t80 4 Ulrich Riedel 68hc05, 68hc08, tiny64, tiny8 4 Jose Ruiz ion, light52, light8080 3 Lazaridis Dimitris mips_fault_tolerant, mipsr2000, mips_enhanced 3 Shawn Tan ae18, aeMB, k68 3 Most FPGA results (e.g. easy to compile, place & route on any FPGA family) ©2014 James Brakefield eco32 cyclone-4, arria-2, spartan-3, spartan-6, kintex-7 5 navre cyclone-4, arria-2, cyclone-5, spartan-6, kintex-7 5 leros cyclone-4, spartan-3, spartan-6, kintex-7 4 openmsp430 cyclone-4, stratix-3, spartan-6, virtex-6 4 Most Clones ©2014 James Brakefield ion, minimips, mips_fault_tolerant, misp32r1, misp789, mipsr2000, plasma, ucore, yacc, MIPS 10 m1_core 6502 ag_6502, cpu6502_true_cycle, free6502, lattice6502, m65c02, t65, t6507lp, m65 8 PIC16 free_risc8, lwrisc, minirisc, p16c5x, ppx16, recore54, risc16f84, risc5x 8 microblaze aeMB, mblite, microblaze, myblaze, openfire_core, secretblaze 6 6800 hd63701, system68, system05, 68hc05, 68hc08 5 8051 dalton_8051, light52, mc8051, t51, turbo8051 5 avr avr_core, avr_hp, avr8, navre, riscmcu 5 z80 nextz80, t80, tv80, wb_z80, y80e 5 openrisc altor32, minsoc, or1k, or1200_hp 4 6809 6809_6309, system09, mc6809e 3 8080 cpu8080, light8080, t80 3 68000 ao68000, tg68, v1_coldfire 3 PDP-8 pdp8, pdp8l, pdp8verilog 3 picoblaze copyblaze, pacoblaze,
    [Show full text]
  • Open-Source 32-Bit RISC Soft-Core Processors
    IOSR Journal of VLSI and Signal Processing (IOSR-JVSP) Volume 2, Issue 4 (May. – Jun. 2013), PP 43-46 e-ISSN: 2319 – 4200, p-ISSN No. : 2319 – 4197 www.iosrjournals.org Open-Source 32-Bit RISC Soft-Core Processors Rahul R.Balwaik, Shailja R.Nayak, Prof. Amutha Jeyakumar Department of Electrical Engineering, VJTI, Mumbai-19, INDIA Abstract: A soft-core processor build using a Field-Programmable Gate Array (FPGA)’s general-purpose logic represents an embedded processor commonly used for implementation. In a large number of applications; soft-core processors play a vital role due to their ease of usage. Soft-core processors are more advantageous than their hard-core counterparts due to their reduced cost, flexibility, platform independence and greater immunity to obsolescence. This paper presents a survey of a considerable number of soft core processors available from the open-source communities. Some real world applications of these soft-core processors are also discussed followed by the comparison of their several features and characteristics. The increasing popularity of these soft-core processors will inevitably lead to more widespread usage in embedded system design. This is due to the number of significant advantages that soft-core processors hold over their hard-core counterparts. Keywords: Field-Programmable Gate Array (FPGA), Application-Specific Integrated Circuit (ASIC), open- source, soft-core processors. I. INTRODUCTION Field-Programmable Gate Array (FPGA) has grown in capacity and performance, and is now one of the main implementation fabrics for designs, particularly where the products do not demand for custom integrated circuits. And in recent past due to the increased capacity and falling cost of the FPGA’s relatively fast and high density devices are today becoming available to the general public.
    [Show full text]
  • Porting Debian to the RISC-V Architecture Tales from a Long Quest
    Porting Debian to the RISC-V architecture Tales from a long quest. Karsten Merker <[email protected]> February 2, 2019 These slides are licensed under the Creative Commons \CC-BY-4.0" license. 1 What is RISC-V? • RISC-V is a freely licensed CPU Instruction Set Architecture (ISA) originating from the University of California, Berkeley (UCB). • Everybody is free to implement processors based on the RISC-V ISA without royalty payments for using the ISA. • The ISA specification is available under CC-BY license. • Conformance to the specification is secured via trademarks. Only implementations that fully conform to the specification may call themselves \RISC-V". • Available in 32bit, 64bit and (not yet fully specified) 128bit flavours • Designed to scale from microcontrollers to supercomputers by using a modular design. • The ISA design aims at using only techniques that are patent-free, although there is no legal guarantee for that. 2 What is RISC-V not? RISC-V • is not a microprocessor implementation. • doesn't require implementations to be freely licensed, i.e. there can be (and are) non-free RISC-V implementations. • doesn't have an open stewardship in the way open-source projects define \open", only in the way the semiconductor industry defines \open": • The specifications are released under a DFSG-free license (CC-BY), but contributing to standard working groups and access to pre-release documents requires a RISC-V foundation membership. • The RISC-V foundation is a US 501(c)(6) non-profit (i.e. an industry consortium), not a US 501(c)(3) non-profit (i.e.
    [Show full text]
  • The RISC-V Instruction Set Manual Volume I: User-Level ISA Document Version 2.2
    The RISC-V Instruction Set Manual Volume I: User-Level ISA Document Version 2.2 Editors: Andrew Waterman1, Krste Asanovi´c1;2 1SiFive Inc., 2CS Division, EECS Department, University of California, Berkeley [email protected], [email protected] May 7, 2017 Contributors to all versions of the spec in alphabetical order (please contact editors to suggest corrections): Krste Asanovi´c,Rimas Aviˇzienis,Jacob Bachmeyer, Christopher F. Batten, Allen J. Baum, Alex Bradbury, Scott Beamer, Preston Briggs, Christopher Celio, David Chisnall, Paul Clayton, Palmer Dabbelt, Stefan Freudenberger, Jan Gray, Michael Hamburg, John Hauser, David Horner, Olof Johansson, Ben Keller, Yunsup Lee, Joseph Myers, Rishiyur Nikhil, Stefan O'Rear, Albert Ou, John Ousterhout, David Patterson, Colin Schmidt, Michael Taylor, Wesley Terpstra, Matt Thomas, Tommy Thorn, Ray VanDeWalker, Megan Wachs, Andrew Waterman, Robert Wat- son, and Reinoud Zandijk. This document is released under a Creative Commons Attribution 4.0 International License. This document is a derivative of \The RISC-V Instruction Set Manual, Volume I: User-Level ISA Version 2.1" released under the following license: c 2010{2017 Andrew Waterman, Yunsup Lee, David Patterson, Krste Asanovi´c. Creative Commons Attribution 4.0 International License. Please cite as: \The RISC-V Instruction Set Manual, Volume I: User-Level ISA, Document Version 2.2", Editors Andrew Waterman and Krste Asanovi´c,RISC-V Foundation, May 2017. Preface This is version 2.2 of the document describing the RISC-V user-level architecture. The document contains the following versions of the RISC-V ISA modules: Base Version Frozen? RV32I 2.0 Y RV32E 1.9 N RV64I 2.0 Y RV128I 1.7 N Extension Version Frozen? M 2.0 Y A 2.0 Y F 2.0 Y D 2.0 Y Q 2.0 Y L 0.0 N C 2.0 Y B 0.0 N J 0.0 N T 0.0 N P 0.1 N V 0.2 N N 1.1 N To date, no parts of the standard have been officially ratified by the RISC-V Foundation, but the components labeled \frozen" above are not expected to change during the ratification process beyond resolving ambiguities and holes in the specification.
    [Show full text]
  • Basic Custom Openrisc System Hardware Tutorial
    DE NAYER Instituut J. De Nayerlaan 5 B-2860 Sint-Katelijne-Waver Tel. (015) 31 69 44 Fax. (015) 31 74 53 e-mail: [email protected] [email protected] [email protected] website: emsys.denayer.wenk.be Basic Custom OpenRISC System Hardware Tutorial Xilinx Version 1.00 HOBU-Fund Project IWT 020079 Title : Embedded systemdesign based upon Soft- and Hardcore FPGA’s Projectleader : Ing. Patrick Pelgrims Projectassistants : Ing. Dries Driessens Ing. Tom Tierens Copyright (c) 2004 by Patrick Pelgrims, Tom Tierens and Dries Driessens. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). I Introduction Purpose of this tutorial is to help you compose and implement a custom, OpenRISC based, embedded system in the easiest way possible. Unexperienced users should be warned that the OpenRISC processor is quite a difficult processor : the lack of a self-configuring embedded system-package and the more ‘open’ nature of the OpenRISC compared to other open-source processors like the Leon SPARC is one of the reasons for this. Before proceeding, check if you have the following software and hardware: Hardware: - Linux-PC or Windows-PC - Development board with Xilinx FPGA (minimum 3100 Slices), UART and 6 available pins. Software: - OpenRISC-GNU Toolchain - Xilinx ISE Webpack or ISE for Windows or Linux - For Windows : WinCVS 1.2 (http://prdownloads.sourceforge.net/cvsgui/WinCvs120.zip) If you experience problems building the OpenRISC-GNU Toolchain, there is also an OpenRISC Software tutorial available from our website (http://emsys.denayer.wenk.be).
    [Show full text]